[RFCI-Discuss] about FQDN for our smtp servers (was RFCI-Discuss
Digest, Vol 39, Issue 3)
Administrative Account
hostmaster at Plectere.com
Wed Apr 12 12:00:33 EDT 2006
>Message: 6
>Date: Wed, 12 Apr 2006 13:13:01 +0200
>From: Alex van den Bogaerdt <alex at ergens.op.het.net>
>Subject: Re: [RFCI-Discuss] about FQDN for our smtp servers
>To: Discussion about the RFC-Ignorant Project
> <rfci-discuss at lists.megacity.org>
>Message-ID: <20060412111301.GC7275 at ergens.op.het.net>
>Content-Type: text/plain; charset=us-ascii
>
>On Wed, Apr 12, 2006 at 05:35:12AM -0400, Jeff Pang wrote:
>> If I send a HELO with a resolvable FQDN but that FQDN does not point to the correct sender IP,was I right?
>> For example,202.108.5.84 is one of our MTAs,whose A record is: m5-84.163.com
>> Now a HELO sent from this MTA with a FQDN as 'm6-84.163.com',I think it's not right.
>> So,I think the 'resolvable FQDN' should be 'resolvable and correct FQDN'.Isn't it?
>
>Yes, it MUST be the correct FQDN. Your host has a name, for instance
>m5-84.163.com. It is this name that MUST be used in HELO. See RFC 1123,
>section 5.2.5
>
>If you would use m6-84.163.com then you are using a name that does not
>exist. This is NOT a resolvable domain, thus can never be a FQDN.
>
>Alex
Not intending to pick on Alex, I could have chosen nearly any of
the various replies to argue with, but the language is this one is the
easiest to refute and the reference to RFC1123 is out of context and thus
incorrect.
First, regarding the HELO/EHLO argument: All discussions seem to
be predicated on resolution of the argument to an 'A' RR, but in RFC2821
section 3.6 we find:
"
3.6 Domains
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.
- The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see section 4.1.1.3) and
MUST be accepted if so used.
"
But this "MUST" is contradicted by section 4.1.4 which reads:
"
...
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 (think dynamic routing - not simple
dynamic addresses, with multiple NAT'd interfaces involved - no dynamic
addresses need be present at all for this situation to occur).
Now regarding RFC1123 section 5.2.5, again there is no requirement
here (despite that in RFC2821) to resolve to an 'A' RR - This is preceded
in the same document by section 5.2.2, which reads:
"
5.2.2 Canonicalization: RFC-821 Section 3.1
The domain names that a Sender-SMTP sends in MAIL and RCPT
commands MUST have been "canonicalized," i.e., they must be
fully-qualified principal names or domain literals, not
nicknames or domain abbreviations. A canonicalized name either
identifies a host directly or is an MX name; it cannot be a
CNAME.
"
Again allowing a name to resolve to a 'MX' RR. And just to be
perfectly clear what is the "name" part of an RR, from RFC1035 section 3.2.1:
"
3.2.1. Format
All RRs have the same top level format shown below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME an owner name, i.e., the name of the node to which this
resource record pertains.
...
RDATA a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource record.
"
So clearly the "name" is the LHS of the RR, by definition.
The only unambiguous construct that can be extracted from this mess
(and yes, I agree it should be cleaned up), is that the argument SHOULD (due
to the "if possible" clause) resolve to an 'A' or 'MX' RR and that it MUST
resolve to some RR. Much of this comes from the mistaken, but commonly argued
notion that a FQDN is a *hostname*, where in fact it is any legal LHS of an
RR anywhere in the DNS tree.
All said and done, life is much easier if you just use an argument
which does indeed resolve to an 'A' RR which does match the sending client's
IP and if the sending client's IP resolves to a matching PTR record (I've
chosen to completely ignore the part of the argument about MUST NOT refuse
if they don't match). Also, there is no reason to believe that a sending
client will be a 'MX' or accept email from the Internet, so in the general
case and rules written applying to receivers/MXs have no bearing whatsoever
on what rules or guidelines a sender/client MUST or SHOULD follow.
What we have is a set of conflicting sections with MUST, SHOULD and
"if possible" in RFC2821 and RFC1123 doesn't provide any added help in fixing
the mess.
Paul Shupak
hostmaster at plectere.com
More information about the RFCI-Discuss
mailing list