[rfc-i] SMTP-HELO clarification
ietf-dane at dukhovni.org
Mon Sep 18 09:42:27 PDT 2017
> On Sep 18, 2017, at 10:12 AM, rfc at dvl.sh-ks.net wrote:
[ No idea what forum this discussion belongs on, if any,
but probably [rfc-i] is not it. If the discussion
continues, it should probably move to a more appropriate
list. For the moment "Reply-To" is still [rfc-i], as I
don't have a better list at my fingertips. ]
> We've problems with some MTA-admins, which interpret the rfc in
> another way, than we do.
They are not interpreting an RFC they are operating a mail server
in whatever way they think works best for them. The spam wars
long ago ended any pretense that RFC-compliance is sufficient for
reliable email delivery to all parties.
> Unfortunately some MTA-admins [...] reject messages because of
They choose to do so because they don't lose much email they
care about, and believe that this helps them to reject much
email they'd rather refuse.
> so, who is right on interpretation of the RFCs?
That's not the right question, I'm afraid.
> Is there any RFC, which defines, that the FQDN-parameter of the HELO
> 1. *MUST* match the reverse-mapping of the used IP-address?
> 2. *MUST* resolve to the used IP-address?
Not exactly, but close, RFC5321 section 2.3.5 says in part:
Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the
rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
And section 4.1.4 goes on to 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. Information captured in the
verification attempt is for logging and tracing purposes. Note that
this prohibition applies to the matching of the parameter to its IP
address only; see Section 7.9 for a more extensive discussion of
rejecting incoming connections or mail messages.
So the EHLO name, if not an address literal, MUST [at least] be a
real FQDN hostname that resolves to an address, but servers are
SUPPOSED TO NOT reject on the basis of conditions 1 or 2 failing.
However, in real life some servers do that, and may not accept mail
where the EHLO domain is an address literal. If you want to be able
to deliver email to these domains, you'll need to play by their rules.
More information about the rfc-interest