Subject: RE: namedroppers, continued

From: Fred Baker <[email-masked]>
Date: Fri, 06 Dec 2002 13:41:52 -0800

At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote:
>The only way to resolve this issue properly would be to require every
>submission to an IETF mailing list to be cryptographically signed (PGP
>or S/MIME), to require the subscribers to register their signing key and
>to then filter the mail sent out on the list so that only signed mail
>gets through.

I would be in favor of that, personally, as long as we can ensure that the 
appropriate signature facility (be it RSA, PGP, or whatever) is freely 
available to all who need to use it. The issue here is not us corporate 
types who have a business reason to buy the software, it is the students 
who often lack the funds. The big issue would be the procedures for posting 
one's key to the appropriate place - what is to stop a spammer from posting 
a key and sending the spam anyway? I'm not proposing a mechanism, but 
someone who is good at such things might well find it of value.

It doesn't address the "off topic" issue. As you say, that could be left to 
a working group chair equiped with formal procedures developed by consensus 
within the work group or adopted by the working group from a more general 
place (ie, the IETF could suggest a procedure, and the WG could adopt it if 
it didn't feel another procedure would be better).

I have had a private exchange, over the past few days, with someone who 
wished that the IETF would please document some good spam-elimination 
procedure, so that it could be used world-wide to completely eliminate 
spam. I think that boils down to "provide a global PKI" in this solution, 
and presumes that spammers are incapable of using one. That might be a 
great research topic. Too bad nobody has ever thought of it before; we 
could really use the outcome of that research. (OK, so it's a lame attempt 
at humor...)

I think it was Steve Bellovin that suggested a procedure for reducing the 
utility of spoofing source addresses in emails; if not, it was me and I 
happened to suggest something his favorite algorithm fit into, by having a 
host in each mail domain (mailid.example.com) be able to assert that its 
domain had or had not sent an email within a given recent  time period 
whose MD5 hash, when divided by <vector of prime numbers> resulted in 
<vector of remainders>. I could write that up in an internet draft if folks 
think it makes sense. That would be a more global procedure that didn't 
require a PKI and only addressed spoofed addresses.

---

From: Marc Schneiders <[email-masked]>
Date: Fri, 6 Dec 2002 23:23:20 +0100 (CET)

> require a PKI and only addressed spoofed addresses.

Spammers would be the first to set up your mailid host. They will have
had years of experience to find holes in the system before you've
convinced everyone to adopt or accept the mailid.

It might be easier to write a new protocol to succeed email, instant
messaging, mobile phones (something useful in itself) with built-in
abuse control from the start.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 6 Dec 2002 16:15:21 -0700 (MST)

> From: Fred Baker <[email-masked]>

>   ... I think that boils down to "provide a global PKI" in this solution, 

It's been years since it was possible to be amused by the number of
people who assume that spammers are more ignorant and less competent
than they are, and so propose spam "solutions" predicated on spammers
being unable to register as many names, keys, identities, or whatever
as needed or as many as everybody else can.

> ...

That's not a powerful solution, because it assumes the existence of
a central mail authenticator for every domain that might send mail.
As long as most SMTP clients don't have such authenticators, the
spammers would simply avoid the few that do, just as they already
avoid providers that break the financial kneecaps of spammers.

As far as I can tell, the familiar claim that most spam carrying
surprising header or envelope From adddresses is forged is mostly wrong.
The claim seems to be based in large part on the knowingly misleading
descriptions of the situation by free mail providers.  The free providers
claim that almost all spam implicating them is "forged." If you read
the fine print in their announcements of terminated accounts, responses
to spam reports, and related messages, you'll discover that free provider
spam is "forged" in the same sense your picture postcards would be if
you were evicted from your home while travelling.

That suggests that such authenticator servers would help reduce spam
using free provider drop-boxes.  However, a better solution that does
not involve the rest of the network subsidizing the advertising agencies
that are the free providers is to reject all mail apparently from free
providers.  Doing extra processing that is made necessary only because
the free providers cannot be bothered enforce sufficiently painful
terms and conditions on their users is a subsidy.  The free providers
could stop spammers from using their services if they would launch
lawyers, require bonds (e.g. creditcard numbers), or any of many
other things, but anything would cost them money.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 6 Dec 2002 16:22:09 -0700 (MST)

> From: Marc Schneiders <[email-masked]>

> abuse control from the start.

That's another stupid crackpot "spam solution" that just won't go away.

You cannot have "abuse control" built into a protocol that allows
strangers to send each other mail.  Any mail protocol that lets you
receive mail from a stranger must also let the stranger send the same
message to you and to 30,000,000 of your closest friends.  On the
other hand, if you want to only accept mail from people who are not
strangers, you can use any of the many official and ad hoc SMTP
extensions to ensure you only receive mail from them.

If your computer system, mail protocol, or whatever knows that a
stranger is not a spammer, then the stranger is not really a stranger.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 07 Dec 2002 00:05:29 +0000

it's difficult to imagine a mailing list for which this thread is on-topic.

> require a PKI and only addressed spoofed addresses. --

here was my attempt at this, which i didn't really know where to go next with:

   Independent                                            Paul Vixie (Ed.)
   Request for Comments: XXXX Category: Experimental
   June 6, 2002

                            Repudiating MAIL FROM

   Status of this Memo

      This memo describes an experimental procedure for handling received
      e-mail.  It does not specify an Internet standard of any kind.
      Distribution of this memo is unlimited.

   Copyright Notice

      Copyright (C) The Internet Society (2002).  All Rights Reserved.

   Abstract

      At the time of this writing, more than half of all e-mail received by
      the author has a forged return address, due to the total absence of
      address authentication in SMTP (see [RFC2821]).  We present a simple
      and backward compatible method whereby cooperating e-mail senders and
      receivers can detect forged source/return addresses in e-mail.

   1 - Introduction and Overview

   1.1. Internet e-mail return addresses are nonrepudiable by design of the
   relevant transport protocols (see [RFC2821]).  Simply put, there is no
   cause for ANY confidence in the proposition "this e-mail came from where
   it says it came from."

   1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail
   routinely use this designed-in lack of source/return authenticity to
   hide their point of origin, which usually involves forging a valid
   return address belonging to some highly visible and popular ISP (for
   example, HOTMAIL.COM).

   1.3. Recipients who wish to reject unwanted bulk e-mail containing
   forged source/return addresses are prevented from doing so since the
   addresses, as presented, are nonrepudiable by design.  Simply put, there
   would be too many false positives, and too much valid e-mail rejected,
   if one were to program an e-mail relay to "reject all e-mail claiming to
   be from HOTMAIL.COM" since, statistically, most e-mail claiming to be
   from HOTMAIL.COM is actually from somewhere else.  HOTMAIL.COM, in this
   example, is a victim of forgery.

   Vixie                         Experimental                      [Page 1]

   RFC XXXX                  Repudiating MAIL FROM             May 26, 2002

   1.4. What's needed is a way to guaranty that each received e-mail
   message did in fact come from some mail server or relay which can
   rightfully originate or relay messages from the purported source/return
   address.

   1.5. Approaches of the form "use PGP" and "use SSL" are not scalable in
   the short term since they depend on end-to-end action and there are just
   too many endpoints.  An effective solution has to be applicable to mail
   relay, not just final delivery.

   1.6. Valid ("wanted") e-mail must not be rejected by side effect or
   partial adoption of this proposal.  Source/return authenticity must be a
   confidence effector, as in "we can be sure that this did not come from
   where it claims" and simple uncertainty must remain in effect otherwise.

   2 - Behaviour

   2.1. Domain owners who wish their mail source/return information to be
   repudiable will enter stylized MX RR's into their DNS data, whose owner
   name is "MAIL-FROM", whose priority is zero, and whose servername
   registers an outbound (border) relay for the domain.  For example, to
   tell the rest of the Internet who they should believe when they receive
   mail claiming to be from [email-masked], the following DNS MX RR's should
   be entered:

      $ORIGIN isc.org.
      MAIL-FROM MX 0 rc
                MX 0 rc1

   In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as
   appropriate places to originate mail from @ISC.ORG.  Note that this
   differs from the normal inbound MX RRset for this example domain:

      $ORIGIN isc.org.
      @         MX 0 rc
                MX 0 isrv4

   So, the inbound mail server set partially overlaps with, but differs
   from, the example outbound mail server set.  This is quite common in the
   Internet, and is the reason why the normal inbound mail server set
   described by a domain's apex MX RRset cannot be used for repudiation
   purposes.

   Vixie                         Experimental                      [Page 2]

   RFC XXXX                  Repudiating MAIL FROM             May 26, 2002

   2.2. Second-stage relays such as ISP mail servers are often used and can
   be described by adding as many relays as necessary to the MAIL-FROM MX
   RRset.  In our example, if ISC sometimes used UUNET for outbound mail
   services, the DNS data describing this relationship might be as follows:

      $ORIGIN isc.org.
      MAIL-FROM MX 0 rc
                MX 0 rc1
                MX 0 uunet.uu.net.

   Let it be noted that a domain owner's power to repudiate forged e-mail
   is only as strong as the security policy of its registered inbound and
   outbound mail relays, and that if such a relay is (for example) open to
   third party relay, then no value will be added by registering a domain
   MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking
   will be possible on final delivery relays for a domain @ MX containing
   that relay.  Multistage relays (both inbound and outbound) are a
   breeding ground for anonymity unless they are very carefully configured.

   2.3. SMTP receivers wishing to attempt repudiation on inbound e-mail
   would check the SMTP (see [RFC2821]) MAIL FROM payload at the time of
   receipt.  The precise method to be used is as follows:

   Vixie                         Experimental                      [Page 3]

   RFC XXXX                  Repudiating MAIL FROM             May 26, 2002

      on (MAIL FROM mailfrom) {
           switch (repudiated(mailfrom, ipsource))
           case tempfail:
                smtpreply(450, "temporary dns failure, try again later")
                break
           case repudiated:
                smtpreply(550, "surely you're joking")
                dsn("5.7.1", "delivery not authorized")
                invalidate()   // reject all but QUIT and RSET
                break
           }
      }

      repudiated(mailfrom, ipsource) = {
           (lhs, rhs) = parse_addr(mailfrom);
           // handle "MAIL FROM:<>" somehow
           mxset = get_mx("MAIL-FROM" "." rhs);
           if (mxset == NULL)
                return nonrepudiated;
           mxset += configured(perimeter_relays);
           foreach mx (mxset) {
                aset = get_a(mx.server);
                if (ipsource IN aset)
                     return nonrepudiated;
           }
           return repudiated;
      }

   (EDITOR'S NOTE: need to establish a value for 5xx.)

   The method amounts to "if there's a MAIL-FROM for the purported domain
   and if the IP source isn't on the resulting list, then reject the mail".
   Multistage inbound relays are allowed for, by implicitly appending one's
   own outer perimeter relay names to every extant MAIL-FROM.

   3 - Impact

   3.1. This specification is optional, and will only affect cooperating
   parties.  Any domain owner who does not enter a MAIL-FROM will be
   unaffected, and any SMTP receiver who does not look for a MAIL-FROM at
   time of receipt will be unaffected.  However, both parties working
   together CAN work to repudiate forged e-mail return/source information.

   3.2. Transport-level e-mail forwarding must be more explicit under this
   specification.  For example if [email-masked]'s account has a

   Vixie                         Experimental                      [Page 4]

   RFC XXXX                  Repudiating MAIL FROM             May 26, 2002

   ".forward" file pointing at [email-masked], then e-mail sent to the
   former will be received by the latter, but with no change in the payload
   of SMTP MAIL FROM.  Thus, ISC's inbound relays would have to be
   configured to implicitly add NETBSD's outbound mail relays as
   "multistage inbound relays."  This could scale poorly and may add
   pressure toward transport remailing (with a new envelope) rather than
   transport forwarding (reusing the old envelope.)

   3.3. Roaming hosts such as laptop computers will probably not be able to
   be listed in the MAIL-FROM MX RR for their return address domain name,
   and may be forced to use an intermediary for outbound e-mail.  STARTTLS
   or an SSL/SSH tunnel back "home" may become a necessary first hop for
   mobile e-mail.

   3.4. The likely endgame for this behaviour is to force senders of
   unwanted bulk e-mail to stop lying about who they are, which is illegal
   in meatspace anyway -- but such laws are unenforceable due to the nature
   of the Internet's mail system.  Under this proposal, any domain owner
   who is the victim of forgery can respond by adding MAIL-FROM data to
   their DNS zone, and any relay owner who is the victim of forged unwanted
   e-mail can respond by checking for MAIL-FROM data upon receipt of all
   incoming e-mail.

   3.5. The DNS TTL for MAIL-FROM MX RRsets ought to be shorter than for
   the corresponding domain's apex MX RR, since the cost of widely cached
   wrong information is much higher for outbound repudiation data than for
   inbound delivery data.  Consider that an incomplete apex MX RR can cause
   mail to be delivered by a suboptimal path, whereas an incomplete MAIL-
   FROM MX RR can cause valid mail to be rejected by relays who attempt
   repudiation.

   4 - Security Considerations

   In the continuing absence of widely deployed security for DNS, this
   proposal effectively places an access control list for forged
   source/return information in a place where it can be attacked.  However,
   it must be noted that the current senders of forged unwanted bulk e-mail
   are typically not technologically capable of attacking the DNS to insert
   forged MAIL-FROM data.

   5 - Acknowledgements

   This idea originated with Jim Miller <[email-masked]> in 1998.

   Vixie                         Experimental                      [Page 5]

   RFC XXXX                  Repudiating MAIL FROM             May 26, 2002

   5 - Author's Address

   Paul Vixie
      950 Charter Street
      Redwood City, CA 94063
      +1 650 779 7000
      [email-masked]

   Vixie                         Experimental                      [Page 6]

---

From: [email-masked]
Date: Fri, 6 Dec 2002 15:58:36 -0800 (PST)

I'v been saying about need for more radical change in mail protocol for
years now on mailing lists. I'd rather work on smtp itself, but some 
people who were involved in original protocol do not want any serious 
changes to what they'v done, though its clear that abuse and other holes 
with current system is creating too many problems.

In any case, by next ietf meeting in san francisco, I'll bring complete
proposal for new protocol and might even try some practical tests. I do still 
believe that smtp can be saved, but not without more complex authentication
system during delivery of email and that can't be done with current 
protocol design or current available extension process. 

Also were there any discussions or more complete discription of this 
algorithm for checking if host had sent an email and if so is this 
available on website or archive to read more about? If answer is yes, can 
somebody send me url or approximate date of discussions so I could lookup 
in archives. 

And am I correct here in understanding what was proposed is that smtp 
conversation id be such that receiving mail server could verify with 
sender (callback?) that it deed indeed initiate the email. If so I do not 
quite understand how MD5 helps there, plus I see quite a few problems with 
creating some special mx-like record in dns just for verification. If 
this is indeed what was proposed its better to go with paul vixie's 
proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or
http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt

---

From: [email-masked]
Date: Fri, 6 Dec 2002 16:14:10 -0800 (PST)

This is note quite right. While its impossible to built open system that 
would prevent all abuse, you can first of all built system that would 
provide good verification of who sender is and you can do a lot to make it 
difficult to send thousands of same emails or at least make it easy to 
identify who is doing it and give tools for sysadmins to monitor and 
prevent such activity.

---

From: Joe Baptista <[email-masked]>
Date: Fri, 6 Dec 2002 19:55:10 -0500 (EST)

> proposal of mailfrom dns record - http://www.vix.com/~vixie/mailfrom.txt or

I've had a look at vixies proposal and it's a good one.  I certainly would
welcome something like the mailfrom dns record.

regards
joe baptista

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 20:53:01 -0500

> welcome something like the mailfrom dns record.

actually I'd call it a nonstarter in its current form.  given that

- mail from is used for nondelivery reports and other notifications;
  users need to make sure it gets set to an address that they'll read

- nomadic users have valid reasons to post from random places on the net 
  (including multiple ISPs) and keep the same mail from address.

- many ISPs won't let you forward or submit mail through someone else's 
  SMTP server, even if you have permission to do so.  so you can't 
  forward your mail through your "home" ISP's mail server to allow the
  "mail from" check to work.

trying to reuse any of the existing return addresses in email as a 
spam identifier just won't fly.  a separate identifier might work.
(actually Sender is the closest thing to what is needed here, 
unfortunately it's routinely munged by mailing lists)

Keith

---

From: [email-masked]
Date: Fri, 06 Dec 2002 21:22:22 -0800 (PST)

> actually I'd call it a nonstarter in its current form.

I would have to agree.

>  given that

>   "mail from" check to work.

In addition to these valid concerns I'd add that various sorts of
autoforwarding exist that don't change the MAIL FROM. These would also tend to
break if such a scheme were implemented.

I'm also concerned about the management aspects of having lists of authorized
"multistage relays" and all that implies.

> spam identifier just won't fly.  a separate identifier might work.

But there's also a problem with NOT using the MAIL FROM -- one of the things
that's being counted on here is that mailing list expanders will (optionally)
check the MAIL FROM against this new DNS record, but then change it
unconditionally to an address associated with the list expander rather than
with the originator.

> unfortunately it's routinely munged by mailing lists)

To the extent that sender is munged by mailing lists to refer to the 
list expander it would actually be a feature here, not a bug. But just
as you cannot count on it being left alone, you also cannot count on it
being changed.

Perhaps the real problem here isn't the use of MAIL FROM but rather the
assumption that binding ipsource to the MAIL FROM domain is a useful 
validation check. A specific ipsource is just not a property a legitimate user
of a given domain can be expected to have. Although I am reluctant to suggest
anything involving public key crypto, another approach would be to put a
public key in the MAIL-FROM DNS record and add a new header field containing a
signature covering the message's  MAIL FROM and the current date.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 02:29:11 -0500

> Although I am reluctant to suggest

that's an interesting idea.  I don't see a big problem with doing something
like this as long as you don't try to make it a signature for the message -
it's just a way to say "I can prove that I have the right to use this
MAIL FROM".  you might need to include more than just the date though.

Keith

---

From: Paul Vixie <[email-masked]>
Date: 07 Dec 2002 08:21:20 +0000

>   users need to make sure it gets set to an address that they'll read

that problem doesn't change.  all the mailfrom draft says is that you
need to be coming from a designated server to be able to set MAIL FROM.

>   (including multiple ISPs) and keep the same mail from address.

then, i'm sorry that i'm such a poor writer.  i tried to cover this case:

>   "mail from" check to work.

in that case you'd be wise to not insert a MAIL-FROM MX for your domain.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: 07 Dec 2002 08:25:38 +0000

[email-masked] writes:

> autoforwarding exist that don't change the MAIL FROM. These would also
> tend to break if such a scheme were implemented.

i apologize for being such a poor writer.  what the "draft" actually says is:

> I'm also concerned about the management aspects of having lists of
> authorized "multistage relays" and all that implies.

then you probably would not want to insert a MAIL-FROM MX in your domain.

> validation check. A specific ipsource is just not a property a legitimate
> user of a given domain can be expected to have. Although I am reluctant
> to suggest anything involving public key crypto, another approach would
> be to put a public key in the MAIL-FROM DNS record and add a new header
> field containing a signature covering the message's MAIL FROM and the
> current date.

i love that plan.  we all know that ip source addresses make poor passwords.
however, it has to be an envelope thing, not a header thing, since it's hop
by hop.  perhaps "MAIL FROM:<$address> $sig" as an ESMTP thing?
-- 
Paul Vixie

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 10:10:18 -0500

> in that case you'd be wise to not insert a MAIL-FROM MX for your domain.

what this seems to require is to have different sets of domains for 
use in MAIL FROM addresses - those for which source verification can
be expected and those for which it cannot.  there are some current
domains which are naturally and exclusively in the former category - 
say hotmail.com; but most domains are probably not exclusively in 
either category.  so it would require establishment of new domains and 
reconfiguration of systems to use those domains to be effective - along 
with the educational effort that this entails.  and it would still
leave a significant portion of mail without a way to identify its source.

Keith

---

From: Paul Vixie <[email-masked]>
Date: Sat, 07 Dec 2002 18:06:31 +0000

> be expected and those for which it cannot.

yes.

> there are some current domains which are naturally and exclusively in
> the former category - say hotmail.com; but most domains are probably
> not exclusively in either category.

yes.

> so it would require establishment of new domains and reconfiguration
> of systems to use those domains to be effective - along with the
> educational effort that this entails.

i think most of the reconfiguration effort would be around existing domains.

> and it would still leave a significant portion of mail without a way
> to identify its source.

so far, working toward a single solution that covers all cases and is easy
("low cost") for spam victims and infrastructure owners to take part in, has
not worked.  what you see in the mailfrom "draft" is just a "point solution."

i am reminded by this thread that the most powerful force on the internet
continues to be a single voice saying that something cannot be done.

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 13:56:54 -0500

> continues to be a single voice saying that something cannot be done.

well, I've certainly seen it happen.  (though I think the most
powerful force on the internet is large numbers of voices insisting
that something be done whether or not it makes sense - not that this
is what is happening here.)

I don't want to discourage you from developing the mail from dns idea 
further, but neither do I think it will help the spam problem much.
my biggest concern is that it will be used as an excuse to constrain
where people can send mail from, and at a time when ill-conceived spam 
countermeasures are already a serious operational problem and probably
the most significant cause of failure to deliver legitimate mail.

Keith

---

From: Dean Anderson <[email-masked]>
Date: Fri, 6 Dec 2002 17:46:46 -0500 (EST)

Every domain would have to have a public key that the public could find.
Then every mailserver would have to check every message.

And spammers could still send spam, because they are authorized to send
email from some ISP, using that ISP's domain, and that ISP mailserver will
sign their email.

Spam isn't a security problem that can be solved technically.

Spam is the exact same problem as when Randy Bush harrasses someone by
abusing his privileges as administrator. There isn't a technical solution,
other than removing the privileges. Then the new administrator could abuse
the privileges, if they were so inclined.  There isn't a technical way to
give someone privileges that they can't abuse, if so inclined.

		--Dean

On Fri, 6 Dec 2002, Fred Baker wrote:

> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Dec 2002 20:04:34 -0500

--On Friday, 06 December, 2002 16:22 -0700 Vernon Schryver
<[email-masked]> wrote:

>> It might be easier to write a new protocol to succeed email,
>> instant messaging, mobile phones (something useful in itself)
>> with built-in abuse control from the start.
>
> You cannot have "abuse control" built into a protocol that
> allows strangers to send each other mail.  Any mail protocol
> that lets you receive mail from a stranger must also let the
> stranger send the same message to you and to 30,000,000 of
> your closest friends.  On the other hand, if you want to only
> accept mail from people who are not strangers, you can use any
> of the many official and ad hoc SMTP extensions to ensure you
> only receive mail from them.
>
> If your computer system, mail protocol, or whatever knows that
> a stranger is not a spammer, then the stranger is not really a
> stranger.

Actually, Vernon, there is a well-known, established
implementation of this approach.  It depends on no one being
able to deliver mail to anyone else except through a network of
trusted intermediaries, who are interconnected with bilateral
agreements.  Each of those intermediaries is essentially
required to authenticate any user sending a message, which they
naturally tend to do because the system strongly assumes a
per-message and per-recipient charging model with settlements
between the originating and receiving intermediary systems.

If spammers tried to use it, they would rapidly become
discouraged, first of all because the per-message charging would
destroy their "free to us, steal resources from others" business
model and second because the accounting and authentication
machinery that is essential to the business models of the
intermediary system vendors (let's call them "ADMDs" for short)
would make tracking them down fairly easy.  And, of course, the
bilateral agreements would make it fairly easy to isolate and
punish an ADMD who didn't control its spammers or pay it
settlement bills.

I suppose I can leave the name of this high-quality,
significantly overengineered, widely-deployed system as an
exercise.

Been there, wasted a lot of time, energy, and resources, gave up.

    john

---

From: Dean Anderson <[email-masked]>
Date: Sat, 7 Dec 2002 12:08:23 -0500 (EST)

This doesn't adequately describe backup relays.  If uunet is providing an
alternate relay service, then all or any of uunet's relays might be
providing that service. So it would have to be able to recursively look up
uunets mail-from mx's, and the mail-from mx's of any subdomains listed by
uunet.  This process might contain loops.

Additionally, the mail forwarding behavior is highly undesirable.  A large
mail site does not want to have to manually configure essentially the
whole of the internet as possible multi-stage mail relays so that its
users can forward mail from other servers to their mailbox. Indeed, even a
relatively small site would not want to do that.

However, even this approach won't stop spam, since a spammer will still be
able to use their ISP's mailservers, with a stolen, or disposable account.
There are plenty of KLEZ viruses out there, and plenty of stolen
passwords. And it won't have any effect at all on spam from real
commercial operators like Exactis who don't forge the from addresses.

Essentially, I'm convinced after years of interaction with some radical
anti-spammers that most of the non-commercial spam (and quite a lot of the
forged-address spam) is sent by anti-spammers trying to essentially
terrorize their way to some kind of technical solution that they think
exists. However, no such solution exists.  If there were such a solution,
we could prevent all kinds of evils, like government corruption,
embezzlement, misuse of all kinds of property.  But there is no substitute
for honesty and responsibility. If someone has possession of a privilege,
(however that privilege was obtained--it may have been stolen), and they
are so inclined to abuse that privilege, the only way to stop them is to
remove the privilege.

		--Dean

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 9 Dec 2002 11:52:26 -0600

> as needed or as many as everybody else can.

The problem I've seen repeatedly, including in an off-list discussion I'm
having about this topic, is people confusing authentication with
authorization.

Even if you can authenticate every sender of every piece of email, that
gains us virtually nothing -- not to mention it's a reasonably well-solved
problem, e.g. PGP, S/MIME.  As Vernon notes, spammers can create authentic
credentials just as easily as anyone else.

The devil is in determining what senders are authorized once we've
authenticated them.  My fear is the only effective solution may turn out to
be closed lists with permission grants, such as the IM services introduced
to keep spammers out.  That will greatly reduce the utility of email.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 9 Dec 2002 12:15:44 -0600

Paul Vixie wrote:
>> - many ISPs won't let you forward or submit mail through someone
>>   else's SMTP server, even if you have permission to do so.  so you
>>   can't forward your mail through your "home" ISP's mail server to
>>   allow the "mail from" check to work.
>

The vast majority of users do not have the ability to make that decision.

The curious thing is that it is in an ISP's best interests _not_ to
implement this draft, since doing so will likely mark nomadic users' email
as suspect and potentially lose a customer.  Most companies only support the
"public good" to the extent it doesn't cost them any revenue.

S

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 9 Dec 2002 13:39:17 -0700 (MST)

> From: "Stephen Sprunk" <[email-masked]>

> having about this topic, is people confusing authentication with

Yes, that's a good way of putting the problem, but only for those able
and willing to see the differences among authorization, authentication,
confidentiality, non-repudiation, and so forth.

It's sad that weak as dishwater authentication as authorization (and
everything else) snake oil sells so well, as witnessed by Verisign's
PKI and Microsoft's ActiveX.

>               ...    My fear is the only effective solution may turn out to

That has already happened about as much as it is going to happen or
could happen, as witnessed by the IETF lists.  The variations in
effectiveness and mechanisms among the IETF lists are minor details.
The notion of limiting submissions to known authors was once very
controversial here, but it's now accepted as necessary and desirable.
I don't see any reduction in  utility as a result.

Individual mailboxes differ.  Because people value its utility, personal
addresses will continue to accept mail from strangers who might be
sending the same message to 100,000 others.  Various technical and
administrative defenses will limit spam.

Except for those few of us who are obsessed with spam, filters that
are sufficent and require little effort will be used.  Popular choices
will be what people can do for themselves such as private and DNS white-
and blacklists, SpamAssassin, Brightmail, Postinni, Cloudmark/Razor, and
the DCC.  ("Do for themselves" includes hiring a competent ISP.)  Filters
that require joint actions by the sender and receiver, including the
computing-cost and authenticating DNS RR proposals, will never be popular.
Because they won't be popular, installations that start to use them will
switch to sufficient equivalents such as simple white-listing.  Sufficient
existing protocols are never vulnerable to slightly better replacements.

Joint action is an enormous barrier.  It is a cost that is justified
only in special cases.  That is why we are not routinely using PGP or
S-MIME for our private mail.  That's also why I see many more SMTP-TLS
connections to my SMTP server than I expected (many including from
spammers), and why almost none of them are authenticated.  To use
SMTP-TLS you need only install and configure a current SMTP server.
To use authenticated SMTP-TLS, you must use PKI or exchange keys.

---

From: [email-masked]
Date: Mon, 09 Dec 2002 16:53:07 -0500

> having about this topic, is people confusing authentication with

Authentication:  Yes, you seem to be Jeffrey Dahlmer.
Authorization:   You say you'd like to borrow a steak knife?

Usually clears up the confusion in all but the most sluggish mind.. ;)

However, "authorization" usually implies "authentication" beforehand.
Does anybody  have a reference on an authorization scheme that
doesn't imply any authentication?
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 9 Dec 2002 16:17:31 -0600

Thus spake <[email-masked]>
> Usually clears up the confusion in all but the most sluggish mind.. ;)

That's a very clear example, thanks.

> doesn't imply any authentication?

In a sense:  the IETF lists (and most others) use a null authentication
method, i.e. you trust whatever is in the message.  After that (null) step,
we apply weak authorization, i.e. whether the sender is on the approved
list.

I've seen lots of proposals to improve the former-- hardly difficult -- but
none for the latter.  Perhaps using precise terminology will help focus
efforts in the right area.

S

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Dec 2002 17:47:58 -0500

>doesn't imply any authentication?

World readable files.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Matt Crawford <[email-masked]>
Date: Mon, 09 Dec 2002 16:55:03 -0600

> doesn't imply any authentication?

"You will deliver the satchel to the one who presents the matching
half of this hundred-euro note."

---

From: [email-masked]
Date: Mon, 09 Dec 2002 17:59:31 -0500

> >doesn't imply any authentication?

We know how to do that already ;)

I was thinking more along the lines of a zero-knowledge proof or
something like that - a scheme where you can prove you're authorized to
do something(*) without having to prove who you are first.

(*) and explicitly ruling out the 'null check, everybody is allowed' case ;)

/Valdis

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Dec 2002 18:11:54 -0500

--On Monday, 09 December, 2002 16:17 -0600 Stephen Sprunk
<[email-masked]> wrote:

>> However, "authorization" usually implies "authentication"
>> beforehand. Does anybody  have a reference on an
>> authorization scheme that doesn't imply any authentication?
> 
> In a sense:  the IETF lists (and most others) use a null
> authentication method, i.e. you trust whatever is in the
> message.  After that (null) step, we apply weak authorization,
> i.e. whether the sender is on the approved list.

Actually, it is a very common situation:

Think about almost any case in which possession of a token
authorizes one to do something, but no identification/
authentication is implied.  For what is perhaps one of the older
examples, can you go to a store where you are not known, in some
part of your country where you are not frequently present, and
buy something.  Of course you can: you pass an authorization
token, typically called "cash" across the counter and get some
merchandise in return.  The quantity of tokens you possess and
their value even determines the extent of your authorization.

Credit card companies often draw an analogy to that situation,
which is one of the reasons they have stayed far out of the
_public_ part of the PKI business: they don't really care who
you are, or who uses the credit card, as long as the bill gets
paid.  Anything they do or require that involves authentication
has to do with the "the bill will get paid without protest"
property, not your identity.

     john

---

From: Ofer Inbar <[email-masked]>
Date: Mon, 9 Dec 2002 18:19:20 -0500

> doesn't imply any authentication?

From:-line based email filters.

  --  Cos (Ofer Inbar)  --  [email-masked] http://cos.polyamory.org/
  --  WBRS (100.1 FM)   --      [email-masked] http://www.wbrs.org/
   "OSI is a beautiful dream, and TCP/IP is living it!"
     -- Einar Stefferud <[email-masked]>, IETF mailing list, 12 May 1992

---

From: Dave Crocker <[email-masked]>
Date: Mon, 9 Dec 2002 15:49:03 -0800

Stephen,

Monday, December 9, 2002, 9:52:26 AM, you wrote:
Stephen> The devil is in determining what senders are authorized once we've
Stephen> authenticated them.

The concept of being "authorized" to send someone mail has good logic, but
goes against established human communication practises for mail and
telephone.  (Filtering is common to both, but is different from
"authorization".)

Some time ago, Mike O'Dell put forward the idea of "accountable", in the
sense of being able to reach back to the sender, to hold them accountable
for their actions.

The general idea behind pursuing simple authentication presumes that the
really nasty spammers would not want to be identified.  It's not clear how
valid this presumption really would be.

d/
-- 
 Dave Crocker  <mailto:[email-masked]>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Mon, 9 Dec 2002 21:07:38 -0500 (EST)

Blinded coins a la digicash
http://www.law.miami.edu/~froomkin/articles/oceanno.htm#xtocid583124

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   [email-masked]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's warm here.<--