|
Hi Matt:
I agree that the IIS log is omitting information
that we would like to see (e.g., it doesn't log the BDAT parameters for inbound
message - only for outgoing - and it doesn't log the mulit-line response to
an EHLO) - but I'd be surprised if the log "replaced" command values, e.g.,
confused a DATA with a BDAT.
Sounds to me as if we're dealing with a poor implementation
on the other side. It doesn't use EHLO to see if chunking is permitted at
all (which it is required to do as per RFCs). That's all we need to
know to point the finger. Everything after that are secondary issues - the
results are "undefined".
If EHLO had been used by the sender, then the max
message size could be checked ahead of time - and if the message size is
permitted, then BDATs chunking would always be less or equal to that and
your IIS would have accepted properly.
What may even be happening is that the other side (lacking
the EHLO information, shouldn't be chunking it all), sends a chunk size that is
unacceptable and your IIS SMTP is aborting the session once it reaches whatever
you may have defined as a session limit.
Can't see where MS SMTP is at fault, based on what we've
seen so far. Best
Regards From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Saturday, July 09, 2005 11:35 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Somewhat OT: Sending server ignoring 552 SMTP error on large messages I do see here that it is definitely improper to send a response during a DATA or BDAT transfer (which is really, really stupid and speaks to the age of the SMTP protocol). Unfortunately MS SMTP doesn't log the DATA or BDAT command part of the session, just the stuff before and after it. Go figure. So I can't really even tell if the session is really BDAT or just DATA, but it is clear that MS SMTP thinks it is BDAT. I am thinking that since the sending server didn't support EHLO, it probably doesn't support BDAT either, but I'm just guessing. So maybe it is most likely that there is a bug in MS SMTP that makes it think it is BDAT, or at least it treats it as BDAT when a message goes over the limit. I do get Sandy's point about the possibility of there being errant information in the transfer that makes it look like <CRLF>.<CRLF> in the middle of the transfer, and while that is a possibility, I have seen this condition happen twice in with two different servers with the same exact conditions in the logs. So I think it is more so that MS SMTP is either thinking it is BDAT, or treating it as BDAT when the size limit is reached, and apparently that is a bug, and while some servers might accept a 552 error during a DATA transfer and handle it appropriately despite being the wrong thing to do, it appears that maybe some don't, and this causes things to be resent. FYI, here's all of the log entries for this message instead of the different pieces in different messages. Take note of the time stamps as there are one or two minutes between some of them: 2005-07-09 05:09:26 204.0.181.214 mailhost1.neimanmarcus.com SMTPSVC1 VALHALLA 66.109.52.201 0 HELO - +mailhost1.neimanmarcus.com 250 0 44 31 0 SMTP - -Attached is also a graph of my Friday traffic at my router showing the effect of just one such message stuck in this resending loop. Thankfully I can now burst far beyond this, but when this happened while I only had a T1, it caused major trouble until I found the problem. In this case all I had to do is tell my gateway to give a 550 error for the sender and after the next try 35 minutes later, it killed the message permanently, but naturally it could happen again. I'm probably going to double the size of what I accept which should help minimize the issue even further. Thanks for helping me understand this better. Matt -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ ===================================================== |
- RE: [Declude.JunkMail] Somewhat OT: Sending server ignoring 5... Andy Schmidt
