ietf-smtp
[Top] [All Lists]

Transparency

2005-09-08 08:43:25


Describing the leading dot escape sequence.

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.

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.


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.

    Correct behavior (for the sender) would be to enable the leading
    dot transparency procedure:
        "This is some text..
         . Hello there."
    should be transmitted as
        "This is some text..
         .. Hello there."
    and the receiver removes one leading dot:
        "This is some text..
         . Hello there."
    to get the original text.


A solution would be to detect a leading dot not followed by another dot.
This however would change rfc821 semantics and is not the purpose
of rfc2821 and thus rfc2821bis.  It also would fail in the case where a
line consists of only a dot, followed by more lines.

regards,
Alex van den Bogaerdt

<Prev in Thread] Current Thread [Next in Thread>