In message <86A2A76C-EA14-462A-B9DE-122E803A09EA@no8.be>, "Niall O'Reilly" <Niall.oReilly+ripe@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