In <20030303092027(_dot_)GA3073(_at_)danisch(_dot_)de> Hadmut Danisch
<hadmut(_at_)danisch(_dot_)de> writes:
Why this is superior to Adam Filip's proposal (
http://groups.google.com/groups?q=vixie+mx+records+spam&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3E18B0B3.43939A35%40Andrzej.Adam.Filip&rnum=10
) to overload the existing MX record?
This proposal appears to overload A records, not MX records.
Basically, it creates a domain name specific DNS blacklist which could
use the same machinery that is already available and in use for all
the various other blacklists. It would require no changes to the name
servers and only very minor changes to MTAs. In the case of sendmail,
"all" it would take is hacking on the sendmail.cf file.
When IP address w.x.y.z connects and claims they are from domain
example.tld, the MTA and/or the spamfilter would do a DNSBL check on
z.y.x.w.smtp-out.example.tld in addition to checking
z.y.x.w.bl.spamcop.net and such.
First, MX records are not meant to be used for that. If you want
to keep the Internet working, use things in the way you are supposed
to do. Using them in the reverse way violates the definition of MX.
This proposal doesn't involve MX records and all the various DNSBLs
prove that it is practical.
Second, it doesn't work and it is too much overhead, because there
is one indirection step missing. Assume that I want to authorize
the relays of my hoster rackland and another set of relays, e.g.
by an employer or some ISP for originating mails from danisch.de.
"All problems in Computer Science can be solved by another level of
indirection"....
There is no more overhead than existing DNSBLs.
More importantly, I suspect that the majority of email traffic would
be sent by domains that would not need this extra level of
indirection. I suspect that this RMX proposal would actually have
greater overhead.
If you really needed this extra level of indirection, you could hack
on bind to do the recursive lookups on other domain specific
blacklists that you are interested in. Hacking on bind would be
required for the RMX proposal anyway, but only the domain that needs
this extra level of indirection would need to be updated.
Third, DNS software is ready to be extended. [ ... ] As soon as the
record type has become a standard, it will be incorporated into the
main distribution. Adding a new record type to a DNS server is not
a big deal.
This adds another hoop that people have to jump through.
How much software has to be changed to support this new record? What
if a users wants to set up SpamAssassin on their local machine to
check the RMX record and doesn't have control over the nameserver they
use? Would they still be able to do it? (Clearly, the domain
specific blacklist would be no problem.) Would people need to update
their resolver stub?
No, the DNS server software is not the problem. It will be more
difficult to convince the MTA software vendors. But that's the
same problem as with the MX proposal.
I suspect that getting the MTA and spamfilter software vendors to
implement a domain specific blacklist would be pretty easy.
IMHO, the hard thing is to get a bunch of the larger ISPs to support
either the RMX or the domain specific blacklists. Every time they add
a new server, they will have to remember to update the list and if
they don't, only a few people who run bleeding edge anti-spam systems
will notice.
-wayne
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg