Subject: [Asrg] seeking comments on new RMX article

From: Mike Rubel <[email-masked]>
Date: Sat, 3 May 2003 15:24:37 -0700 (PDT)

Dear ASRG,

I have written a new article to help explain RMX records, and would
sincerely appreciate any feedback or comments you might have on it.  The
article here can be found here:

	http://www.mikerubel.org/computers/rmx_records/

Best regards,
Mike

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 May 2003 06:56:59 -0700

Mike,

MR> I have written a new article to help explain RMX records, and would
MR> sincerely appreciate any feedback or comments you might have on it.  The
MR> article here can be found here:

The premise of the scheme is in the following text:

MR> Detecting a forgery begins by realizing that email systems never
MR> legitimately use third-party relays anymore.

What this therefore asserts is that the domain name in a From field is
always tied to a fixed set of originating MTAs.

The presumption is incorrect.

For a variety of reasons -- notably for some mobile users -- the
originating MTA may well be unable to know the set of valid domains
sending from it.  That is, some mobile users must be able to
spontaneously post through different MTAs.

This highlights an important requirement for evaluating proposals:  What
*valid* scenarios does it prevent?

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: "Alan DeKok" <[email-masked]>
Date: Sun, 04 May 2003 10:49:52 -0400

> The presumption is incorrect.

  I agree.  But I still like RMX.

  What's important for me is that RMX allows the receiving MTA to
trivially discover that the originating domain has consented to send
mail from that MTA.  Right now, we have *no* way of verifying the
originators consent.

> spontaneously post through different MTAs.

  I've heard this before, and I have no idea why it's true.

  Are there NO other methods which a mobile user may use to send mail?
SMTP is only one of many protocols used to send/receive email.

> *valid* scenarios does it prevent?

  Used properly, RMX doesn't prevent anything.  It simply allows the
recipient MTA to make faster, better decisions about how to deal with
the email.

  No RMX?  Run the message through a content filter with a high false
positive rate.  RMX?  Run the message through a content filter with a
high false negative rate (spam is now accountable, and traceable...)

  Alan DeKok.

---

From: J C Lawrence <[email-masked]>
Date: Sun, 04 May 2003 12:16:42 -0700

On Sun, 04 May 2003 10:49:52 -0400 

>> What this therefore asserts is that the domain name in a From field
>> is always tied to a fixed set of originating MTAs.

> mail from that MTA.  

That doesn't work for things like yahoo, mail.com, etc who offer
POP/IMAP accounts to arbitrary users without an outbound smarthost.

> Right now, we have *no* way of verifying the originators consent.

It specifically doesn't work for me as I aggregate mail from ~8
addresses here at home, and have my MUA configured to automatically
generate the correct From: header depending on what folder I'm sending
mail from.  Of the eight domains involved, I control only two...

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

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

DC> The premise of the scheme is in the following text:

	Detecting a forgery begins by realizing that email systems never
	legitimately use third-party relays anymore.

Dave,

Thank you very much for writing!

I must respectfully disagree; this is emphatically not the premise of the
scheme.

The sentence you cite comes from the section on how present-day forgery
detection works.  If you read on, about two paragraphs below, I write:

	The problem with the forgery check just described is that while
	<em>most</em> sites obey this convention, there is no shortage of
	exceptions and marginal cases.  One issue is that small sites
	sometimes use their hosting company's mail server, and the
	business relationship might not be obvious from whois records.
	Also, some organizations do not (yet) provide remote
	authenticated SMTP services for traveling members, relying
	instead on laptops which send their messages directly.
	
	However, there is a way to make the forgery check robust, which
	we shall now demonstrate by way of example.

It is not until after this point that RMX records are introduced.

In order to make this point clearer, I have added the text:

	(certain exceptions to this rule, discussed below, are the reason
	forgery detection is currently an inexact science)

immediately after the phrase you cite.

Does that make it clearer?

Thanks again--

Respectfully yours,
Mike

---

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

DC> What this therefore asserts is that the domain name in a From field
DC> is always tied to a fixed set of originating MTAs.

DC> The presumption is incorrect.

AD> I agree.  But I still like RMX.

AD> What's important for me is that RMX allows the receiving MTA to
AD> trivially discover that the originating domain has consented to send
AD> mail from that MTA.  

JCL> That doesn't work for things like yahoo, mail.com, etc who offer
JCL> POP/IMAP accounts to arbitrary users without an outbound smarthost.

JCL> It specifically doesn't work for me as I aggregate mail from ~8
JCL> addresses here at home, and have my MUA configured to automatically
JCL> generate the correct From: header depending on what folder I'm 
JCL> sending mail from.  Of the eight domains involved, I control only 
JCL> two...

Dear J.C.,

I'm in exactly the same boat here--multiple accounts on different machines 
without outbound smarthosts.

This is not an insurmountable problem, though.  When the administrator of
a system decides to implement RMX records, he will need to provide
SMTP-AUTH or VPN or even a port-25 ssh tunnel.  Many (most?) sites already
do something like this, but it's only fair to factor it into the work 
involved in implementing the RMX approach.  I have added a note to that 
effect at the bottom of the page:

	http://www.mikerubel.org/computers/rmx_records/#notes_limitrelays

Even with this cost factored in, however, I still believe that the RMX
solution is far better (smaller effort required to implement and fewer
things broken) than any other solution I have seen to the email forgery
problem.

Best regards,
Mike

---

From: J C Lawrence <[email-masked]>
Date: Sun, 04 May 2003 14:19:24 -0700

On Sun, 4 May 2003 13:27:23 -0700 (PDT) 
Mike Rubel <[email-masked]> wrote:

> I'm in exactly the same boat here--multiple accounts on different
> machines without outbound smarthosts.

I'm in a slightly different position to that: multiple accounts on the
same machine.  Umm, actually its slightly worse than that thru
repetition.

> This is not an insurmountable problem, though.  When the administrator
> of a system decides to implement RMX records, he will need to provide
> SMTP-AUTH or VPN or even a port-25 ssh tunnel.  Many (most?) sites
> already do something like this, but it's only fair to factor it into
> the work involved in implementing the RMX approach.  I have added a
> note to that effect at the bottom of the page:

An additional cost there is MTA configuration, a non-trivial problem.
Consider the case of someone with multiple accounts etc, using a
non-SMTP based MUA, an MUA which uses localhost SMTP only, or even more
simply, an MUA which doesn't support multiple configurations for
outbound smarthost.  In any/all of those cases support is required from
the localhost MTA -- which in the general case can be assumed to not be
available.

> things broken) than any other solution I have seen to the email
> forgery problem.

I've a fondness for forward signed Received: headers, but that attacks a
different aspect of the forgery problem.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 May 2003 14:44:07 -0700

Alan,

AD>   What's important for me is that RMX allows the receiving MTA to
AD> trivially discover that the originating domain has consented to send
AD> mail from that MTA.  Right now, we have *no* way of verifying the
AD> originators consent.

if you find the rmx record, and then you know the posting is through an
authorized MTA.

if you do NOT find the rmx record, you do not know anything.

so, what is the real utility of the rmx record?

that is, what can you safely do, versus not do?

>> spontaneously post through different MTAs.

AD>   I've heard this before, and I have no idea why it's true.

firewall blockage of outbound port 25.  relatively common.

it means that mobile users often must re-configure their outbound MTA to
be something new and transient.

AD>   Are there NO other methods which a mobile user may use to send mail?

no.

AD> SMTP is only one of many protocols used to send/receive email.

interesting.  i believe there are no others.  ("submit" is simply smtp on
another port.)  which ones are you referring to?

I also believe that if there were others, it would not solve this
problem.

d/

---

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

DC> no.

Dave,

What about VPN?  What about stunnel?  What about smtp-auth?  What about
Courier's "outbox" for IMAP over SSL?  Heck, what about ssh tunnels?  
There are many, many well-known, widely-used mobile user solutions that
either do not involve a direct SMTP connection or add some sort of strong
authentication, and plenty of them are freely available.  Even in the most
restricted case that I can imagine--mobile users whose only access to the
system is via public web terminals--the organization could install an
https webmail system, and there are a lot of very good free ones out
there.

An organization that wishes to implement RMX records is not exactly
limited in its options.  But should an organization not wish to implement
RMX records (yet), it can choose not to, and everything will continue to
work as it does now.

Perhaps I'm not understanding your objection?

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 May 2003 18:55:54 -0700

Mike,

AD>> Are there NO other methods which a mobile user may use to send mail?

MR> What about VPN?  What about stunnel?

those are not mail protocols.

MR>   What about smtp-auth?

smtp-auth is an option to smtp.  so, it is smtp.

MR>   What about
MR> Courier's "outbox" for IMAP over SSL?

I don't know what you are referring to, but it is not an Internet
standard for posting mail.

MR>   Heck, what about ssh tunnels?

not a mail protocol.

MR> Perhaps I'm not understanding your objection?

possibly.

d/

---

From: J C Lawrence <[email-masked]>
Date: Sun, 04 May 2003 19:20:51 -0700

On Sun, 4 May 2003 14:44:07 -0700 

> interesting.  i believe there are no others.  ("submit" is simply smtp
> on another port.)  which ones are you referring to?

In descending order of popularity: SMTP, UUCP, LMTP, and FIDO are the
one's I'm familiar with for Internet email.

---

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

Hi Dave et al,

DC> those are not mail protocols.

True, but they are "other methods which a mobile user may use to send
mail." My point is that if an organization with mobile users wants to
implement RMX, it has plenty of options already available.  Some work may
be involved, but it's hardly a show-stopper.

In any case, introducing RMX involves far less work than replacing SMTP,
which many have suggested, and it gives each organization the freedom to
make a change--or not--on its own schedule and terms.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 May 2003 21:16:28 -0700

Mike,

DC>> those are not mail protocols.
MR> True, but they are "other methods which a mobile user may use to send
MR> mail."

no they are not.

in some cases, they are other methods for running smtp, besides using a
raw tcp/ip channel.

but they ultimately either use smtp or they are not for email.

please let's try not to introduce "let's invent new and special ways for
individual sites to do special things."  non-standardized methods do not
scale to the rest of the Internet.

MR> In any case, introducing RMX involves far less work than replacing SMTP,

and it does not accomplish what you seem to think it accomplishes.

you have not addressed the minor problem that failure to find an rmx
record has ambiguous meaning.  hence it is not at all clear what the
benefit is when you DO find the entry.

SN>> If the RMX matches the IP, it's a good bet the domain is not forged.
SN>> If the RMX doesn't match, all bets are off.
 MR> One more case here--if RMX is present and doesn't match, the message is
MR> definitely forged (or the system is misconfigured).

You are quite wrong.  When you do not find a matching rmx record, the
only thing you know is that there is no rmx record.  There are at least
two different reasons possible.  forgery is only one of them.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 May 2003 21:11:10 -0700

J,

JCL> On Sun, 4 May 2003 14:44:07 -0700 

>> on another port.)  which ones are you referring to?

JCL> In descending order of popularity: SMTP, UUCP, LMTP, and FIDO are the
JCL> one's I'm familiar with for Internet email.

 I apologize.

 I took the word "used" to mean "used on the Internet, in sufficient
 quantity to demonstrate global utility."

 We are, after all, discussing use on the global Internet.

 It seems unlikely that anyone is going to seriously suggest uucp or
 fido. (I don't recall the details of fido, for email, but uucp is too
 creaky to even discuss for modern usage.

 LMTP is simply SMTP on a different port.

d/

---

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

DC> no they are not.
DC> 
DC> in some cases, they are other methods for running smtp, besides using a
DC> raw tcp/ip channel.
DC> 
DC> but they ultimately either use smtp or they are not for email.
DC> please let's try not to introduce "let's invent new and special ways for
DC> individual sites to do special things."  non-standardized methods do not
DC> scale to the rest of the Internet.

1. They solve the problem you raised, namely that mobile users may not be
   able to reach port 25 on their organization's outbound mail servers 
   because of firewall or other restrictions.  Or was that not your 
   objection?

2. They are neither special nor non-standard; using email through one's
   internal network via VPN (to draw just one of the examples I provided)
   is quite common on the Internet nowadays.  I'm not sure what you mean
   by "does not scale to the rest of the Internet".

We seem to be degenerating into semantics here.  Yes, the connections are
SMTP (which is good and standard), or whatever else the sender wishes, and
they may be tunneled.

DC> you have not addressed the minor problem that failure to find an rmx
DC> record has ambiguous meaning.  hence it is not at all clear what the
DC> benefit is when you DO find the entry.

Please see below.

SN> If the RMX matches the IP, it's a good bet the domain is not forged.
SN> If the RMX doesn't match, all bets are off.

DC> You are quite wrong.  When you do not find a matching rmx record, the
DC> only thing you know is that there is no rmx record.  There are at least
DC> two different reasons possible.  forgery is only one of them.

Ah, I think I see the confusion:

	1. RMX record present + received IP address matches

		--> email is not a forgery

	2. RMX record present + received IP address does not match

		--> email is a forgery

		    (or sender's mail system is misconfigured)

	3. RMX record not present

		--> email is either a forgery or not a forgery; no
		    information.  This is the way all email works now.

	4. Unable to contact the sender's nameserver

		--> up to the recipient; possibly hold the message in
		    quarantine until the nameserver comes back online,
		    or forward it with a warning.

In every case, the RMX check provides information that can be passed on to
intelligent spam filters to help them make better decisions.

You may object that case (#3) does not really provide any information.
Right now, and that's true, but as RMX becomes more common, absence of an 
RMX record will become a gradually stronger indicator of spam.

So far as I can tell, the system does perform its intended job, which is
to give senders a way to allow their recipients to distinguish between
forged and non-forged mail.  Spammers could still send spam, but would be
unable to represent the spam as having come from an RMX-protected domain.

Is that clearer?

Best regards,
Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 May 2003 23:19:34 -0700

Mike,

MR>         3. RMX record not present
MR>                 --> email is either a forgery or not a forgery; no
MR>                     information.  This is the way all email works now.

MR> You may object that case (#3) does not really provide any information.
MR> Right now, and that's true, but as RMX becomes more common, absence of an
MR> RMX record will become a gradually stronger indicator of spam.

When discussion adoption of Internet services, statements of the general
form "it will not be much use until there is widespread adoption, and
then it will be quite useful" are problematic.

Internet adoption of changes to existing services takes 5-10 years, at
least.

d/

---

From: J C Lawrence <[email-masked]>
Date: Sun, 04 May 2003 23:32:15 -0700

On Sun, 4 May 2003 21:11:10 -0700 
Dave Crocker <[email-masked]> wrote:

> fido. 

FIDO lack of usage and deployment I'll accept, however UUCP remains in
wide deployment and usage to this day, and is even aggressively growing
in a number of areas.  Much of the third world (Africa in particular)
hangs off UUCP links, as do large stretches of Scandinavia (Norway and
Finland in particular).

> (I don't recall the details of fido, for email, but uucp is too creaky
> to even discuss for modern usage.

Yet it remains in wide modern usage.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 10:32:18 -0400

> if you do NOT find the rmx record, you do not know anything.

  Exactly.

> so, what is the real utility of the rmx record?

  Umm... you have more information with which to make better
decisions?  That doesn't seem like a bad thing.

> that is, what can you safely do, versus not do?

  For RMX systems, you can safely be more liberal in filtering
messages, because you have some level of confidence that any spam
coming from RMX systems will be traceable and accountable.  That
doesn't seem like a bad thing to me.

> AD>   Are there NO other methods which a mobile user may use to send mail?

  I disagree most strongly.

> another port.)  which ones are you referring to?

  Some people have posted other alternatives.  An additional one is
mail via a web interface.  If you care about privacy, use SSL.

  The feeling I get here is the same from everyone who's requiring
that mobile users be allowed to send SMTP traffic to any port 25 on
the planet, and to pretend to come from any domain.  They're adamant
that that's the ONLY way they can send mail from remote sites, and
that there are NO other workable alternatives.  The fact that probably
90% of such non-traceable, anonymous traffic worldwide comes from
spammers has no bearing on the subject.

  I'm at a loss to respond to such a position.  It's so trivially,
obviously wrong, that I'm left wondering what I'm missing.

  (I have my suspicions, but in the interest of keeping this
discussion on a technical, rather than political level, I've deleted
the additional paragraph I really wanted to write.)

  Alan DeKok.

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 5 May 2003 17:01:53 +0200

Dave,

> so, what is the real utility of the rmx record?

that's not how RMX works. That's how several different attempts to 
whitelist authorized MTA's by giving them some kind of A record.
RMX works different.

When doing an RMX lookup for a given pair of sender domain name
and MTA IP address four different cases can occur:

* You get an RMX record and it does cover the sending MTAs IP address.
  -> You know it is authorized
  -> You know how many addresses are authorized, 
     e.g. 213.133.101.23/32  vs.  0/0  as a decision base

* You get an RMX record and it does not cover the IP address.
  -> You know it is not authorized, at least not by RMX.

* You get an authoritative negative answer (No RMX)
  -> You know that the domain owner refuses to publish
     an RMX policy

* You don't get an answer (usual DNS reasons, timeout, routing
                           problem, server down...)

  -> you do not know anything

So the utility of the rmx records are the first three of four
cases: They do provide you information needed to base your decision
about what to do with the email on.

regards
Hadmut

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 May 2003 08:16:34 -0700

Hadmut,

HD> * You get an authoritative negative answer (No RMX)
HD>   -> You know that the domain owner refuses to publish
HD>      an RMX policy

Sorry, no.

All you know is that the domain owner has not published the record.  You
do not know whether that was from a decision or from sloth.

Really, folks, please understand that adoption of new specifications
takes years.  Until you have adoption, you do NOT have "refusal".  You
have non-adoption.  When something is not used, you cannot know whether
that is due to refusal or whether it is due to not having (yet) adopted
the specification.

HD> So the utility of the rmx records are the first three of four
HD> cases: They do provide you information needed to base your decision
HD> about what to do with the email on.

please provide a concrete example of the differences in handling with,
versus without, the rmx.

so far, those in favor of the rmx record are consistent in believing
that it provides more information than it does.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 May 2003 07:55:20 -0700

J,

JCL> however UUCP remains in wide deployment and usage to this day,

uucp is fine for some specialized (limited) uses.

these days, uucp is a rather rich set of features, and it is extensible.
uucp (rmail) does not come close to supporting even a fraction of the
features smtp has.

while solving one problem, we need to be careful that we do not create a
satchel full of others.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 May 2003 08:05:36 -0700

Alan,

>> so, what is the real utility of the rmx record?
AD>   Umm... you have more information with which to make better
AD> decisions?  That doesn't seem like a bad thing.

Spam is about filtering bad guys.  RMX is about labeling good guys.

Hence, with RMX, you still know nothing about bad guys.

How does it help to control spam if you continue to know nothing about
the bad guys?

>> that is, what can you safely do, versus not do?

AD>   For RMX systems, you can safely be more liberal in filtering
AD> messages, because you have some level of confidence that any spam
AD> coming from RMX systems will be traceable and accountable.  That
AD> doesn't seem like a bad thing to me.

What does this mean, exactly?  A different set of filters for RMX-based
mail?  The idea of maintaining two rulesets is a bit daunting.  Seems
unlikely to scale.

>> AD>   Are there NO other methods which a mobile user may use to send mail?

AD>   I disagree most strongly.

>> another port.)  which ones are you referring to?

AD>   Some people have posted other alternatives.

no they have not.

On the modern Internet, all of the mail posting semantics are achieved
with SMTP.

The "alternatives" presented were for alternative lower layers, or for
extremely limited email protocols that will never gain large-scale use.
(They have been around long enough to demonstrate this limitation
clearly.)

AD>  An additional one is
AD> mail via a web interface.

oh boy. now you are going to propose an array of non-standard user
interfaces as an email posting protocol?

methinks we have left the world of technical discussion of spam control.

the work here needs to be about protocols.

AD>   The feeling I get here is the same from everyone who's requiring
AD> that mobile users be allowed to send SMTP traffic to any port 25 on
AD> the planet, and to pretend to come from any domain.  They're adamant
AD> that that's the ONLY way they can send mail from remote sites, and
AD> that there are NO other workable alternatives.
...
AD>   I'm at a loss to respond to such a position.  It's so trivially,
AD> obviously wrong, that I'm left wondering what I'm missing.

You are over-interpreting my statements.  They were written carefully.
Please read them the same way.

By way of seeking something constructive out of this, would someone who
believes there are viable alternatives to SMTP -- and that they will

     a) solve or at least reduce the spam problem,

     b) match SMTP's functionality, and

     c) stand some chance of being adopted by the Internet's 100 million
     users

please put forward a technical specification of this "viable"
alternative, so that it moves from a general idea into something
concrete.

d/

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 5 May 2003 09:33:39 -0600 (MDT)

> From: "Alan DeKok" <[email-masked]>

> decisions?  That doesn't seem like a bad thing.

In fact, you have more bits but no more information.

> messages, 

That has not been established.  It would obviously be false for the
first many years of the deployment of any system certifying the virtue
of incoming mail.  At first, all mail with an RMX tag would be from
people and SMTP clients that don't send spam.  They will often already
be white-listed, and they certainly won't care many other signs of
spam.  Seeing an RMX tag will not tell you or your computers anything
not already known by you and your computers until most of the Internet
uses RMX tags.

The idea of combining imperfect indications virtue or spam in mail is
based on the unstated but false notion that the indications are
independent.  Ten independent indicators that accurate 50% of the time
can be combined to give an answer that is more than 99.9% accurate,
but only if they are independent.  If they are only restatements of
the same thing, such as "this mail is or is not from someone who cares
enough about spam to among the first 1,000,000 or 0.1% of adoptors of X,"
then combining them is a waste.

>           because you have some level of confidence that any spam

How does traceability and accountability reduce spam?  If you believe
the DNS blacklist enthusiasts, most spam is already sufficiently
traceable to be blocked.

Why do you care more about tracing and accounting than not receiving
spam?  That's a rhetorical question, but it involves what I think is
an important point.  Many people do care about tracing spammers.
However, unless you are spammer fighter interested in attacking
spamemrs, you don't care who or where the spammers are if you can
simply arrange to not receive their junk.

> obviously wrong, that I'm left wondering what I'm missing.

You have grossly misrepresented what people have been saying.  No one
has said that mail from from mobile users must be non-traceable and
anonymous.  Thanks to SMTP-AUTH, STARTTLS, pop-before-SMTP, and other
mechanisms, it is usually entirely traceable and not at all anonymous
as far as the first MTA is concerned.

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

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 5 May 2003 17:33:50 +0200

Dave,

> that is due to refusal or whether it is due to not having (yet) adopted

you're correct in the end user environment (e.g. inventing new 
features for web browsers). You're not correct in the administration
environment of DNS records. >98% of the DNS zone tables fall into
one of the two categories:

- automatically generated by one of the large ISS.
  >80% of german domains could be updated within 24 hours.

- locally generated and maintained zone tables, but under
  control of a good administration crew. It won't be much 
  work to understand what RMX is and how it works. 

Once RMX could become running, I estimate that >70% of german domains
could be updated within 3 months and >95% within 6-9 months.

I know what I am talking about. I was working for the largest german 
domain and web service provider, hosting the DNS tables for about
70% of german domains.

regards
Hadmut

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 May 2003 08:40:27 -0700

Hadmut,

HD> you're correct in the end user environment (e.g. inventing new
HD> features for web browsers). You're not correct in the administration
HD> environment of DNS records. >98% of the DNS zone tables fall into
HD> one of the two categories:

Please review the last 10 years of history, concerning the adoption of
new Internet protocols. And please remember that protocols are adopted
by system administrators, not users.

Adoption takes much, much longer than folks seem to be appreciating.

Please also realize that what is possible in one environment is almost
never possible in *all* environments.  So when you cite what is possible
in one place, chose several other, unrelated environments and see
whether it is equally possible to achieve the same, wonderful things.

Usually it is not.

HD> I know what I am talking about. I was working for the largest german
HD> domain and web service provider, hosting the DNS tables for about
HD> 70% of german domains.

Please recite your experiences with Malaysian ISPs, US ISPs, Bolivian
ISPs and Tunisian ISPs.  They, too, must accomplish adoption before the
proposed mechanism is useful.

d/

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 12:00:57 -0400

> Hence, with RMX, you still know nothing about bad guys.

  I don't quite agree.

> How does it help to control spam if you continue to know nothing about

  Right now, we have a pool of SMTP originators.  The pool contains
both good guys, and bad guys.  It's difficult and expensive for any
recipient to distinguish between them.

  With tools like RMX, a recipient can easily seperate the pool into
"accountable" originators, and "unknown" originators.  This means that
the bad guys are more likely to be marked as bad guys, and the good
guys less likely to be so marked.  While this doesn't give you direct
information about the bad guys, it does give you indirect information:
They're not the good guys.

  In summary, RMX allows us to increase our confidence in the marking
probability for bad guys.

> mail?  The idea of maintaining two rulesets is a bit daunting.  Seems

  I don't see why.  Run spam assassin, and for messages from RMX
systems, set the "spam" threshold high, so that it's more forgiving.
For messages from non-RMX systems, set it low, so it's less forgiving.

  Maintaining two numbers shouldn't be difficult for a seasoned system
administrator.

> On the modern Internet, all of the mail posting semantics are achieved

  That's nice, but it leads me to a few questions:

  - What changes, if any, may be made to a recipient MTA or MUA, in
order to fight spam?

  - What changes, if any, may be made to an originating MTA or MUA, in
order to fight spam?

  From what I can tell, your answer to the second question appears to
be "None".  If the answer to the first question is also "None", then
I don't see why we're pretending we want to solve the spam problem.

> interfaces as an email posting protocol?

  No... I'm saying that mobile users can today choose methods other
than SMTP for sending mail.  They're ugly, they're awkward, but
they're also proven to work for thousands of people.

  And as someone who's inundated with spam, I have *no* problem with a
local site policy saying "people who lie about their originating
domain go into the bit-bucket with the spammers."  That's my
perogative, and I believe that with systems like RMX, many recipient
MTA's will be making similar choices.  Mobile users who refuse to use
VPN's will then discover that most of their mail gets bounced.

> believes there are viable alternatives to SMTP 

  I believe there are viable alternatives to naked, un-accountable
SMTP for mobile users.  VPN's, authenticated relaying, etc., all
exist, and are in wide-spread deployment.

  What I'm missing about the "mobile user & naked SMTP" problem is
why, as the recipient of such email, it's *my* problem to filter out
mobile users from the spammers who use similar methods.  Is it really
that difficult or contentious to ask mobile users to use a VPN?

> -- and that they will

  Allow MTA's to verify the originator of the email?

>      b) match SMTP's functionality, and

  SMTP over a VPN seems to be a good solution.

>      c) stand some chance of being adopted by the Internet's 100 million

  Companies are selling these solutions today for mobile users, and
are making a living at it.

> alternative, so that it moves from a general idea into something

  I'm not proposing that we scrap SMTP.  But I still haven't heard
reasons why naked SMTP is the ONLY possible method for mobile users to
send email.  Alternatives exist today, and are in wide-spread
deployment.

  Alan DeKok.

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 5 May 2003 18:03:39 +0200

Dave,

On Mon, May 05, 2003 at 08:40:27AM -0700, Dave Crocker wrote:
> new Internet protocols.

Please remember, what the Internet has been 10 years ago. HTTP
and Mosaic were just invented. You can't compare this with today's 
Internet, so reviewing the last 10 years is pointless.

Furthermore: Even if adoption of new protocols has been slow in the
last 10 years, has there ever been a threat like Spam? No. You can't
compare the last 10 years with today.

> proposed mechanism is useful.

I agree, that the 'Old Europe' might be faster than the rest of the
world. Second and Third world countries must be forced to upgrade,
because that's where the Spam comes from that is unreachable by law.

But the US ISPs will be a problem, I agree. The New World might not be
so new and fast, that's true. But this can be solved easily: Tell
people that Iraq's domains have RMX records and therefore are more
advanced than US domains. This is a tactical disadvantage for future
wars. Declare RMX records to be a patriots duty and claim to be on
a mission for God. This will make everything in the US move. Even the 
Internet.

Hadmut

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 12:15:47 -0400

> the DNS blacklist enthusiasts, most spam is already sufficiently

  My experience has been different, as have others.

  Additional traceability means that it's more difficult for spammers
to send anonymously.  Once they're out in the open as spammers, then
blacklists become more useful.

  Note that blacklists only work against openly declared long-term
spammers.  "Stealth" spammers who use throw-away accounts, "hacked"
machines, etc. can easily circumvent any blacklist, unless the
blacklist reporting & distribution are both instantaneous.

  My experience with blacklists was that only about 10% of originating
IP's were on any blacklist, which made such lists useless to me.

> an important point.

  I don't.

> simply arrange to not receive their junk.

  I agree.  But I don't think such arrangements are trivial, or easily
made.

  Making more people accountable for their behaviour is just one more
tool in the fight against spam.  I've never claimed that any tool is
perfect, or that it will do everything.  In contrast, many people
violently oppose any system which *isn't* perfect, which makes me
wonder what the heck their agenda is.

> as far as the first MTA is concerned.

  Which misses entirely what I said.  A mobile user SHOULD use
SMTP-AUTH, STARTTLS, pop-before-SMTP, or other systems to
authenticate & secure his connection to his home domain.  So it's his
home domain which has done the hard work of verifying a previously
unknown, anonymous, roaming user.  Now that that's done, the
well-known, public, open MTA for the home domain can relay the message
to other well-known, public, open MTA's.

  The people going on about roaming users requiring naked SMTP to the
recipient domain haven't made it clear why it's the *recipients* job
to do authenticate them.  Isn't it easier for the home MTA to do
SMTP-AUTH, STARTTLS, etc., than it is for the recipient MTA to run the
message through crappy content filters?

  The MTA for the home domain has information which the recipient MTA
doesn't have, and may never have.  That information can be used to
reduce the work done by the recipient, to separate spam from
non-spam.  So the work of spam filtering is spread more evenly across
the network, and significantly less work is done, as a whole.  I fail
to see why there's any opposition to that goal.

  That's the entirety of my position in this matter.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 12:55:03 -0400

I'll respond again in the same thread, hopefully to focus the
discussion a bit more.

1) I'm opposed to ISP's filtering port 25 outbound.  I think there are
better solutions to the spam problem from their dial-up systems.

2) I believe that anyone, anywhere, should be able to connect to a
consenting peer, and send any SMTP traffic they desire to that peer.

3) I also believe that any recipient MTA can impose any conditions it
desires on traffic it consents to accept.

  The issue for me is that people talking about mobile users of SMTP
believe (1) and (2), but appear to disagree with (3).  That is, there
is opposition to recipient MTA's imposing conditions for consent.

  I want mobile users to be able to send email.  I'm not proposing
that any behaviour I dislike be forbidden due to network policy.  But
actions have consequences.  The policy of the recipient MTA may be to
discard non-consentual traffic, and that policy MUST be explicitely
permitted.

  I don't want to be forced to accept messages which appear to me to
be spam.  I don't want to be labelled "non-compliant" for discarding
such messages, even if they come from mobile users.  I do want to be
permitted to create local site policy.

  For me, that's the crux of the matter.  People who want to roam want
to do so under *their* terms, and want to have *me* accept those
terms.  They also appear to be opposed to me offering conditions of my
own, before I consent to any traffic exchange.

  Alan DeKok.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 5 May 2003 10:49:02 -0600 (MDT)

> From: Dave Crocker <[email-masked]>

> proposed mechanism is useful.

Never mind ISPs.  No one with the least clue about commercial sites
outside Germany would claim anything like the other person's claims.
It's more accurate to say that most DNS data are broken, at least
outside Germany.  Given my fairly recent experience with people
configuring DCC clients and servers in Germany, I've doubts about
his claims about Germany.

For another view, look at page 19 in
http://www.fruug.org/Archive/2002-12/cricketDNS-2002-12.pdf
and notice that Cricket Lui measured an error rate of 41% in
zones in domains in .de.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 5 May 2003 11:19:37 -0600 (MDT)

>   My experience has been different, as have others.

I chose my words carefully.  I don't use any DNS blacklists.

> blacklists become more useful.

Please justify both the premise and conclusion in that paragraph.
Please give an example of a spammer that would be more easily blacklisted
if it were more out in the open in some sense related to RMX.
Please give an example of a major spammer that is not already out in the
open.  Are you familiar with http://www.spamhaus.org/rokso/ ?

> blacklist reporting & distribution are both instantaneous.

Yes, but that's got nothing to do with getting spammers into the open
and nothing to do with RMX or other mail virtue certificates until
the mail from at least 80% of the Internet or 400,000,000 people uses
them.  How long do you think it might be until RMX or any technical
anti-spam system could reach 80% use?

> IP's were on any blacklist, which made such lists useless to me.

Other people report substantially higher rates with DNS blacklists.

Again, I don't use any DNS blacklists.  However, my private blacklists
are better than 99% effective against my spam loadwith a much less than
1% false positive rate.  Note that the DCC is not what I consider a
blacklist.

> perfect, or that it will do everything. 

RMX records do nothing I can see to making people accountable for
their behaviour ever, and certainly not until the mail of 100's of
millions of people use them.

>                                          In contrast, many people

What is your agenda for flogging something that cannot have any effect
for decades?  Or are you claiming RMX records might be used on more
than 80% of mail within 10 years?   If so, please justify that claim.

> to see why there's any opposition to that goal.

What does any of that have to do with stopping spam?  What does knowing
that one of UUNet's resellers has validate a mail sender as
[email-masked] tell you?  

Do you check the whois records for the domains advertised in spam?
What do you learn from records like 
http://opensrs.org/cgi-bin/whois.cgi?action=lookup&domain=gamingclub.com
What would RMX tell you that whois records and IP addresses don't?

By the way, that whois record told me to blacklist that domain.

---

From: J C Lawrence <[email-masked]>
Date: Mon, 05 May 2003 11:14:52 -0700

On Mon, 5 May 2003 07:55:20 -0700 
Dave Crocker <[email-masked]> wrote:

>> however UUCP remains in wide deployment and usage to this day,

...
> while solving one problem, we need to be careful that we do not create
> a satchel full of others.

More simply I don't want to break UUCP users.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 14:29:58 -0400

> Please justify both the premise and conclusion in that paragraph.

  My example below (which you disagreed with) did just that.

> if it were more out in the open in some sense related to RMX.

  As I said, throw-away accounts, among others.  This is a significant
fraction of the spam I'm seeing, which is why I like RMX.

> open.  Are you familiar with http://www.spamhaus.org/rokso/ ?

  Spammers using throw-away accounts.  Even ones on the 'rokso' list
hide their identity from time to time.  Is it so bad to prevent them
from *never* hiding their identity?

> them.

  Evidence for such an assertion is...?

>  How long do you think it might be until RMX or any technical

  I don't know, and I really don't care.  If implementing an anti-spam
solution on my system saves me work, and reduces my spam load, then
I'm all for it.

> millions of people use them.

  AOL, Yahoo, Hotmail.

  Done.

  See, if those 3 companies decide that originators using RMX get
"priority" service, I'll bet that a lot of sites will fall all over
themselves adding RMX records to their DNS.

> for decades?

  For one, I disagree with your idea that it will take decades.  I
note that you have offered no proof for such a position.

  In contrast, how quickly did domains add web servers in 1993-1994?
I'll bet that if someone checked, probably 30% of active domains had
web sites within 3 years.  That's a good timescale for something like
RMX.

>  Or are you claiming RMX records might be used on more than 80% of
> mail within 10 years?  If so, please justify that claim.

  Nope.  Putting words into your opponents mouth is a well-known style
of ad hominem attack, and one which astudiously avoids discussing any
issues of substance.

> [email-masked] tell you?  

  I'll go out on a limb: It allows me to track down that spammer, and
potentially get them removed from the domain.  If the domain refuses
to remove the spammer, then I have records which will justify my later
filtering of ALL traffic from that domain.

  It's the concept of "innocent until proven guilty."  It's been
around for a while...

  As for well-known, openly declared spammers, working from well-known
IP's, I believe that blacklists go a long way to alleviating that
problem.  You seem to be assuming that my support of RMX means that
I'm proposing *no* other anti-spam system is used.

  I'd be happy if RMX was used to add domains to blacklists.  Right
now, domains have "plausible deniability" about spam from their
domain.  Hotmail can say "Yes, they claim to be from hotmail, but they
didn't use our MX, so it's not our problem."  RMX allows the recipient
to refute that denial.

> Do you check the whois records for the domains advertised in spam?

  I don't have the time, sorry.

> What would RMX tell you that whois records and IP addresses don't?

  RMX, by design, explicitely exposes the originating domains intent
to send email from an IP.  This intent is currently *implicit*.

> By the way, that whois record told me to blacklist that domain.

  That's your perogative.  It's a local policy issue, and it has
nothing to do with general anti-spam policies.

  Alan DeKok.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 May 2003 11:25:16 -0700

Alan,

AD>   With tools like RMX, a recipient can easily seperate the pool into
AD> "accountable" originators, and "unknown" originators.  This means that
AD> the bad guys are more likely to be marked as bad guys, and the good
AD> guys less likely to be so marked.

I do not see that.

We might hope that those using RMX-based hosts are good guys.  We might
hope that, but there is no assurance that the hope will be correct.

Accountability does not mean that the originator is comforming to good
policies.

In any event, the remaining pool consists of good guys and bad guys and
we are not in a better position to distinguish them.

AD>   I don't see why.  Run spam assassin, and for messages from RMX
AD> systems, set the "spam" threshold high, so that it's more forgiving.

Why?  What makes it likely or certain that someone coming through an RMX
host is not sending spam?

AD>   Maintaining two numbers shouldn't be difficult for a seasoned system
AD> administrator.

Ahh. I see you have a very different model of the life and performance
of a professional administrator than I have been taught.

AD>   - What changes, if any, may be made to a recipient MTA or MUA, in
AD> order to fight spam?

AD>   - What changes, if any, may be made to an originating MTA or MUA, in
AD> order to fight spam?

AD>   From what I can tell, your answer to the second question appears to
AD> be "None".  If the answer to the first question is also "None", then
AD> I don't see why we're pretending we want to solve the spam problem.

You are confusing "be very careful with the design of changes and the
assumptions about their adoption" with "do not make any changes."  I
have participated in a fair number of efforts to make changes to
Internet Mail.  Some work.  Some don't.  It would be foolish to ignore
the lessons of that history.

AD>   No... I'm saying that mobile users can today choose methods other
AD> than SMTP for sending mail.  They're ugly, they're awkward, but
AD> they're also proven to work for thousands of people.

1.  Thousands is not 100 milion.  The difference in scale is important.

2.  Ugly and awkward are usually terms that apply to failed proposals.

3. Please provide a detailed description of non-SMTP Internet mail that
is used by many thousands of people who cover a wide range of user types
(eg, grandmothers, secretaries, children, executives, and even
engineers.)  Absent that, please provide a discussion that explains how
the presence of "ugly and awkward" will not pose insurmountable
usability barriers.

AD>   I believe there are viable alternatives to naked, un-accountable
AD> SMTP for mobile users.

The original assertion was that there were alternatives to SMTP, not
simply alternatives to "naked, unaccountable SMTP".

>>      a) solve or at least reduce the spam problem,
AD>   Allow MTA's to verify the originator of the email?

We have had PGP and S/MIME for approximately 10 years.  They permit
identifying the originator.  Yet they have not achieved any significant
adoption or use in the Internet.  How will you achieve success now?

>>      b) match SMTP's functionality, and
AD>   SMTP over a VPN seems to be a good solution.

SMTP over VPN is SMTP.  The claim was about using something other than
SMTP.

>>      c) stand some chance of being adopted by the Internet's 100 million
AD>   Companies are selling these solutions today for mobile users, and
AD> are making a living at it.

I believe no one else selling and email protocol other than SMTP and making a
living at it.

d/

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 5 May 2003 20:51:45 +0200

Dave, 

> hope that, but there is no assurance that the hope will be correct.

Sorry, you still have not understood RMX yet. A valid RMX entry
doesn't mean the user is a good guy. It does mean that he actually
belongs to the given domain and that's the way how to find the person 
in case he is a bad guy.

> Accountability does not mean that the originator is comforming to good

Accountability requires the posibility to track back the originator.
That's what's RMX is about.

> host is not sending spam?

Because he can be tracked back and hold responsible.

> adoption or use in the Internet.  How will you achieve success now?

That's not logical. If PGP and S/MIME didn't have succes yet, it
doesn't mean that no authentication method will ever have success. 
The failure of PGP and S/MIME is a design criterion for RMX:
It is designed to avoid the problems of PGP and S/MIME, which are
far too complicated and error prone, require time-expensive and
difficult-to-learn certification steps and keeping secret keys. 
Therefore RMX was designed to be simple, without cryptography, 
without secrets. 

Furthermore, PGP and S/MIME are a completely different story. 
You're comparing apples and oranges. PGP and S/MIME are designed to 
keep messages confidential, to provide authenticity and integrity, 
and to provide non-repudiation. PGP and S/MIME provide authenticity
by solving the problem that anyone could use a particular address
before. SPAM is a different problem. Here the attacker can use any 
address, which is a slightly different problem. 

Most people don't actually have the problems that PGP and S/MIME
solve. That's one of the reasons why they don't use it. Because
they don't need it. In contrast, many people receive tons of Spam.

Hadmut

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 15:11:16 -0400

> Accountability does not mean that the originator is comforming to good

  I agree, but it does mean that we can account for whether or not the
originator is conforming to good policies.  It's just one more nail in
the coffin of spammers.

> we are not in a better position to distinguish them.

  I agree, but for that pool, we're no worse off than we were before.

> host is not sending spam?

  Nothing.  But having proven to be a spammer, it's easier to hold
them to account, and to block/filter their traffic.

  At the minimum, RMX will alleviate the need for DUL blocks.  RMX can
alleviate the "forged sender" problem, which many people on this list
have run into.  If I publish RMX records for my domain, and it
prevents others from forging mail from my domain, then that's a good
thing.

> assumptions about their adoption" with "do not make any changes."

  That's probably because ANY change which is proposed gets responses
like:

  "That feature is a design requirement of the protocol."

  Such responses are, quite frankly, idiotic.  If NONE of the proposed
changes are acceptable, then why are we wasting our time talking about
trying to fix the problem?

  Why can't the people shooting down the proposed changes come up with
a list of requirements that the changes must satisfy?  That should
alleviate much of the discussion.  But my belief is that the people
shooting down proposals will spend 5 years doing just that, and then
discover that their email is unusable.  In the mean time, others who
are willing to accept ugly solutions, will have implemented some
horrible hack which will allow them to keep using email.

  Duct tape and binder twine aren't always bad.

  The problem I have is that most of the requirements for change that
I've seen really appear to come down to "nothing must change."  The
proponents of non-change say that's not what they mean, but they don't
let ANY changes through.

  Actions speak louder than words.

> I have participated in a fair number of efforts to make changes to
> Internet Mail.  Some work.  Some don't.  It would be foolish to
> ignore the lessons of that history.

  I agree.  But most of the opposition to change I've seen doesn't
appear stem for history lessons.  Instead, the discussion goes like:

  a) We can alleviate spam problem FOO by changing the way we do BAR
  b) We want to use BAR as-is
  a) Well, then we can try changing BAZ
  b) We want to use BAZ as-is
  <repeat ad nauseum>
  a) I'm going home, and having a large drink..

  Is there ANYTHING we can change in the use, implementation, or
protocol of SMTP to help alleviate spam?  I've never heard an explicit
"NO" to this question, but I've heard explicit "NO"s to every related
issue, which leads me to believe that the answer to that question is
also "NO".

> 1.  Thousands is not 100 milion.  The difference in scale is important.

  I understand.

> 2.  Ugly and awkward are usually terms that apply to failed proposals.

  Like IPSec.  It's ugly, awkward, but it appears to currently be the
best of ugly and awkward alternatives.

  Until we're perfect and god-like, sometimes the best solution *is*
the ugly and awkward one.

  As someone once said: "Who the heck put a waste disposal site next
to the entertainment district?"

> simply alternatives to "naked, unaccountable SMTP".

  Not at all.  Or, at least, not from me:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg04161.html

>>> Are there NO other methods which a mobile user may use to send mail?

  I was very careful to phrase it that way.

>>> SMTP is only one of many protocols used to send/receive email.

  As my previous messages on this issue have tried to make clear, my
concerns here about SMTP were only about the requirement for mobile
users to be able to send mail to anyone, and claim to be anyone.
That's a "feature" which I believe should be deprecated in SMTP.

> adoption or use in the Internet.  How will you achieve success now?

  PGP and S/MIME solve different problems from RMX.  RMX, like
STARTTLS, can be used to authenticate the conversing peers, not the
content of the message.

> I believe no one else selling and email protocol other than SMTP and making a

  My claim was for SMTP over VPN.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 15:21:47 -0400

> POP/IMAP accounts to arbitrary users without an outbound smarthost.

  Then they have an opportunity to update their business model when
(as may be expected) the world around them changes.

  Alan DeKok.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 5 May 2003 12:16:11 -0700

Hadmut,

>> Accountability does not mean that the originator is comforming to good
HD> Accountability requires the posibility to track back the originator.
HD> That's what's RMX is about.

>> host is not sending spam?
HD> Because he can be tracked back and hold responsible.

what does it mean to hold them responsible, when there are no global
rules to which a sender is held?

>> adoption or use in the Internet.  How will you achieve success now?

HD> That's not logical. If PGP and S/MIME didn't have succes yet, it
HD> doesn't mean that no authentication method will ever have success.

However, it DOES mean that it is dangerous to claim that authentication
will be used as a basic technique, unless there is some reason to
believe that the technique will be successful now, in spite of not being
successful for 10 years.

HD> The failure of PGP and S/MIME is a design criterion for RMX:
HD> It is designed to avoid the problems of PGP and S/MIME,

they perform entirely different tasks.

HD> Furthermore, PGP and S/MIME are a completely different story.
HD> You're comparing apples and oranges.

the reference was to authenticated senders.  pgp and s/mime authenticate
senders.  rmx does not.

d/

---

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

Alan,

AD>   I agree, but it does mean that we can account for whether or not the
AD> originator is conforming to good policies.  It's just one more nail in
AD> the coffin of spammers.

It is one more nail into something, yes.  But there has not yet been any
detailed description of what it accomplishes that is useful.  It adds
overhead, but no one has yet stated what it enables that is useful in
the prevention, detection, or handling of spam.

>> we are not in a better position to distinguish them.
AD>   I agree, but for that pool, we're no worse off than we were before.

when you add mechanism, you make things worse -- more complicated and
more effort. this is only acceptable when you are also making things
significantly better. so far, no one has provided a clear and compelling
case in favor of using rmx for anything that will prevent or reduce
spam.

>> host is not sending spam?

AD>   Nothing.  But having proven to be a spammer, it's easier to hold
AD> them to account, and to block/filter their traffic.

so the benefit is post-hoc filtering of spam that has previously
purported to be from a particular host and continues to falsely claim to
be from that host?

unfortunately, spammers will work around that block within hours. they
are very clever and adaptable.  so you will have spent a great deal of
time and energy to create a mechanism that will prevent spammers for,
perhaps, a few days.  total.

AD>   At the minimum, RMX will alleviate the need for DUL blocks.  RMX can
AD> alleviate the "forged sender" problem,

no it will not.  not until the entire internet uses it, and that will
not occur for a very long time.

>> assumptions about their adoption" with "do not make any changes."

AD>   That's probably because ANY change which is proposed gets responses
AD> like:
AD>   "That feature is a design requirement of the protocol."

AD>   Such responses are, quite frankly, idiotic.  If NONE of the proposed
AD> changes are acceptable, then why are we wasting our time talking about
AD> trying to fix the problem?

If you need to cook some food and you propose to hold the food in your
hand while it is cooking, do not blame the person who observes that
there is a basic, serious problem with your approach.

look for a better approach.

AD>   Why can't the people shooting down the proposed changes come up with
AD> a list of requirements that the changes must satisfy?

please read the internet draft I submitted last week.

there are some other drafts floating that also do as you suggest.  have
you read them yet?  what about them is insufficient?

AD>   I agree.  But most of the opposition to change I've seen doesn't
AD> appear stem for history lessons.

you must be reading different mail than I.

>> 2.  Ugly and awkward are usually terms that apply to failed proposals.
AD>   Like IPSec.  It's ugly, awkward, but it appears to currently be the
AD> best of ugly and awkward alternatives.

actually, there is frequently a stronger case for TLS, when needing
connection-based privacy and authentication.

>>>> SMTP is only one of many protocols used to send/receive email.

Apparently we read your original statement very differently.  I cannot
guess how you interpret it as meaning anything other than claiming there
are alternatives to SMTP.  (And we can ignore the error in claiming that
SMTP is used to receive mail, although it is only used to send it.)

So far, no protocol other than SMTP has been citing for sending email,
other than a couple of ancient protocols that long-ago failed to be
enhanced and failed to be widely adopted.

>> I believe no one else selling and email protocol other than SMTP and making a

AD>   My claim was for SMTP over VPN.

SMTP over VPN is SMTP.  Hence it is not "only one of many protocols used
to send/receive email".  It is SMTP.

d/

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 5 May 2003 21:49:17 +0200

Dave,

> rules to which a sender is held?

It means: 

- to hold them responsible by the rules and laws of the country 
  the Spam comes from. Most Spam originates from the US. Many
  countries have or develop laws against Spam.

- if the message comes from a country without rules, to 
  identify the country where the domain resides and to give 
  you that information to base your decision on

- to allow blacklisting domains or responsible persons mentioned
  in the whois entry

> believe that the technique will be successful now, in spite of not being

That's nonsense. RMX is a completely different kind of authentication.
It doesn't require any special software or configuration on the MUA
side, and it doesn't require per person key generation. 

The main reason is, that PGP and S/MIME didn't have any real
purpose for the masses, it was a complicated game which became
boring. They take a severe overhead of user interaction for every
single mail.

RMX solves a real problem people have 10-20 times a day. PGP and
S/MIME never did so. RMX doesn't require user interaction (once it is
installed).

> the reference was to authenticated senders.  pgp and s/mime authenticate

Exactly. That's what RMX is designed for. RMX is designed to not
handle user details, that's to be left in the domains private
business. RMX covers the domain part only to keep it smart and simple 
and to avoid work for every single user. It's expense is O(1). 
To be precise in security science, RMX is not even an authentication.
Actually, the authentication is done by TCP/IP, where TCP traffic
allows to sufficiently ensure that the peer IP address is reliable. 
A higher level of security is not reasonable since mail delivery by
SMTP also is limited to the TCP/IP address check. So the sending
MTAs "name" is the IP address and the "authentication mechanism" is 
TCP/IP. (I know, this is not a real good one, but it is sufficient for
this purpose.) RMX is the method to distribute the authorization
information through DNS. It tells you which IP addresses are
authorized to use the given domain as part of the sender address. 
That's it. No sender authentication. Being cheap, simple, and robust
is the design goal. Not 2048-bit-security that nobody uses.

Hadmut

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 5 May 2003 14:30:05 -0600 (MDT)

> prevents others from forging mail from my domain, then that's a good

I don't agree.  Since you've made the assertion, you bear the burden
of supporting it.  To help you, I'll point out some facts you'll
need to address:
  - For RMX bits to be useful dialup users, their mail provider must
     list their home IP addresses.  That would be a major burden for
     all but the smallest outfits that serve as home domains, except
     for something that seems to make the problem worse.  The IP
     addresses of dialup users are dyanimic (hence the 'D' in "DUL").
     Thus, the home domain must list all IP addresses of the dialup
     ISP as legitimate senders, because the user might next get any
     address owned by the dialup ISP.  For dialup ISPs with millions
     of current and prospective customers (e.g. RBOCs and cable modem
     providers), that would amount to authorizing a lot of spammers.
     In that case, what information would the RMX bits convey?

   - how big a problem is forgery of your domain name?  How many such
      messages do you see daily?  

   - until a signficant number of SMTP servers check RMX bits and reject
      messages with mismatching RMX bits, there will be just as many
      forgeries of your domain name.  How long until a significant
      number of SMTP servers check RMX bits?

> a list of requirements that the changes must satisfy?  ...

Have you read Dave Crocker's ID?

>                                                        That should

>   Actions speak louder than words.

Indeed.  So why aren't you out applying tape and twine instead of
railing at people who you say are "preventing" your use of RMX?

> STARTTLS, can be used to authenticate the conversing peers, not the

You are ducking the question.  While PGP and S/MIME were created to
solve different problems, they certainly do permit identifying the
originator of email.  If identifying the originator of email is
effective against spam, what's wrong with PGP and S/MIME for serving
that purpose?

   ......

> Message-Id: <[email-masked]>

> (as may be expected) the world around them changes.

In your preceding message you said that Yahoo was going to leap on
the RMX bandwagon.  Are you now saying that Yahoo will leap on a
bandwagon that forces them to update their business model?  What
business model do you foresee Yahoo using?  Would Yahoo users be
required to use Yahoo SMTP clients to send mail?  If so, how will
Yahoo users get past port 25 blocking on other ISPs?

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 5 May 2003 14:01:31 -0600 (MDT)

> > millions of people use them.

Do AOL, Yahoo, and Hotmail have a total of more than 100,000,000 mail
users?  I don't think so, but if I'm wrong about that, I know that
that the RMX bits of AOL, Yahoo, and Hotmail would all say "any IP
address on the net can send mail with envelope Mail_From values of
our domain."  They all have many mail users that must send mail from
other ISPs and who are their mail users only because they can use AOL,
Yahoo, and Hotmail return addresses.

> themselves adding RMX records to their DNS.

If the service is merely "priority" instead of "rejection," certainly
not.  In technical practice they cannot give better service to incoming
mail with RMX tags than without.  In fact, the cost of checking the
RMX RRs will slow down mail that has RMX records.

