On Thu, Sep 11, 2014 at 02:36:51PM +0200, Sean Durkin wrote:
> > PLEASE DISABLE
> > ALL VERBOSE logging. NO "-v" options in master.cf, NO debug_peer_list,
>
> Yes, sorry, I cranked up the debug level, since normal logging looks like
> this:
>
> Sep 11 09:43:31 mail postfix/smtpd[25170]: connect from
> mail18-21.srv2.de[193.169.181.21]
> Sep 11 09:43:31 mail postfix/smtpd[25170]: 2C076C4026A:
> client=mail18-21.srv2.de[193.169.181.21]
> Sep 11 09:46:33 mail postfix/smtpd[25170]: lost connection after DATA (33290
> bytes) from mail18-21.srv2.de[193.169.181.21]
> Sep 11 09:46:33 mail postfix/smtpd[25170]: disconnect from
> mail18-21.srv2.de[193.169.181.21]
That's sufficient. It shows you're likely not using TLS here, and
the time beetween message start and connection loss. The number
of samples is rather small now. I would expect the session duration
for each sending host to be essentially constant over multiple
deliveries (equal to the remote machine's TCP timeout).
Possibilities include a broken network interface somewhere or a
bad cable that corrupts IP or TCP packet headers given specific
input patterns.
If the problem is with the message payload, you could try enabling
inbound TLS, perhaps these sending servers support it. Don't recall
whether you already have TLS. If the problem is not with the
payload, then TLS won't make any difference (some hosts will still
fail even after TLS).
> I didn't think that info alone was particularly useful...
It is sufficient, and the verbose logs just add noise.
> Meanwhile, I've managed to record a tcpdump of such a failed
> session. What exactly am I looking for there?
Retransmissions from the sender of data with the same sequence
number...
Post "tcpdump" output (without packet content is fine), containing
packets from just a single failed session.
> There's no packet filtering or rate limiting on port 25, at least
> not on my machine. The hosting provider might have something there,
> I'd have to ask them...
They probably have middle boxes, which might be the cause of the
problem.
--
Viktor.
