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

[Matt]

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/ =====================================================