If you arrived here looking for information on "SMTP fixup", a more relevant article may be found here. Google seems to offer the article below first for this search although it is probably less relevant to most visitors.

In the normal course of SMTP mail delivery, your Domino log will record something like this:

18/02/2004 09:52:07   SMTP Server: 192.168.0.1 connected
18/02/2004 09:52:07   SMTP Server: Originator: <originator>
18/02/2004 09:52:07   SMTP Server: Recipient: <recipient>
18/02/2004 09:52:07   SMTP Server: Message 00364B87 (MessageID: <21D5084642AA334AB57F4727C3E0B4A01BDDA7@someplace>) received from 192.168.0.1 size 2320 bytes
18/02/2004 09:52:07   SMTP Server: 192.168.0.1 disconnected. 1 message[s] received

For every host that connects to deliver mail, you expect to see a corresponding disconnect with a non-zero value for "message[s] received".

Now, suppose you use DNSBLs and/or other techniques to reject certain SMTP clients during the SMTP delivery phase. The remote host still has to disconnect, but now has not delivered a message. So for every rejection for any reason (which could be a DNSBL or a local block, an invalid local recipient, a bogus sender, an attempted relay and so on and so forth), you now expect to see a corresponding disconnect with "0 message[s] received".

Of course, it is probable that an occasional host will connect and disconnect without being rejected or delivering anything and you may never know why. But the total of all SMTP sessions actively rejected should be very roughly equal to the number of times your log records "0 message[s] received".

However, some sites report a wide discrepancy between sessions actively rejected and "0 message[s] received", with the latter sometimes outnumbering the former by a factor of two or more. Why is that?

Here are three answers that worked for me:

• Some firewalls mess about with SMTP. For example, CISCO PIX has something called SMTP fixup protocol. This does a number of things, the significant one of which is that it defeats ESMTP functionality.
  
  So, for example, mail.example.com connects to you and says "EHLO mail.example.com". The firewall intercepts this and passes "XXXX mail.example.com" to your Domino server. So instead of getting the expected 250 response code back, the remote host gets back "500 Syntax error".
  
  According to RFC2821, the remote host should now retry with HELO. Most do, but some seem to disconnect first, then reconnect to try HELO.
  
  Simply disabling SMTP fixup protocol on our firewall was sufficient to kill most of the spurious "0 message[s] received" log entries, by permitting the use of ESMTP (which RFC2821 says is preferred behaviour anyway).
  
  This is not risky, providing you do not enable a lot of ESMTP extensions (example; VRFY: leave it disabled!). In fact, we have only one ESMTP extension enabled, SIZE.
  
  
• Having enabled ESMTP, disable inbound pipelining. Many spammers will attempt to pipeline entire spams, ignoring any 4xx or 5xx responses. Having done so, they also often fail to disconnect until quite some time later, tying up one of your inbound SMTP handlers unneccessarily.
  
  
• Finally, be aware that many hosts using a high speed ethernet connection to a NATting firewall may have their default MTU size set too large. This should not be a problem as MTU size can be negotiated between two hosts talking to each other over the Internet. Sadly, many firewalls get in the way of this by blocking all ICMP traffic (so ping, traceroute and so on do not work). The process of MTU path discovery uses ICMP "destination host unreachable" messages. Where these messages are blocked, two hosts will simply stop talking and the connection will time out.
  
  Set the default MTU size to a lower value on your Domino SMTP host and you may also see a reduction in the number of SMTP conversations which fail for no apparent reason. Dr. TCP is a very nice utility to help with this on the Windows platform.

This combination of tweaks brought the number of "0 message[s] received" log entries here down to a level which relates closely to the number of SMTP sessions actively rejected.

Category: Domino: Administration
Technorati: Domino: Administration

1. Justin14/09/2006 12:55:41

We have a similar situation as you describe here, except many times when there is a connection and disconnection the mail is being delivered to our backup mail server and then retired to be send to our domino server at a later stage sometimes being delivered correctly, other times going back through the loop again.
Any ideas?

2. Chris Linfoot14/09/2006 13:55:20

Looks like a fault on the sending system...

3. matt09/10/2006 20:42:09

How do you disable inbound pipelining? Not sure if this is my problem, but every 3 or 4 days the smtp server task quits accepting mail and I look in Domino admin at the tasks and mail routing events and find that there are servers that are not disconnecting. I have to kill the server and start it back up and then it is fine until it happens again.

thanks,

Matt

4. Chris Linfoot09/10/2006 20:52:01

Server config document, Router/SMTP / Advanced / Commands and Extensions tab.

There are settings there for inbound and outbound ESMTP extensions. I have them all disabled except for SIZE inbound and outbound and negotiated SSL inbound.

Unable to post a comment? Please read this for a possible explanation...