At 09:04 AM 7/13/03 -0400, Alan DeKok wrote:
[heavily edited]
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org> wrote:
My proposal is for a NO_XMIT record in DNS.
[...]
It would signify IP addresses that have no
business connecting to external MTAs.
This is semantically identical to the DUL blacklists, but
implemented differently. It shares the DUL problem, in that
administrators have to sign up to an "opt-out" list for it to work.
Experience has showed that opt-out lists are problematic. In
addition, there are ~2^32 possible machines which are not dedicated
MTA's, and ~2^18 or so long-lived MTA's. (See previous stats posted
to the list)
So an "opt-in" list of "yes, I'm really an honest ISP" would be
smaller, and probably more effective.
2) Your MTA queries someting like "host -t NO_XMIT 10.1.2.3"
Implicit in that statement is a global manager for the list, similar
to the existing reverse map.
i.e. You're looking up IP's, not domains. So this proposal *cannot*
be implemented by updating DNS for a domain, there *must* be a global
registry.
3) This proposal depends on ISPs wildcarding their dynamic IP address
ranges to return 127.0.0.2. However, it will have much less
logistical hassle than trying to maintain *UP-TO-DATE* lists of who
can send for whom from which IP addresses.
Is it really that difficult to update a reverse record, at the same
time as you update an MX record?
4) I'd prefer to use strictly the 127.0.0.2 return value for rejection.
This would allow for future extensions, e.g. 127.0.0.3 might mean
that an RMX record exists, and you can further query it if you wish.
TXT records?
Markus Stumpf in a post apparently archived at
http://www.ripe.net/ripe/mail-archives/anti-spam-wg/2003/msg00175.html
suggests a TXT record using the same FQDN as the rDNS record.
I.e. - each valid outgoing mailserver should have a TXT record
in reverse DNS like:
3.2.1.10.in-addr.arpa IN PTR mail.example.com
IN TXT "MTA=yes"
Or
3.2.1.10.in-addr.arpa IN PTR mail.example.com
IN TXT "MTA=no"
You could use A records;
3.2.1.10.in-addr.arpa IN PTR mail.example.com
IN A 127.0.0.1
or both for that matter,
3.2.1.10.in-addr.arpa IN PTR mail.example.com
IN TXT "MTA=no"
IN A 127.0.0.2
but I think the RFC 1464 method is cleaner, and allows for additional
TXT records like "ABUSE=mailto:abuse(_at_)example(_dot_)com" and other
expansion.
Some comments;
If widely adopted, this would effectively stop spam from
open proxies and cracked machines. It might even stop spam
from hijacked IP addresses, depending on how the rDNS is designated.
It's relatively painless, but it does require some effort
on the part of the rDNS owner.
There is a conflict between the user of an IP address,
and the owner of the rDNS record. Many ISPs do not currently
allow the end user to set the rDNS record for the IP they use.
Many others only allow it with the payment of very high fees.
Dynamic IPs have special problems, and probably wouldn't
be able to do it in most cases. The net effect is that
when "permission to send email" is set by the rDNS owner,
some currently valid, non-spamming mail servers lose the
ability to send email.
The usual chicken and egg problem applies.
This can be mitigated in the usual way - IPs which have neither
a "MTA=yes" or "MTA=no" entry can be checked against a third party
list (probably DNS based, but it could be anything really).
There will always be IPs for which no record exists,
but that isn't any worse than what we have now (nothing).
Scott Nelson <scott(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg