Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 *******************

share|improve this question
up vote 4 down vote accepted

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:


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.

share|improve this answer
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 5:54
@JustinGerace That shouldn't be a problem. As per section 2.2.1 of RFC 2281, "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 6:01
Note that opportunistic TLS may not be quite as useful as you'd like (see this answer): 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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.