@nthony

Today I solved an issue that had been causing me grief in the office for quite a while. Mail attachments.

Our configuration with being in a shared building is that our traffic, while secured, controlled, throttled, sanitised by our firewall before being passed on to the outside world. Where it skips a Cisco based firewall that the rest of the building goes through before joining a Cisco based VPN router before joining a govt LAN over leased hard line.

Now, every time we send an email be it on 25 or the secondary port (to evade zealous ISP's and scanners) 2525 - it goes just fine - but if you add an attachment (2k or 2mb it matters not) it crashes and burns. Moreover it crashes and burns without so much as a FW log entry or complaint. All we have to go on after doing an green and red side tcpdump to find nothing was the servers comments with key phrases of:

collect: premature EOM: Connection reset by

SYSERR(root): collect: I/O error on connection from

...which is nice, thank you sendmail.

Now after playing hunt the clue I managed to tie it down to two things, MTU and the kit that I do not have access to - the upstream Cisco VPN and what lay after that. Having had to join the dots I thought I would write a little about it so 1) I dont forget 2) if this is you also - you now know.

In essence somewhere along the line MTU is not being negotiated using ICMP properly, and then, because of this, a fragmentation limit is possibly being reached and the hardware is saying "NO." and terminating the connection, hence no local logs or signs of the stream being dropped.

1) Check that your local firewall is not blocking ICMP for a bit, if its just not returning echo requests, well that's fine;

2) Run some pings running from normal (1500) down to silly low, watch and see if the responses you get back change.

In the case of my home DSL connection the MTU is needless to say not 1500 - here is an example:

anthony@anthony-desktop:~$ ping -M do -s 1465 some.machine.com
PING relay.nsnoc.com (xxx.xxx.xxx.xxx) 1465(1493) bytes of data.
From anthony-desktop.local (xxx.xxx.xxx.xxx) icmp_seq=1 Frag needed and DF set (mtu = 1492)
From anthony-desktop.local (xxx.xxx.xxx.xxx) icmp_seq=1 Frag needed and DF set (mtu = 1492)


Compared to...


anthony@anthony-desktop:~$ ping -M do -s 1464 some.machine.com
PING relay.nsnoc.com (xxx.xxx.xxx.xxx) 1464(1492) bytes of data.
1472 bytes from relay.nsnoc.com (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=55 time=70.6 ms
1472 bytes from relay.nsnoc.com (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=55 time=59.6 ms


Now in THEORY this all happens automagically - the MTU is negotiated down using ICMP with fragmentation responses. However if no one is picking up the ball and fragmentation is running wild, drop the connection and that is what Sendmail is telling you.

So ifconfig ethX mtu 1414 - or more specifically what yours turned out to be, and you should be able to bypass the lack of MTU path discovery going on to the lowest common denominator and job done.

* In my case also remember to update and packet shapers to also reflect this ;)

** More information (thank you Leigh) on MTU discvoery here http://www.znep.com/~marcs/mtu/