>...
>On the contrary. That's exactly what it asks for. The key for understanding
>the
>requirements here is "client identity".
>
>If we rewrite it this way:
>
>> So we find it is actually not only *not* contained with RFC2821
>> any requirement that the HELO/EHLO argument match the reverse DNS record,
>> but we find an explicit prohibition on refusing a transaction because of
>> the lack of match.
>
>it makes sense. I don't know if you wanted to say this.
>
>Kai
>
>--
>Kai Schätzl, Berlin, Germany
>Get your web at Conactive Internet Services: http://www.conactive.com
>
Whose "reverse DNS record"?
Actually, I think checking that if rDNS exists, it matches is not
a bad idea; But the actual prohibition is on the forward DNS (or even the
supplied address literal, as stupid as that seems) not matching the client
IP is being used for rejection. Basically this is to allow a "service" such
as where domainA handles mail for domainB, and being "smart" does a HELO/EHLO
using domainB as the argument when sending mail for domainB; This leads to
the situation where the client's IP is domainB (or some host contained within
it), but the the HELO/EHLO argument "seems" unrelated (since the receiver has
no knowledge of a relationship between the domains). Also, there is no rule
against requiring that the client's IP meet FCrDNS, hence that is the common
check that is applied (and not prohibited).
The classic case of checking for FCrDNS is to check for:
client IP -> hostname -> clientIP
and/or (with the exceptions below - a useful test, but not always possible)
HELO/EHLO arg -> some IP -> HELO/EHLO arg
NOTE: There need not be any relationship between "client IP" and "some IP"
in the two cases above (if indeed the "some IP" can even be found).
To consider the notion of "client identity" (which is a valid way
to view the concept), we must include also the case of agency - i.e. the
client is acting as an agent of the domain identified in the HELO. This
has many analogies outside the computer world - Try calling a company's
service center, help line, etc. when it has been out-source'd - often the
person answering the telephone will "identify" themselves by stating the
name of the company whom you are trying to contact, while in fact they
work for and are physically at a different organization that is acting
as an agent for the company you are trying to contact. An even better
case is if you leave a message (telephone, email or by web page) and you
are called back by someone who states that they are calling for or from the
company you wanted to contact, but in fact they do not work for or at that
company (this case is the equivalent of the email HELO/EHLO - "Hi, this is
John from companyX service center, you left us a message...", when in fact,
John works thousands of miles away for and at companyY, not company X).
For the second case above, if the argument does not resolve to any
IP but does resolve to at least one 'MX', the qualifiers in 2821 leave out
any chance to check the second half of the argument - i.e. the forward part
of the FC ("full circle") - some IP -> HELO/EHLO arg. You can still always
check FCrDNS on the client IP and reject on that basis if there is a lack
of mapping (the prohibition is on rejecting because "client IP" != "some IP").
In fact, it is fairly common for people to pose the question, "Why
is there any argument to HELO/EHLO at all?". After all, by the nature of
the TCP protocol, we know unambiguously the client's IP, which is a unique
identifier; The answer is that the HELO/EHLO argument give us, rather than
the identity of the sending machine, the identity of the organization (re.
domain) on whose behalf the mail is being sent. This information is useful
simply because of the situation where a client is acting as an "agent" for
an organization (re. again as domain) to which it does not belong, but is
authorized (in a manner which may *not* verifiable or even knowable to the
receiver) to take action(s) in the name of (the classic "legal" sense of
the term - under common law or the UCC - but IANAL). When viewed in this
way, it becomes clear why the early text specifies "HELO <domain>" and not
"HELO <host>" or "HELO <client>", either of which would only provide redundant
information.
And of course, the additional cases of virtual hosts sharing a
machine (and IP address), but wishing to give the name of the domain sending
the email, rather than merely the and identifier mapping to the hosting
campany or the case of an organization with multiple domains sitting behind
a common NAT'd IP address wishing the same, are provided for by interpreting
the HELO/EHLO argument of the idenitifer of the originating organization (re.
again as domain), not of the owner of the IP which may be visible to the
receiver (which as stated, is already unambiguously defined).
If it were a requirement that HELO/EHLO argument -> client IP,
there would be no reason to have the argument.
Paul Shupak
[EMAIL PROTECTED]
