> 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.
What I'm saying is that MS SMTP doesn't send the response during what IT THINKS is the DATA stage. It thinks that the DATA stage is complete and has been ended by a <CR>.<CR>. It's easy to verify that MS SMTP traditionally sends 552s in proper command order and does not try to force responses over a receiving socket when the remote end is not, and should not be, listening. > 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. Those messages are handled properly _by both ends_, that's why they work. MS SMTP waits until the <CR>.<CR> to 552, unless triggered by the bug you're seeing here. It's irrational, non-RFC, and poor programming for it to try to send the response out of order. What triggers the out-of-order condition, I cannot say. But, if it were by design, it is discernably wrong to expect the other server to listen at the application level for out-of-RFC commands. MS SMTP doesn't think it's doing this, though, in your situations: I think it "mishears" a <CR>.<CR> because of bad decoding on its end when presented with a particular sequence by a sender. The sender itself may be bending the RFCs for some reason, and the MS SMTP side understandably does not parse it correctly. . . or the sender may be sending a sequence of bytes which is rare yet RFC-compliant, but there's a bug in MS SMTP. . . either way, MS SMTP is acting out of character _for itself_. > 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. They shouldn't listen during the session for out-of-sequence application-level responses. It would be a poor programming choice. > 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. You can't because the RFCs say you can't. That's the bottom line for MTA design. --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.
