OK, I don't think it is productive to repeat these semantic difference
of opinions of what section 4.1.1.10 says:
IMTO, no matter how you wish read this, NO QUIT means a cancellation
because otherwise the only other way to end a SMTP session is for the
client to close the socket connection. So what this would indirectly
suggest the SMTP specs implicitly says:
There is two ways for a client to end a SMTP session:
QUIT or DROP THE LINE
and that does not jive with the written words:
The sender MUST NOT intentionally close the transmission
channel until it sends a QUIT command,
I can understood your position, very clearly, but in general, I don't
think this is a good way to do robust client/server communications
(allowing drops to signal message transaction completion). It opens
the door for unsureness.
Keith Moore wrote:
On Aug 16, 2011, at 7:48 PM, Hector Santos wrote:
SM wrote:
At 15:03 16-08-2011, Keith Moore wrote:
sorry, I misunderstood what was being suggested. if the server gets DATA
followed by a message (or a message fragment) followed by CRLF.CRLF, it should
accept the message (or fragment) and deliver it. no matter what else follows,
or doesn't follow, during the same SMTP session .
Yes. The SMTP server mentioned that it is accepting the message (up to the
end-of-data terminator. Rejecting the message is not an option once the
message has been accepted.
Hence the dilemma. It wasn't an valid RFC5322 message and the issue is
exasperated when it was DKIM signed and now recorded as a failure. Never mind
the fact QUIT (or a new transaction command) is an SMTP requirement before the
transaction is considered complete for delivery.
Where do you get that idea? RFC 2821 doesn't require this. It only requires
that the server not close the connection until it sees a QUIT. (It even says
that clients SHOULD send a QUIT, implying that things should still work if they
don't.)
Keith
--
Sincerely
Hector Santos
http://www.santronics.com