SM 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.
Regards,
-sm
Point taken, and I agree, but I guess I took offense to the incorrect
singular interpretation label which is clearly not correct and
wouldn't make sense to design products that will operates one way that
no one supports.
Here is one sender log (trust me its more than one sender) that will
resend regardless of DATA response
250 message accepted for delivery
simply because it was not able to issue the 2821/5321 SMTP required
QUIT.
The following session log is repeated 5 times so I will only show the
first one. This is for a XML-DEV mailing list I subscribed and no
doubt, as I suspect now do some unique message structure. I never had
a problem with this sender in the near 10 years as a member:
**************************************************************************
Wildcat! ESMTP Server v6.4.454.1
SMTP log started at Sun, 07 Aug 2011 04:20:54
Connection Time: 20110807 04:20:54 cid: 0000A022 tid: 00000F04
SSL-Enabled=NO No-Quit-Cancel=ON Receiver-Bin=ON
Client IP: 66.151.234.57:42705 (unknown) Host IP: 208.247.131.9:25
04:20:54.752 S: 220 winserver.com Wildcat! ESMTP Server v6.4.454.1 ready
04:20:54.804 C: EHLO sf01.oasis-open.org
04:20:54.804 S: 250-winserver.com, Pleased to meet you.
04:20:54.804 S: 250-SIZE 10240000
04:20:54.804 S: 250-8BITMIME
04:20:54.804 S: 250-SUBMITTER
04:20:54.804 S: 250-ETRN
04:20:54.805 S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
04:20:54.805 S: 250-AUTH=LOGIN
04:20:54.805 S: 250 HELP
04:20:54.945 C: MAIL
FROM:<xml-dev-return-55772-xml-dev=winserver(_dot_)com(_at_)lists(_dot_)xml(_dot_)org>
SIZE=724226
04:20:54.945 S: 250
<xml-dev-return-55772-xml-dev=winserver(_dot_)com(_at_)lists(_dot_)xml(_dot_)org>... Sender
validation pending. Continue.
04:20:54.997 C: RCPT TO:<xml-dev(_at_)winserver(_dot_)com>
04:20:55.273 ** WCX Process: wcsap ret: -1 (275 msecs)
04:20:55.273 S: 250 <xml-dev(_at_)winserver(_dot_)com>... Recipient ok
04:20:55.329 C: DATA
04:20:55.329 S: 354 Start mail input; end with <CRLF>.<CRLF>
04:20:55.407 ** end of data received. (bytes: 2622) (24.7 K/s)
04:20:55.591 ** WCX Process: SmtpFilterHookLoader ret: 1 (183 msecs)
04:20:55.592 S: 250 Message received for delivery. (bytes: 2622)
04:20:55.592 C: Candle's markup_
04:20:55.592 S: 500 'Candle's markup_ ': command not understood.
04:20:55.592 C:
(http://www.candlescript.org/doc/candle-markup-reference.htm)
language is strongly-typed even without schema, whereas XML
04:20:55.592 S: 500
'(http://www.candlescript.org/doc/candle-markup-reference.htm)
language is strongly-typed even without schema, whereas XML ':
command not understood.
04:20:55.592 C: is only weakly-typed without schema.
04:20:55.592 S: 500 'is only weakly-typed without schema. ': command
not understood.
a bunch of these 500 response finally ending with:
04:25:56.440 ** connection drop - error: 10054 state:
tMessageQuitPending lastcmd: DATA
04:25:56.441 ** Cancelling message delivery due to incomplete
transaction (NO QUIT).
04:25:56.441 ** Completed
Again, this is repeated 5 times before it decides to stop. Thats a
clear indication that the 250 response is not viewed as the
transaction complete signal that a server has accepted the transaction
for delivery and the client can "believe" it doesn't need to send the
QUIT nor retry again and can just drop the line.
--
Sincerely
Hector Santos
http://www.santronics.com