sendmail & mime

[Fred Martin_1]

I have an odd issue. A newsletter is emailed from a 3rd party, after having been created by us on their website in HTML.

It is emailed by the 3rd party to a user's home email and also to the user's work email here at my office.

It arrives at user's home and looks fine. Arrives here on my sendmail server, but when email clients pick it up there are visual issues with the email.

Looking at it closely, I discovered this (a simplified example).

Source code of original email:

6" src=3D"http [etc]

The equals sign is at the end of a line and appears to be MIME signal of the EOL. I have no idea how the height and width tags got reversed on delivery here as opposed to what is seen on the user's home email client.

But the kicker is that the decimal point in 231.6 is now missing. All periods that fall on the end of the line seem to be truncated.

The effect is that when my user's mail client picks up this email from sendmail, it sees the width of the image as 2316 and the image is stretched.

We actually had a case where this source code:

Your cost is only $6.00

Looked like this in MIME:

Your cost is only $6=
00

So the email client got this:

Your cost is only $600

What the heck? I've no idea how this is happening. But it is consistent, periods at the end of the lines are disappearing.

Fred

[Steven E. Protter · Accepted solution]

Shalom Fred,

Looks like a character set issue.

I would tend to blame the sender, but it may be using a character set your email system is unable to support.

SEP

[TTr]

The true sendmail service is a mail transport service. It does not modify any of the email contents.

First, check the mail viewer that the user is using at work. Look for differences in the mail viewer versions and/or settings to see if you can display properly. As noted the character set encoding may be the problem.

Second, check if your server is doing any local email processing. As I mentioned, sendmail does not do any mail processing but other add-ons may be doing just that.

[Fred Martin_1]

Sendmail here is definitely just a transport. All the users are POPing in to retrieve mail from the sendmail box, with either Outlook or Thunderbird. No Exchange server. There is an anti-spam gateway between the internet and sendmail, using MS-SMTP, but I bypassed it for testing anyway with a firewall rule, so inbound email went straight to the sendmail box.

Fred

[Patrick Wallek]

Have a look at the users e-mail box / e-mail file on your Unix server, if possible, and see what the e-mail looks like there.

If the HTML code looks good while the message is still on the server then that would point to a client issue. If the code exhibits the same symptoms you mention above, then there is something in the transport that is causing problems.

[Fred Martin_1]

Patrick, that example I gave was in the user's inbox on the sendmail server, prior to his client popping in to get it.

Since I bypassed my own anti-spam gateway for this test, and it's prior to the client getting it, I can only blame by own sendmail server or the sender.

Not sure how I can blame the sender since the same email goes from the sender to his home email and it looks ok there.

Fred

[Fred Martin_1]

To be clear, the email goes from the 3rd party sender to my user's home email, and it looks ok there. Only when the email also comes to the user's inbox on my sendmail server does it appear to mess up.

I'm running sendmail 8.11.1/8.9.3 which has been patched since but not recently.

[Dennis Handly]

>Source code of original email:
>6" src=3D"http

This the following encoding:
Content-Transfer-Encoding: quoted-printable

>The equals sign is at the end of a line and appears to be MIME signal of the EOL.

Not really. This is the EOL in the mail but it is glued back together and the =3d are converted to "=". A "=20" is the end of a line/paragraph in the original message.

>I have no idea how the height and width tags got reversed on delivery here as opposed to what is seen on the user's home email client.

Hmm, didn't notice that. It means someone must have reformatted the message.

>All periods that fall on the end of the line seem to be truncated.

Hmm. I would assume they would be moved to the next line. Or replaced by =2e.

Does the mail have both text and html so you can check both parts?

[Fred Martin_1]

>> Source code of original email:
>> >> 6" src=3D"http
>
> This the following encoding:
> Content-Transfer-Encoding: quoted-printable

The header at the top of the email from the 3rd party says this:
Content-Transfer-Encoding: 7bit

But farther down in the email, below where it says "This is a multi-part message in MIME format" then it has this line:
Content-Transfer-Encoding: quoted-printable

>> ...how the height and width tags got
>> reversed on delivery here as opposed to
>> what is seen on the user's home email
>> client.
>
> Hmm, didn't notice that. It means someone
> must have reformatted the message.

I'm not sure. The same email is sent from the 3rd party at the same time, to the user's home address and his work address, here. I can only assume that the email client is swapping the tags.

>> All periods that fall on the end of the
>> line seem to be truncated.
>
> Hmm. I would assume they would be moved to
> the next line. Or replaced by =2e.

I agree. The period is definitely disappearing, but only when it falls exactly at the end of the line as seen when the email is sitting in the inbox on the unix server.

> Does the mail have both text and html so
> you can check both parts?

I'll have to re-run a test and look again.