Subject: RE: namedroppers, continued

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 08:28:57 -0800

This whole discussion should be taken to the
YWKTIEDNWWFALNORIBNLTICSADEWSIFOSTFSTNOML working group. (yes we know
that internet email does not work well for a large number of reasons,
including but not limited to, incorrect code, spam and dare we say it
failure of smtp to fully support the needs of mailing lists).

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.

While this would require a moderate degree of work on the part of the
list users it would eliminate the need for moderator action. Problem
posters could be dealt with by means of  a formal process.

Thawte still provides free S/MIME certificates, however for the purposes
of this proposal it would suffice to use a self signed certificate.

SPAM is becomming a serious problem - as Bersnteins own rather offensive
spam protection measures atest. The only way to resolve that problem in
the long run is to start authenticating the good signal at source. The
strategy of attempting to isolate the bad signal from the good is
failling progressively as the spam companies employ counter measures.

The relevance of this to DNS is that the ability to authenticate an SRV
record provides an imense amount of leverage in automating this process.
For example I can have some form of information service set up linked to
the DNS that tells people that I sign every one of my emails without
exception and that any unsigned mail message can be rejected.

SPAM is a security problem. If we don't fix it the signal to noise ratio
will fall way below acceptable levels for many users.

	Phill

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Saturday, November 30, 2002 8:00 AM
> To: D. J. Bernstein
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: namedroppers, continued
> 
> 
> [ 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. ]
> 
> On 29 Nov 2002, D. J. Bernstein wrote:
> > Keith claims that allowing ``contributions from outsiders'' requires
> > delay and manual review. That claim is absurd. Immediately 
> bounce the
> > message to the ``outsider,'' with instructions explaining 
> how to have
> > the message sent to subscribers; end of problem.
> 
> No, it's not 'end of problem'.
> 
> If I cross-post a reply to some message with was cross-posted 
> to a list
> I'm subscribed at and a list I'm not, in the general case I 
> do *not* want
> to subscribe to the other list to be able to send my 
> cross-post reply to
> both.
> 
> Waiting for moderator approval is just fine for me, much better than
> requiring to subscribe or do something else.
> 
> It's not black and white.
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> 
> 
> 
> --
> 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: Aaron Swartz <[email-masked]>
Date: Mon, 2 Dec 2002 12:42:36 -0600

Hallam-Baker, Phillip wrote:
> submission to an IETF mailing list to be cryptographically signed
> [and] to require the subscribers to register their signing key

And how do we prevent spammers from registering their signing key? Are 
you suggesting that we change the IETF's open enrollment policy?

-- 
Aaron Swartz [http://www.aaronsw.com]

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 11:12:36 -0800

First off, the problem of SPAM is one of the perfect being the enemy of
the good. If we can cut the spam by 95% then that is a pretty useful
achievement.

So, no I don't think that the folk selling feather luggage, herbal
viagra, p0rn etc are likely to go to that length in great numbers,
unless that is the Internet as a whole adopts the same type of measure
following our lead.

However I have thought ahead to the issues of scale here, let us imagine
that a large number of groups use the same scheme, that email agents
that filter based on signatures are available and widely used.

First, consider the effect of a minor authentication requirement on
certificate issue, the ability to read email sent to the address
specified in the certificate. Using that technique we could eliminate
spams with bogus addresses which itself would be a major advance. The
amount of spam that comes through with a valid email address is
vanishingly small.

Second consider that if the whole internet follows our lead and starts
to use cryptography routinely there are a lot of additional steps that
then become possible that are not practical until most people have a
public key and there is a means of discovering that via a DNS linkage.

Third one of the things we could do in an extended enrollment process
would be to get participants to agree to the following set of terms:

	1) Thou shalt not SPAM.
	2) Thou shalt permit your messages to be posted in the archives.
	3) Thou shalt provide timely notice of any intellectual property
claims.
	4) Thou shalt not take the name of the chair in vain unless she
deserves it.
	5) etc.

Then we could sue the b*#*@#&ds if they spammed after that. People have
been looking for a test case for digital signatures for ages, so don't
worry about the cost.

A side benefit of this is that it would cause a lot of people to start
using secure email and thus start to create some critical mass for email
security.

What we need is for someone to take Majordomo or the like and merge in
some sort of filter to check S/MIME and PGP signatures. Then find a
group that wanted to serve as a guinea pig (S/MIME or PKIX perhaps?).

Alternatively we should perhaps form a group 'Deployment of secure
email' which could apply this rubric. 

		Phill

> From: Aaron Swartz [mailto:[email-masked]]
> Sent: Monday, December 02, 2002 1:43 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Dec 2002 09:53:28 -0800

One of the main reasons why anti-spam measures are failing is that the
spam-artists are fraudulently hijacking people's email addresses so as
to bypass anti-spam filters. 

My reading of the open enrollement policy is that anyone can contribute.

I don't think that a secondary manual filter by which the first post to
the list by an individual was only forwarded after moderation would
breach that principle - but it would be one heck of a lot less work for
the chairs than having to moderate every message.

I certainly do not consider it an imposition on those who want to
pontificate on Internet protocols to require them to actualy eat the
company dog food and sign their messages with either PGP or S/MIME.

I am not pushing a corporate interest here, a self signed certificate
would be fine. I think that one of the problems for the PKI world is
that the perfect has been the enemy of the good. OK you can argue that
it would not exactly hurt VRSN if more people started to use security
routinely, I don't think that would hurt the IETF either.

		Phill

> Sent: Monday, December 02, 2002 10:43 AM

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Dec 2002 11:05:27 -0800

> From: "D. J. Bernstein" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: namedroppers, continued
> ...
> Okay, Bush: Put [email-masked] on the list of addresses from which
> submissions are automatically accepted.

sorry bernstein.  as your message also was addressed to lists to
which i subscribe, the copy to namedroppers-owner was deleted
locally due to dupe message-id: detection.  erik and harald pointed
it out, and rob just forwarded a copy to me.  so i have done the
addition.

thanks, as approving all your postings was becoming a pain in the
butt.

randy

---

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

How much spam is going to namedroppers?

I haven't seen any. So, don't you think this has gone a little of the deep
end?

		--Dean

---

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

>to then filter the mail sent out on the list so that only signed mail

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: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 06 Dec 2002 17:08:36 -0500

In message <[email-masked]>, Fred Bake
>someone who is good at such things might well find it of value.
Well, it's also the availability of the right signature facility in the 
myriad email clients people use.
>require a PKI and only addressed spoofed addresses. 
Wasn't me...

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Dec 2002 14:34:14 -0800

> How much spam is going to namedroppers?

Well none since Randy Bush and a bunch of others turned
on the moderator bit.

The problem here is that having Randy Bush moderate is
not a scalable solution to the problems of Spam in general.

	Phill

---

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

And how much before Randy was moderator?

I'm on other large, subscriber-restricted, public lists, where this isn't
a significant problem.

		--Dean

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Fri, 6 Dec 2002 16:48:46 -0600

> Too bad nobody has ever thought of it 
> before; we  could really use the outcome 
> of that research
while researchers has not thought about global
PKI, their are research which focus on spam 
elimination.

this is the work all about (yesterday's seminar in a MIT group)

" If I don't know you, and you want your e-mail to appear in my
  inbox, then you must attach to your message an easily verified
 "proof of computational effort", just for me and just for this
 message.

If the proof of effort requires, say, 10 seconds to compute, then the
economics of sending spam are radically altered, as a single machine
can send only 8,000 messages per day.

The recent proliferation of spam has lead to a renewed interest in
these ideas.  This  work is about both the choice of
functions that can be used to yield easily verifiable proofs of
computational effort, and architectures for implementing the proof of
effort approach.  Filtering and/or forcing senders to pay in other
currencies, such as human attention and money, will be covered as time
permits"

for more details http://research.microsoft.com/research/sv/PennyBlack

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Dec 2002 15:45:43 -0800

> myriad email clients people use.

I disagree here, I believe it is a case of supporting the 
overwhelming majority of the platforms with software that
is freely available and free.

I don't believe that we should consider support for Open
Genera to be a 'must support' issue. Years ago people used
to whinge when someone sent a MIME attachment of 10K or 
so because it took too long to download over a 300 baud 
modem.

I don't think it is a bad thing to consider that high 
bandwidth connectivity is still a constrained resource 
absent in many less developed parts of the world. However
the complaints about using MIME never come from those
quarters.

> I could write that up in an internet 
> draft if folks 

The problem is not the PKI, the problem is the directory.

Deployment of PKI is easy. It is the Directory baggage that
people foisted onto PKI that is the failure. X.500 has set
us back more than the NSA crypto export regulations ever did.
LDAP merely compounds the problem, building failure on top
of failure.

We need a DNS linked PKI, not a directory linked PKI.

We need a PKI that only cares about the addresses the
applications route on. The idea of using human names for
PKI is bogus.

The directory PKI model fails for the Internet for many
reasons. First taxonomic organization is a broken concept.
No real world information is stuctured in that fashion,
not even genealogies (cousins marry cousins). The reason
that so many enterprise directory projects are fiascos
is that they are trying to fit data into a representation 
that is simply inappropriate.

The other main reason that directories are a failure for 
Internet PKI is that they are exclusively an internal
data resource. VeriSign has an employee directory accessible
from the inside of the company. There is no way it is 
ever going to be accessible from the outside.

At the Internet level trust relationships are complex,
they are certainly not hierarchical. Trying to store that
data in a taxanomic sturcture then do path discovery is
nonsense on stilts.

Linking the PKI to the DNS completes the picture. I want
to send Fred Baker an email, well I had better know his 
email address first. My email client can follow an SRV 
record from cisco.com to find an XKMS service for cisco.com
where I can ask 'what key should I use to send an
encrypted S/MIME email to [email-masked]'.

Allowing organizations to find out that [email-masked] is still 
working for Cisco is actually a security improvement. It
means that Office Max can shut off his personal stationary
account ordering privs the minute he leaves Cisco.

Don't reject the leverage that public key provides just
because you don't like the package people tried to wrap
arround it. The protocol you describe requires state and
is simply not deployable for large systems like hotmail.

It would be nice if the IETF could get ahead of the curve
this time instead of being the brake. We still have members 
of the IESG speaking to security forums disputing the 
utility of network security measures such as firewalls
even after Steve became a security area director.

We need to shift towards a comprehensive multi-level
security approach which accepts that there are problems
that cannot be addressed by the end to end argument.

Real users are saying that SPAM is their number one 
internet related problem today. Classify it how you like
but deal with it with a security mentality. The spamers
are seriously degrading the utility of email. We need
a short term approach to mitigate the problem (filtering)
and long term approaches that have the potential to
put them out of business. Authenticating the good signal
is completely complimentary with rejecting the bad.

		Phill

---

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: 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: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 07 Dec 2002 13:15:05 -0500

In message <[email-masked]>, Dean An
derson writes:
>This seems clever, however, it will also take significant computational
>effort to verify the computational effort was actually done. Even if a
>class of functions are found that are "easier" to verify than to compute,
>they will no doubt still take up a significant fraction of time.

In fact, that's the easy part.  You could demand that the sender 
compute 1,000,000 HMACs of the text, the envelope, the time of day, and 
a counter.  The verifier could check 100 randomly-chosen ones -- if any 
fail, there's a forgery.  (Well, you probably wouldn't want those 
values, since 1,000,000 HMACs would be a lot of data to transmit.  But 
you get the general idea.)

---

From: Lloyd Wood <[email-masked]>
Date: Sun, 8 Dec 2002 23:56:14 +0000 (GMT)

[ 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. ]

On Fri, 6 Dec 2002, Randy Bush wrote:

> locally due to dupe message-id: detection.

As I said and as this has clearly demonstrated, Randy doesn't
understand admin/policy separation, or that namedroppers-owner should
be a completely different entity to Randy Bush (or at the very least,
carefully and deliberately treated as such).

djb _does_ understand admin/policy separation (as his software
demonstrates) - but far too well, as he insists on applying it to all
of his emails and addresses in a somewhat perverse and rather schizoid
way.

Paul Vixie writes:

$ for the record, we must each work to create the world we want to
$ live in (and that we want our children to live in.)

our children and not all children? can't say I'm big on the Divine
Rights of Parents.

$ i'm not in universal agreement with dbj nor with randy bush, but i
$ won't fault them for their passion about making the world more like
$ whatever they each think "better" means.

Oh, come on. This entire thread has been about each of them trying to
make their personal email better for themselves, about whom they are
naturally deeply, deeply passionate.

L.

hitler had loads of passion for remaking the world in his desired
image. is this thread over now?

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

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

