List Mail User wrote on Mon, 19 Dec 2005 05:40:35 -0800 (PST):
> Whose "reverse DNS record"?
The client's.
>
> Actually, I think checking that if rDNS exists, it matches is not
> a bad idea;
it's not a bad idea. But it's not RFC-compatible and bound to FP quite often.
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.
Ahm, yes. There is a slight misunderstanding. I didn't want to imply that you
can
reject based on certain helo requirements and be 2821-conformant. But your
original sentence binds the requirement for identification and the requirement
for not-refusal together. It's not bound together. There *is* a requirement to
helo with correct information. And there *is* a requirement not to refuse if
that
information is wrong. This doesn't wipe out the first requirement.
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).
Well, I don't see an explanation in the document that it's because of this. The
requirement is quite clear: identify yourself, not someone else. Heloing with
different credentials is not correct, even with "best intent".
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).
I'm not sure what FCrDNS means. But just because it's not mentioned doesn't
mean
it's allowed. You can deduce from the document and the meaning is clear:
identify
yourself and don't refuse others because of incorrect data. Saying that rDNS
match rejection is conformant with 2821 is like saying rejecting all blue
servers
is conformant just because it's not explicitly forbidden.
> 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.
No, that's not at all even implied in there. Remember, a machine can carry
thousands of domains. It's not the purpose to identify for which domain it is
sending, but who it is: "who am I".
> 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").
This is a subcase of the whole matching story. It's not allowed. There is *no*
requirement that this check matches, obviously you cannot reject on a basis of
a
non-requirement. See above: rejecting blue servers.
If you want to be strict you could argue that the only way for the client to
know
*for sure* "who am I" is to do a reverse lookup (otherwise he can't assure that
what he grabs from /etc/hosts or HOSTNAME is accurate and unique and really
identifies itself) and thus construct this requirement. Nevertheless, you still
clash with the requirement not to refuse because of wrong data.
>
> 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.
No. The only rationale for this argument given in the document (or maybe it's
another RFC, I don't remember) is that the machine can identify loops. It's
clearly a *machine* identifier. Nothing else makes sense. The sending
organization is known from the email address.
> 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).
All of that is not of interest at all in this document.
> If it were a requirement that HELO/EHLO argument -> client IP,
> there would be no reason to have the argument.
It *is* a requirement. You are just not allowed to refuse if the client fails
to
do this. Which means if a client wants to assure delivery he better complies or
he risks getting rejected by someone who doesn't obey this rule. It's like
using
rubber wheels on a street because wheels of steel may prove difficult to use.
I'm going on vacation soon and don't have time to continue such lengthy
discussion. So, wish you a relaxing end of year and if you want to follow up I
suggest moving it to private mail.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
