Re: [MlMt] SMTP Timeout

2014-09-04 Thread 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 . 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@lists.freron.com
http://lists.freron.com/listinfo/mailmate

___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate


Re: [MlMt] SMTP Timeout

2014-09-04 Thread Bill Cole

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 . 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@lists.freron.com
http://lists.freron.com/listinfo/mailmate


Re: [MlMt] SMTP Timeout

2014-09-04 Thread Benny Kjær Nielsen

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.


Thanks in advance.

--
Benny
___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate


[MlMt] SMTP Timeout

2014-09-04 Thread John Grasty

Hey Benny and all,

I've been using Mailmate for a while. I really love it. I've just made a 
change to my mail server, and I'm running into an SMTP timeout 
issue...but only with Mailmate, none of my other clients.


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 .


Normally I wouldn't ask, but I've not had a problem with other clients 
(even when sending the exact same message). Any ideas?



Thanks,
John Grasty
___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate