In the spirit of Yakov, here is an interesting cross-post from Dave Farber's IP
list.
This is not intending to advocate RMX or any other proposal, I am merely
forwarding it to give a perspective to some admittedly anecdotal reception of
Hadmut's RMX proposal.
-e
==== Forwarded Message ====
On Friday, May 30, 2003 7:15 PM, Dave Farber [SMTP:dave(_at_)farber(_dot_)net]
wrote:
Date: Fri, 30 May 2003 18:26:18 -0400
From: Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
Subject: ReverseMX: review and suggestions
To: Dave Farber <dave(_at_)farber(_dot_)net>
On Fri, May 30, 2003 at 04:04:36PM -0400, Dave Farber wrote:
| >Spam blockers may wreak e-mail havoc
| > By Declan McCullagh
Content analysis, exemplified by Bayesian filtering, can only go so far.
The best idea I've seen yet is Reverse MX.
Reverse MX provides a mechanism in DNS for domains to vouch for
certain IP addresses; MTAs which subscribe to the ReverseMX philosophy
will only accept messages whose sender domains match the published RMX
ip addresses.
This concept should have been in SMTP and DNS from the very beginning.
It's backed by the Anti-Spam Research Group at IETF.
http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-01.txt
Reverse MX allows Hotmail, Yahoo, and other commonly-forged sender
domains to protect their names. Spammers will have to instead forge
sender domains which have not set up ReverseMX entries in their DNS.
If ReverseMX is widely adopted, only those domains who do not have
ReverseMX set up will show up in forged spam sender addresses. This
encourages domain owners to set up RMX because it is costly to handle
the resulting bounce messages and misinformed abuse complaints.
Spam blacklists can then become domain-specific. Right now most
blacklists go by IP network and for political reasons will blacklist
an entire hosting provider's IP range in an attempt to pressure them
to enforce their AUP against a single spamming customer. I consider
the collateral damage unacceptable; blacklists such as SPEWS cause
more trouble to nonspammers than to spammers. With ReverseMX,
blacklists will contain two types of domains: known spamming domains,
and known "non-RMX-compliant" domains which are the 21st century moral
equivalent of the open relay.
The biggest objection to ReverseMX comes from travellers who want to
send mail from their regular email address from foreign SMTP servers.
The solution is easy: they should connect to their home SMTP server
and authenticate using SASL.
ReverseMX is backward compatible;
it should have been built into SMTP and DNS from the start;
it requires only a few new entries in an existing DNS zone;
in the case of small systems or lazy sysadmins, it can be intuited from
existing MX records;
it is easily implementable in all major opensource MTAs such as sendmail,
postfix, exim, qmail.
I recommend it.
Note 1: Unfortunately, existing antispam vendors cannot be expected to
champion ReverseMX for obvious reasons.
Note 2: DNS may be an imperfect platform, but it's better than
commercial PKI. I give Verisign enough money already.
To encourage adoption, the authors of the major opensource MTAS could
simply declare, by fiat, an arbitrary date by which the ReverseMX
feature should be considered widely adopted. That allows institutions
and ISPs to plan for the change, resulting in a smooth transition.
Without such a declaration, it's harder for everyone to work together
to get over the energy barrier. A generally accepted adoption date
lends justification to ISPs who choose to reject mail on the basis of
RMX failure.
Sometime in the next six months,
1) Standard DNS software such as BIND and djbdns should support the
extensions required for RMX on an experimental, development basis;
2) commercial and opensource MTAs should be patched to support RMX
lookups and record a pass/fail status for each message in syslog
and also as a new header in the message itself:
3) An RMX RFC should extend the RFC2822 standard headers with
(in order of increasing severity)
Received-RMX: pass (client sasl.smtp.pobox.com[64.49.196.25]
in RMX list for domain of sender mengwong(_at_)pobox(_dot_)com)
Received-RMX: error (temporary failure while resolving RMX list for
domain of sender mengwong(_at_)pobox(_dot_)com)
Received-RMX: unknown (domain of sender mengwong(_at_)pobox(_dot_)com
has no
RMX records)
Received-RMX: fail (client
194.red-80-34-201.pooles.rima-tde.net[80.34.201.194]
not in RMX list for domain of sender carolcrowooxh(_at_)aol(_dot_)com)
4) more ISPs should begin to support SASL authentication for their
users, in addition to IP-based relaying. This is already happening.
Then, in the six months before the worldwide activation date, a media
campaign should raise awareness in the Internet industry of the
impending adoption date, so sysadmins everywhere have time to upgrade
their DNS and MTA software, and if necessary purchase new versions
from commercial vendors. ISPs should notify customers that if they
plan to travel outside the local network, they need to configure their
MUAs for SASL SMTP.
I propose a worldwide adoption date of July 4th, 2004.
On this date, ISPs should be generally expected to have RMX records
for their domains, and if they bias as spam all mail from domains
without RMX records, that action should be considered justified.
Explicitly whitelisted addresses can still get through, but apart from
those, non-RMX compliant domains can be considered as much a spam
haven as an open relay.
ISPs who presently subscribe to blacklists will, presumably, start
blocking on the basis of RMX after that date.
For more information, see http://www.mikerubel.org/computers/rmx_records/
==== End Forwarded Message ====
-----
Eric Williams, Pres.
Information Brokers, Inc. Phone: +1 202.889.4395
http://www.infobro.com/ Fax: +1 202.889.4396
mailto:eric(_at_)infobro(_dot_)com Pager: +1 301.303.8998
For More Info: info(_at_)infobro(_dot_)com
PGP Public Key
http://new.infobro.com/KeyServ/EricDWilliams.asc
Finger Print: 1055 8AED 9783 2378 73EF 7B19 0544 A590 FF65 B789
----------------------------------------------------------------
The information in this message is confidential. It is intended
solely for addressee(s). Access to this message by anyone else
is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg