I've seen various proposals for RMX and variants. There are two major
problems...
1) If a domain can specify which machines can send for it, spammers
simply point their domains' records to trojaned machines, *JUST LIKE
THEY'RE DOING FOR WEBSERVERS AND DNS RIGHT NOW*. And I'd have to keep
up to date on MTA names for 3 ISPs (IStop plus a couple of backups). So
there are no major security benefits, but there is additional paperwork
for me.
2) If a domain can specify which machines it can send for, you're back
to the fiasco at (I thik it was) Bell Atlantic, where for a time, you
could only send out email "From:" your own account, not from a valid 3rd
party or personal domain you were authorized to use.
Let's get back to basics to see why RMX has been proposed. Trojaned
machines have been used to originate spam. The RMX proposal seeks to
set up lists of which machines can tramsit for which domains. This
misses the point of the problem. It's not the authorized MTAs we have
problems with, it's the trojaned home machines, that have no business
whatsoever connecting to port 25 (except to their own ISP) on behalf of
*ANY* domain whatsoever.
So much for criticism; what do I propose as an improvement ?
My proposal is for a NO_XMIT record in DNS. It effectively stands the
RMX proposal on its head. It would signify IP addresses that have no
business connecting to external MTAs. This would be very similar in
function to MAPS DUL(TM) and other lists of dynamic IP addresses. Here
is a sample implementation for discussion...
1) IP address 10.1.2.3, which is not one of your customers, connects
to your MTA wanting to send you mail. "customers" includes those
authorized to ssh/vnc/vpn/etc to your system.
2) Your MTA queries someting like "host -t NO_XMIT 10.1.2.3"
3) If the query returns 127.0.0.2, your MTA may choose to reject the
email. This depends on ISPs wildcarding their dynamic IP address
ranges to return 127.0.0.2.
Notes...
1) Since absence of a DNS record implies accepting the email, NO_XMIT
will "fail safely" during DNS outages; i.e. all email (including
spam) will be authorized, rather than no mail
2) Since absence of a DNS record implies accepting the email, NO_XMIT
is backwards-compatable to systems which haven't implemented it.
If NO_XMIT is widely accepted, non-adopters may be seen as bad
internet neighbours, and be blocked locally, but that's another
thing altogether.
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.
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.
5) Given that IPV6 will get here eventually, it's probably a good idea
to develope an IPV6 version at the same time as IPV4.
--
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg