Alex van den Bogaerdt <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> wrote:
rfc2821bis, as does rfc2821, contains "<CRLF>.<CRLF> where the first
CRLF is actually the end of the previous line. It needs a kludge to
cover the case of an empty mail, CRLF is then the end of the DATA
command.
We should be very hesitant to change this.
I suggest to work line by line and look at ".<CRLF>" only. Not only
does this make the text more clear (IMHO) but it also doesn't need
that ugly kludge. Of course it should be made clear that this sequence
is only to be interpreted at the beginning of a line.
This strikes me as shuffling of terms; not as a simplification. That
certain platforms have different ideas of what constitutes a "line" is
an adverse feature we have learned to live with. I don't belive there
is any hope of resolving those differences.
Another problem with transparency:
Adding a dot happens only when the sending server detects a leading
dot on a line, but removing a dot happens not only when a line starts
with two dots. I'm not suggesting to change this behavior but I
would like to suggest an example of how things go wrong. Hopefully
this helps recognizing problems with message injection where the
sysop forgot to enable the hidden-dot algorithm:
Add to 4.5.2:
Sometimes users complain about missing dots. The message they
send is formatted similar to this:
"This is some text... Hello there."
and their mail client actually send it like this:
"This is some text..
. Hello there."
After sending this message without transparency enabled, the
receiver will strip the leading dot nevertheless. The message
then becomes:
"This is some text..
Hello there."
and then appears as "This is some text.. Hello" in such clients.
This strikes me as a bug. Even if it were a common bug, I fail to
see why it deserves discussion in 2821bis.
--
John Leslie <john(_at_)jlc(_dot_)net>