Small Business Server 2008 contains (amongst other things) Exchange 2007. This means that email handling is done on-premises rather than by an SMTP/IMAP/POP3/Exchange server hosted out on the internet somewhere.
This has good points and bad points. The good is that you have a lot of functionality and control, the bad is that it makes your email susceptible to issues that you wouldn’t get if your mail server wasn’t on the end of a (for most small businesses) broadband connection.
I recently encountered, and resolved, just one of these type of issues. Most emails were being received with no issues at all. However emails from one contact would always bounce. i.e. the external sender would get a bounce message back similar to:
From: Mail Delivery Subsystem <MAILER-DAEMON@c2bthomr15.btconnect.com>
Subject: Warning: could not send message for past 4 hours
Date: 26 January 2015 17:03:29 GMT
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
The original message was received at Mon, 26 Jan 2015 12:35:02 GMT
from c2bthomr15.ncs.ibs-infra.bt.com [10.87.69.228]
----- The following addresses had transient delivery errors -----
Reporting-MTA: dns; c2bthomr15.btconnect.com
Arrival-Date: Mon, 26 Jan 2015 12:35:02 GMT
Final-Recipient: RFC822; <firstname.lastname@example.org>
Remote-MTA: DNS; mail.rcmtech.co.uk
Diagnostic-Code: SMTP; 451 4.7.0 Timeout waiting for client input
Last-Attempt-Date: Mon, 26 Jan 2015 17:03:29 GMT
Will-Retry-Until: Tue, 27 Jan 2015 12:35:02 GMT
Another email sent automatically, daily, from an online service (rightmove.co.uk) also didn’t appear. Due to the sender of these emails being automated, there was no bounce message to look at, and the online service’s tech support were less than helpful.
The interesting thing about the bounce message above is that the sending MTA (Message Transfer Agent) is reporting a timeout from the SBS. Yet we know that the vast majority of other email is getting through fine. So what would cause this particular MTA to consistently fail, when others are consistently working? We also know that this same MTA that consistently fails when trying to talk to the SBS, must work perfectly well when talking to other SMTP servers.
The cause was down to MTU (Maximum Transmission Unit) size. The SBS was set to use the default MTU of 1500 bytes, which should be fine. I verified this by running the command:
netsh int ip show int
Idx Met MTU State Name
--- --- ----- ----------- -------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
10 20 1500 connected Local Area Connection
Then I checked the MTU size setting on the ADSL modem/router:
Note how it is set to 1492, which is smaller than the 1500 set on the server.
For info, this is apparently because of the PPPoE protocol being used. The following is from the Netgear WNR2000v3 manual:
MTU – Application
1500 – The largest Ethernet packet size and the default value. This is the typical setting for non-PPPoE, non-VPN connections, and is the default value for NETGEAR routers, adapters, and switches.
1492 – Used in PPPoE environments
This ADSL connection is running PPPoE, hence the MTU is set to 1492.
This shouldn’t be a problem though. When the MTA and SBS start to communicate, they should negotiate the MTU size and adjust it if larger packets get lost. The problem is that if a network device along the path can only cope smaller packets than either of the two servers, it has to send a message back to the servers to tell them to reduce the packet size. As I have discovered, various ADSL routers evidently don’t do this, or some firewalls block the “reduce your MTU size” ICMP packets, and thus you get a black hole where the packets are just silently dropped. This explains why the MTA was reporting a timeout.
The fix was to change the MTU on the SBS to be the same size as that on the ADSL router, namely 1492. This is done via the command:
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Following this, emails are now being received from both the sources that had been failing.