ReverseMX: review and suggestions

[Dave Farber <dave () farber net>]

> Date: Fri, 30 May 2003 18:26:18 -0400
> From: Meng Weng Wong <mengwong () dumbo pobox com>
> Subject: ReverseMX: review and suggestions
> To: Dave Farber <dave () farber 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 () pobox com)
>
>      Received-RMX: error (temporary failure while resolving RMX list for 
> domain of sender mengwong () pobox com)
>
>      Received-RMX: unknown (domain of sender mengwong () pobox 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 () aol 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/


-------------------------------------
You are subscribed as interesting-people () lists elistx com
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/