Opinions on RDNS - A layer of anti-spam protection?
Danny
lists at brenius.com
Tue Jan 21 00:39:26 UTC 2003
Greetings,
I realize that reverse DNS is not manditory, but I believe that it can
be used as *a* layer of protection against spam/mail-abuse/etc.
What are your thoughts on part of this thread below?
Thank you,
Danny
(The message below and the message thread it was a part of, will
probably be up on the isp-tech archives in the next while, so I do
not see any harm in forwarding part of this thread. If there is, please
excuse my ignorance, as I do not see anything wrong with it.)
----- Original Message -----
From: "Dean Anderson" <dean at av8.com>
To: <isp-tech at isp-tech.com>
Sent: Sunday, January 19, 2003 2:24 AM
Subject: [isp-tech] Re: bloody and BAD IPs
> From: Phil Howard <phil-isp-tech at ipal.net>
> Date: Mon, 13 Jan 2003 15:34:40 -0600
> X-Message-Number: 5
>
> On Sun, Jan 12, 2003 at 06:43:47PM -0500, Danny wrote:
>
> | So, not only does Dean promote open relays, he also does not
> | recommend using reverse DNS. Not much of a surprise, here.
>
> I noted that he said RDNS is not required. This is true since it
> is merely recommended.
Wrong. It is _not_ "recommended". It is _OPTIONAL_
> Including those that don't have the matching A record when they do have a
> PTR record, I found that 71.4% of rejected mail on my personal mail server
> (the one where I am most aggressive) is from these "unknown" addresses.
One of the presenters at the MIT conference remarked that one has to know
whether you are blocking spam or legitimate email. Clearly, you only know
that 71% is was blocked for a certain reason. You have no idea whether you
are blocking spam or ham.
> One reason I do this is to ensure I have an extra level of identity on
> whose mail server is sending junk. If their network registration is not
> right (frequently, such as unSWIPPED, broken rwhois, false info), then
There aren't any such things. _EVERY_ network is registered to someone
from a registry. Almost none of that has false info. Where there are
mistakes, it is due to relocation and consolidation. Mailing addresses
may not work as listed, phone numbers often don't work, but it is trivial
to contact the company/ISP that is responsible for the space.
Further, _YOU_ can't know whether someone ELSE has delegated space and
left it unSWIPPED. SWIP is encouraged for some blocks, but again, not
required.
> I at least have another shot (and have even gotten a domain disabled for
> false registration data) and another way to block specific culprits while
> minimizing collaterla damage (e.g. by blocking their domain name instead
> of blocking an arbitrary subnet around their address).
Getting a domain terminated for false data is different than RDNS
problems, or address registration. They are not related.
> From: "James-lists" <hackerwacker at cybermesa.com>
> Date: Mon, 13 Jan 2003 15:27:51 -0700
> X-Message-Number: 8
>
> > I noted that he said RDNS is not required. This is true since it
> > is merely recommended.
>
> If you buy your address space from ARIN, rDNS is required.
ARIN cannot change RFCs, and has no authority over RDNS.
> From: Len Conrad <LConrad at Go2France.com>
> Date: Mon, 13 Jan 2003 18:13:36 -0600
> X-Message-Number: 11
>
> >Clearly, your decision making isn't all that good.
>
> Couldn't resist an unsubstantiatd, content-free ad hominem, could you? Can
> you substantiate your opinion or are you just looking for a pissing match?
Nonsense. It was a substantiated ad hominem. Truth is a complete defense.
My opinion is substantiated in RFC 1034 and 1035.
> >This won't work if the machine is multi-homed. In such cases, the reverse
> >record might not match the forward record.
>
> Correct, the table of sender.domains that are to be verified are known not=
> to be multi-homed. The outbound ip's and domain names of the big ISP's are=
> not multi-homed so this test is effective, as we have proven in practice=20
> for months.
So, your mail breaks the minute some large ISP decides to multihome a
server? Goooooooood.
> > > All the big ISP's do this,
> >
> >Wrong again.
>
> Why do you embarrass yourself in front of the entire list?
You mean, "why do I embarrass you in front of the list?" Well, its fun, I
guess.
> gives:
>
> AC97C37D.ipt.aol.com[172.151.195.125]
^^^^^^^^^^^^^^^
You want to retract that?
> imo-d02.mx.aol.com[205.188.157.34]
> The AOL outbound MTA'a are not using $generate or whatever for PTR=20
> hostnames of their servers.
So? The rest of their "spammer" space has RDNS.
> And, I=B4ll leave it to you to query for the A records of those PTR=
> hostnames=20
> to see if there are any with multiple A records.
You seem to think (wrongly, as usual) that you can generalize from a some
number of ISP's (only one, but I'll say a lot _aren't_ multihomed) that
_NO_ mailservers are multihomed. That's faulty reasoning. Clearly, there
exist multihomed mailservers. Clearly, your [hairbrained] scheme doesn't
work for those cases. Thus, you should be embarrassed.
> Anyway, just to counter your your eternal FUD and knee-jerk naysaying based
> on your theoretical fantasizing, let's verify your FUD as FUD:
>
> %dig AC97C37D.ipt.aol.com a
>
> ;; ANSWER SECTION:
> AC97C37D.ipt.aol.com. 1D IN A 172.151.195.125
>
> Do you think this match was accidental on AOL's part, or by=20
> design? Whatever, the PTR+A test is not applied to DUL's, it's applied to=
> =20
> the outbound server MX's.
It is not accidental. This is just trivial and meaningless RDNS. AC is
hex for 172. 97 is hex for 151. etc. And the in-addr will give you back
the right name. But, pretty much, only spammers will send you mail from
this address.
> So for Elaine's ip, PTR + A record do match. But would have my MTA done=20
> PTR+A validation? No, because boss.com is not in my table of frequently=20
> forged domains.
So, you learned _NOTHING_ as a result of checking the RDNS. Your check
relied _SOLELY_ on the contents of the sender envelope or header DOMAIN
name.
> >Further, an abuser with delegated reverse DNS can spoof whatever they
> >want.
>
> We don't care about the value of the PTR and A hostnames. so the spammer=
> can put whatever he wants for hostnames.
Well, then there isn't any point to checking something you don't care
about, is there?
> For those failing the A+PTR validatiion and are rejected, we know they are=
> true positives.
No, you don't know that at all. You don't know that because there are many
hosts that won't have forward and reverse matches, yet won't be spammers.
> Mail abuse defense has many different weapons to bring to the fire fight,=20
> so let's continue:
Thats well and good. But we aren't talking about things other than RDNS.
> > > and it permits tremendously reducing forgeries
> > > of sender at sender.domain for these frequently forged domain
> >
> >Actually, it doesn't. All of the domains you listed use automatically
> >generated in-addr tables. There is no point in checking reverse DNS for
> >these domains.
>
> BS, see above for AOL outbound MX's. I am talking about the big ISPs'=20
> outbound MX's, not their DUL's, which as a policy we don't accept mail from.
You miss the point. You can re-read the my statement. It doesn't matter
that they don't have $generate for _all_ addresses. It matters that all
_SPAMMER_ addresses will have matching forward and reverse DNS. It doesn't
help to check them.
To the extent that all dialup will have forward and reverse DNS, and only
real mailservers would be multihomed, you will eventually _ONLY_ block
legitimate mail.
> >All of these domains have automatically generated reverse tables. And they
> >still generate a huge amount of spam. None of these rules ever match.
> In fact, had this Elaine not been RBL'd, we would have rejected her anyway,=
> because we also verify that the mx for boss.com accepts mail for user=20
> "big", but the MX for boss.com is dead:
This has _NOTHING_ to do with RDNS.
> So the A + PTR validation is an extremely effective contribution. Your=20
No, it isn't. In the "elaine" example, RDNS played no role WHATSOEVER. Not
only does your example not support your point, it demonstrates that you
have no idea what RDNS does or doesn't do.
> Subject: Re: Reverse DNS (was bloody and BAD IPs)
> From: "Danny" <lists at brenius.com>
>
> Dean Anderson writes:
> > Because people wrongly depend on it as a "security" measure.
>
> Where was this stated?
>
> Security, as with anti-mail abuse, should be implemented in layers. I
> depend on layers, not one "security" solution. With regards to mail abuse
> and SPAM, a mail server lacking reverse DNS, is not RFC1912 2.1
> compliant, and in my thorough abuse dept. experiences, an overwhelming
Apparently, you weren't too thorough in your reading of the RFC's.
> amount of SPAM is relayed or originates from servers without reverse
> DNS. Therefore, a verification for the presence reverse DNS is used
> as a *layer*, not a solution, for combating mail abuse/SPAM.
RFC 1912 is an "informational" RFC. It is not binding on anything. It
doesn't not overrule RFC 1035. 1912 isn't even a standard.
4.2.2 Informational
An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation. The Informational
designation is intended to provide for the timely publication of a
very broad range of responsible informational documents from many
sources, subject only to editorial considerations and to verification
that there has been adequate coordination with the standards process
(see section 4.2.3).
Specifications that have been prepared outside of the Internet
community and are not incorporated into the Internet Standards
Process by any of the provisions of section 10 may be published as
Informational RFCs, with the permission of the owner and the
concurrence of the RFC Editor.
> Subject: Re: bloody and BAD IPs
> From: Phil Howard <phil-isp-tech at ipal.net>
> But they do have to have authority over the domain they put on the PTR
> record, as long as you also verify that the name has an A record that
> matches the connection.
> What this gives you is that the owner of the
> domain sanctions that IP address. It's certainly not authentication
> strength, but it's a little more to go on.
It doesn't give you even that because all you have is a domain name, which
is probably falsely registered. In other cases, both DNS responses might
be spoofed. You need the IP address. Only the IP address is useful.
Nothing else is.
------------------------------------------------------------------
One of the original messages:
----- Original Message -----
From: "Len Conrad" <LConrad at Go2France.com>
To: <isp-tech at isp-tech.com>
Sent: Monday, January 13, 2003 7:13 PM
Subject: [isp-tech] Re: bloody and BAD IPs
> > when trying to decide whether questionable mail from an ip justifies
> > blocking the ip or Class, absence of reverse delegation and/or PTR record
> > for the sending ip weighs heavily in the decision.
>
>That is, it weighs heavilly in _your_ decision.
no, the 1000's of users of heuristic evaluators like spamassassin, etc also
include the absence of PTR in the their decisions to mark/reject a msg as spam.
>Clearly, your decision making isn't all that good.
Couldn't resist an unsubstantiatd, content-free ad hominem, could you? Can
you substantiate your opinion or are you just looking for a pissing match?
> > Furthermore, not only should every ip that sends mail to internet have a
> > PTR record, but the PTR hostname should match that hostname's A record's
> > ip, like this:
>
>This won't work if the machine is multi-homed. In such cases, the reverse
>record might not match the forward record.
Correct, the table of sender.domains that are to be verified are known not
to be multi-homed. The outbound ip's and domain names of the big ISP's are
not multi-homed so this test is effective, as we have proven in practice
for months.
My MTA receives a connect from an ip which alleges to send
as sender at sender.domain. Sender.domain is in my table of domains that 1)
are frequently forged and 2) that are known to have matching A + PTR
records (which excludes a domain name from having multiple A records, but
not from a single ip being shared by multiple domain names).
So my MTA queries for PTR hostname for that ip (best practice is that there
should be only one PTR per ip).
Querying for the PTR hostname's A record, we get back an ip that matches
the sending MTA's ip. So we accept the msg, else reject.
> > All the big ISP's do this,
>
>Wrong again.
Why do you embarrass yourself in front of the entire list?
Here is a fairly large sampling from today's maillog of the PTR hostnames
for the ip's that send outbound for AOL:
mx1# awk ' -i / connect from.*aol\.com\[/ {print $8}' /var/log/maillog |\
sort -f | uniq -i
gives:
AC97C37D.ipt.aol.com[172.151.195.125]
imo-d02.mx.aol.com[205.188.157.34]
imo-d03.mx.aol.com[205.188.157.35]
imo-d04.mx.aol.com[205.188.157.36]
imo-d05.mx.aol.com[205.188.157.37]
imo-d06.mx.aol.com[205.188.157.38]
imo-d07.mx.aol.com[205.188.157.39]
imo-d08.mx.aol.com[205.188.157.40]
imo-d09.mx.aol.com[205.188.157.41]
imo-d10.mx.aol.com[205.188.157.42]
imo-m02.mx.aol.com[64.12.136.5]
imo-m03.mx.aol.com[64.12.136.6]
imo-m04.mx.aol.com[64.12.136.7]
imo-m05.mx.aol.com[64.12.136.8]
imo-m06.mx.aol.com[64.12.136.161]
imo-m07.mx.aol.com[64.12.136.162]
imo-m08.mx.aol.com[64.12.136.163]
imo-m09.mx.aol.com[64.12.136.164]
imo-r01.mx.aol.com[152.163.225.97]
imo-r02.mx.aol.com[152.163.225.98]
imo-r03.mx.aol.com[152.163.225.99]
imo-r04.mx.aol.com[152.163.225.100]
imo-r05.mx.aol.com[152.163.225.101]
imo-r06.mx.aol.com[152.163.225.102]
imo-r07.mx.aol.com[152.163.225.103]
imo-r08.mx.aol.com[152.163.225.104]
imo-r09.mx.aol.com[152.163.225.105]
imo-r10.mx.aol.com[152.163.225.106]
newman-d02.blue.aol.com[205.188.210.41]
omr-d05.mx.aol.com[205.188.156.66]
omr-d06.mx.aol.com[205.188.156.71]
omr-m02.mx.aol.com[64.12.138.2]
omr-m04.mx.aol.com[64.12.138.5]
omr-m08.mx.aol.com[64.12.138.20]
omr-m09.mx.aol.com[64.12.138.21]
omr-r07.mx.aol.com[152.163.225.147]
rly-ip02.mx.aol.com[152.163.225.160]
rly-ip03.mx.aol.com[64.12.138.7]
rly-ip04.mx.aol.com[64.12.138.8]
rly-ip05.mx.aol.com[64.12.138.9]
The AOL outbound MTA'a are not using $generate or whatever for PTR
hostnames of their servers.
And, I´ll leave it to you to query for the A records of those PTR hostnames
to see if there are any with multiple A records.
oh, btw, the first PTR was not an AOL MTA but probably a dial-up account,
Elaine's PC, that got blocked by our much-appreciated RBL:
# grep -i "AC97C37D" /var/log/maillog
Jan 13 16:25:53 mx1 postfix/smtpd[18365]: connect from
AC97C37D.ipt.aol.com[172.151.195.125]
Jan 13 16:25:53 mx1 postfix/smtpd[18365]: C2291142B09:
client=AC97C37D.ipt.aol.com[172.151.195.125]
Jan 13 16:25:54 mx1 postfix/smtpd[18365]: C2291142B09: reject: RCPT from
AC97C37D.ipt.aol.com[172.151.195.125]: 554 Service unavailable; Client host
[172.151.195.125] blocked using rbl-plus.mail-abuse.org;
from=<big at boss.com> to=<kcthomas at xxx.net> proto=ESMTP helo=<ELAINE>
Jan 13 16:25:55 mx1 postfix/smtpd[18365]: disconnect from
AC97C37D.ipt.aol.com[172.151.195.125]
So here we see Elaine on an AOL DUL ip, forging big at boss.com, and trying to
send directly to my MX. She's been caught spamming before and got AOL's ip
listed in mail-abuse.org, or maybe mail-abuse just lists it it DUL.
Anyway, just to counter your your eternal FUD and knee-jerk naysaying based
on your theoretical fantasizing, let's verify your FUD as FUD:
%dig AC97C37D.ipt.aol.com a
; <<>> DiG 8.3 <<>> AC97C37D.ipt.aol.com a
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; AC97C37D.ipt.aol.com, type = A, class = IN
;; ANSWER SECTION:
AC97C37D.ipt.aol.com. 1D IN A 172.151.195.125
Do you think this match was accidental on AOL's part, or by
design? Whatever, the PTR+A test is not applied to DUL's, it's applied to
the outbound server MX's.
So for Elaine's ip, PTR + A record do match. But would have my MTA done
PTR+A validation? No, because boss.com is not in my table of frequently
forged domains.
>Further, an abuser with delegated reverse DNS can spoof whatever they
>want.
We don't care about the value of the PTR and A hostnames. so the spammer
can put whatever he wants for hostnames.
For those failing the A+PTR validatiion and are rejected, we know they are
true positives.
Mail abuse defense has many different weapons to bring to the fire fight,
so let's continue:
> > and it permits tremendously reducing forgeries
> > of sender at sender.domain for these frequently forged domain
>
>Actually, it doesn't. All of the domains you listed use automatically
>generated in-addr tables. There is no point in checking reverse DNS for
>these domains.
BS, see above for AOL outbound MX's. I am talking about the big ISPs'
outbound MX's, not their DUL's, which as a policy we don't accept mail from.
> > aol.com reject_unknown_client
> > msn.com reject_unknown_client
> > hotmail.com reject_unknown_client
> > yahoo.com reject_unknown_client
> > earthlink.com reject_unknown_client
>
>All of these domains have automatically generated reverse tables. And they
>still generate a huge amount of spam. None of these rules ever match.
Again, you are wide of the mark. For the ip's that send their outbound
mail, the match works. We are not talking about DUL. And much more
importantly and to the point, it's not the matches that work we value, it's
the failed matches that we reject.
In fact, had this Elaine not been RBL'd, we would have rejected her anyway,
because we also verify that the mx for boss.com accepts mail for user
"big", but the MX for boss.com is dead:
mx1# telnet boss-polar.bossgame.com 25
Trying 198.179.246.19...
telnet: connect to address 198.179.246.19: Operation timed out
If boss.com's MX won't accept mail to "big at boss.com", then we won't accept
mail from "big at boss.com". Turnabout's fair play, mate.
So the A + PTR validation is an extremely effective contribution. Your
eternally academic, off-mark naysaying is plain silly in the face of mail
admins who use these techniques in practice with great success. If you
would denigrate other's approaches based on your own concrete experience of
trying those approaches, you would be credible. But you don't, so you aren't.
oh, big at boss.com is a virus going around today, so Elaine is probably
infected. Had this message gotten over the above hurdles, our MTA's
"dangerous attachment" blocking rules based on content-inspection would
have rejected it, also. And then the next hurdle is the SMTP virus scanner
machine.
From what I see,
mx1# egrep -i "big at boss" /var/log/maillog | wc -l
1299
... big at boss.com is extremely active today.
Len
_____________ The ISP-TECH Discussion List _____________
To Join: mailto:join-isp-tech at isp-tech.com
To Remove: mailto:remove-isp-tech at isp-tech.com
Archives: http://isp-lists.isp-planet.com/isp-tech/archives/
More information about the bind-users
mailing list