Subject: [Asrg] IP cross post (interesting RMX reception...)

From: "Eric D. Williams" <[email-masked]>
Date: Sat, 31 May 2003 00:39:21 -0400

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:[email-masked]] wrote:

>Date: Fri, 30 May 2003 18:26:18 -0400
>From: Meng Weng Wong <[email-masked]>
>Subject: ReverseMX: review and suggestions
>To: Dave Farber <[email-masked]>
>
>
>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 [email-masked])
>
>      Received-RMX: error (temporary failure while resolving RMX list for
> domain of sender [email-masked])
>
>      Received-RMX: unknown (domain of sender [email-masked] 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 [email-masked])
>
>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:[email-masked]      Pager: +1 301.303.8998
           For More Info: [email-masked]
                    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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Crocker <[email-masked]>
Date: Sat, 31 May 2003 09:09:26 -0700

Folks,

EDW> In the spirit of Yakov, here is an interesting cross-post from Dave Farber's IP
EDW> list.
EDW> This is not intending to advocate RMX or any other proposal, I am merely
EDW> forwarding it to give a perspective to some admittedly anecdotal reception of
EDW> Hadmut's RMX proposal.

And here is John Levine's particularly literate rejoinder on both RMX
and on cybercoin mechanisms:

>Date: Sat, 31 May 2003 04:01:08 -0400
>From: John R Levine <[email-masked]>
>
>
>The spam stopping ideas mentioned in two recent messages to IP, designated
>sender and e-postage, have been debated at length in the e-mail community.
>Unfortunately, each has technical and social problems that make them
>unworkable.  The existing e-mail system is large, complex, and has
>operational aspects that are often subtle, and a lot of superficially
>plausible ideas have already been evaluated and discarded for good
>reasons.
>
>Reverse MX and other designated sender schemes attempt to prevent people
>from sending mail from unauthorized hosts, so that. for example, yahoo.com
>could identify the hosts that are supposed to be sending mail with Yahoo
>return addresses, and receiving hosts can reject mail purporting to be
>from Yahoo that originates elsewhere.
>
>A significant technical problem with Reverse MX is that large mail domains
>like yahoo.com have distributed mail hosts all over the world.  Reverse MX
>proposes that a mail server make a DNS query to find the addresses of all
>of the valid sending servers for an incoming message, but all those
>addresses won't fit in a 512 byte DNS response packet.  (The DNS spec
>provides for larger packets sent with TCP, but in practice, larger packets
>are much slower and many DNS implementations don't handle them right.)
>This problem isn't hard to fix once you realize it's a problem; see Gordon
>Fecyk's Designated Mailer proposal which is similar but better thought
>out:
>
>http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-02.txt
>
>The social problem with designated sender is that there are plenty of
>perfectly legitimate reasons for mail from a domain to originate someplace
>other than its home network.  Lots of people maintain accounts at Yahoo or
>other free mail providers, but send mail with their Yahoo address from
>their home ISP using the ISP's mail server.  Many others use forwarding
>services such as pobox.com, which would all be unable to function with
>designated sender, since mail forwarded by such services correctly retains
>the original sender's address, not the forwarding service's.  And finally,
>this won't really block any significant amount of spam, since there will
>always be some domains who out of political principle, malice, or
>incompetence designate the entire Internet as their valid sender ranges,
>and spammers can just use those.  Or spammers can register throwaway
>domains of their own, since burning an $8 domain for a 10 million message
>spam run isn't much of a deterrent.
>
>
>The other message proposes attaching "cybercoins" as e-postage on e-mail.
>The technical problem here is much more serious: nobody has any idea how
>to build a micropayment scheme that could scale up to the size needed to
>handle the world's e-mail and work reliably enough to deter spam.
>Cybercoin systems require that recipients ask the issuing bank if the coin
>is genuine and hasn't already been spent.  There are probably a hundred
>billion e-mail delivery attempts per day in the U.S. (Hotmail alone
>reports about two billion.)  By comparison, there are maybe 100 million
>credit card transactions a day, so this would require a system that can
>handle a thousand times the transaction volume of the credit card system.
>Some designs use statistical validation, only check some fraction of the
>coins, but in view of the reality that many systems report 80% or more of
>their mail is spam, you have to validate everything or else let a lot of
>spam through.  There are other technical problems (how do you clear a ten
>cent transaction between individuals the U.S. and Indonesia?)  but the
>transaction volume is the most obvious.
>
>Even if through some technical breakthrough we were able to affix e-stamps
>to every message, we'd turn the e-mail system into something like a phone
>network where all the numbers start with 1-900.  Since non-commercial
>mailing lists like IP couldn't exist if they had to pay postage, and most
>people don't want to charge their friends to write to them, proposals
>generally have some way to waive postage from known senders or only cash
>the coin if you don't like the message or otherwise vary the price at the
>receipient's option.  But this replaces the spam problem with a new world
>where you have no idea how much postage you'll be paying, and with lots of
>innovativive e-postage scams, both to avoid paying postage on outgoing
>mail, and to trick people into sending mail to receipients who want to
>collect the incoming postage.  Unlike the spam problem, these scams
>quickly involve large amounts of real money. Think of chain letters saying
>"write to this address to get coupons for free beer, they won't even cash
>your stamp."  (Yeah, right.)  Or let's say a virus on your computer sends
>out a thousand spams.  Who pays the postage?  If the answer isn't "you
>do", who decides to waive the postage?  How do you tell a user with a real
>virus from a spammer who deliberately infects his own computer?
>Doubtless we can come up with a whole set of laws and rules and
>adjudication procedures, but I don't see any reason to believe that what
>we'd end up with would be preferable to the admittedly lousy situation we
>have now.
>
>
>I'm not arguing that nothing can work so we should throw up our hands, but
>it's dismaying that the same old unworkable anti-spam approaches keep
>reappearing over and over, reinvented by people who haven't done the most
>rudimentary investigation of prior work, invariably foundering on the same
>problems that came up the last six times that similar proposals failed.
>
>There's plenty of room for innovative thinking, both to try to identify
>and deter spam, and to pick out the real mail from among the spam and get
>it to the receipients.  But please, let's stop going in circles, build
>some prototypes, run some experiments to see how they work, and try to
>move forward instead.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>