At 12:43 -0700 on 05/16/2006, Tulsi Ram Mayala wrote about Re: Transparency:
Yes a sender sending a single dot is buggy. But a receiver not
removing a dot in case of a single dot should not be called buggy.
Maybe a better way to put it is it can throw an error ("Invalid data
input" or something else).
Unless we can see what "went out over the wire" (ie: Was sent to the
Receiving SMTP Server) we can not state where the error lies.
The RFC states that:
1) .CR+LF is the signal that the transmission of the body is over.
2) When .CR+LF occurs in the body of a message to prevent it from
being acted upon by the receiving SMTP Server, it is to be converted
to ..CR+LF (by appending a second period.
3) To avoid needing to special case ..CR+LF at the receiving end,
ANY line that begins with a period in the body is to be prefixed with
a 2nd period when sent.
4) The receipt of .CR+LF by the receiving SMTP Server is an
end-of-body signal.
5) Any OTHER line that begins with a period is to have that period
removed and the rest of the line accepted.
What this means is that this is what gets sent:
Input Sent
. ..
.. ...
.one ..one
..two ...two
So long as the string in the Sent column is received by a properly
working SMTP Server then the original string from the input column
will be recovered.
Now lets look at a broken sender that only adds a period if the 2nd
character is NOT a period. This would cause the following:
Input Sent
. ..
.. .. (not ...)
.one ..one
..two ..two (not ...two)
Now we see that the situation is as follows assuming a "correctly
functioning" receiver (which seems to be what is occurring):
Input Sent Received
. .. .
.. .. .
.one ..one .one
..two ..two .two