[anti-abuse-wg] Reliance on rDNS

In message <86A2A76C-EA14-462A-B9DE-122E803A09EA at no8.be>, 
"Niall O'Reilly" <Niall.oReilly+ripe at no8.be> wrote:

>On 4 Aug 2017, at 20:46, Ronald F. Guilmette wrote:
>> I do agree completely.  However as is made clear by this exact case,
>> there are enough inbound mail servers still left on this planet that
>> do not follow that rule {to accept only inbound mail from SMTP clients
>  with reverse DNS implmented}
>
>  This is not a "rule", but a heuristic of first approximation which,
>  if relied on exclusively and dogmatically, has the consequences of
>  arbitrarily penalizing the innocent, breaking network neutrality,
>  and violating the end-to-end principle.
>
>  Any of these consequences is itself an abuse.
>
>  Email administrators and reputation brokers have other information
>  and processes available to them which can be used to mitigate these
>  consequence when appropriate.  Failure to do so is either to play
>  the bully or complacently to take the lazy option.

Well, actually, I do agree, mostly, with Niall O'Reilly's primary point
here, and I apologize for having been a little less than precise in my
earlier comments on this topic.

For my own mail server, I determined some long time ago that I simply
did not wish to receive any more inbound emails from any SMTP client
IP address for which I was not able to definitively tie that specific
IP address back, conclusively, to a specific domain name... a domain
name that I could hold responsible, e.g. if the email in question later
turned out to be spam.

There are a couple of ways to make exactly such a definitive connection
between an SMTP client's IP address and a specific domain name.

The simplest and most obvious is to check and see that the IP address in
question has some reverse DNS name, and then forward resolve that and
check that this gets us the same IP address.

A second method however is take the domain name given in the SMTP
HELO or EHLO command, and try to forward resolve that.  If that FQDN
has a forward resolution, and if the forward resolution matches the
IP address of the present/current SMTP client, then I and my mail
server will also accept the inbound mail... subject of course to
various blacklists, including my own local one.

I was motivated to implement this somwhat more liberal approach to
establishing the identity of a "responsible domain name" for each
incoming email by some concerns that were similar, but perhaps not
identical to those expressed by Niall O'Reilly.  I did not want to
inappropriately or unfairly penalize any mail senders who, through
no real fault of their own, could not obtain reasonable cooperation
from their service providers, e.g. to set up proper reverse DNS.

My acceptance of inbound emails from SMTP clients that at least can
properly identify themselves via HELO/EHLO is both approprite and
helpful, I think.  (And when I say "helpful", I mean helpful -for me-.)

That all having been said, I do think that Niall O'Reilly put his
case a bit too ardently, and I don't think that any hyperventilation
about "network neutrality" or "the end-to-end principle" (whatever
the heck that is) either can or should affect people's decisions
about what they will or should accept email from.  These decisions
are, for most of us, a matter of pragmatic considerations... we want
the mail we want, and we don't want the mail we don't want.

I am satisfied with the specific set of tradeoffs that I personally
have made for my own mail server, and I think that they well serve
my own pragmatic goals, even as they also may tend to nudge some
mail senders in the direction or what I feel is more reasonable
behavior.  (For example, even though the RFCs allow it, I personally
do not allow my mail server to accept mail where the argument value
given in the HELO/EHLO command is provided in the form [A.B.C.D].
My preceeding comments regarding my desire to have a verified
"accountable" domain name for each inbound email should make the
reasons for this choice apparent and obvious.)


Regards,
rfg