>...
mous replied to my comments (originally directly to Kai):
>List Mail User a écrit :
>[snip]
>> Leave the FQDN part out and you can try to base an argument on 2821,
>> but there sections 2.3.4 and 2.3.5 simply and clearly states that "Domain
>> names are used as names of hosts and of other entities in the domain name
>> hierarchy." So there seems little left to argue about and "single dot rule",
>> even a "no dot" case is allowed in RFC2821 - "consists of one or more",
>> though
>> I don't believe any such hosts still exist.
>
>agreed.
>
>"localhost" is an fqdn with no dots. (also in theory, some TLDs have
>A/MX records, so they could send mail and thus helo as their tld name.
>but fortunately, these don't send mail, so they can be ignored).
>
>also, the "matching" argument seems to be misinterpreted. the
>requirement (in my understanding) is that
> ip(helo) = client_ip
>not helo = rdns or mx(helo) = foo_bar
>
It is actually much better/worse than that. By sections, let us
go over the language in RFC2821.
The phrasing in RFC2821 section 3.2:
"
...
In the EHLO command the host sending the command identifies itself;
the command may be interpreted as saying "Hello, I am <domain>" (and,
in the case of EHLO, "and I support service extension requests").
"
gives us some comment about the intent - notice the explicit "<domain>",
not "<host>". However the wording in section 3.6 regarding the argument
to HELO/EHLO is:
"
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 A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
...
"
Notice that here in section 3.6 the requirement that a HELO/EHLO argument
be either resolvable to an 'A' RR or an IP literal is a "MUST", but in
section 4.1.1.1, we get:
"
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system. y The SMTP server identifies itself to the SMTP
client in the connection greeting reply and in the response to this
command.
...
"
(Note: the apparent typo of a 'y' in the last quoted paragraph actually
is the text of the RFC, not an error I have introduced). Here, the previous
"MUST" requirement is reduced to a "SHOULD", introducing ambiguity in the
specification. My specific situation is that the sending server does have
a static IP, but the upstream routing is dynamic and some possible paths
are NAT'd (though to static addresses, not DULs) - i.e. yet another case
beyond the example case where the client IP (and hostname) as seen by the
receiver is not known - and worse yet is neither known or readily knowable
by the sending machine (i.e. it couldn't construct an IP literal, even if
it wanted to).
Similar "weasel" words occur later in section 4.1.4:
"
...
The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a valid principal host name (not a CNAME or MX
name) for its host. If this is not possible (e.g., when the client's
address is dynamically assigned and the client does not have an
obvious name), an address literal SHOULD be substituted for the
domain name and supplemental information provided that will assist in
identifying the client.
...
"
with the key words here being "if possible", and for other cases "SHOULD".
This discounts the possibility of it not being possible *and* also not
possible to construct an IP literal.
So, to this point the only unambiguous requirement we have yet is
that a FQDN or IP literal must be used, or a CNAME that refers to one of
these and that it must resolve to either one or more 'A' *and/or* 'MX' RRs.
Now, still in section 4.1.4, we completely blow away any requirement
that the HELO/EHLO requirement match the client's IP at all with the next
paragraph:
"
...
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
...
"
So we find a rare "MUST NOT" case in that a conforming server is actually
prohibited from refusing mail because the HELO/EHLO != client IP! There
are at least one escape clauses for administrators who wish to enforce a
stricter set local rules - section 7.7 says:
"
7.7 Scope of Operation of SMTP Servers
It is a well-established principle that an SMTP server may refuse to
accept mail for any operational or technical reason that makes sense
to the site providing the server.
...
"
Which leads to the old and well-worn adage "your server, your rules", and
together with other clauses basically allows a 550 response anywhere you
like for any reason.
So we find it is actually not only *not* contained with RFC2821
any requirement that the HELO/EHLO argument resolve to/match the client IP,
but we find an explicit prohibition on refusing a transaction because of
the lack of match. For those administrators that do want to enforce some
other set of rules for whatever reason(s) they choose, we do still have
section 7.7 which basically is a "anything you think makes sense is OK"
clause - which doesn't require the administrator to be correct, or even
rational but simply to want to impose a rule that he/she believes in, and
that *is* allowed.
Paul Shupak
[EMAIL PROTECTED]
