RE: [Declude.JunkMail] Somewhat OT: Sending server ignoring 552 SMTP error on large messages

[Andy Schmidt]

Hi,   sorry, I lost the original email.  Somehow I thought it saw a "BDAT" instead of "DATA" in the log - but I could be mistaken.  (Curious to see it again.)    In any case, take a look at this: http://freesoft.org/CIE/RFC/821/20.htm   This seems to imply, that the sender does not have to "look for" return codes until HE is complete with the data.  In fact, your server would have responded to the DATA command with a 3xx reply saying, okay, start sending, I'll wait until I see a CR . CR.   If your server sends something out of turn, then that may not register.  It will look like a dropped connection - and thus retry.  In fact, I know that this is a know behavior of certain mail servers (that they will simply keep retrying if you drop the connection during a DATA transfer.)   Now, if it was indeed a BDAT (chunking) transfer, then the RFC is very specific - that your server must wait its turn - even disk-full would not be an "excuse" to respond while data is being transmitted:     After all MAIL and RCPT responses are collected and processed, the    message is sent using a series of BDAT commands.  The BDAT command    takes one required argument, the exact length of the data segment in    octets.  The message data is sent immediately after the trailing <CR>    <LF> of the BDAT command line.  Once the receiver-SMTP receives the    specified number of octets, it will return a 250 reply code.      ... snip ...      A 250 response MUST be sent to each successful BDAT data block within    a mail transaction.  If a failure occurs after a BDAT command is    received, the receiver-SMTP MUST accept and discard the associated    message data before sending the appropriate 5XX or 4XX code.     ... snip ...         Note: An error on the receiver-SMTP such as disk full or imminent       shutdown can only be reported after the BDAT segment has been       received.  It is therefore important to choose a reasonable chunk       size given the expected end-to-end bandwidth.       Best Regards Andy Schmidt Phone:  +1 201 934-3414 x20 (Business) Fax:    +1 201 934-9206   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Saturday, July 09, 2005 05:06 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Somewhat OT: Sending server ignoring 552 SMTP error on large messages Sandy, One minute and 20 seconds after that log snippet showing the 552 error, MS SMTP logs the following: 2005-07-09 05:11:09 204.0.181.214 mailhost1.neimanmarcus.com SMTPSVC1 VALHALLA 66.109.52.201 0 QUIT - mailhost1.neimanmarcus.com 240 102953 105 4 102719 SMTP - - The QUIT command is issued by the sending server of course.  It then apparently waits for a 250 response and never gets one because MS SMTP has already given up on the message after the 552 error, and therefore the sending server just requeues the message and tries again on the next run.  I do have MS SMTP set to close connections after 1 minute of inactivity, but I'm not sure that it would have issued a proper response to the message after it has already done so earlier.  So the fact that after it reached my max size, it continued on for another 1:20 might be part of the issue, but not the whole issue. I'm not totally sure why this happens, but I get messages all of the time that are too large for the server to accept and they are handled properly, even when plain HELO is used.  I suspect that some servers don't bother to listen during the session for any types of responses, and because MS SMTP gives up on the message before the QUIT arrives, this produces a form of a loop. Because this is so isolated, and I am using one of the most popular gateways out there, I strongly suspect that this is the sending server's problem.  I don't see why one couldn't issue an error during the DATA being sent as there are lots of things that can go wrong during this process.  If it is in fact in the RFC's that one should wait until the DATA command is finished before sending the error, I could see that MS SMTP was in error here, but I don't see why this would be so. Matt Sanford Whiteman wrote: The error is sent however during the transfer of DATA, as soon as it is found that the message is too large. . . Are you sure that that's what MS SMTP thinks it's doing? That's not the behavior I observe in sending vastly oversize messages; MS SMTP waits until the closing <CR>.<CR> to issue the 552. I suspect that with these messages, MS SMTP thinks that it _has_ received the end of the DATA section, either because of an encoding error on the sending server or a decoding error in MS SMTP. Not sure if that sheds any real light, but I don't think MS SMTP is _by design_ sending responses in the middle of DATA transmission -- that would never work at all, and one would think it would've been fixed some time ago. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================