Blank EHLO/HELO commands

[Wolfe, Robert]

Hi all.  This is not a postfix-specific question, but rather a generic one, but I hope I can get the answer I am searching for here.

I run a third part SMTP filtering program in which I have "EHLO/HELO Must Resolve" turned on.  I am amazed at the number of exceptions I have to put into my configuration to accept email from domains affected by this.  Is this normal practice, or, according to RFCs, is the FQDN _REQUIRED_ to be present in the EHLO/HELO verbage during an SMTP session?

Robert Wolfe <robert...@robertwolfe.org>
Linux & Windows System Engineer, Architect, and Administrator
H: 716.210.8663
C: 901.495.9671
W: http://www.robertwolfe.org
"Email.  Powered by Exchange 2016.  Driven by Outlook."

[Noel Jones]

On 12/21/2015 4:54 PM, Wolfe, Robert wrote:
> Hi all. This is not a postfix-specific question, but rather a
> generic one, but I hope I can get the answer I am searching for here.
>
>
> I run a third part SMTP filtering program in which I have "EHLO/HELO
> Must Resolve" turned on. I am amazed at the number of exceptions I
> have to put into my configuration to accept email from domains
> affected by this. Is this normal practice, or, according to RFCs,
> is the FQDN _REQUIRED_ to be present in the EHLO/HELO verbage during
> an SMTP session?

I quit using reject_unknown_helo_hostname a couple years ago when it
quickly became clear that a significant percentage of the clients
rejected were legit. Of course, YMMV.

I use reject_non_fqdn_helo_hostname and have some PCRE
check_helo_access rules that reject IP literal or all-numeric HELO,
"localhost", and variants of my own domain, and I use
"smtpd_helo_required = yes". They don't catch a lot of spam, but
they rarely hit legit mail either, which is why I leave them in.



-- Noel Jones

[Jeffrey 'jf' Lim]

On Tue, Dec 22, 2015 at 7:26 AM, Noel Jones <njo...@megan.vbhcs.org> wrote:

On 12/21/2015 4:54 PM, Wolfe, Robert wrote:
> Hi all.  This is not a postfix-specific question, but rather a
> generic one, but I hope I can get the answer I am searching for here.
>
>
> I run a third part SMTP filtering program in which I have "EHLO/HELO
> Must Resolve" turned on.  I am amazed at the number of exceptions I
> have to put into my configuration to accept email from domains
> affected by this.  Is this normal practice, or, according to RFCs,
> is the FQDN _REQUIRED_ to be present in the EHLO/HELO verbage during
> an SMTP session?


I quit using reject_unknown_helo_hostname a couple years ago when it
quickly became clear that a significant percentage of the clients
rejected were legit.   Of course, YMMV.

were these MUAs? or MTAs?

-jf

[Noel Jones]

On 12/21/2015 6:44 PM, Jeffrey 'jf' Lim wrote:
> On Tue, Dec 22, 2015 at 7:26 AM, Noel Jones <njo...@megan.vbhcs.org
>

> I quit using reject_unknown_helo_hostname a couple years ago when it
> quickly became clear that a significant percentage of the clients
> rejected were legit. Of course, YMMV.
>
>
> were these MUAs? or MTAs?
>
> -jf
>

MTAs. It would be kind of silly to try to enforce this on an MUA.



-- Noel Jones

[Jeffrey 'jf' Lim]

Yeah, sorry, but I just had to check. I can believe a problem with MUAs, but MTAs... hm. Thanks for the confirmation!

-jf

[Bill Cole]

On 21 Dec 2015, at 17:54, Wolfe, Robert wrote:

> Hi all. This is not a postfix-specific question, but rather a generic
> one, but I hope I can get the answer I am searching for here.
>
>
> I run a third part SMTP filtering program in which I have "EHLO/HELO
> Must Resolve" turned on. I am amazed at the number of exceptions I
> have to put into my configuration to accept email from domains
> affected by this. Is this normal practice,

Not normal, but quite common. A substantial number of apparently
legitimate mail systems introduce themselves as members of the .local or
.localdomain TLDs or with unqualified or otherwise unresolvable
hostnames. The first 3 flavors seem to be symptoms of running servers
that are "so easy any idiot can set one up" (and one did.) Historically
that mostly meant Exchange, but in recent years MacOS X Server, Zimbra,
and random "mail appliance" VMs for cloud hosters apparently share the
problem of being unable to truncate human errors by failing when
definitively misconfigured.

For Postfix, I've found that rejecting *invalid* HELO names (illegal
characters, trailing dot, etc) never causes trouble but rarely occurs,
while rejecting IP literals, bare IPs (not in brackets,) and my own
names would catch a huge pile of bots, were it not for postscreen
already catching almost all of them for talking too fast. I also reject
*.local and *.localdomain and unqualified names EXCEPT for a substantial
number of exceptions added when I learn that a particular user wants the
mail from that broken MTA.

That is of course all in regards to SMTP transport (port 25) NOT for
mail submission (port 587) because the people writing MUAs are a large
enough set to follow Sturgeon's Law and so it is a small minority of
port 587 connections that use a resolvable FQDN in EHLO.

> or, according to RFCs, is the FQDN _REQUIRED_ to be present in the
> EHLO/HELO verbage during an SMTP session?

Neither RFC5321 nor its predecessor RFC2821 use SHOULD or MUST regarding
the name used in EHLO/HELO *except* where they also say that a SMTP
client SHOULD use an IP literal if it doesn't have a meaningful FQDN.
Note that they also say:

An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.

Of course, RFCs are not laws, they are documentation for the primary
purpose of interoperability. A rule that "EHLO/HELO Must Resolve" in a
MTA may not quite violate that MUST NOT, but it comes close and some
MTAs can be configured to require that the name resolves to the IP of
the client. That can cause mail from some major mail providers to be
frequently rejected.