At 09:46 PM 8/30/2003, Brad Knowles wrote:
At 7:58 PM -0500 2003/08/30, Steven F Siirila wrote:
You missed the point. Spammers do NOT control the DNS for trojanned PC's
and open proxies which appear to be our primary problem now. Direct
spammers
are the easiest ones to catch already; who cares if they want to better
identify themselves?
No, but they control their own DNS. Depending on how this sort
of system would be expected to work, anybody could claim to be an MTA in
{HE|EH}LO, and when you look up the IP address under that domain,
lo-and-behold you find that they are authorized to send mail on behalf of
them -- through a wildcard that you know nothing about.
I never proposed using the value of the HELO; as it said, it is forgeable.
That is only true if you don't require rDNS in addition. I'm not 100%
sure
that everyone is going by the same definition of rDNS I am either. By
rDNS
I am strictly speaking of the connection IP address, it's associated PTR
record, and the A record of the name returned by the PTR.
To make his work, you've got to handle the possibility of the PTR
returning multiple names, and each name returning multiple IPs. You've
got to follow that chain to it's complete logical conclusion.
While that is true in theory, we've gotten by by taking the first PTR returned
and resolving it back to an A record which must match. A site can run
several domains and still have a single A/PTR per MTA if they want to.
This can lead to its own form of DDoS attack on your servers. In
fact, all it takes is a slightly hacked nameserver which generates new
records on the fly, and which returns two names for every IP address and
two IP addresses for every name. In short order, you're going to have
more names and IP addresses to track than you have memory or disk space.
True.
With rDNS I can at least be assured that the owner of the in-addr.arpa
space
is the owner of the domain named in the PTR (or at least an agreement
exists
between the two). BTW, having this domain makes it easier to determine
an
abuse address to send reports to, too.
The rDNS chain gets broken far, far too often. In most cases,
the entity handing out the name has nothing to do with the entity owning
the network space, and vice-versa.
We have found over time that this situation is improving (at least for
legitimate MTAs connecting to us).
Moreover, you are dependant on the RIRs and LIRs doing their job.
Until recently, RIPE was always backed up on getting rDNS delegations
done, to the order of multiple years. During the time I worked there,
Skynet had applied for rDNS delegations for several netblocks that RIPE
had issued to them in the recent past, and as of the time I left a couple
of years later, they still hadn't been done.
These are technical issues that certainly need resolution.
Then there are all the spammers operating out of stolen netblocks
or netblocks that haven't been issued yet, and for which they convince
some poor sod ISP to give them network connectivity.
At best, rDNS checks might stop naieve open proxies and
SoBig-like viraspam networks if they've infected machines that don't have
reverse DNS set up, but it would also catch a lot of SOHO operators that
have their own mail servers and have few options for upstream
connectivity (among others).
While that is true, you can still implement rDNS, especially if you've given
choices to your user base as to how THEY want they blocking to work for them.
For example, we will soon give our users the ability to block entire domains
by name. I won't name any, but I have one particular one I will be blocking
personally due to 100% spam and 0% non-spam.
--
Brad Knowles, <brad(_dot_)knowles(_at_)skynet(_dot_)be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--)
N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++)
R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg