Subject: [Asrg] 2 - Solving Spam By Establishing A Platform For Sender Accountability

From: "Howard Roth" <[email-masked]>
Date: Fri, 27 Jun 2003 11:27:31 -0700

Overview of Email Sender Validation Effort to reduce SPAM:

Efforts to validate the sender of an email message will help reduce the
dissemination of unwanted email. We propose a specific methodology to
address this issue by using a simple method based on a process that responds
to a new message with specially coded request for validation message.  This
specially coded message is sent to the “reply to” address.  The message
initiating mail server receives this reply and responds with an
acknowledgement to the recipient mailer server if the initial message was
indeed sent from this server.  Otherwise it does not respond.  If a positive
response comes back the initial message is transferred from a pending
directory to the recipients directory.  If there is no response in a
parameter based time period the initial message is discarded by the
recipient mail server.

Here is a more detailed, but simple, example of how we propose the solution
work:

User A uses his or her MUA to send a message to User B.  Server A sends the
message to Server B.  Server A runs a standard MTA process and that
transmits the message.   A copy of the message header is stored on Server A
to match against a validation effort.  Server B receives the message through
the standard MTA method but all messages go into a pending mail directory
(PMD).  Another process called mail validation agent (MVA) manages the
pending mail directory.

Server B’s MVA reviews incoming messages in the PMD and sends a request for
validation (RFV) to the sender for each new message via the standard MTA of
Server B. The file name of a message that has an RFV outstanding is changed
to differentiate it from new messages.

The RFV is a standard message that contains some specifically defined
elements to allow the process of verification to work.  The RFV contains a
random string that is associated with the initial message’s file name.  The
RFV also contains details for Server A to validate that the message was
sent.  A piece of the message is purposely not sent to Server A so that it
gets added to Server’s A response to the RVF and provides additional
legitimacy to the validity of the message.

Server A receives the RVF and places all such messages in a specific mail
directory.  A process manages RVF’s on the server.  This process on Server A
validates the RVF.  If it is valid, that is there is a match to the stored
header; the process on Server A sends a response to validation request
(RVR).  Server A deletes the stored header. This RVR is returned to Server B
and proceeds to manage the “valid” message.  If Server A does not find a
match to the RVF, then no action is taken.

Stored header information for matching is cleaned up from a sending server
based on a parameter driven period of time.  This could be several days to
account for a recipient’s server being down.

If there is no response to the RVF, within a parameter-based period of time,
the message is discarded.

This is a rough draft of the concept without too much detail in terms of
actual implementation.

Comments would be appreciated.

Howard Roth
The NetTech Group, Inc.
11 Airport Blvd., Suite 200
South San Francisco, CA 94080
Phone - 650-871-7209
Fax - 650-871-7219
Email - [email-masked]

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 27 Jun 2003 15:33:56 -0400

Re Howard Roth's proposal for RFV's, etc....
    I think this proposal is addressing a real opportunity in a bad way.
Basically, what it seems that what the author is looking for is a way
for a server to state whether or not it was, in fact, the sender of a
specific message. The approach used in the proposal is to generate
additional network traffic by having the recipient of a message query
the claimed sender as to whether or not it did actually send the
message.
    If the goal is really to determine whether the stated sender
actually sent the message and if you're willing to write new
code/protocol in order to get such a statement, then the "correct" way
to do this is to have the originating server simply sign outgoing
messages. Recipients would then look in some well known place to find
the appropriate certificates with which to validate the signatures. (It
would be most convenient if the location of the certificate repository
for the domain and/or server were found by doing a lookup on a resource
in the domain's DNS record.)

	Note: Such a mechanism would be very easy to implement, cheap to
operate, distributed, provides for gradual acceptance, etc.... But, for
some reason, people seem not to like signatures. I don't understand why.

        bob wyman

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 27 Jun 2003 15:02:23 -0500

Dear Bob,

I'm not saying this to be smart - perhaps part of the problem is our
inability to come up with a certificate for an arbitrary person
somewhere in the Internet, so we can verify signatures?

Spencer

----- Original Message ----- 
From: "Bob Wyman" <[email-masked]>
To: <[email-masked]>; "'Asrg@Ietf. Org'" <[email-masked]>
Sent: Friday, June 27, 2003 2:33 PM
Subject: RE: [Asrg] 2 - Solving Spam By Establishing A Platform For Sender
Accountability

        bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 27 Jun 2003 18:03:08 -0400

Spencer Dawkins wrote:
> our inability to come up with a certificate for 
> an arbitrary person somewhere in the Internet, 
> so we can verify signatures?
	I said nothing about certificates for "arbitrary persons". The
subject discussed was how do you prove that a message was sent by a
specific *server*. The key to simplification here is that the server
will have a DNS record and that DNS record can have SVR records
associated with it. What you do is set up an SVR record that points to
the certificate server for the mail server. Then, you pick any of the
many available certificate formats and say: "This certificate format is
the one to use for mail server identification."
	Locating certificates for arbitrary people is a different
problem since we don't have anything like a DNS service for them. i.e.
there is no way to make a connection to an "arbitrary person" and ask it
questions. In any case, certificates for "arbitrary persons" are only
needed if you are trying to ensure that mail came from "arbitrary
persons." In this case, we're trying to determine if mail came from a
specific server -- not a person.
	The kind of certificate needed in a system like I'm suggesting
here can be very minimal and even self-generated. You don't, for
instance, have to worry about having any CA that issues the things. You
can just create an arbitrary public key and publish it via the
certificate server of your choice. The reason for this is that you are
asking the server's DNS server itself to tell you where to find the
server's key. As long as you trust that you are speaking to the server's
DNS, you can invest reasonable trust in any statements it makes. 
	(Yes, I realize that one can spoof DNS data, etc. however, I
believe that will not be a significant problem in *this* specific
application. The worst case that results from any spoofed data is the
present case: i.e. faked addresses. However, I believe that the vast
majority of servers will have management that ensures that their data is
properly maintained and monitored. The fake source data will diminish as
more and more server managers adopt the method even though some small,
and insignificant portion of them will end up with hacked data.)

		bob wyman

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 27 Jun 2003 17:06:28 -0600 (MDT)

> 	                                                   ...     The
> associated with it. ...

Ok, but why do you care about servers instead of persons?  I don't
care how legitimate mail gets into my mailbox.  I also don't care how
many signatures are associated with a server that sends spam my way.

It sounds as if you are making the familiar assumption that every
legitimate sender transmits only via a small number of SMTP clients.
That assumption would vastly simplify solving the spam problem, but
it would also vastly change non-technical aspects of the mail system.

From another angle, why is it any harder for a spammer to get a signed,
throw-away domain name than to get a throw-away personal or other
certificate?  Some of the ostensibly Chinese spammers are disclosing
several dozen new domain names in my spam traps every day.  What
difference would it make if they had signatures to go along with their
domain names? 

Yes, most of these spammers seem to be forging sender names (in the
real sense, not in the too familiar bogus sense of "forge"), but I
don't understand why.  They could as effectively use their new domain
names as senders including using signatures.  I suspect that within
a day or so of the first appearance of their domain names in URLs in
spam, those domain names appear in comemrcial body filters.

Applying Barry Shein's analogy, how does this stop the bad guys
from ringing all of the phones in Manhattan?

Vernon Schryver    [email-masked]

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 27 Jun 2003 20:27:30 -0400

At 11:27 AM -0700 6/27/03, Howard Roth wrote:
>Efforts to validate the sender of an email message will help reduce 
>the dissemination of unwanted email. We propose a specific 
>methodology to address this issue by using a simple method based on 
>a process that responds to a new message with specially coded 
>request for validation message.  This specially coded message is 
>sent to the "reply to" address.  The message initiating mail server 
>receives this reply and responds with an acknowledgement to the

In what way is this any functionally any different than RMX or other 
similar server-is-authorized-to-send-mail protocols?  Unlike those, 
this requires maintaining state and uses a heavyweight protocol.  It 
does have the advantage of not requiring a live internet server to do 
verification.  But it has the disadvantage of requiring millions of 
people to change how they send email (most especially users of 
web-mail services).
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: "Howard Roth" <[email-masked]>
Date: Fri, 27 Jun 2003 18:09:26 -0700

The idea behind this concept is to not modify current software, but provide
additional stand-alone software that provides sender accountability.   RMX
requires a modification to DNS to allow for the match between the sending IP
address and the 'reply to' server IP address.  I feel adoption of an added
piece of software is more likely to occur in a shorter period of time than
by substantially modifying existing MTA or DNS software.  That doesn't rule
out the more efficient methods, like RMX, being adopted as a long-term
solution.

Basically, the intent is for this method to be completely transparent to the
users and therefore have no impact on web-mail services.  I am familiar with
my web-mail services using Ipswitch mail server software, but there may be
other issues that you are alluding to that I may not be aware of.

I also understand that there are network utilization issues with the added
messages, but if sender accountability occurs we will see a significant drop
in overall usage by reducing SPAM.  As well, the intent is to make these
additional validation messages as small as possible.

Howard Roth
The NetTech Group, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Kee
Hinckley
Sent: Friday, June 27, 2003 5:28 PM
To: [email-masked]
Cc: 'Asrg@Ietf. Org'
Subject: Re: [Asrg] 2 - Solving Spam By Establishing A Platform For Sender
Accountability

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 27 Jun 2003 22:01:30 -0400

>additional stand-alone software that provides sender accountability.   RMX

In what way does this not modify existing software?  The MTAs have to 
be modified to support it, correct?

>other issues that you are alluding to that I may not be aware of.

The issue is that people send mail "from" one domain while using the 
mail servers of another.  This is done all the time for perfectly 
legitimate reasons.  Not only is it done on an individual level, it 
is also done regularly in mass commercial mailings (which are sent by 
one company on behalf of another).  Using the "reply to" to 
authenticate breaks all of that.  Yahoo users can only send mail 
using Yahoo's web mail.  Macromedia can't send mail from 
"[email-masked]" using mx0's mail servers, and so on.

This can be avoided to some degree if you use the from address in the 
mail envelope, since that can easily be different than the headers. 
However then you need to deal with issues regarding bounces.  In 
addition, no matter which header you choose to use, you need to 
figure out how it will work with mail relayed by a mailing list.

---

From: Matthew Elvey <[email-masked]>
Date: Sat, 28 Jun 2003 12:50:30 -0700

Boy, it seems like an increasing number of the posts I've seen since 
this list started come from posters who seem to be gravely misinformed 
or deliberately spreading misinformation. (General comment, not directed 
at Kee or Howard!) I hope this is something the ASRG reorg will try to 
address. It seems like the discussion of the most promising proposals is 
exceedingly rare.  :-(

Apropos RMX (mail-from Reverse MX) and a similar proposal:

Kee Hinckley wrote:

>> additional stand-alone software that provides sender accountability.  
>
>

No, just the MUAs.

Also, I think Howard Roth is mistaken, in that if the current versions 
of qmail, sendmail, and postfix supported RMX, the Internet would be 
most of the way to adoption.  Exchange and Notes would likely follow, 
and another inevitable security bug announcement in a few of them will 
cause the vast majority to upgrade.  Result: the Internet is RMX ready 
for any domain that wishes to do so to roll out and have it be highly 
effective.  Trying to get the majority of the world's MUA end users to 
upgrade is much more difficult, IMO.
I had cisco.com and some other major domains whitelisted for a while, 
but had to remove 'em due to repeated spam 'From' them. 
abuse@<trademark>.com seemed uninterested in pursuing abuse of their 
trademark.

> legitimate reasons.  Not only is it done on an individual level, it is 
> also done regularly in mass commercial mailings (which are sent by one 
> company on behalf of another).  Using the "reply to" to authenticate 
> breaks all of that.  Yahoo users can only send mail using Yahoo's web 
> mail.  Macromedia can't send mail from "[email-masked]" using 
> mx0's mail servers, and so on. 

This capability is NOT broken with the RMX proposal.  Any legitimate 
users WILL be able to use the domain of their choice.  There are at 
least 3 ways yahoo users could continue to use their own servers in an 
RMX-compatible world.

Mailing list servers need to be responsible for the email they send (in 
the RMX sense), and with some minor tweaking, will be (some already are).

In an RMX world, domain-based DNSRBLs can be highly effective, with low 
false positives and low false negatives.

---

From: "Jean-Christophe Bandini" <[email-masked]>
Date: Sat, 28 Jun 2003 13:16:30 -0700

Bob

> DNS, you can invest reasonable trust in any statements it makes. 

Using signature to authenticate sounds like a good idea ;-). Plus
s/mime has been around for a while and server-to-server s/mime is
available in commercial products for several years now.

But the idea of using self-signed certificates (vs CA) is not
going to work well because they are free. The spammers will simply
do what they do today with the spamvertised URLs' hosts and keep
using new ones because domain cost is low enough (<$10 today).
Using a CA could introduce a new cost in the spammer economics
(plus force some basic validation depending on cert class).

But until the vast majority of the legitimate MTAs support
some verification (with or without digital signature), no one
can start to refuse unauthenticated inbound mails. So the
benefits in that (long) transition period seems to be:
- ability to increase probability of an email being spam if
   sender is not verified.
- ability to have reliable white/black sender domain lists on
   verified senders _if_ the cost of creating new 'verified
   sender domains' is high enough.

jean

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 28 Jun 2003 15:19:52 -0600 (MDT)

> From: Matthew Elvey <[email-masked]>

> address. It seems like the discussion of the most promising proposals is 

We agree about some of that, but we may disagree about which is
the information and which is the misinformation.

Other IRTF mailing lists have been effective or at least interesting.
ASRG has been none of the first and little of the second so far.  For
example, end2end has long suffered the noise of those who wish that
research would consist of advocacy instead of doing one's own
measurements, simulations, coding, tests, trials, and even deployment.
Howver, end2end has also had people who are not only would be gurus
or leaders.

The most reasonable ASRG thread concerned Graylisting.  That report
was of measured results from real code in the real world, unlike
the white papers about RMX, consent, and the rest.

Various spam filtering is done on at least 50% of all mailboxes.
(Doesn't Brightmail claim 40%?)  If those filters are at least 50%
effective, then more than 25% of all spam in the Internet is already
being handled.  That's consistent with the reports of many that
their personal spam loads are lower than they were years ago.  Many
mailboxes are like mine, suffering an entirely tolerable load of
spam of fewer than 1-4 spam/week.

Contrast that fact with the positions of advocates for various silver
bullets.  They talk as if public, long term mailboxes like mine must
receive many spam/day and about stopping practically all of that spam
with their wonderful solutions.  None advert to the fact that at least
half of the field has alreading been taken by others who range from
silent (e.g. Postini, and SpamPal) to practically silent (Brightmail
and Cloudmark) to extremely quiet (SpamAssassin).

That's not to say that the current solutions are sufficient, but that
anyone who claimsto have a sliver bullet is spreading misinformation.
Dealing with spam today is about like networking 15 or 25 years ago.
NCP and TCP before congestion control and avoidance were useful.  The
claims of the ISO OSI, Appletalk, NETBUI, and other silver bullet
mongers and research framework leaders eventually came to naught.
There is still good research to be done on TCP, and so I continue to
read end2end.  I try to ignore the wannabe leaders and would be gurus,
some of whom who are still pitching x.25.

> ...
>                                      Result: the Internet is RMX ready 
> effective.  

Effective in what way?  The most commonly used sender domain names in
spam are those of the free providers.  (My measurements on ~30K recent
spam imply >40% of spam currently involves free provider sender
domains.)  Please offer some evidence that the major free mail providers
would go along any sort of RMX system.  Outblaze is widely seen as
one of the most anti-spam free providers.  Please point out the words
in a web page (perhaps starting at http://outblaze.com/index.php )
where the owners of the 30,000,000 Outblaze mailboxes are told to send
only through Outblaze's servers.  Feel free to point out such words
in Hotmail's, Yahoo's, or some other major free (or non-free) mail
service provider's terms of service.

>             Trying to get the majority of the world's MUA end users to 

That's interesting when you think about it.  Please offer some evidence
other than your personal assurances that Cisco would restrict employees
from sending mail with cisco.com sender addresses from random locations
including their homes, customer sites, hotels, and even airplanes in
order to stop that abuse of their trademark.

> ...

That is so wrong that it qualifies as what you called "misinformation."
Why didn't you touch on those three ways Yahoo uses could use "their
own servers"?  Was it because expecting users to adjust the DNS
records for the IP addresses from which they are sending mail at
the moment would sound so completely unrealistic?

Some RMX-like proposals require adjusting among the RRs of the SMTP
client based on its IP address.  Those are merely grossly implausible.
Other RMX-like proposals that use RRs in the envelope sender zone
domain are worse, given the fact that free providers show no signs of
objecting to their users sending from elsewhere.

> ...

Domain and IP address based DNS based blacklists can be highly effective
with quite low false positive and a usefully low false negative rates
outside RMX worlds.
The reason that there are so few domain based DNS blacklists is
that the easy choices fairly static, and because the legal liabilities
sound worse.

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 28 Jun 2003 15:23:52 -0600 (MDT)

> From: "Jean-Christophe Bandini" <[email-masked]>

> can start to refuse unauthenticated inbound mails. ...

Which major MTAs don't have current versions that support SMTP-TLS
and SMTL-AUTH?

That might be considered a trick question, given the years that sendmail
and others have supported both.  I'm not sure the original question
is not equally tricky.

---

From: "Jean-Christophe Bandini" <[email-masked]>
Date: Sat, 28 Jun 2003 15:10:54 -0700

Vernon

> Which major MTAs don't have current versions that support SMTP-TLS

Signing at the first MTA seems a bit stronger but you are right that
TLS can also be used.

But it seems the problem remains that:
- there needs to be a critical mass of actual deployments (without it
   one cannot refuse non TLS inbound or whatever other scheme is chosen)
- there needs to be an acceptance of certificates more costly than
   self-signed which a spammer can keep on generating like for domains.

Thanks,

jean

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 28 Jun 2003 16:32:23 -0600 (MDT)

> Signing at the first MTA seems a bit stronger but you are right that

If you prefer end-to-end authentication, there are S/MIME and PGP.

>    one cannot refuse non TLS inbound or whatever other scheme is chosen)

yep.

>    self-signed which a spammer can keep on generating like for domains.

They must be expensive enough that the CA can verify that a new
applicant is not the entity that is again and currently (well, as of
this week) calling itself "zhangguojie" but not so expensive that the
CA will keep the money regardless of spam sign.  I think the first
numbers is more than $1000 and the second is less than $500, which
would make the excercise academic even if real people were willing to
pay as much as $10.

  ]]]]]]]]]]]]]]]]]]]

] From: Bob Wyman <[email-masked]>

]    Sure, we could make it more expensive for everyone to send
] mail in order to squeeze out the spammers. But, we'll squeeze
] out a large number of other people at the same time. Using  
] such a blunt method should only be considered if there are no
] alternatives. In this case, simply raising costs won't
] accomplish much.

