--On Tuesday, August 16, 2011 21:51 -0700 SM <sm(_at_)resistor(_dot_)net>
wrote:
Hi Hector,
At 20:23 16-08-2011, Hector Santos wrote:
So the only highly subjective argument which I will never buy
as being absolute in either direction is that the receiver
MUST ALWAYS deliver with the 250 even for invalid messages.
As a clarification, acceptance of a message (SMTP transaction)
does not equate with delivery, i.e. the SMTP server already
sent the 250, it cannot send a 550 as it already provided a
reply code. John commented on the server sending a NDN if it
deems fit. Randall Gellens commented on the timing issue. I
haven't seen anyone arguing in this thread that the receiver
must always deliver.
Two additions:
(1) The somewhat convoluted wording in Section 3.3 of RFC 5321
about the receipt of the end of mail data indicator is there for
a very specific purpose, which is to be sure that, while the
server has accepted the message (and a responsibility handoff),
it is not required to deliver it immediately after receiving the
EOD. It is also not required to deliver it immediately after
receiving a QUIT or RSET. As far as the spec is concerned, it
can initiate delivery to a mailbox or mail store any time
between when it receives the EOD and the day the sun burns out.
It can also choose to bounce the message at any time during that
interval. Of course, waiting days or months after the message
has been accepted before delivering (or bouncing) it would be
terrible operational practice, but it is prohibited only by good
sense, not by 5321.
(2) At least as far as I can remember or been able to find,
nowhere does 5321 say "MUST deliver". Even if it did, the very
broad language of Section 7.8 (titled "Resistance to Attacks"
and often known as the "operational necessity" provision). What
it does say instead is very important for this discussion:
Section 2.1 talks about a formal handoff of responsibility when
the EOD is received and a success response delivered. That
handoff is associated with
"MUST accept responsibility for either delivering the
message or properly reporting the failure to do so".
That is a far cry from "MUST deliver". And, again, it is tied
to receipt of EOD, sending out a success reply, and terminating
the mail transaction state, not to QUIT or any future command.
There is no difference at all between RFC 821 and 2821/5321 in
that regard -- the prohibition on the client closing the
connection without sending QUIT first is about the SMTP session,
not a mail transaction.
john