Subject: [Asrg] RMX proposals and Nash Equilibrium

From: Daniel Feenberg <[email-masked]>
Date: Sat, 3 May 2003 17:51:17 -0400 (EDT)

An Economist's Take on RMX-style Proposals to Curtail SPAM

In my understanding, the most cogent reason presented for why RMX
protocols are undesirable is that forwarded mail retains the original
envelope MAIL FROM, while coming from an arbitrary source. So an RMX
participating site would end up rejecting perfectly valid forwarded mail,
because the connecting server would not be on the list of authorized
servers for that FROM address.

I understand that this is a powerful argument, although not necessarily
decisive. REDIRECT (see http://www.sendmail.org/m4/features.html#redirect
)  is a little used potential substitute for forwarding, but if a
substantial number of sites were enforcing RMX matching, it might come
into common use to mitigate (not solve) the forwarding problem. 

But could RMX ever take hold? Would thousands of independent sites use
such rules to protect themselves? Millions of sites manage to get HTTP
(approximately) right, so spontaneous coordination is possible. Will the
characteristics of RMX make it also a success?

Note that these proposals call for two actions. Senders of mail are asked
to publish via DNS a list of authorized sources for mail with their from
address. Receivers of mail are asked to check those lists before accepting
mail. Although everyone sends and receives mail, it is entirely possible
for a mail server to implement only half the proposal.

In proposals such as this on, there is a temptation to restrict the
analysis to "What if everyone did this?" and claim disaster will stike. Or
to clamor loudly "Everyone won't do this" with similar confidence. But I
would like to address the slightly different questions:

1) What incentive do the early adopters have to do this? Does that
incentive apply to both halves of the proposal?

2) If the answer to (1) is "some" or "much" then as more servers join,
does the incentive for more to join grow or shrink?

3) If the answer to (2) is "grow", then what is the outcome if much of the
internet follows the proposal?

This is just asking what the equilibrium is going to turn out to be. Since
there is no authority to make anyone implement one of these proposals, the
incentives for voluntary adoption are crucial to determining the success
of the project.

Consider the single system "hotmail.com". No doubt they resent the fact
that for no fault of their own, all the clueless users of email think that
they are the source of 50% of all spam. Would Hotmail have an incentive to
publish their list of servers?  Probably. It wouldn't cost them anything
and it would only have a negative effect on users with hotmail return
address but using other smtp servers. This may be a very small group, and
perhaps not one Hotmail is concerned about. The potential benefit to
Hotmail is modest if their abuse desk is an automaton, but even robots
need electricity.

Given that Hotmail participated, would I set my mailer to check MAIL FROM
RR records? If sendmail supported it as a feature, I probably would. It
would cut 50% of my incoming spam, with very few type two errors. So in
the short run I have a substantial positive incentive to do the checking.
But remember that most mail won't come from checkable addresses. I can't
start rejecting that mail without justifiable complaints from my users.

Would I have much incentive to register my server names? To start with,
very little, as I am not aware of any spammers using my return address,
and in the beginning there would be few or no other sites who would refuse
my messages merely because they were unregistered. On the other hand I
have already paid the price of implementing SMTP AUTH, so my users won't
see any adverse effects from my participation. So I probably would publish
the RMX records.

Sites who might need to pay a consultant to modify their DNS and establish
SMTP AUTH and might not think it worthwhile. Sites will certainly differ.
It is no use appealing to either authority or their sense of right and
wrong - non-implementors will see RFCs as just that and themselves as
fully justified in delay or rejection.

The proposal only works if it can transition from a few sites to many. How
would the situation play out?

If the proposal starts to gain some traction - say a few large sites start
to enforce RMX requirements were the MAIL FROM: address matches a site
supporting RMX records. Very soon spammers would learn not to use hotmail
return addresses, and what happens then? It won't cost them any more to
use an non-participating site as the MAIL FROM: address. They might pick
mine, which would give me a real incentive to register.

But there are millions of possible names. Spammers could use all of them -
they already have them, after all. At that point the incentive for sites
to check incoming mail is greatly reduced. If there are any disadvantages
(and there are some related to roving users and forwarded mail) then a
dramatic reduction in the advantage might sink the proposal at
non-participating sites. It won't catch 50% of the mail anymore , but only
a tiny fraction. The disadvantages would outway the advantages for a
greater percentage of sites. As time goes by, more might register, but the
incentive to check would become very small.

