[Mimedefang] Rejecting e-mails with blank CC: and Reply-To:

[John Halewood]

Scott Nelson wrote:
> Apr 10 08:04:57 mx sendmail[1400]: q3AF4uDC001400: collect: premature EOM: unexpected close
> Apr 10 08:04:57 mx sendmail[1400]: q3AF4uDC001400: collect: unexpected close on connection from bolt7b.mxthunder.net, sender=<webmaster at gt-t.net>
> 
> And this is what our upstream mail handler gets:
> 
> (hostXXXX.thermeon.com[1.2.3.4] said: 554 5.7.1 This message has been blocked because the return email domain is invalid.(domain name  has invalid syntax) (in reply to end of DATA command))

This doesn't entirely make sense, and has nothing to do with mimedefang (as I think we've established). However I also get a fair few of the 'premature EOM' messages every day, just about all of them from spammers in Eastern Europe. Looking at it I've found a couple of causes:
1) "Premature EOM" means exactly what it says - the sendmail process has had the connection terminated before a full SMTP dialog (HELO, MAIL FROM, RCPT TO, DATA, QUIT etc.) has happened. I can reproduce this by manually telnetting to the SMTP port of my servers and waiting long enough between commands that the connection times out. However this doesn't explain why the other end is claiming to get a 5XX series error message back (unless it's making it up).
2) I can also (sometimes) generate it by doing the same but putting the commands in a script that doesn't wait for a reply before sending the next. Sendmail doesn't like this and it's not RFC compliant. As the remote end is using a script to send the mail, this might be the cause of the problem - if you use the sendmail GreetPause feature, you'll know for sure as the error message will be quite different.
3) It could actually be a networking issue to do with the size of the tcp window (seen that as well). If the remote end is using a strange window scaling (or routers in between aren't passing it) ,you might be losing some of the data that's in the packet along the way (or just at your end). I'd recommend using tcpdump/wireshark on your server to check what it's actually seeing - that way you'll also see the error message (if any) being sent back to them and be able to see if it correlates with what their system reports.

I'd actually guess that the latter two possibilities are most likely - in the real world you should only get the first if you're typing SMTP by hand or the network is really congested (or you have stupidly short tcp timeouts, but then you should be seeing a lot of other issues as well).

Regards
John