Overall size calculation and limit of an email message job

api_support

It is my understanding that there is a limit to the overall size of an email message job. If that limit is exceeded, the job is successfully accepted by the EasyLink server, but some recipients may not receive the email message at all. Is this correct? If so, what is the overall size-limit of an email message job?

 

I want to make sure that we code our software to avoid problems with email messages not being delivered because of job size limitations. Therefore, if there really is a size limit, we will either need to limit the number of recipients or size of attachments before the message is sent OR split up the message into multiple jobs (with a different set of recipients in each job) so that each individual job does not exceed the size limit. Assuming that there is a size limit, how do you accurately calculate the size of a particular job? I'm thinking that you have to take into account the size of the email body parts (plain text and HTML), the size of email attachments, and the number of email recipients. Are there other things that need to be considered?

 

For example, if the plain text part of the email is 5KB, the HTML part of the email is 20KB, there is one email attachment with a size of 100KB, and there are 1000 email recipients, then I'm thinking that the overall size of the job is calculated as follows:

 

Size = (5KB + 20KB + 100KB) * 1000 = 12.5MB

 

Is this correct? Is this information provided in the developer/API documentation? If so, what are the documentation URL and the section/page reference?

api_support

You are correct that the system limits the "size" of outbound email messages. The parameters involved in those limits are:

 

• Total Number of Recipients

• Size of an individual delivery

• Total Size of the Entire Delivery (number of recipients * size of individual message)

 

The purpose of having these limits is to catch possible spam emails, and also to avoid having one user's traffic (either deliberately or accidentally) have a negative impact on other users' traffic on the system.

 

When the system detects that a jobs has exceeded one or more of these values, an item is placed on the operators' queue for review (it says something like "this job is too big - do you want to let it go anyway?"). The operations team can then choose to release the job when it is deemed not to be detrimental to the system or cancel it. So bumping up against the limits is not necessarily fatal.

 

These parameters are controlled through entries in the user profile. Rather than having to split up your jobs (which defeats the purpose of the safeguards), the best approach is to work with your account team to undertake a review of your application with the capacity management group so that the parameters can be set in such a way that you are not constrained by them.

 

Having said that, your size calculation is not quite right because the attachments are base64 encoded before delivery; base64 encoding increases the size of the content by a third. There's also a bit of overhead associated added to each message due to the inclusion of SMTP headers, but if you wanted to get a rough estimate of how big your job will be, you would use something like this:

 

Size = (5KB + 20KB + (1.333 * 100KB)) * 1000 = 15.8 MB (approximately).

 

But as I said, it would be much preferred if you work with us so you don't have to do this, and so your jobs don't get delayed when they shouldn't.