What is max message size in llEmail?

I am trying to have my script calculate the maximum message size that will fit into an email sent from a SL object to an external email address. The wiki says the following:

"The entire message (including the address, subject and other miscellaneous fields) can't be longer than 4096 bytes combined."

"The 4096 byte size limit includes the subject line and automatically added text. The practical maximum body size is approximately 3600 bytes".

Its not clear what is meant by "other miscellaneous fields". Also, I would like to calculate the exact maximum body size, not the approximate practical size.

So I need to figure out how many bytes to subtract from 4096 to account for the address, subject and automatically added text, so I know how much room I have available for my actual message body. I know how to find the variable length of the address and subject strings as well as the automatic message header lines (e.g. Object-Name, Region and Local-Position) and associated \n's. I even accounted for the expansion of \n to \r\n.

The problem is that the llEmail call fails with several hundred less message characters than the above calculation indicates it should. So there must be more hidden header or other overhead bytes than the wiki implies.

Does anyone have a (verified) formula or method for calculating the maximum number of message characters that can be put into an email?

Thanks,

Fred

It's not really going to be constant, LL changes things over time. For example, at one point in the last year, LL added X-Owner-Id and X-Task-Id mail headers, those would be good for 100 right there.

Thanks Viktoria. So are you saying that it is impossible for a script to calculate how big a message it can put in llEmail? When you put in more text than will fit, the llEmail appears to fail silently, so there is not even a way to test after the fact. Is there some absolute maximum message payload size that if you stay under, it is 100% guaranteed to fit (and is > 1 of course)?

-Fred

A decent guideline would be to treat it as a fallback where chat, IM and HTTP won't work, and keep messages in the 1-2K range. The rest is leeway for headers and so on.

The size limits and time throttles can be super annoying, but they're running a balancing act, trying to keep messaging open without making SL too attractive as a free email or spam hub.