2

I have a mailserver with opportunistic TLS enabled (Postfix smtpd_tls_security_level = may), however the SMTP banner is being masked by SMTP fixup on our FWSM. Before I disable this masking, is the SMTP banner required for other mailservers configured for opportunistic TLS to negotiate a TLS session for incoming mail? I read somewhere that Postfix may not use ESMTP if that term isn't in the banner.

The banner is masked by asterisks: 220 *************************************

Justin Gerace
  • 23
  • 3

1 Answers1

4

I think there are two different questions being asked here so I'll address them separately.

Question 1: Is the SMTP Banner required to display unmasked for other mail servers to use TLS?

Answer: No, the SMTP greeting banner itself does not determine eligibility for TLS. So if that's the ONLY thing that is masked, it shouldn't cause an issue.

Question 2 (Paraphrased): Is the firewall interfering with incoming TLS connections?

Answer: Most likely. In addition to masking the greeting banner, the fixup/esmtp inspection service on Cisco Firewalls typically only accepts specific commands.

I'm not sure what version/model firewall you're using but as per this tech note:

ESMTP inspection operates in the same way that SMTP inspection does. Packets with illegal commands are modified to an "xxxx" pattern and forwarded to the server, which triggers a negative reply. An illegal ESMTP command is any command except for these commands:

AUTH
DATA
EHLO
ETRN
HELO
HELP
HELP
MAIL
NOOP
QUIT
RCPT
RSET
SAML
SEND
SOML
VRFY

When external servers connect and issue the ehlo SMTP command, they'll see a list of SMTP services/options supported. Assuming they see 250-STARTTLS the sending server will issue a STARTTLS command to begin the attempt to use TLS. You'll notice that this command isn't included in the list of commands above.

So in summary, I suspect that your firewall IS interferring but not because of the banner greeting. I think it's blocking/masking the STARTTLS command from the remote mail server.

Mike B
  • 11,570
  • 42
  • 106
  • 165
  • We changed it to allow ESMTP and STARTTLS, so TLS will work through the firewall. My concern would be that some mail servers would not see ESMTP in the banner and would fall back to a normal HELO instead of an EHLO, which would not return the list of allowed commands, and thus there was the chance it would not know that was available. – Justin Gerace Jun 13 '12 at 05:54
  • @JustinGerace That shouldn't be a problem. As per section 2.2.1 of [RFC 2281](http://tools.ietf.org/html/rfc2821#section-2.2.1), "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." – Mike B Jun 13 '12 at 06:01
  • Note that opportunistic TLS may not be quite as useful as you'd like (see [this answer](http://serverfault.com/a/397136/47187)): other mail servers (i.e. clients as far as the connections to your server are concerned) would be open to downgrade MITM attacks anyway if they're not configured to expect SSL/TLS to be used (and to use it only, without downgrades). Worrying whether those clients will see HELO or EHLO when they connect becomes almost irrelevant then unfortunately. – Bruno Jun 13 '12 at 17:53