On Wed, 12 Nov 2014, Lee Howard wrote:
You've combined issues. Mail servers rejecting mail from unmanaged networks (such as houses) is a feature.
There is no such thing as a "mail server". There are hosts on the internet, and some of them send and receive email. Access Providers love restricting features of their IP addresses. It reduces human resources in the complaint department. Which we should try to solve differently so access IP's don't need to be artificially restricted. If the access provider has a webfarm too, they have an incentive to demote their access IPs in favour of their webfarm service. The current anti-spam race is dangerous. We are forcing endusers to do email via a select few mail providers. This encourages advertising, centralised control and censorship. We are already seeing a next step in this race. People hire something cheap in a cloud like AWS. And those IP ranges have already started to get their first "untrusthworthy" marks. Some VPN service providers noticed that some cloud IPs are blocked for browing because often their competition uses those cloud IPs to suck down a copy of their entire website/datastore. I fully understand the need to filter/ban misbehaving IP addresses. But the PRT method is just so bad. The reason ISPs put stupid PTRs in there is also to reduce cost/complains from their users. Those who blame the ISPs are the ones that encouraged it by blocking things without PTRs. Extending that to block "recognised auto-generated PTRs" is continuing a bad race. It would not be too hard to write down something that would fix this for SMTP. We have DKIM/DNSSEC which is a much better method for determining whether or not a message coming from an IP without PTR should be dropped or not. If needed, the HELO could be extended so the receiving SMTP server can present a cookie to be signed by the incoming SMTP server based off a public key in DNSSEC for that zone. Which would allow an SMTP server to refuse receiving the actual data. Doing PTR records is actually more of a risk than a benefit. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