Those 3 companies won't decide to reject mail without RMX records
because their RMX bits will authorized all IP addresses everywhere.
Microsoft certainly won't because of anti-trust issues.   AOL won't
for the same reasons that caused AOL to abandone its old closed BBS
system.  AOL has jumped on some radical filtering, but only when it
had single digit false positive rates.  Today rejecting mail without
RMX bits would have a better than 99.99% false positive rate, and there
is no prospect that will change.

> web sites within 3 years.  That's a good timescale for something like

You'd lose that bet, unless you circularly define "active domains" as
those with HTTP servers.

> of ad hominem attack, and one which astudiously avoids discussing any

In your message you twice claimed that RMX records will be very popular
in less than 10 years, including in your immediately preceding words.
Asking if that's your position is hardly inappropriate.

> filtering of ALL traffic from that domain.

Why do you need contact anyone before filtering all traffic from a
domain that has a pattern of supporting spammers?  What spam supporting
domains are you unable to identify today without RMX?

> didn't use our MX, so it's not our problem."  RMX allows the recipient

Why do you care about the plausible deniabilty of outfits that support
spammers?  If they are popular with spammers, why don't you just quitely
blacklist them?  Why do you need to count coup on them first?

>   I don't have the time, sorry.

My point is that the information you say you want and a lot more is
already available.

> nothing to do with general anti-spam policies.

My point was that the information you say you want from RMX
and a lot more is already available.  If you "don't have the time"
to deal with whois, then you won't have the time to deal with RMX.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 05 May 2003 16:48:42 -0400

> the prevention, detection, or handling of spam.

  Which leaves out the previously stated utility of the proposal:
tracing and accounting.

  Once more spam is traceable and accountable (where RMX may help), we
can apply other methods to prevent/detect/handle spam (where RMX
may not help.)

> case in favor of using rmx for anything that will prevent or reduce

  RMX is a low-cost mechanism for both the sender and receiver, so any
requirements on it "making things significantly better" are similarly
expected to be low.

> purported to be from a particular host and continues to falsely claim to

  That's one benefit, yes.

> perhaps, a few days.  total.

  I'm not sure why RMX would be "a great deal of time and energy" to
implement.

  As for utility, let's suppose that all spammers implement RMX on
their originating MTA's.  In addition to Hadmut's recent comments,
this has other benefits for the recipient:

  - we can now blacklist by domain, in addition to IP.
    There are fewer domains than IP's, by probably 2 orders of
    magnitude.

  - the spammers choice of originating IP will be more limited,
    which decreases the work required for IP blacklists.
    (A newly discovered open relay which is added to a spammers DNS
     as RMX will take more time to fully propogate throughout the net
     than TCP connections from that relay)

  RMX can help moderate the work required to deal with spam, and can
help to slow down the rate of sending spam.

> you read them yet?  what about them is insufficient?

  Some.  I don't have specific objections right now, otherwise I would
have said something.

  As for your draft, I think it's very good.  But it's much looser on
the requirements for proposed solutions than the discussions on this
list have been.  So until the draft becomes more restrictive on the
requirements, I'm left addressing opposition/requirements on the list,
and not in the draft.

> you must be reading different mail than I.

  <shrug>  The messages don't quote history, and say "we tried this in
1998, and that doesn't work for reasons given <here>."  Instead, the
messages say things like "It takes significant time before protocols
are widely adopted."

  For some protocols, yes.  For others, no.  See:

http://www.freeradius.org/rfc/radius-minutes-95apr.txt

  RADIUS was designed and originally implemented around 1993.  By
1998, it had acheived wide-spread adoption.  Similar things may be
said for HTTP.  Sub-decade widespread adoption of new protocols is the
reality of the net, given:

  Incentive:           high.
  Implementation cost: low.

  We're now at the point where we have high incentive to fight spam.
If there's a low-cost solution which will help recipient MTA's, then
my prediction is that it will achieve wide-spread adoption within 3
years.  That is, at least 30% of sites will use it. (By number of
users, not domains, as there are millions of domain squatters.)

  That's a testable prediction.  If I'm wrong, then 3 years from now,
I'll buy people a beer (or other beverage) at IETF.  If I'm right,
then I ask that people predicting otherwise buy *me* a beverage.

  Until then, it's all "he said, she said" for whether or not any
proposal will achieve wide-spread acceptance.

> >>>> SMTP is only one of many protocols used to send/receive email.

  Again, you've snipped the previous sentence, which gives additional
context.

  I can't help your misunderstanding what I say, if you insist on
taking things out of context.

> to send/receive email".  It is SMTP.

  Wonderful.  So you have no opposition to a BCP document which says
that mobile users SHOULD use SMTP over VPN's to their home domains,
and SHOULD NOT send SMTP traffic directly to the final recipient.

  As I've tried to explain in many messages, I don't oppose all of
SMTP design, implementation, or practice.  In the context of mobile
users, I oppose some current practices involving SMTP, and believe
that there are viable alternative to those practices.  But I've never
claimed that we should throw away SMTP entirely.

  Alan DeKok.

---

From: J C Lawrence <[email-masked]>
Date: Mon, 05 May 2003 22:36:35 -0700

On Mon, 05 May 2003 15:21:47 -0400 

> (as may be expected) the world around them changes.

Considering the companies involved and their business models (MSN,
Hotmail, Yahoo, etc), I guess their eagerness to adopt as negative, and
the chilling factor that reticence would add to adoption velocity as
noticeable.  You're dealing with significantly higher operational costs
for a business with a very slim profit percentage.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 06 May 2003 10:04:42 -0400

Vernon Schryver <[email-masked]> wrote:
>      list their home IP addresses.

  Nonsense.  I have stated explicitely many times that I expect
users at a domain to authenticate to a well-known MTA for that domain,
and to use that MTA for sending mail.

  In that situation, a proposal which "qualifies" the originating MTA
will deal with the public MTA for that domain, not the umpteen IP's in
the network for that domain.

  I find it curious that your objection to a proposal is based on
using it a situation where it's expensive and unhelpful, when
equivalent, but cheaper alternatives exist.  Your agenda appears to be
to find any crumb, no matter how contrived, which you can then use to
devalue a proposal.

>      In that case, what information would the RMX bits convey?

  In a nonsense situation you invent, of course the propose is
useless.  But you'll have to take the ownership for the nonsense
situation, as I've never had anything to do with it.

>       messages do you see daily?  

  Last time I checked years ago, it was a fair number a week.  I got
tired of wasting my time dealing with idiots who didn't understand
forgeries, and bit-bucketed all of those messages.  If I care enough
to check today, I'm sure the number of forgeries would be large.

> Have you read Dave Crocker's ID?

  Yes.  I read it again yesterday, to be sure I hadn't missed
anything.  It's a good start, but it's significantly more vague than
messages on this list.  Until such time as it signficantly restricts
proposed solutions, I'm left dealing with more descriptive messages on
this list.

> railing at people who you say are "preventing" your use of RMX?

  Since I've never said that, I have no clue as to what you're talking
about, or what your problem is.

  My concern has been people who oppose proposals, where that
opposition consists mainly of comments like "that won't work", or "we
don't want to change that", or inventing nonsense situations, or
ridiculous ad hominems.

> effective against spam, what's wrong with PGP and S/MIME for serving

  Cost.  DNS lookups are cheaper than accepting a full SMTP
transaction, and then doing crypto on the data received.  Is it really
that hard for you to figure that out?

> business model do you foresee Yahoo using?

  One that works?

  One that reduces their costs?

>  Would Yahoo users be required to use Yahoo SMTP clients to send
> mail?

  If Yahoo desires it, I don't see why not.

>  If so, how will Yahoo users get past port 25 blocking on other
> ISPs?

  That's really up to Yahoo, the ISP, and their customers, isn't it?

  Alan DeKok.