Folks,
For whatever my perspective is worth, please calm down. First
and foremost, if the robustness principle is applied, all cases
are covered. The sender, being conservative about what is sent,
never sends lines with one leading dot and any other text. The
receiver, being liberal about what is accepted, (i) allows for
the possibility of white space between a leading dot and CRLF,
treating either
.CRLF
or
.<whitespace>CRLF
as end-of-data, and (ii) removes a leading dot regardless of
what follows it. The second rule creates some slight
possibility of removing a dot that should have been there, but
such a singular dot is an error anyway, so no one is in much
condition to complain.
The text in 2821, and the distinction between sending and
receiving behavior, is intentional and basically reflects the
principles above.
With regard to "throwing errors", who are you going to tell?
Certainly one could add a header that says, more or less "the
input was a little bogus and we tried to fix it up", although
I'd assume most MUAs and users would ignore such a message. A
trace field could be annotated (with a comment) in much the same
way (and that is what I'd do personally if I felt obligated to
report something like this). 2821 basically prohibits (again,
intentionally) returning a error reply but still delivering the
message; rejecting or bouncing a message over something like
this would impress me as strange indeed.
While you are welcome to continue if you like, I think that
ought to be more or less the end of this discussion unless it
can be demonstrated that following the robustness principle
and/or the text of 2821 causes harm.
Yours for robust and interoperable SMTP implementations,
john
--On Tuesday, 16 May, 2006 12:43 -0700 Tulsi Ram Mayala
<tulsi_rammayala(_at_)strongmail(_dot_)com> wrote:
The question is not about the difficulty/ease of
implementation. It is about defining exact inverse operation
and RFC should define it correctly.
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).
________________________________
From: Paul Smith [mailto:paul(_at_)pscs(_dot_)co(_dot_)uk]
Sent: Tuesday, May 16, 2006 1:13 AM
To: Tulsi Ram Mayala; ietf-smtp(_at_)imc(_dot_)org
Subject: Re: Transparency
At 01:55 16/05/2006, Tulsi Ram Mayala wrote:
However there are conflicting statements in RFC regarding
single dot. Here are the RFC statements:
1. Before sending a line of mail text the sender-SMTP checks
the first character of the line. If it is a period, one
additional period is inserted at the beginning of the line.
This implies a reciever should never recieve a line with
single dot
followed by characters (other than CRLF).
2. When a line of mail text is received by the receiver-SMTP
it checks the line. If the line is composed of a single
period it is the end of mail. If the first character is a
period and there are other characters on the line, the first
character is deleted.
This says remove dot even in case of single dot followed by
charactes
other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE DOTS.
In my opinion single dot case is not a valid test case.
There are two statements there, one applies to the sender, and
one applies to the receiver.
In your example, you have a bug in the sender (not your
software) AND a bug in the receiver (your software).
You CAN fix the bug in your software - ie do what (2) above
says - if the first character is a period, and it's not on a
line of its own, delete the first character. Statement (2)
above isn't ambiguous.
You can't fix the bug in the sending software (unless your
software does that as well...) so don't worry about that. If
the developers of the sending software complain that your
software shouldn't remove the leading '.' unless there's two
of them, you have plenty of ammunition to defeat their
arguments!
I can't see it being hard to fix the bug in the receiving
software...