Re: [Exim] SMTP Command Timeouts - from certain senders only

--
On 2001-12-29 at 14:06 -0800, Jeff Sloan wrote:
> I receive regular log reports of an SMTP Command Timeout only from certain
> users.
>
> the log snip below shows that one user can get through right away and
> another get's hung up.

Do you have any specific hosts which cause the problem where you can
pre-arrange to try a delivery? The best approach might seriously be to
then tcpdump all traffic between the two hosts into a file and try the
delivery, see what happens.

Failing that, and given:

> Some messages from one sender going through the same host will get blocked,
> some will get through, then the first messages get rejected back to the
> sender by their MTA as a bad address.

> Is there a qmail vs exim ideosyncracy that I need to be taking into account.
>
> It should also be noted that the box1.mpowercom.net address is my backup
> mailserver.
> About 1/2 of the messages I get on a given day will go through it.

Are they equal MX? Is this for vatran.com?

If it's vatran.com, then your DNS is broken.

10 208.57.84.2
20 box1.mgci.com

The host in an MX record *MUST* be a name, with an A record (not a
CNAME). The reverse doesn't need to point straight back to that
(although it's nice) so you could perhaps add something like
smtp.vatran.com. with an A record pointing to [208.57.84.2].

qmail, being written by Dan Bernstein, might very well be being pedantic
about the DNS -- I wish more things were.

OTOH, you are _getting_ the connection, so this seems dubious.

> Any pointers would be much appreciated.

If it's not the DNS causing a problem, then what about Path MTU
Discovery? If the connection fails during the DATA section, when larger
packets start coming through, then I'd take a look at the firewalls.
Are they filtering "ICMP Destination Unreachable, Don't Fragment set but
Must Fragment"? If so, then hosts attempting Path MTU Discovery might
be getting hurt by the b0rked config. I've seen this, on multiple
occasions. ICMP is a control protocol, and should not be blindly
filtered without understanding the consequences.

If the firewall isn't under your control or you don't want to try
changes to experiment, then perhaps if you lower the MTU on the ethernet
interface of the mail server you can test this. If things start
working, it's because the lowered value is causing Path MTU Discovery to
start from a lower value (min(their-MTU, your-MTU)).

An MTU of 576 should be routable everywhere without fragmentation (or
with immediate reassembly) so that's the easy check.

Preferably, if it's the MTU and this work-around fixes it, then please
do get the firewall corrected.

> TIA

Well, I've thrown a couple of ideas at you. Hope they help,
--
Top Secret (a.): The highest secrecy classification in the following scale:
Top-Secret, Dead-Secret, Strictly-Entre-Nous-Secret, Fair-to-Middling-Secret,
Mum's-The-Word-Secret, Rent-A-Hall-And-Sell-Tickets-Secret, Bottom-Secret.
--
[ Content of type application/pgp-signature deleted ]
--