Therefore I believe that the eventual equilibrium is that many domains may
register allowed SMTP sources for their outgoing mail, and some will
reject incoming mail which does not match one of the registered domains,
but that essentially no sites will reject mail from non-participating
domains and spammers will not use registered domains in MAIL FROM:
addresses. Net improvement:  little or none.

Compare this to connection IP address based blacklists of open relays. In
that case each participating site benefits from refusing mail from open
relays. So each site gets a private benefit from subscribing to a
blacklist, which encourages subscriptions. As relays are closed the
remaining relays share the traffic among a smaller group. The increased
traffic increases the incentive for the remaining relays to close up. When
only one open relay remains, it will be overwhelmed with spam traffic and
will close up in minutes. Well, perhaps that is utopian, since if the
anti-relay campaign get close to success, the incentive to subscribe is
reduced. But success can be dealt with if it occurs.

Of course we are not at the final equilibrium yet, but the more relays are
closed, the harder it is to maintain one. This could be called a "virtuous
circle"  because once started it becomes stronger and stonger on its own
accord.

 Daniel Feenberg 
 feenberg at nber.org

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 04 May 2003 10:35:57 -0400

> start rejecting that mail without justifiable complaints from my users.

  That's not the point.

  The usual idea is that any new anti-spam method allows MTA
administrators to catch & delete spam.  This idea is wrong.

  Anti-spam methods allow MTA administrators to make better decisions
with less work, than their curent methods.  If one of the outcomes of
those decisions is to drop mail, then it's a local MTA issue, and
totally unrelated to the anti-spam method.

  An alternative policy approach for sites implementing RMX lookups
would be to rate-limit non-RMX connections to some small amount of
bandwidth.  Mail from non-RMX sites would still get through, but would
be punished relative to RMX aware sites.

> very little, as I am not aware of any spammers using my return address,

  You're lucky.  Nothing more.

> a tiny fraction.

  What you're missing is that email is not evenly distributed across
domains.  So if even 20% of mail to an ISP comes from a few sites
implementing RMX, that 20% will contain little to no spam.

  In addition, RMX still allows nearly zero-cost "grouping" of
messages into categories:  accountable originating MTA's, and
non-accountable ones.  At that point, it becomes feasible to drop
nearly all content filtering for accountable originators, because you
can trust (at some level) that any spam from them will be
non-deniable, and that they will probably deal with the issue.

> addresses. Net improvement:  little or none.

  Nonsense.  Again, you're stuck on the idea that the MTA choices are
to drop the mail, or to accept it blindly.  There are more options.

  Non-RMX sites can be put through a content filter which has a high
false positive rate, but a low false negative one.  Any bounce/error
message from the content filter can say "Because you didn't do
anything which allowed us to trivially verify you, we're doing the
work, and we're doing it in a way to make us happy.  If it means
dumping your messages, well, it sucks to be you."

> relays.

  Again with the accept/refuse...

> As relays are closed the remaining relays share the traffic among a
> smaller group. The increased traffic increases the incentive for the
> remaining relays to close up.

  True, but irrelevant.  Little spam comes from open relays.  A lot
comes from knowingly complicit senders, from "owned" machines, or from
throw-away accounts.

  Alan DeKok.

---

From: Mike Rubel <[email-masked]>
Date: Sun, 4 May 2003 14:14:41 -0700 (PDT)

On Sat, 3 May 2003, Daniel Feenberg wrote:
> to check incoming mail is greatly reduced.

Dear Daniel,

This is a very interesting analysis.  May I raise an objection though?

Combating spam is not the only incentive for sites to check RMX on
incoming mail.  The other incentive is to avoid being misled.  I would
argue, for example, that it is more important to correctly identify a
forgery claiming to come from (for example) one of a site's software
providers, business partners, or family members than it is to correctly
discern forgeries from other, unrelated sites or people.  This factor
means recipients are more likely to check RMX than a pure spam-rejection
analysis would suggest.

If the equilibrium is high enough, mail coming from a non-RMX site would
have a significantly higher probability of being spam, meaning filters
like spamassassin would give it a lower rejection threshold.  This factor
gives all senders (including those for which the first argument doesn't
apply) a strong incentive to implement RMX.

Overall, I think that the equilibrium RMX penetration would be much higher
than you suspect, but since neither of our analyses are quantitative,
we'll just have to see.  :)

> Compare this to connection IP address based blacklists of open relays.