On Mon, 9 Dec 2002, Lloyd Wood wrote:

> On Sun, 8 Dec 2002, Dean Anderson wrote:
>
> > On Sun, 8 Dec 2002, Lloyd Wood wrote:
> > > "Sender pays" is good. The penny black stamp effectively introduced a
> > > flat-rate tax on sending letters, rather than a variable-rate tax on
> > > receiving them, effectively turning mail into a common good available
> > > to all society.
> >
> > You assume this really means "the spammer pays" [more].
>
> that quote is excerpted out of context.

I don't think its out of context. You assume your scheme will only
increase the costs for the spammer, and make it less economical to spam.
This is a false assumption on your part. Your scheme increases the cost
for everyone, and indeed it increases the cost for legitimate email more
than it increases the cost of spamming. In other words, it makes it
_even_more_economical_ to spam.

This is the kind of "shoot your self in the foot" thing as when Sanford
Wallace and Cyberpromo lost his T1, and spammers turned to dialup. The
dialups cost less than T1's, and so it was even cheaper to spam, and
harder to find out who was behind it.  The anti-spammers made it cheaper
to spam, and harder to determine who the spammers really were. At least
CyberPromo could be identified, sued, made to obey the law and court
orders.

> > But that isn't the case.  This is based on the myth that somehow the
> > receiver pays the entire cost of a spam message. This isn't true,
> > and never was true.
>
> It's true. It's an attention economy, where the recipients' lives and
> time are finite. But placing a value on time is tricky.

This argument was raised (and rejected) in the 1970's with regard to junk
postal mail.

> > The sender is already paying, whether they are spammer or mailing
> > list operator, or regular end user.  The fact is that email is so
> > cheap that it costs almost nothing per message to send and receive.
> > It gets cheaper every day, as disks and bandwidth get cheaper and
> > cheaper. The receiver doesn't pay any more than the sender pays.
>
> only if a purely fiscal definition is taken.

That is the only definition you can take, absent additional legislation.

> > Real commercial spam happens because the cost of sending spam is
> > less than the cost of sending letters or postcards.
>
> this is very true. It's also true for physical commercial bulk mail,
> which gets special rates compared to individual letters or postcards.
>
> Bill Cunningham adds:
>
> $ Lloyd, in the US we pay .37 to mail a first-class letter. I don't
> $ know how many pence you pay in the UK but we still have "spam" bulk
> $ rate unwanted solicitations.
>
> ...that are paid for at commercial bulk rates vastly cheaper than the
> individual rate, which encourages them. That's what you get for
> running the postal service as a commercial business rather than as a
> emphasising the social good aspects.
>
> $ Forcing the sender to pay doesn't solve a spam problem.  I don't see
> $ how in could. It would force everyone to have to pay a price.
>
> if everyone pays the same price, then those sending the most are most
> penalised. flat-rate.

Uhh, not exactly. They pay more in total, but it doesn't matter as long as
the advertising costs are low enough that they are still selling products
at a profit.

> > If you artificially made email expensive, it would be expensive for
> > list operators and regular people as well. You mentioned a rate of
> > one cent per message.
>
> I did not mention such a rate; you've taken the Penny Black
> one-penny-over-150-years-ago and run with it. Perhaps you would care
> to actually read my entire message, and tailor your canned rant to it?

I read your whole message, and I read it again just now.  Perhaps I wasn't
clear:  Your assertion about the benefits of flat rate vs variable rate
are irrelevant. Whatever the value (flat rate or variable rate), if its
less than the bulk postal rate, plus the cost of printing, stuffing, etc,
it will still be more economical to send spam than to use bulk postal
mail.

And, as above, it is dubious there is a variable rate involved in spam.
However, even if there was a variable rate, it wouldn't make any
difference.

> The act of subscribing to a list indicates that you know the list, and
> you're less likely to reject mail from people you don't know that
> comes or also comes via the list, since you're interested in reading
> that list -- unless the list is a simple exploder with no filtering
> mechanisms itself, in which case, subscribers pester each other
> (rather than the list) for computational proofs until the list
> implements spam filtering.

The computational proofs cost you more than they cost the spammer.  And in
the end, the spammer can do them, and it won't make any difference so long
as the cost is still low enough to be economical.

		--Dean