Chris-Linfoot.net

2.2.1 Background

   Contemporary SMTP implementations MUST support the basic extension
   mechanisms.  For instance, servers MUST support the EHLO command even
   if they do not implement any specific extensions and clients SHOULD
   preferentially utilize EHLO rather than HELO.  (However, for
   compatibility with older conforming implementations, SMTP clients and
   servers MUST support the original HELO mechanisms as a fallback.)
   Unless the different characteristics of HELO must be identified for
   interoperability purposes, this document discusses only EHLO.

Prima facie therefore, the use of SMTP fixup is enough to render an SMTP RFC non compliant. But it gets worse.

Look what you miss by killing ESMTP. Among other things:

• STARTTLS - want to use negotiated transport layer security on your SMTP server? To send and receive email over a negotiated SSL secured channel so that it passes over the public Internet encrypted? * Sorry. Can't do that.
  
  
• AUTH LOGIN - want users to authenticate in order to gain relay privileges? The alternative is to deny your own users an SMTP message submission channel, or to operate an open relay and let the world use you as a spam conduit. Well if neither of those alternatives seems appetising to you, too bad.

It also actually breaks some SMTP implementations completely. Apparently some Exchange systems just can't handle having SMTP mucked about with in this way at all and Microsoft offers a detailed description of how to turn it off.

At least Domino servers can work behind SMTP fixup but at what cost? And what are we protected from? I'll tell you. We are protected from our own stupidity in not being able to figure out that certain ESMTP extensions are a bad idea:

• VRFY - possibly not such a great idea to let anonymous strangers look up the email addresses of your users.
  
  
• EXPN - likewise.
  
  
• Pipelining - used by spammers to pump and dump spam. So turn it off.
  
  
• and last but not least AUTH LOGIN - on systems that don't need it, or on systems that have generic role accounts with trivially guessable passwords or where the Guest account has been enabled (usually by malware).

All of these and more can be managed by configuring the SMTP system behind the firewall correctly in the first place. Fixup is in other words no more than a sticking plaster to cover up sloppy security practices behind the firewall.

I am truly at a loss to understand why some people seem to find fixup so necessary. If your are one of these, please tell me. Why?

Rant ends.


* all of our servers negotiate a secure channel where connecting systems support it

Category: Infosec
Technorati: Infosec

1. Fred Janssen11/08/2005 21:23:07
Homepage: http://www.bigbearfreddy.com

Hi,

Can some explain this:
Pipelining - used by spammers to pump and dump spam. So turn it off.

I tend to turn this on...

Fred

2. Ben Rose12/08/2005 17:53:19
Homepage: http://www.jaffacake.net

I've suffered many a problem with the shitty pix SMTP fixup thing. It used to cause duplicate messages.

It's also a pain in the ass for SMTP testing and offers no benefit whatsoever to a secure mail server.

3. Chris Linfoot15/08/2005 09:04:00

@Fred - see http://www.faqs.org/rfcs/rfc1854.html

In particular, read the list of flaws in the introduction.

Pipelining where used by spamware often exhibits one or more of these flaws and when used against an SMTP that supports pipelining can result in a partial denial of service condition by tying up one or more inbound handlers for an extended period. Of course this is a two way street - this also means that affected SMTP systems act as tarpits and can keep spamware systems busy for long periods (they can therefore not simultaneously be used to deliver spam elsewhere).

I generally recommend turning off pipelining because

a) latency isn't the problem it once was in modern high speed switched networks and
b) I haven't the time or the inclination to become an involuntary tarpit

However, your mileage may vary. If pipelining works for you and you see more upside than downside, then go ahead and use it. It's some of the other extensions that can be really troublesome - including if memory serves some proprietary extensions only ever seen in one vendor's MTA software (everyone say "buffer overrun vulnerability").

4. A.K.24/03/2006 15:11:23
Homepage: http://none

Hello,

I've stumbled across this post while searching for people having the same problem as i do. Symptomatic thing is that in most cases people responsible for pix are not willing to turn it off. And usualy, they dont even know what is it for. Worse is that after detailed explanation they still refuse to turn it off.

5. Chris Linfoot24/03/2006 15:34:22

This is very depressing but not a lot I can suggest I'm afraid. Seems to be a common ailment

6. Hugh Gunn29/03/2006 08:56:47
Homepage: http://www.imltd.co.uk

I have suddenly started to experience refusal of an smtp connection, which was working yesterday morning to accept mail. Error reported is
"503 Issue RCPT To: command before DATA command". It works fine with My portable, wirelessly connecting via the router is fine, the log is reporting the connection. I guess that it is anti Spam settings on the SMTP server. I have tried tweaking the SMTP config and rebooting smtp any ideas where I might look for inspiration?

7. Chris Linfoot29/03/2006 12:13:19

Is it a Domino server?

Is it your Domino server?

If so you need to up the log level (turn on SMTPdebug) to see what is happening.

The RCPT TO command is evidently being lost. Could be a TCP packet level problem or a software firewall getting in the way.

8. Terry T03/05/2006 19:15:44
Homepage: http://www.franklintech.net

Chris -

I don't know if I have encountered something similar to the PIX firewall thing, but I have had problems with SMTP behind a newly installed ZyWALL 35 firewall. What occurs is during the SMTP conversation is a problem between the ACK and RESPONSE from source to target. I have gone to the extent of packet sniffing and can see where this occurs.

Now I can't say specifically that it is the firewall, as I foolishly upgraded my 1) network configuration (adding the firewall), 2) ISP (switched from one Covad reseller to another, 3) OS (Windows Server 2000 to 2003), and last but not least 4) Domino version (6.0.2 to 6.5.5).

What makes me think that it is the firewall is that this only occurs with 3 SMTP mail transfer servers. All of my mail is sent through a 3rd party SPAM/Virus checker, and we only allow connections from this companies SMTP servers. Of their roughly 50 servers that connect to us, 3 of them exhibit this problem. It may be an issue with these 3 server and their IP communications through the firewall -- what do you think?

9. Chris Linfoot03/05/2006 20:19:36

Could be.

I'd look at the server OS first though (theirs and yours). I see no good reason to run a Domino server on Win2K3 and have seen many reports of intermittent or erratic IP connectivity to Domino servers when running on that OS. Any chance you could run a test with a Win2K box instead of a 2K3 one?

Also, while you're sniffing packets, look at fragmentation too. Is ICMP traffic flowing freely between your servers and your host's servers. Is initial MTU size sensible? Is MTU being negotiated properly?

10. jude16/12/2007 08:48:39

Hi!!
Need help desperately.

I've configured IRONMAIL on domino SMTP server. I am able to recive mails from the internet but the problem is that my internal domino server is not sending mails to the SMTP domio server all the mails which are meant to go outside domain are sitting the MAIL.BOX of the internal server.

NO CLUE WHY this is happening.

But the beauty is that when I copy the mails from my internal mail server and put them in Mail.BOx of the smtp mail server the mails are going.

SO I guess there seems to be a problem with the connection of the two servers.

Hmm I did all the tricks of the trade, Deleted the connection docs recreated with different ports but nothing seems to be working.

Please any one has any suggestions. ITS AN EMERGENCY!!

Thanks in advance
Jude:-

11. Chris Linfoot17/12/2007 10:27:04

Global domain?

Foreign SMTP domain?

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