Eric,
I believe that you have misinterpreted (and only partially quoted)
RFC2821. A more correct interpretation (or at least different) and a fuller
set of quotations is below.
>
>SA 3.0.2 currently performs a handful of tests against HELO greetings that
>contain an IP address. These tests don't currently fire when an "address
>literal" is used in the HELO greeting, but they should.
>
>See section 3.6 of RFC 2821:
>
>| - 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.
>
"
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:
..."
Nothing in either the section you have quoted, or the one I have
allows a hostname which is not a FQDN to be used.
and then section 4.1.1.1 "downgrades" the "MUST" which you quote to a "SHOULD".
"
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.
..."
(The 'y' which is apparently misplaced exists in the original document, it is
not a "typo" by me.)
Please note there is absolutely no requirement for an 'A' record;
My domain does not have one! The requirement is for either an 'A' record
or an 'MX' record. Admittedly, the "requirement for an 'A' record is indeed
recommended as a "SHOULD", but is not not a "MUST". Section 4.1.1.1, while
not as clear as it should be, is a catchall that basically allows anything
at all that is a possible FQDN and that is not identifiable as a CNAME (it
is legal in general for a CNAME to otherwise also be a FQDN, I have subdomains
for which this is true - I just don't send mail from them). Also there is no
wording requiring the recommended "reverse mapping record" be an 'A' record,
any record will suffice (even a 'RP', 'TXT', 'WKS' or 'HINFO' etc.).
Also, note that RFC2821 is *still* on the "standards track" and has
not yet (and probably like most RFCs will never be) ratified (though RFC821
was and thus is still valid despite the intention for RFC2821 to replace it).
Further, the section you do quote makes clear that hostnames which are
not also FQDNs are illegal (yet that is actually the standard practice in use).
In other words using any old hostname to a HELO/EHLO is *not* legal by RFC2821,
but rather it is intended that one use a domain name (which, of course may be
a subdomain) which "SHOULD" have an 'A' record *or* "MUST" have an 'MX' record
*or* "SHOULD" use an address literal (with the caveat that 4.1.1.1 makes, most
probably because of oversight, nearly anything legal which could be interpreted
as a FQDN - hence hostnames, which are recognizable, but not identifiable
domains themselves, strictly should get a 4xx response, but I've never seen
a system which does that).
The only examples I still know of which abide "strictly" by RFC2821
are "sgi.com" and "ibm.com". "sun.com" used to, but doesn't anymore (I have
over a decade of logs to demonstrate this). And the most common case of using
a hostname which is not also a FQDN is clearly not allowed (again, despite
that being the standard practice) - i.e. FQHN != FQDN.
>and section 4.1.3:
>
>4.1.3 Address Literals
>
>| Sometimes a host is not known to the domain name system and
>| communication (and, in particular, communication to report and repair
>| the error) is blocked. To bypass this barrier a special literal form
>| of the address is allowed as an alternative to a domain name. For
>| IPv4 addresses, this form uses four small decimal integers separated
>| by dots and enclosed by brackets such as [123.255.37.2], which
>| indicates an (IPv4) Internet Address in sequence-of-octets form. For
>| IPv6 and other forms of addressing that might eventually be
>| standardized, the form consists of a standardized "tag" that
>| identifies the address syntax, a colon, and the address itself, in a
>| format specified as part of the IPv6 standards [17].
>
>Technically, addresses that are NOT enclosed in brackets are illegal, but
>those are the only ones that SA sniffs out currently.
Of course, my machines just refuse these during the SMTP conversation,
long before SA gets involved - They are neither address literals nor possible
FQDNs (no TLD has only digits). BTW. This is/can be a setting for either
sendmail or Postfix.
>
>Extending the current rules to include literals can probably be done by
>simply changing the sniff code to look for open and close brackets, but I
>haven't looked so I'm just guessing. As far as that goes, the tests might
>already do this, and just not firing.
>
>I think the four affected rules are RCVD_HELO_IP_MISMATCH,
>RCVD_NUMERIC_HELO, RCVD_ILLEGAL_IP, RCVD_BY_IP
>
>
>--
>Eric A. Hall http://www.ehsco.com/
>Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
>
Please be careful and check the definitions and references in each
document (usually incorporating, by reference a half dozen or so other RFCs
and documents, some of which have been superseded, some of which are intended
to be, and others which have expired without acceptance, but which give the
definitions needed for interpreting the document at hand). Going through
these documents is like untangling spaghetti in most cases - it helps to both
use the set of copies at ftp://ftp.rfc-editor.org/ and to have an original
set of the DOD reference manuals at hand (i.e. the 1985 3 volume set).
Paul Shupak
[EMAIL PROTECTED]