And yet it does not appear that IP blacklists will resolve the spam
problem either.  There are too many exploitable machines on the `net, and
too many exploits being discovered daily.  I believe there is a consensus
that the only way to fix this problem in the long term is through a
cocktail of attacks--intelligent filters, blacklisting of relays, improved
accountability of SMTP through RMX, and governmental pressure.

Mike

---

From: Barry Shein <[email-masked]>
Date: Mon, 5 May 2003 19:03:56 -0400

FWIW, RMX strikes me as a possibly useful approach to a problem
somewhat orthogonal and/or slightly overlapping the spam problem.

What it helps with is whether some specific piece of email is highly
likely to be from the organization it claims to be from, in a
relatively lightweight way.

Which would be primarily useful for what others are calling
"transactional" messages like your order was shipped or please check
your order status at URL there's a problem you need to resolve or
here's your receipt or monthly activity statement.

That is, relatively low-security stuff which a miscreant might mimic
to trick you into visiting their web site etc.

So arguing that it doesn't seem terribly useful in the fight against
spam is probably correct, but doesn't necessarily obviate the
underlying idea.

It's kinda like arguing that nail-proof tires won't do you much good
in a snowstorm (except inasmuch as it'd be nasty to change a tire
punctured by a nail in a snowstorm.)

On the other hand, even taken at its best, there are other ways to
accomplish the same thing (e.g., PGP signing or similar), though there
is something attractive about pushing this mechanism into the servers
such that the MUA's only have to recognize the result, e.g., a special
header, "X-RMX: OK".

That's simpler than coordinating PGP signing between end-users (both
from the point of view of implementing PGP in the MUA's and
administering its use), I'll grant that.

So if RMX is "good enough" for some specific uses such as "did this
bank statement actually come from my bank?" then it might have merit,
even if it's not of much help with spam, per se.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 May 2003 19:14:32 -0700

Barry,

BS> What it helps with is whether some specific piece of email is highly
BS> likely to be from the organization it claims to be from, in a
BS> relatively lightweight way.

If you find an RMX record, yes you can make that positive
interpretation.

The problem is that you have zero information if you do NOT find an RMX
record.

BS> It's kinda like arguing that nail-proof tires won't do you much good
BS> in a snowstorm (except inasmuch as it'd be nasty to change a tire
BS> punctured by a nail in a snowstorm.)

or inasmuch as we are discussing mechanisms for making it safer to be in
a snowstorm.

it's not that a cure for cancer is not wonderful, but it has nothing to
do with snowstorms.  so this is the wrong venue.

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>

---

From: Mike Rubel <[email-masked]>
Date: Mon, 5 May 2003 21:33:00 -0700 (PDT)

DC> it's not that a cure for cancer is not wonderful, but it has nothing 
DC> to do with snowstorms.  so this is the wrong venue.

Perhaps what we have here is a cure for cancer with significant
implications for snowstorms.

Mike

---

From: "Peter J. Holzer" <[email-masked]>
Date: Tue, 6 May 2003 10:52:10 +0200

> The problem is that you have zero information if you do NOT find an RMX

Some proposals for RMX records allow to distinguish between "this domain
doesn't use RMX records" and "this domain does use RMX records but this
address is not an authorized RMX for this domain".

So you have a positive, a negative, and a don't know case.

	hp

-- 
   _  | Peter J. Holzer    | Latein ist das humanoide Äquivalent
|_|_) | Sysadmin WSR       | zu Fortran.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |    -- Alexander Bartolich in at.linux

---

From: "Tom Thomson" <[email-masked]>
Date: Wed, 7 May 2003 19:11:50 +0100

Dave Crocker wronte on 06 May 2003 at 03:15

>do with snowstorms.  so this is the wrong venue.

I would agree with Dave if the sole objective of this group were simply to
make filtering spam at the receiver end (whether MTA or MUA) an easier task.
But I think we have a wider objective - we want to ensure that less spam is
sent and thus reduce the cost of discarding/bouncing what is sent to
non-existent addresses and filtering what is sent to real addresses, as well
as make the filtering of whatever is still sent somewhat easier.

The RMX proposal can make it less likely for spam to be sent by improving
our ability to identify and hence, in jurisdictions where this is provided
for in law, to prosecute and punish the sender.  The EU directive on this
subject means that a very large part of the world will be in such
jurisdictions by the autumn of this year, so that a large number of
potential spammers would be deterred by an increased chance of being caught.
Using off-shore ISPs is not a way around this EU law.

So ASRG is clearly not the wrong forum for discussion of improved sender
identification mechanisms such as RMX (whether RMX is a good enough improved
sender identification mechanism is of course another question, and one of
the ones we should be addressing here).

Tom