SMTP dot stuffing.. when and where to do it?

Question

I have found conflicting information about dot stuffing when transmitting an email.

1. stuff a dot if the line contains a single dot (to avoid premature termination)
2. stuff a dot to every line stat starts with a dot
3. stuff a dot to (1) and to every line part of a quoted-printable message part only

Can anyone clarify?

Solution 1

According to the SMTP standard RFC 5321, section 4.5.2:

https://www.rfc-editor.org/rfc/rfc5321#section-4.5.2

To allow all user composed text to be transmitted transparently, the following procedures are used:

• Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line.
• When a line of mail text is received by the SMTP server, it checks the line. If the line is composed of a single period, it is treated as the end of mail indicator. If the first character is a period and there are other characters on the line, the first character is deleted.

So, from the three points of your question, the second one is right.

Solution 2

The practical answer: If you're using quoted printable format then always translate a dot to =2E. You can't rely on all smtp servers doing the dot removal correctly.

If you want to assume the whole world is standards compliant then go with answer 2 above.

Comments

[transilvlad]

This does not answer my question.

[chus]

If a server removes only one out of two dots on a line, it is doing exactly what the standard specifies. When the first character of a line of the original message is a period, the client adds another one before sending the message. Then, the server removes the added period.

[transilvlad]

I meant it only removes one out of two IF THE WHOLE LINE CONTAINS ONLY TWO DOTS. Example: \r\n..\r\n But not for any other line.

[chus]

I think now I can see the point. The solution depends on the agent your are implementing (MTA, MDA). May be you can identify the servers that are not RFC-compliant and process the message to preserve the original text.

[transilvlad]

My problem is not the senders is the receivers. I am sending out DKIM signed emails that on some servers fail because of this. I spent months thinking it was my fault but eventually I managed to identify it was an issue on their side. Oddly enough they use various known agents but they must have done some modifications I guess.

[transilvlad]

The more time passes the more non-compliant messes I see and the more I remember your answer. Thanks.