Re: Working around recalcitrant ISP wrt rDNS

[lst_hoe02]

Zitat von li...@rhsoft.net:

Am 05.02.2015 um 11:03 schrieb lst_ho...@kwsoft.de:

You are putting too much of meaning in a DNS token. There is no global
rule or RFC about the interpretation of the string forming this token.
I'm totaly free to call my host bad-host-static-0815.example.com.

which is no problem because it don't match
[\.\-]?[0-9]{1,3}[\.\-][0-9]{1,3}[\.\-][0-9]{1,3}[\.\-][0-9]{1,3}[\.\-]

The problem still stands. Because some provider choose to "name" their IP with that schema does not mean no one should be able to choose a name for their hosts like that.

There are a lot of zombies in the *.comcastbusiness.* PTR space, but
you throw out the baby with the bathwater.  There are other ways to
get rid of the zombies on static IPs without wholesale blocking.
Greylisting and a couple reliable RBLs (or postscreen) will block
the vast majority of zombies without wholesale slaughter.

you did not get the point:

if PTR's with a IP-part would be rejected worldwide and ISP's would
block outgoing port 25 for homeusers the business of infect client PCs
to send out malware to MX hosts would die from one day to the next

* greylisting does *much* more harm be it for large senders
 retry with a dfiierent IP or sender verification on the
 other side for your own outgoing mail

It is true that it is more burden for the sender, but that is *always*
the case with spam preventing systems

no it's not always

greylisting slows down legit mail too

E-Mail is and ever was store-and-forward, so occasionally longer delays are by design, rejects or vanish in dustbin because DNS names choosen are not.

* all the dialupo RBLs are far from complete

You don't need them

* other RBLs are way too late, if someone makes it on them
 he already had sucess in send his crap out

With greylisting the RBL has time to settle

---------------------------------------------------------------------------------------

195-154-48-147.rev.poneytelecom.eu (195.154.48.147)

* RBL: b.barracudacentral.org
* RBL: bl.mailspike.net
* RBL: dnsbl.inps.de
* RBL: dnsbl.sorbs.net
* RBL: dnsbl-uce.thelounge.net
* RBL: zen.spamhaus.org

Jan 29 22:57:40: 195-154-48-147.rev.poneytelecom.eu: PTR 615; ****; ****
Jan 30 05:38:49: RBL inps.de; ****; ****
Jan 30 05:39:00: RBL inps.de; ****; ****
Jan 30 05:39:10: RBL inps.de; ****; ****
Jan 30 05:39:17: RBL inps.de; ****; ****
---------------------------------------------------------------------------------------

with a well desigend PTR filter you don't have the delay of greylisting and 95% of the PTR rejects are *later* in enough of the 28 RBL's of the postscreen mix - it looks like below

* there is no single reason for not have a sane PTR

I'm free to call my hosts as i like as long as it is a valid DNS token

surely, you are free to configure your server in a way to get delivery problems and since a lot of customers only hosting DNS here insisted to get a SPF record for avoid their mails going to the spam folder at gmail and other large providers virtually nobody has such a generic PTR and at the same time no SPF *and* no DNSWL entry

You are right in the case that the concept of SPF and DNSWL and the like in the same liga. They are used for spam fighting which they are not really useful for. The most part of our spam reaching inbox for example is perfect SPF/DKIM validated, most of the "ham" we get is not. You say that greylisting slow down mail/sender but the way larger problem is that PTR parsing, SPF/DKIM whatever cruft introduces additional failure point which prevent mail delivery at all.

* postfix has even a setting that A/PTR needs to *match*
 and if someone enables that we no longer dicuss about
 the PTR part in the reverse DNS at all

This is not related at all. With a matching PTR there is some *week*
evidence that i'm the "owner" of the IP, nothing more.

it * is* related because if it is no longer a 123.123.123.123.isp.tld but your domain it is *not* some infected *enduser machine* and all the dialup-rbls are far away from complete

See, even you don't block everyone with an offending PTR -- you
check for valid SPF or dnswl

because the intention is *not* to block mailservers
a random enduser IP i not listed in the SPF record nor on DNSWL's

We don't care about DNS names and we do not even check for matching PTR
or SPF,DNSWL and the like and still our spam ratio reaching the inbox
from random dial-ups is below 5%. The vast majority of spam are the
famous freemailer like Yahoo,Hotmail,Google some hacked edu-accounts and
the well connected SPF/PTR whatever clean spam centers around the world.

that are *your values*

we have some hundret domains and around 1200 mailusers
97% of the 473209 in the last month rejected by RBL would


Connections:       531224
Delivered:         58015
Blocked:           473209

have hit the PTR filters too and 90% of all incoming legit mail have SPF or are on one or more DNSWL

The ration in our case is similar *without* PTR/SPF/DKIM/DNSWL checking at all...

So no, to construct some meaning to DNS token which is not there is not
useful at all.

for you - that may change quickly

there are days with no single RBL reject and then there are days where within 20 minutes 50 dead-safe phishing mails are blocked where the sending IP is not on enough of the 28 RBL's in the postscreen mix and SpamAssassin catches only parts of that or is way too epensive when the amount of incoming trash get too high

Regards

Andreas

Content-Filtering is another evil story. But enough on this topic. If you are confident with your rules and your users agree you are fine, but do not try to force unrelated others to agree to random self invented rules. With this you will only break e-mail even more than it is today.

smime.p7s
Description: S/MIME Cryptographic Signature