Myself, I look at it this way.
RMX and things like it are a minimal *authentication* step that can give
you reasonable that the mail is from the domain it says it's from. This
is very valuable, but is indeed only a piece of the picture.
Beyond that I think we need ways for you to provide in the mail that you
send positive evidence that the mail isn't spam (having the evidence
flow with the original message at the get-go means the existing mail
delivery experience is preserved). When all is said and done, I only
know of two basic ways to do this:
1. Get someone whose opinion your recipient values to say you are
a good guy.
2. Do something that it's uneconomical for a spammer to do, and
you did that.
The first of these amounts to trading on your reputation; the latter
amounts to expending some resource on behalf of the message (money, CPU
cycles, and so on, though lack of a viable micro-payment scheme makes
using the first of these difficult).
While not one and the same thing, the authentication and the spam
deterrence measures are related. For example, domains and their owners
have reputations: thus, to the extent you can attribute a message to a
domain, you can ask questions about the reputation of / policies
associated with the domain, which is likely to be a very interesting
question. Similarly, if you have an authenticated piece of mail (perhaps
it's signed) you can reasonably then ask policies about the particular
sender of the message.
I think it's also worth noting that the two fundamental approaches above
are likely to serve quite different audiences.
More likely that not, it's only the larger organizations / domains which
will have sufficient reputation so that their mail transmission policies
can be evaluated and monitored and sufficient money to pay for that
evaluation. All those small businesses, personal mail servers and other
small domains out there realistically won't be able to participate.
On the other hand, it's a happy coincidence that the situation is
exactly reversed when it comes to the availability of spare CPU cycles:
the people who send volumes and volumes of mail generally run their
machines to the hilt. After all, if they have such volume, they have to
budget and capacity plan the thing, and they don't tend to build in huge
extra capacity that they don't actually need. On the other hand, the
machines running the small domains are by and large highly idle, with
plenty of spare cycles.
I think it's important that as the industry picks spam deterrence
measures that we don't end up making 1st and 2nd class senders. No one
mechanism will be usable by all senders, yet all receivers need to value
all the mechanisms.
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org] On
Sent: Thursday, October 30, 2003 4:09 PM
To: 'Eric Dean'; 'Alan DeKok'; asrg(_at_)ietf(_dot_)org
Subject: RE: 3. Requirements - Anonymity (was Re: FW: [Asrg] 0. General)
I agree. RMX would merely allow for me to protect my domain from
getting spoofed. By no means is it an anti-spam method.
RMX and SPF do not prevent all spam but they do have the potential to
eliminate impersonation spam (aka Joe Jobbing). This type of spam is
particularly serious because it has been used in a series of very
identity theft schemes. These include the persistent 'update your
ebay/amazon/paypal account solicitations and recently a series of emails
impersonating several banks.
Impersonation spam creates considerable inconvenience and cost for the
impersonation victim. In addition to the cost of fielding complaints
the spam the victim's reputation is damaged. In many cases the
may steal business from the victim (anti-virus software spam, domain
registration spam). It is not unusual for a spam to be correct in every
detail except for the telephone number to contact to give payment.
Certainly it is possible and useful to go further than IP address/Domain
Name verification of the type supported in RMX/SPF. But this does
RMX/SPF infrastructure as a first step. Nor is it tenable to claim that
RMX/SPF are insufficient and then claim that certificate based schemes
Asrg mailing list
Asrg mailing list