That could be worded better.  You cannot force people to choose
between a new, spam-resistant system and not using email.
Given a new, spam-resistant system, all of us, including spammers
will have to choose among several alternatives including:
  1. paying the higher price in money or whatever.
  2. not paying and not using email.
  3. not paying and continuing to use the old email system.
  4. not paying and using some other new email system, perhaps
     such as SMS.

Note that many spammers would be overjoyed to choose #1 in a system
without the viagra porn homeworks.  Many would be glad to pay more
per delivered spam than most retail end-users would pay for private
email.  Junk postal mail is amazingly expensive when you include all
of the costs and not just what the Postal Service collects.

] ...
]     Any anti-spam method that relies on the fact that
] spammers might not follow some technical guidelines is doomed
] to failure. You must assume that spammers will follow all of
] the technical rules -- they just don't follow the moral or
] legal rules. Any other set of assumptions will result in
] systems that are trivial to get around - simply by following
] the rules.

That could also be phrased better.  Spammers will follow those technical
guidelines that are in their interests, as demonstrated by their
non-conformant notions of SMTP command pipelining.

---

From: "Jean-Christophe Bandini" <[email-masked]>
Date: Sat, 28 Jun 2003 15:59:41 -0700

Hi Vernon

> If you prefer end-to-end authentication, there are S/MIME and PGP.

That's why i mentioned s/mime in my original post.

Yes, good point on PGP.

jean

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 29 Jun 2003 00:58:34 -0400

At 11:27 AM 6/27/2003 -0700, Howard Roth wrote:
>[..]
>address this issue by using a simple method based on a process that 
>responds to a new message with specially coded request for validation 
>message.  This specially coded message is sent to the reply 
>toaddress.  The message initiating mail server receives this reply and 
>responds with an acknowledgement to the recipient mailer server if the 
>initial message was indeed sent from this server.  Otherwise it does not 
>respond.  If a positive response comes back the initial message is 
>transferred from a pending directory to the recipients directory.  If 
>there is no response in a parameter based time period the initial message 
>is discarded by the recipient mail server.
>[..]

This has been mentioned on the list before - this is a specific case of 
C/R. The CRI protocol that is being worked on by Eric Dean and me includes 
the ability to verify whether the sender has in fact sent a specific message.

Yakov

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 30 Jun 2003 13:04:11 -0700

Vernon Schryver wrote:

>>or deliberately spreading misinformation. [...]
>>
>> It seems like the discussion of the most promising proposals is 
>>exceedingly rare.  :-(
>>    
>>
>
>the information and which is the misinformation. [...]
>
Your <4/week number must be net (after applying good antispam measures, 
and not counting the spam folder you need to scan for false positives) 
or you are an  outlier.  Are you saying that the claims of Postini, 
Brightmail, Hotmail, (and a bunch of nanae posters) all showing that 
around half of email is spam are wrong?  (73%, 2/5, 80%, various, of all 
email, respectively, for their systems; URLs available; just ask here)

Your DCC seems to be a very good system, but it causes false positives, 
so you have to go through what it thinks is spam, (or bounce it) right?  
What are average DCC user false positive rates?  Do you think DCC alone 
is a solution that works well for now (like bayesian filtering), or one 
that will also work well in the long term without needing to participate 
in a continuing arms race?   I use SpamAssassin (not the latest version, 
and w/o custom weights, or SMTP-time 4xx/5xx bouncing unfortunately; my 
ISP isn't perfect; I've complained), and I get a couple dozen spam a day 
that have lower scores  than my non-spam.  I don't even know how much 
really spammy spam I get, because I delete or bounce it.  It's so much 
that I couldn't reasonably go through my spammy spam looking for false 
positives. That's not a tolerable load, IMO.  I should keep it for a few 
days to check.

>and Cloudmark) to extremely quiet (SpamAssassin).[...]
>
What do you mean by silent?  That they silence the noise that is spam?  
I am skeptical that SpamPal (which is purely DNSRBL-based), today, is 
gonna eliminate all my spam, or work w/o a ton of false positives.  
"SpamPal will not be able to detect all of your spam. However, I think 
it will detect enough to make a considerable difference!" - the spampal 
site

BTW, what RBLs does SpamPal currently use by default?  Anyone?

>Effective in what way?  
Effective in preventing abuse 'from' their domain.

>The most commonly used sender domain names in
>would go along any sort of RMX system. 
>
But having that evidence ahead of time is not a realistic possibility, 
even if RMX were a mathematically proven silver bullet (it's not a 
silver bullet at all, but it could be a component of a silver bullet, 
IMO).   They're not gonna come out in favor of this stuff ahead of time.
Hotmail and Yahoo are pro-spam (they are on record as opposing 
California's SB 12, which is going to be voted on tomorrow, BTW.)
They would only do so under pressure.  Pressure that would build, as 
email sent 'from' domains that don't implement RMX gets to be a 
progressively more reliable indicator of spam.  That pressure would 
largely come from their own users, whose email would be getting filtered 
because they hadn't implemented RMX.

> Outblaze is widely seen as
flamer.  chill.  Your tone is so unpleasant I'm tempted to just ignore 
you completely.  Tone it down if you want to continue the conversaion, 
please.

Ask Suresh yourself if he thinks Outblaze would be up for this.  
Outblaze ALREADY makes this difficult: any mail sent 'from' an outblaze 
account not through their servers that bounces gets filed in /dev/null.  
So I suspect they may be up for it.  Besides, there are a lot of major 
providers who utterly fail to enforce their TOS, such as Verio, so what 
TOS say or don't say is of little import.

>order to stop that abuse of their trademark.
Chill.  Any Cisco employee who is going to be connecting to the 'net for 
work will connect to cisco over a VPN from said random locations and 
would have full access to cisco SMTP servers.  Ok, so it's unlikely, but 
perhaps they can't send from cisco.com from their cellphones without 
some work (some cellphones support SMTP already, and probably some 
support smtp-auth as well).  It's unlikely, but perhaps a VPN or 
smtp-auth connection won't be practical from 30,000 feet.  If so, so 
their mail in these very rare cases comes from airline.dom or 
cellphonecompany.dom.  Big deal?

>own servers"?  
Chill!
1)Yahoo doesn't implement RMX on its domain.  Anyone can still send 
'from' yahoo.com from any server.  This is the easiest solution.  RMX 
isn't mandatory for all domains, remember?  Or did you not actually read 
the proposal that you so harshly criticize?
2)They modify the 'to' addresses from [email-masked] to 
[email-masked], and yahoo resends it for them using the RMX- 
authorized servers, after checking that it's 'from' a yahoo user.  How 
good this check is  is up to yahoo*, and would impact their reputation 
if they employed this scheme.
3)People can ask/pay yahoo to list their servers.  (Ok, so this doesn't 
scale, but solutions 1 and 2 would work, realistically.  I think I had 
another scheme, but seem to have forgotten it.)
B)Of course Yahoo could also implement RMX on its domain and allow yahoo 
mail users to use an SMTP server they've set up, with security of their 
choice*.

*e.g. The security could be smtp-auth, or a variant of POP before SMTP, 
or allowing users to approve an SMTP server that can relay for them, or 
just a check on whether it's a valid user, or whatever.

>Was it because expecting users to adjust the DNS
Dammit, you're antagonistic.  It seems you don't understand the protocol 
at all (or at least the RFC I read).  How it normally works:  Nearly 
everyone sends mail through their ISP's SMTP server, whether that be an 
earthlink, or their employer.  It's the IP of that server that needs to 
be in the RMX records!  Not the user's IP.  If they're doing that, then 
there's some level of security on the SMTP server, allowing them to use 
it, or it's an open relay, and is already broken, as many servers are 
already blocking it for that reason.  So there are no DNS records for 
users to update!  Just the ISP admin, IF they want to protect their 
domain name from abuse, can CHOOSE to set it up, adjustments would be 
needed very infrequently. 

>with quite low false positive and a usefully low false negative rates
They're useful (especially with scoring systems like SpamAssassin), but 
standard IP based blocklists alone will never be highly accurate in 
terms of positives and negatives.

>that the easy choices fairly static, and because the legal liabilities
 I think it's mainly because IP addresses can't be forged and domains 
can.  SpamPal doesn't support them yet, either. With RMX, domain-based 
blocklists can have much lower false rates than IP-based blocklists.  
Abuse desks and IP-based blocklists are better off as well, because an 
abuse desk can identify a joe-job/forged abuse report a bit more easily, 
and have more evidence to show it to be a forgery. 
A little work implementing RMX would allow a lot of abuse desk work to 
be eliminated.