[MlMt] SMTP Timeout

[John Grasty]

Benny and Bill,

Thanks. Mr. Cole, you nailed it. I changed from opensmtpd (which I love) 
to postfix, and I went from an outsourced spam filtering to ASSP, a 
behemoth of a perl script that is a "transparent" proxy. So far it has 
done a great job at filtering, but this certainly seems to be their 
problem.

I will do some additional debugging to narrow down which failure it is 
(I suspect the former), and try to hound them to fix it.

Bill, as you seem to be quite knowledgeable in this arena, what is your 
preferred server side spam handling technique? Off list reply is fine.

Thanks,
John Grasty

On 4 Sep 2014, at 18:22, Bill Cole wrote:

> On 4 Sep 2014, at 17:03, Benny Kjær Nielsen wrote:
>
>> On 4 Sep 2014, at 22:18, John Grasty wrote:
>>
>>> Every once in a while a message will timeout and not get sent. The 
>>> activity log shows everything down to the closing . , but the mail 
>>> server never seems to receive the .
>>
>> It's not a known issue. Could you send me an example of such a log? 
>> Off list if you like.
>
> This has been seen historically in situations where a stupid 
> "transparent" proxy (notably some versions of Cisco's PIX/ASA "smtp 
> fixup" malware) is mangling SMTP interactions at the application 
> layer. The common error is failure to anticipate the possibility of 
> the terminating <cr><lf>.<cr><lf> sequence being split between 2 TCP 
> segments and/or read() calls (or their logical equivalents), resulting 
> in the proxy not seeing the whole termination sequence at once. Some 
> SMTP client implementations have adapted to this careless coding by 
> making sure that the message itself is pushed in one segment and the 
> terminating sequence in a segment of its own. This assures that the 
> full sequence isn't split between TCP segments and makes it very 
> unlikely (but not quite impossible) that it will not be returned 
> intact in a single read().
>
> That tactic also slightly mitigates a similar problem when a sending 
> system uses "Path MTU Discovery" and sets the "DONT FRAGMENT" flag on 
> packets, while some intermediary is dropping ICMP "MUST FRAGMENT" 
> replies of some distant device that can't deal with large packets. 
> That problem usually hits every message over 1500 bytes to a 
> particular SMTP server, instead of the "every once in a while" 
> occurrence of the split termination sequence problem.
> _______________________________________________
> mailmate mailing list
> mailmate at lists.freron.com
> http://lists.freron.com/listinfo/mailmate