On 10/07/2011 09:35 AM, Roberts, John J wrote:
Anyone have any idea what is going on here? This looks to me like the email I
am receiving is ill-formed.
Some installations have special handling for email sent to addresses outside
the home organization. The email is intercepted and stored in a database.
What gets sent to the destination email address is a rich text page containing
hyperlinks the recipient can use to access the original message, but it works
only for a limited period of time (like 30 days).
Of course, when these rich text pages are sent, they appear as hexadecimal
garbage to the list servers.
I am plagued with this at my installation. I always have to watch that my
posts are small since big messages trigger the special secure handling.
John
But in this particular case, the data definitely is just UTF-8 text not
RTF, only it is base64 encoded (which shouldn't be necessary these days
- see 8BITMIME, circa 1994). The message body appears to be
quasi-multi-part MIME with some missing multi-part headers (specifically
the initial ones that are required to indicate the message body is
multi-part and the multi-part separator string) and also with missing
Content headers for a 2nd base-64-encoded part in the message body
(apparently a base64-encoded ibm-main footer added by the list server),
and finally there is no final multi-part header to indicate the end of
the 2nd part.
If the list server does not support broadcasting multi-part MIME
messages, I don't see any easy way it could possibly handle an incoming
message that is UTF-8 base-64 encoded without first decoding the message
to UTF-8 to allow adding the list footing without requiring a 2nd part
in the message body. From the data I am seeing, it looks like the list
server attempted to add the footer message in a format consistent with
the original message data (UTF-8, base64), but was unable to handle the
generation of all the headers required to make this really work. If
that is the case, then either the arrival of UTF-8 base64 rather than
UTF-8 Text must somehow be prevented, or the server must be smart enough
to convert the UTF-8 base64 to UTF-8 Text before attempting to process
it. Or, perhaps this failure was triggered by an incoming message that
was actually multi-part (someone with email configured to send both text
and html formats all the time?)
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
