The meaning of this is that our mail server should refuse to accept emails from another mail server that does not have a PTR record on the DNS. A PTR record maps an IP address to a domain name. It’s like the reverse of an A record.
This check is intended to prevent emails from spammers. However I think that we should not use it in our mail servers, for these reasons:
Getting a PTR record for your server is not easy. It does not depend on you (on the configurations that you may do), but depends on your provider (ISP or VPS provider), on its technical capabilities and on its will, sometimes maybe on the amount of money that you can afford. A person that wants to have his own mail server most probably will not be able to afford it. So, it is not a good indication of spammer vs. non-spammer. By using it on our own server we penalize non-powerful users (like us).
I think that GMail and other systems don’t pay much importance to a PTR record too. If you have SPF+DKIM+DMARC set properly, your mails will not end up as spam. A mail never is discarded or considered as spam just because the sender does not have a PTR record. However the Postfix rule above does just that, it rejects a mail if the sending SMTP server does not have a PTR record. It is a very strong restriction.
What is your opinion? In your experience, how easy or difficult is to get a PTR record for your server?
I beg to differ. Rejecting e-mail or even SMTP sessions from clients without PTR record or with reverse/forward DNS mismatch is more or less best practice. For IPv6 connections, Google has been doing this from the beginning. If your ISP does not offer you PTR records for your servers, you should find a new one. Of course getting a PTR for your DSL or other home internet connection is a different story, but these IP ranges are blocked by many e-mail servers anyway.
That said, the technologies you mention are not sufficient as anti-spam measures (SPF is broken by design anyway IMHO) and there is much more information about a client and the actual message content that should be part of your spam rating.
Getting a PTR record for your server is not easy. It does not depend on you (on the configurations that you may do), but depends on your provider (ISP or VPS provider), on its technical capabilities and on its will, sometimes maybe on the amount of money that you can afford. A person that wants to have his own mail server most probably will not be able to afford it. So, it is not a good indication of spammer vs. non-spammer. By using it on our own server we penalize non-powerful users (like us).
that is simply not true.
yes, for your home contract dsl line, it will not be easy.
for any buisness contracts with fixed ips addresses or server
hosting (be it colocation, VPS, rootserver, …) it is usually not a
problem (though the level of simplicity can be anything from the
zone beeing delegated to a dns server that you control yourself, a
webinterface or the need to open a ticket).
if there is no option for that you will sadly need to find a
different provider to host your mailserver (and depending on how you
read RF1912 you could consider it broken even non-mailserver usage,
though for a lot of usages it’s probably not a major hassle)
I think that GMail and other systems don’t pay much importance to a PTR record too. If you have SPF+DKIM+DMARC set properly, your mails will not end up as spam. A mail never is discarded or considered as spam just because the sender does not have a PTR record. However the Postfix rule above does just that, it rejects a mail if the sending SMTP server does not have a PTR record. It is a very strong restriction.
this is a false impression.
yes, SPF, DKIM and DMARC play a role (for some of these providers,
though not as much as one would thinkg), though you will have a hard
time getting mails delivered without it see
“Follow recommended IP practices”[0] for gmail and
“Are you advertising yourself as a non-routable IP?”[1] for MS hosted mailservices,
similar policies have existeted for years now for big and small mail servers
(i’m just using 2 big examples as they are publishing (at least part
of) their policies in that regard and also because they (sadly) are
usally quite a big junk of the mail volume you handle.
generally, the ptr record is a way to check if you actually have
control over the ip you are using instead of just running “somthing”
there…
by the way, bigger providers also started to reject generic ptr
records like ipXXXX.someprovider.com if you try to get around the
setting of a proper ptr record and just try to use the generic name
in the HELO/EHLO.