Subject: [Asrg] Proposal for transition to authenticated email

From: "Ken Hirsch" <[email-masked]>
Date: Mon, 28 Apr 2003 14:15:30 -0400

I've read back through the archives for April, but not before, so apologies
if this duplicates something earlier.

From my reading, it seems that a distributed challenge-response system is
perceived as too burdensome and too likely to cause problems (lost messages,
delays, and loops), and a centralized challenge-response system is perceived
as legally/politically/technically unworkable.

What I propose is that the large ISPs transition to cryptographically
authenticated email and use challenge-response systems for non-participating
ISPs.  The proposal uses already existing protocols (S/MIME, SMTP,
SMTP-over-TLS) with relatively minor changes to existing software.

No new laws would be needed--impractical given the international nature of
email, anyway.  Instead, ISPs will be responsible for declaring their
anti-spam policy and enforcing it with their users.  Third parties will
handle complaints about ISPs not enforcing their policies.  Note that the
third-parties do not set the policy, they only handle disputes about whether
the ISP is enforcing its policy on its senders.  If ISPs feel that a given
third-party (dispute arbitrator) is not doing its job, it will treat all
email from ISPs using it as non-authenticated email.

Here are some (slightly disorganized and redundant) notes:

Each participating ISP must use cryptographic signatures when
sending or receiving messages from other participating ISPs and MUST
use a challenge-response system for messages not from participating
ISPs (unless the intended recipient has specifically requested
otherwise).

This is completely compatible with existing protocols.  It allows
users to send messages to and receive messages from
non-partiticipating ISPS.  The added C/R burden on users of
non-participating ISPs will put pressure on their ISPs to join the
system.

Users of non-participating ISPs can either use the
challenge-response system or sign up with a 3rd-party authenticating
service who will send/forward mail.  (I think that in some countries
it may be a while before you can find an ISP that will be
acceptable.)

For brevity, I'll just use ISP as a generic term for entities
operating MTAs, although obviously not all are ISPs in the narrow
sense.

The cryptographic signatures can be on each message (S/MIME) or can
be for an entire session (HTTP-over-TLS).  But the latter is only
acceptable if no further forwarding of messages will occur.

The certificate used to sign the message (or authenticate the
session) must be from a recognized Certificate Authority (CA), must
be "expensive enough" that spammers cannot easily get many of them,
and should be designated for email authentication purposes.

In the certificate, the responsible party (generally ISP) must
indicate which anti-spam policies are followed and procedures for
dispute resolution.  It must include a party (which can be CA or
third-party) which will indicate whether the entity is following the
declared policies and dispute resolution procedures.
(e.g. must have automated certificate-revocation checking)

Example anti-spam policies--
  - no open relays
  - more generally, no sending of mail from unauthenticated parties
  - no sending allowed to harvested emails
  - double opt-in required for mailing lists.
  - all senders identities and addresses have been authenticated.
    (e.g. road-runner, but not Hotmail)

(4) In each email message, the class of sender and/or email should
    be indicated
   Some possiblities:
    - This is a free email account without identity verification
    - This user is limited to 100 messages/day
    - This user is limited to existing correspondents + 10 messages/day
    - This user has been active for more than 180 days and has no complaints
    - This a new user
    - This user is a paying customer resident in same country as ISP
    - This email is an advertisement to existing customer
    - This email is non-advertisement to existing customer
    - This is a challenge message for email list subscription
    - This is a challenge message for antispam purposed
    - This is a message for a subscribed and confirmed email list
    etc.
    The properties that are supported are related to the general
    anti-spam policies listed in the certificate.

From both a legal and technical standpoint, it is desirable that
each receiving ISP have the final decisions over:
   (1) Which CAs are acceptable
   (2) Which classes of certificates are acceptable
   (3) Which dispute resolution arbitrators are reputable
   (4) Which anti-spam policies are acceptable
      (It may be desirable that individual users have the ability to
      choose these.)
E-mail that does not meet the ISP's policies are subject to the
challenge-response system.

Almost all the technology to do this already exists.  A workgroup
could specify what specific properties and polices need to be
defined and how to encode the necessary information in certificates
and email headers.

It might also be helpful for a workgroup to standardize message
headers for challenge-response systems to facilitate the requirements
that Brad Templeton enumerated:

>    a) Properly handle mailing list mail
>   b) Never challenge a reply to an E-mail you sent, even if you sent
>      it from elsewhere and a different account which aliases over to
>      the real mailbox.
>   c) Include protections against loops, obviously and challenging other
>      challenges, autoresponses etc.
>
>   d) Provide a means to allow the user to review all their blocked mail
>      (sorted by spam score) to catch the people who did not respond
>      to the challenge.  Yes, these happen regularly even with simple
>      challenges, and not because the other person is lazy.
>
>   e) If you don't do (d), provide some other means for anonymous mail
>      and yes, mail from people with broken mailers, to make it to you.

Okay, discuss.

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

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 28 Apr 2003 15:40:02 -0400

>acceptable if no further forwarding of messages will occur.

Define forwarding?  Mailing list?  I hit Forward in the MUA?  I'm not 
sure what you mean.

>be "expensive enough" that spammers cannot easily get many of them,

What do you think that is?  I can get a web cert for @$100 US/yr. 
(Probably cheaper.)  Is that enough of a cost to keep spammers out?

I doubt a certificate authority could manage to police the system as 
you indicate without significantly increasing that price.

>   - no sending allowed to harvested emails

It's not clear how you enforce this, or deal with an expensive dispute process.

>   - double opt-in required for mailing lists.

I think the existing commercial list providers have made it clear 
that they will not do confirmed opt-in.  And even on this list people 
have pointed out that confirmed opt-in loses legitimate subscribers. 
Perhaps if there were MUA support for it, but otherwise I don't think 
you'll get sign on.

>   - all senders identities and addresses have been authenticated.

How is this possible?  Who is going to do it?  And where does the 
money come from?  And who will stand for it?

-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Ken Hirsch" <[email-masked]>
Date: Mon, 28 Apr 2003 16:58:08 -0400

> Define forwarding?  Mailing list?  I hit Forward in the MUA?  I'm not

This is a good question.  If you use S/MIME, then the authentication
will be carried forward no matter what, but generally it is the outermost
signature that should be used for anti-spam authentication.  If you hit
Forward in the MUA, then you (the forwarder) are the sender and you are
responsible for the message.  For a mailing list it's not clear.  Some
thought would need to go in to how a mail-forwarding service should work
with this.

My thinking is that SMTP-over-TLS is less expensive, because
certificates will be checked fewer times and encryption/decryption can
be hardware-accelerated.  I think that the vast majority of emails are
directly from the originator's MTA to the recipient's MTA and you should
be able to use session authentication, but it may be difficult in
practice to know when it is applicable.

>you indicate without significantly increasing that price.

That may well be.  Note that the certificate authority is not the only
one doing policing, though.  If messages are authenticated, it is much
easier to detect abuse and filter it.  Even at $100 per cert, if abuse
is detected after 10,000 messages, that's $.01 per message, which may be
enough to dissuade the abuse.  Plus the certificate authority will have
at least some identifying and financial information to prevent the
abuser from acting again.

The certs should be expensive.  One per ISP is enough, so $1000, $5000, or
even $10,000 would not be unreasonable.  I can hear the small ISPs screaming
now, but they could contract out SMTP service.

>It's not clear how you enforce this, or deal with an expensive dispute

People already create fake addresses to detect harvesters.  If a sender
uses these then the burden would be on him to show that he was tricked.
This should promote good practices (double opt-in, logging of web-based
subscriptions, etc.) to avoid penalties.

>I think the existing commercial list providers have made it clear that
>they will not do confirmed opt-in.  And even on this list people have
>pointed out that confirmed opt-in loses legitimate subscribers.

They may well object, but I'm under no obligation to accept them,
either.  My proposal is not to make any of these policies mandatory, but
only to mandate authentication and truth-in-labeling.

---

From: Jim Youll <[email-masked]>
Date: Mon, 28 Apr 2003 17:33:30 -0400

At 16:58 -0400 4/28/03, Ken Hirsch wrote:
>If you hit

Is it not the case that in the case of a mailing list:
- from the mailing list's point of view ("should i forward this?"), the
writer is the sender
- and from a list member's point of view ("should i accept this?"), the mailing
list is the sender?

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 28 Apr 2003 16:01:19 -0600 (MDT)

> From: "Ken Hirsch" <[email-masked]>

> ...
> be hardware-accelerated. 

S/MIME and other mechanisms could also use hardware.

I advocate the use of SMTP-TLS, but it has a major defect for
authenticating mail.  It only authenticates one MTA to another, or
in some cases an MUA to an MTA or an MTA to an MUA.  It does not
authenticate the sender of the mail message itself.

>                           I think that the vast majority of emails are
> directly from the originator's MTA to the recipient's MTA ...

That is true only in very simple cases.  If that were true, then
you could filter spam by rejecting all mail with more than one
Received header.  Please consider "smart host," "mail firewall,"
"bastion host," and "MX secondary."

> ...

If any of that were true, then it would be equally true of ISPs.
Every SMTP message carries a practically unforgeable token identifying
and authenticating the previous hop ISP.  If certificate authorities
could be trusted to police customers that spend $100/year for a
certificate, then ISPs could be trusted to police customers that spend
$240/year for ISP service.

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

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 28 Apr 2003 21:20:16 -0400

>abuser from acting again.

If the authority is not revoking certs, then you have a situation 
identical to what we have now.  Blacklist operators with lists of 
invalid IPs become blacklist operators with lists of invalid certs. 
Not much gain.

>now, but they could contract out SMTP service.

Never mind small ISPs.  What about *companies*?  There are several 
orders of magnitude more of them running mail servers than ISPs. 
What are they supposed to do?

>subscriptions, etc.) to avoid penalties.

Sure.  But given that you've punted on enforcement, how is this world 
any different than the current one.

>only to mandate authentication and truth-in-labeling.

No, *you* don't have to accept them.  But a solution which leaves out 
every major bulk mail company, all the major etailers, not to mention 
your local bank, is not likely to fly very far.

---

From: Jim Youll <[email-masked]>
Date: Mon, 28 Apr 2003 21:59:35 -0400

>What are they supposed to do?

And all the little nonprofits!  And what u gonna do when everybody's 
got a tiny mail server in their basement next to the humidifier and 
the telco demarc?
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 00:46:21 -0400

From: "Vernon Schryver" <[email-masked]>
> authenticate the sender of the mail message itself.

And that is all that is necessary.  I don't think that authenticating the actual
sender is practical.  In order for sender authentication to be common it has to be
inexpensive and convenient.  In order to prevent spam,  certificates need to be
expensive and/or inconvenient.  That is why I only propose that some party (usually
the ISP) be authenticated and responsible for enforcing antispam policy.

[...]
> $240/year for ISP service.

Well, if you really consider message headers unforgeable, you can skip the
cryptographic authentication! There are still a few differences from the current
system.  Instead of an MTA blacklist, you have an MTA whitelist.  Each ISP must
declare its policies and provide a means to check that it is abiding by them.
That's a pretty big difference, I think.

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 00:45:49 -0400

From: "Kee Hinckley" <[email-masked]>
[...]
> What are they supposed to do?

If they can't afford the certificate, forward through their ISP.  That's what most
small businesses do now.  It's no great hardship.

> any different than the current one.

Oh, please, if you are going to discuss the proposal, do it seriously.  I never said
the CAs wouldn't enforce, I just said that they would have lots of help.  If the CAs
don't enforce, their certificates become worthless.  Nobody will buy them.

> your local bank, is not likely to fly very far.

I must not have made myself clear.  It is the _recipients_ that decide what policies
are acceptable.  If senders choose policies that aren't acceptable, their messages
won't get through.

---

From: Jim Youll <[email-masked]>
Date: Tue, 29 Apr 2003 00:50:11 -0400

>small businesses do now.  It's no great hardship.

So now you've moved enforcement activities off the certificate and 
onto the ISP.
How is that any different from the present regime?
The number of small mail servers will tend to increase, not decrease...
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Mon, 28 Apr 2003 21:57:49 -0700

On Tue, 29 Apr 2003 00:45:49 -0400 
Ken Hirsch <[email-masked]> wrote:

> Oh, please, if you are going to discuss the proposal, do it seriously.
> I never said the CAs wouldn't enforce, I just said that they would
> have lots of help.  If the CAs don't enforce, their certificates
> become worthless.  Nobody will buy them.

A brief check of my browser cache shows that I have just over 700
self-signed keys lodged in my browser.  While my browsing habits are
likely atypical, I'd wager that that outnumbers the number of central CA
signed keys I've hit in the last year by a factor of at least 5.

CA keys just aren't worth that much, and frankly, never have been.

-- 
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: wayne <[email-masked]>
Date: 29 Apr 2003 00:35:41 -0500

In <01be01c30e0a$4cdc1760$0201a8c0@DXHIRX1> "Ken Hirsch" <[email-masked]> writes:

> > and authenticating the previous hop ISP. 
> 
> cryptographic authentication!

As quoted above, only the IP address of the previous hop is
practically unforgeable.  Most other headers can be trivially forged.

-wayne

---

From: J C Lawrence <[email-masked]>
Date: Mon, 28 Apr 2003 22:56:54 -0700

On 29 Apr 2003 00:35:41 -0500 

>>> Every SMTP message carries a practically unforgeable token
>>> identifying and authenticating the previous hop ISP.

>> Well, if you really consider message headers unforgeable, you can
>> skip the cryptographic authentication!

> practically unforgeable.  Most other headers can be trivially forged.

:mutters something about a forward chained Received: header proposal
that (potentially) makes the (entire) Received: chain reliably
auditable.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 29 Apr 2003 07:02:02 -0600 (MDT)

> From: "Ken Hirsch" <[email-masked]>

> expensive and/or inconvenient.

I agree SMTP-TLS is the first form of mail encryption that has any
hope of becoming somewhat common.  But being somewhat common is
not the only requirement for stopping spam.

>                       That is why I only propose that some party (usually

If ISPs could be relied upon to enforce antispam policies, then there
would be no spam problem.  Absolutely every bit of spam comes to your
SMTP server from a network controlled by an ISP that could enforce an
antispam policy that could have prevented it.  This applies to spam
through open proxies and relays as well as direct-from-MTA spam,
because the ISP of the party with the open relay or proxy could enforce
terms of service that treat running an open proxy or relay like the
security violation it is.

> Well, if you really consider message headers unforgeable, ...

I've written so variations of that screed for so many years that I
didn't see that left out an important bit.  The practically unforgeable
token is the IP address of the SMTP client.  If you were right that
a vendor that has sold $100/year certs could be trusted to revoke
them, then you would be right that vendors that sell the $240-$360/year
certs that are IP addresses could be trusted to revoke those, and
there would be no spam problem.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 29 Apr 2003 07:09:44 -0600 (MDT)

>                           ...  If the CAs don't enforce, their
> certificates become worthless.  Nobody will buy them.

> ...
> I must not have made myself clear.  It is the _recipients_ that
> decide what policies are acceptable.  If senders choose policies
> that aren't acceptable, their messages won't get through.

That is the situation we have now, using the certs that are IP addresses.

  - all mail carries the practically unforgeable cert of the IP address
     of the preceding SMTP client.

  - people use public and private blacklists of IP addresses to enforce
     their own anti-spam or other access policies.

  - some CAs (ISPs) sell certificates (IP addresses) that are less
     valuable, because the CAs (ISPs) are known to not revoke them
     (terminate service) for naughtiness.

  - those bad CAs still manage to sell their less valuable certs (IP
      addresses) to people who pay less and then whine and complain
      about the unfairness of blacklist lists that list their certs
      as issued by CAs that don't care about stopping spam.

---

From: Jim Youll <[email-masked]>
Date: Tue, 29 Apr 2003 10:43:17 -0400

Vernon, in many cases the CA's are not selling the certificates (IP addresses)
but only renting them for short periods of time. We get a great deal of spam
from one-off dialups or otherwise variable IP addresses... such as the guy who
has been dictionary-spamming one of our domains for a week now. He still hasn't
gotten through the A's@ourdomain. I've now locked out
a whole class C block and if he pops up elsewhere, I'll have to block 
yet another...

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 29 Apr 2003 09:04:40 -0600 (MDT)

> From: Jim Youll <[email-masked]>

> a whole class C block and if he pops up elsewhere, I'll have to block 

Yes, and if ISPs were willing to spend the time and money to break
the financial kneecaps of spammers, that sort of spam would not be a
problem.  Practical proof of that theory is that there are ISPs that
rent dynamic IP addresses but that do not have a spam problem.  I use
one when I travel.

If the ISPs infested with dial-up spammers also sold cryptographic
certificates, those certificates would be just as valuable as the
corresponding IP addresses.  The slum lord ISPs on the spam-friendly
side of the Internet would still choose to not know their customers.
They would rent cryptographic certificates just as they now rent IP
addresses, except that they would always discard the cryptographic
certs after use instead of only sometimes switching IP addresses.

The cryptogrphic certs of those ISPs would be blacklisted along with
their IP address certs.  We would then have their customers shouting
about the unfairness of blacklists of PacBell's ADSL open proxy infested
ADSL lines and demanding that ISPs be regulated like common carriers
and not allowed to reject their important messages.

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 11:34:47 -0400

>       as issued by CAs that don't care about stopping spam.

I think there are important differences:

Can you tell who is responsible for the mail server?
  Now: Sometimes
  Proposal: Yes, instantly

Can you tell who issued/can revoke the IP address or certificate?
  Now: With difficulty
  Proposal: instantly

Number of authorizers of IP addresses: thousands, who knows?
Number of CAs: A few dozen to maybe a few hundred

Can you tell the spam policy of responsible party?
  Now: no (never in machine-usable form; hard to find for humans)
  Proposal: yes, it's right there in certificate, in standard form

Can you tell who to contact about spam?
  Now: no
  Proposal: yes

Can you show that spam was sent from server?
  Now: no
  Proposal: yes, cryptographically signed

Can you tell anything about the email content/sending user?
  Now: no
  Proposal: Maybe (policy-dependent)
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 29 Apr 2003 10:30:43 -0600 (MDT)

> Can you tell who issued/can revoke the IP address or certificate?

That is backwards.  Anyone can now instantly tell who is responsible
for an SMTP client.  The SMTP client's IP address can be associated with
a responsible party by checking routing tables and IP address whois
data.  That might not give you the address of the spammer, but it does
give you the name and address of the party who should stopping the spam.

On the other hand, an x.509 cert tells you less than the typical domain
name whois data even with the best of intentions by all parties.  The
name and address in domain name whois data is often maliciously bogus
for spammers.  Why wouldn't the same apply to certs?

Note that domain name and IP address whois data differs significantly.

> Number of CAs: A few dozen to maybe a few hundred

That is wrong.  Either your CAs correspond to the handful of organizations
like ARIN or they correspond to the bazillions of ISPs.

Note CAs and certificate issuers are quite different (assuming as you
must that there are no self-signed certs).  In your model CAs are very
much like ARIN.

>   Proposal: yes, it's right there in certificate, in standard form

So your certs include some sort of spam policy?  I missed that.  Why
would it work better than the abject failure that is the "web page
privacy policy" protocol?  Why would it be an honest statement?  What
outfit would have certs that say "we send spam"?  Why wouldn't it be
the same as the current anti-spam policies of ISPs?  Today you can
instantly find the ISP that issued an IP address "cert" and review
its spam policy.

> Can you tell who to contact about spam?

There is no spam today for which anyone who understands how things
work doesn't know whom to contact.  Anyone who can't figure out who
to contact about spam today, still won't be able to with your certs.

>   Proposal: yes, cryptographically signed

That is simply wrong.  All spam carries the unforgeable signature
of a sending IP address.

>   Proposal: Maybe (policy-dependent)

Yeah, right, just like the TrustE certificates or Topica's "gold members."

---

From: wayne <[email-masked]>
Date: 29 Apr 2003 11:52:53 -0500

> that (potentially) makes the (entire) Received: chain reliably

Well, if it makes you feel any better, your forward chaining proposal
was the first thing I thought of that caused me to change "All other
headers" to "Most other headers".

-wayne

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 29 Apr 2003 13:17:08 -0400

>small businesses do now.  It's no great hardship.

Do you have any numbers to back up that?  My personal experience is 
that I know hundreds of small business that are providing their own 
email through DSL and other providers. In most cases the ISP doesn't 
provide more than 1 to 4 email addresses, and none using the 
customer's domain. What makes you think that is rare?

>decide what policies

A proposal which is unacceptable to all the major email senders is by 
definition unacceptable for the receivers.  If the receiver's adopt 
it enmass--they get none of the email they want.  You *must* have 
buyin from the senders before you flip the "block non-compliant 
email" switch.  Otherwise your false positive rate is unacceptable to 
the majority of customers.

We can talk all we want about the recipient being in control--but the 
fact of the matter is that they only power they have right now is to 
walk away from the table and stop receiving any email.  New standards 
will involve negotiation between the major parties, not mandates from 
an RFC.  (And unfortunately, the recipient is only indirectly 
represented at the table, through the major ISPs.)
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 15:50:12 -0400

> customer's domain. What makes you think that is rare?

Well, I don't have numbers, but who cares?  There is no hardship involved in
sending outgoing mail through the ISPs SMTP server.  You don't have to use
the same domain name.

[...]

> represented at the table, through the major ISPs.)

The purpose of the standard is not to define what is spam or what is an
acceptable antispam policy, only to ensure that the policies can be defined,
communicated, and enforced.

There could be separate negotiations or just consensus-building about what a
minimally-acceptable policy should be.  When S/MIME messages are signed with
an antispam certificate, it would be easy for the MUA to do additional
filtering beyond what the ISP does, so the end user is not totally dependent
on the ISP.

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 15:44:53 -0400

> for spammers.  Why wouldn't the same apply to certs?

Mainly because the certs will cost a lot more than an IP address.  The
contents of these certificates need to be standardized.

> must that there are no self-signed certs).  In your model CAs are very

Wrong.  In my proposal, the CAs are  _required_ to have a procedure to
handle spam complaints and have automatic revocation checking of
certificates.  ARIN, APNIC, etc. only allocate addresses and refuse to get
involved in spam prevention.

> privacy policy" protocol?

Because these policies would be used by programs at all the major ISPs.  The
P3P doesn't really have any automated use.

>  Why would it be an honest statement?  What
> outfit would have certs that say "we send spam"?

Probably quite a few would say "we send spam".  More to the point, there is
no universally accepted definition of spam, but this proposal allows senders
to declare exactly what email they allow as well as, optionally, the
properties of the individual messages and senders.

Of course it is not going to be 100% accurate and honest.  That is why there
are mandatory procedures for resolving complaints.

> Why wouldn't it be

1) It is _not_ easy even for a human to find the policy.
2) It is impossible to programs to use this information.
3) There is no standard way to tell if they are in compliance.

> That is simply wrong.  All spam carries the unforgeable signature

Unforgeable?   Well I guess you sent this spam, then!

    Received: (from vjs@localhost)
     by calcite.rhyolite.com (8.12.9/8.12.9) id h3TGUhsH011243
     for [email-masked] env-from <vjs>;
     Tue, 29 Apr 2003 10:30:43 -0600 (MDT)
    From: Vernon Schryver <[email-masked]>
    Message-Id: <[email-masked]>
    Subject: + Database of 200 mil U.S. Citizens!  vtb m
    [rest deleted so I don't trigger content filters]

Gee, I swear I got this!  S/MIME solves this problem, although SMTP-over-TLS
doesn't (unless you keep an impractically large log.)

---

From: Jim Youll <[email-masked]>
Date: Tue, 29 Apr 2003 17:12:08 -0400

>contents of these certificates need to be standardized.

This is a very well-funded Western view of things.

Cost may be expressed as either money, or effort. I propose that any cost
that is introduced (and this applies to sender-pays "deterrents" as well)
must not be directly mapped to money.

There are many means of throttling the issuance and replacement rate of
certificates (e.g. an über-difficult applicant-side calculation that takes
a week to generate, or just a clock) that do not involve money.

>involved in spam prevention.

Yet "what is spam" remains a subjective matter. How will such things not
get into the same morass as, e.g. the domain name dispute resolution process?
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 29 Apr 2003 17:53:22 -0400

>Mainly because the certs will cost a lot more than an IP address.  The

I'm still waiting for an explanation of how high-cost certs will work 
in the real world.

>  > That is simply wrong.  All spam carries the unforgeable signature

Anyone can type in forged headers.  Sending a message where it's not 
possible to detect the forgery is theoretically possible, but I've 
never seen a documented case.  (Which is not to say that I think that 
signing isn't a good idea, or that I agree with Vernon's claim that 
figuring out those headers is something that can easily be done by 
the people who need to do it--but it can be done.)
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 29 Apr 2003 17:54:57 -0400

At 3:50 PM -0400 4/29/03, Ken Hirsch wrote:
>  > >That's what most

As a small business owner--I care.  And you're living in a fantasy 
world if you think it's not a hardship.  It's not even *possible* for 
most small business.  The ISP does not provide the service, and does 
not want to.

>communicated, and enforced.

Ah.  Then please remove the double-opt-in requirement from the standard.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 29 Apr 2003 16:18:33 -0600 (MDT)

> contents of these certificates need to be standardized.

How much more?  A Verisign cert currently costs about the same as the $120
to $360 per year price of an IP address from Earthlink, Juno, etc.

Why would I pay at least $120 to $360 per year to get your spam-CA to
swear rhyolite.com doesn't send spam?  I've never had a mail blocking
problem.

> involved in spam prevention.

Who will enforce that requirement on your CAs?  ISPs and registrars
are ignoring their promises to cut off spammers.

> P3P doesn't really have any automated use.

Again, why will your program differ from P3P?  The P3P people said there
was supposed to be automated use of it.  Netscape 7 can be told to
pay attention to it.

> properties of the individual messages and senders.

How are you going to encode a declaration of exactly what is sent into
at most a dozen bytes?  Remember that your certs have to be tacked onto
every mail message.

> 3) There is no standard way to tell if they are in compliance.

The same applies to you proposal.

>     Subject: + Database of 200 mil U.S. Citizens!  vtb m

I don't know what you think that might represent.  I do know it does
not contain an IP address.  RFC 2822 headers even when they mention
an IP address are not IP addresses.  

Please offer a detailed explanation of how you can forge the IP address
of an SMTP client connecting to an SMTP server so that the SMTP server
gets the wrong idea.  Note that by my definition, the IP address of
the SMTP client is on the outside of a NAT box or other proxy.  The
client's IP address is in the source field of the IP header of its
initial and every subsequent SMTP/TCP/IP packet.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 29 Apr 2003 17:11:11 -0600 (MDT)

> To: "Ken Hirsch" <[email-masked]>
> From: Kee Hinckley <[email-masked]>

> the people who need to do it--but it can be done.)

Why do you guys keep talking about headers?  Of course headers can be
forged (unless they're added by your own software).  Who cares?  I'm
not talking about headers.  I'm piqued that you think I'm so stupid
or at least ignornant and unthinking that I might be talking about
obviously forgeable headers.  I'm quite frustrated that every time I
write "IP address" it is read as something about SMTP headers.

Again, the practically unforgeable token that has always come with
every SMTP mail message is not in the headers or even in the SMTP
envelope.  It is in the IP destination field of every SMTP/TCP/IP
packet from the sending system or SMTP client.  That 32 or 128-bit
value almost always fingers a person or organization that bears a
large part of the responsibility for sending the message.  (The
exception is "hijacked" IP addresses of recent note.  That exception
is akin to Verisign signing those certificates for the fake Microsoft.)

Yes, I know about TCP ISN predicting, the Mitnick/Bellovin attack,
RFC 1948, and related topics.  I profess to be a kernel hack with
interests in networking.  As such, I claim that the IP address of the
SMTP client is practically unforgeable for spam.

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 20:03:33 -0400

> the people who need to do it--but it can be done.)

If people are going to be fined, be kicked off nets, certificates revoked, etc.,
then the evidence that they violated a contract should hold up offline.  Signed
messages have this property.

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 20:30:27 -0400

From: "Jim Youll" <[email-masked]>
> a week to generate, or just a clock) that do not involve money.

Yes, I said that certificates should be expensive and/or inconvenient to obtain.
Certificates should say (and do, to some extent), what it is they are certifying and
what procedures were used for verification.  A recipient should be able to choose
what class of certificates are acceptable, and which CAs are acceptable.  A
certificate that provides strong identity (e.g. government-issued) is not by itself
sufficient as an antispam certificate.  A CA would have to (1) check it against a
database of known spammers (2) get the person to sign a contract  to abide by a set
of antispam policies and (3) have a set of procedures to handle complaints against
the person (including reporting the person to the database if they do not
cooperate).

But, yes, in the Western business world, money is the easiest shortcut to prevent
the proliferation of too many certificates.

[...]
> get into the same morass as, e.g. the domain name dispute resolution process?

The antispam policies should be, as much as possible, objective and verifiable.
Some that I suggested are:
  - no open relays
  - more generally, no sending of mail from unauthenticated parties
  - no sending allowed to harvested emails
  - double opt-in required for mailing lists.
  - Opt-out requests must be honored
  - all senders identities and addresses have been authenticated.
    (e.g. road-runner, but not Hotmail)

In each email message, the class of sender and/or email should
    be indicated
   Some possiblities:

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 29 Apr 2003 19:48:27 -0400

> most small business.  The ISP does not provide the service, and does

Well if there really are ISPs that don't provide SMTP service, you can contract with
someone else to do it.  There may be a slight expense, but it would be pretty
trivial.  There are plenty of people who do it now.  Fighting spam will require some
kind of control over sending mail.  There's no way around that.

> Ah.  Then please remove the double-opt-in requirement from the standard.

There is _no_ double-opt-in requirement.  What I proposed is
"In the certificate, the responsible party (generally ISP) must
indicate which anti-spam policies are followed and procedures for
dispute resolution.  It must include a party (which can be CA or
third-party) which will indicate whether the entity is following the
declared policies and dispute resolution procedures.
(e.g. must have automated certificate-revocation checking)."

The exact policies that are used are up to the sender.  The minimum policies that
are acceptable to the recipient are up to the recipient.  The standard would specify
a syntax for describing the policies, but not what policies are used.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 29 Apr 2003 22:48:10 -0400

>someone else to do it.  There may be a slight expense, but it would be pretty

I'm sorry.  You need to go off and look at real world email use 
before you blithely make statements like that.  Pandora's box is 
open.  People run their own mail servers.  You aren't going to put it 
back.  Put some rational restrictions on them, yes.  But you aren't 
going to take it away or suddenly charge them thousands of dollars.

>  - double opt-in required for mailing lists.

I guess I missed the context.

---

From: "Ken Hirsch" <[email-masked]>
Date: Wed, 30 Apr 2003 00:34:07 -0400

> going to take it away or suddenly charge them thousands of dollars.

It's a one-line change to a Sendmail configuration to forward all mail through
another SMTP server.  It's no big deal.  It's not a hardship.  We don't need
hundreds of thousands of SMTP servers doing point to point connections.

---

From: J C Lawrence <[email-masked]>
Date: Tue, 29 Apr 2003 22:56:43 -0700

On Wed, 30 Apr 2003 00:34:07 -0400 
Ken Hirsch <[email-masked]> wrote:

> It's a one-line change to a Sendmail configuration to forward all mail
> through another SMTP server.  It's no big deal.  It's not a hardship.
> We don't need hundreds of thousands of SMTP servers doing point to
> point connections.

This is essentially a RTKBA or you-don't-really-need-an-SUV issue.  It
may be true in some global sense, but at the level of humans, egos, and
the simple wish for people to control (and waste) their own destiny and
not pass all their traffic thru an easily targeted
supervision/big-brother point its just not going to happen.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 30 Apr 2003 02:48:43 -0400

>hundreds of thousands of SMTP servers doing point to point connections.

I'm not talking about the technical difficulty.  I'm talking about 
the complete infeasibility of this solution from a business 
standpoint.  It's an absolute non-starter.  Have you ever done any 
work in the commercial email business?

Off the top of the head.

- I don't want my ISP to be able to see who I am sending email to.
- I want connections between my mail server and certain peers to be 
encrypted and/or verified.
- I want my spam filters, not my ISPs.
- I want my virus filters, not my ISPs.
- I don't want to be limited by my ISPs rate limiting.
- I want my outbound mail to be authenticated (if we ever get to the 
point where that is possible) using my domain and my standards--not 
my ISPs.
- Current end-user SMTP solutions (e.g. smtp.com) are rate limited.
- Current multi-user SMTP solutions are significantly more expensive 
than running your own server.

There is no point in making a proposal which starts off with the 
assumption that you are going to add major costs to millions of small 
businesses and organizations, remove functionality and control from 
millions of small businesses and organizations, and assume the 
creation of an entire new industry to support them.  Never mind that 
the existing MTA vendors would not exactly be pleased to see their 
customer base suddenly shrink by several orders of magnitude.  I'm 
sure the ASP folks would love the idea--but it's not going to happen.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: "Ken Hirsch" <[email-masked]>
Date: Wed, 30 Apr 2003 07:28:13 -0400

> work in the commercial email business?

I'm sorry, I have no sympathy.  You're just whining, "I'm not part of the problem,
why should I bear any inconvenience or expense?"  Because the current system
(anarchy) is broken.

> - I don't want my ISP to be able to see who I am sending email to.

They can now. Trivially.

Somehow millions of people manage to deal with the fact that their phone companies
know whmo they are calling.  The local phone companies don't have any problem with
the fact that the long distance companies know their customers long distance
destinations.

> encrypted and/or verified.

I am not proposing blocking port 25.  The proposal  just says that if you want to
send to a participating SMTP server, then you must be a participating SMTP server,
otherwise each sender will be subject to challenge/response.

Point to point sends would still be available for non-participating servers, just as
there are still people who use CB radios, Usenet and other anarchic media.

> - I want my virus filters, not my ISPs.

I didn't say anything about incoming mail, did I?

> point where that is possible) using my domain and my standards--not

Get over it.  There will be some cost and/or inconvenience if you want your email to
be treated as first-class mail.

> than running your own server.

No ISP I've had has ever rate-limited or charged for out-going mail.

> sure the ASP folks would love the idea--but it's not going to happen.

Wow!  You mean businesses don't like regulation, what a revelation!  Nevertheless,
it often happens.

---

From: "Ken Hirsch" <[email-masked]>
Date: Wed, 30 Apr 2003 08:46:17 -0400

> swear rhyolite.com doesn't send spam?  I've never had a mail blocking

"I'm not part of the problem.  Why should there be the slightest
inconvenience to me?"

Because the current system is broken.

[...]
> are ignoring their promises to cut off spammers.

I think that the large ISPs will enforce this.  Spam is getting to be such
an issue that the will is there.  I also think that my solution has the
right granularity of enforcement.  If you decide a CA is not doing its job,
then you treat all mail from associated ISPs as unauthenticated and fall
back to a challenge/response system.  It is a lot less drastic than totally
throwing them off the net or simply blocking all their mail.  The CAs
customers will start screaming.

(I do think there will need to be a blacklist for those who abuse the
challenge/response system.)

> was supposed to be automated use of it.  Netscape 7 can be told to

I haven't seen anything useful that a program can do with P3P.  It is also a
solution to a problem that few people care about.  _Everybody_ hates spam,
but P3P deals with arcane issues that most people just don't care about.

> at most a dozen bytes?  Remember that your certs have to be tacked onto

This is a good question.  My guess is that something quite useful can be
done, but this is an issue that needs to be explored in a working group.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 30 Apr 2003 09:55:12 -0400

>why should I bear any inconvenience or expense?"  Because the current system

You are completely missing the point.  This has nothing to do with 
me.  This is a business reality.  It's like you woke up one day and 
said, "I've got the solution to pollution!  Everyone will junk their 
cars and use buses!"  Sure, it's a solution.  But it's not going to 
happen.  You can't force that kind of solution on people, they won't 
accept it.  A small cost (akin to current certs), sure.  But the kind 
of cost, inconvenience, loss of of control and loss of privacy you 
are discussing?  It doesn't meet the ASRG requirements for a system 
which can be adopted.

>  > - I don't want my ISP to be able to see who I am sending email to.

Not when I'm using SSL.

>No ISP I've had has ever rate-limited or charged for out-going mail.

Did I say ISP?  I told you that business ISPs often provide a pipe 
and no email service.  You told me to use an SMTP service.  SMTP 
services *do* rate limit and they *do* charge for out-going email. 
That's their business.

You don't see this issue because you aren't a business customer.

---

From: Ken Simpson <[email-masked]>
Date: Wed, 30 Apr 2003 07:35:21 -0700 (PDT)

What about the processing load required to deal with verifying
cryptographic signatures? Will that cause an unacceptable load on very
large mail installations?

TTUL
Ken

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 30 Apr 2003 10:54:32 -0400

...
> > was supposed to be automated use of it.  Netscape 7 can be told to

True.

> I haven't seen anything useful that a program can do with P3P.

I have.
 
>                                                           .... It is also a
> solution to a problem that few people care about.

It is a problem domain that has several distinct approaches, which is to say
that there are several distinct manifestations of "care".

>                                               ... _Everybody_ hates spam,

See above.

> done, but this is an issue that needs to be explored in a working group.

See draft-jaye-http-trust-state-mgt-01.txt, available via anonymous ftp, from
this host, for how Dan and I attempted to put compact metadata, and certs, on
http cookies.

---

From: "Ken Hirsch" <[email-masked]>
Date: Wed, 30 Apr 2003 11:42:54 -0400

From: "Ken Simpson" <[email-masked]>
> large mail installations?

Excellent question.  I don't know and I do worry about it.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Ken Hirsch" <[email-masked]>
Date: Wed, 30 Apr 2003 12:13:00 -0400

> are discussing?  It doesn't meet the ASRG requirements for a system

Sorry, but I'm not proposing everybody give up cars.  In fact, my solution
is a lot less intrusive than catalytic converters, which did get adopted.
People manage to deal with _a lot_ of regulations for their cars because
they have to share the road: driver's licences, insurance requirements,
license plates, safety inspections, emissions checking, and so on.  What I
am proposing is about equivalent to requiring a license plate on a car.
It's trivial.

This is not a big inconvenience, the cost is small, the loss of control is
negligible.  If people were really concerned about privacy, they would
encrypt their email.  They don't.  If you have the volume and really need
that tiny extra bit of control, pay for the certificate.  If you are
legitimate, it will last a long time and the cost per email will be trivial.
Only people whose certificates are revoked will end up with a high
per-message cost.

Vernon Schryver has brought up legitimate questions--Will the policies
_really_ be enforced?  Can you encode useful policies in a certificate?  I
think the system will work, but these are open questions.  But I just don't
believe people care about the ability to do point-to-point SMTP.

Every phone call anybody makes works this way.  It gets routed through just
a few companies and they know whom you are calling.  It is just not an
issue.

> >  > - I don't want my ISP to be able to see who I am sending email to.

And I'm not proposing stopping you.  Carry on with those few SMTP servers
that support it.  Very little email moves that way.  If this were such a
major concern that it was a show-stopper, everybody would encrypt their
email or use TLS.  But they don't.  99%+ of email is not encrypted.

(And of course, you can still encrypt email sent the way I propose.)
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Ken Simpson <[email-masked]>
Date: Wed, 30 Apr 2003 09:29:44 -0700 (PDT)

Instead of certificates, why not just use the Bonded Sender approach and
use PTR queries to a whitelist DNS server or group of servers? A quick DNS
query is less intensive than cryptography and requires less programming.
Besides, running a CA is a huge undertaking.

TTUL
Ken

--
http://ttul.org/~ksimpson

---

From: J C Lawrence <[email-masked]>
Date: Wed, 30 Apr 2003 10:03:04 -0700

On Wed, 30 Apr 2003 11:42:54 -0400 

>> cryptographic signatures? Will that cause an unacceptable load on
>> very large mail installations?

> Excellent question.  I don't know and I do worry about it.

The safe assumption is that the majority of sites won't bother, assuming
blithely, that someone else will have.

---

From: Claus Assmann <[email-masked]>
Date: Wed, 30 Apr 2003 10:46:13 -0700

> sending outgoing mail through the ISPs SMTP server.  You don't have to use

Of course there is. You give up control over what happens to your
mail.  I can enforce TLS between hosts as long as I send mail
directly.  I know whether mail is stuck in the queue or whether it
got delivered.  Using an ISPs mailservers requires that their systems
are actually working well and I have enough evidence to doubt that.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Ken Hirsch" <[email-masked]>
Date: Wed, 30 Apr 2003 14:00:35 -0400

> Besides, running a CA is a huge undertaking.

This is a possibility.  A DNS query may be less computationally intensive,
but I think it takes more time.  A DNS query would avoid the byte overhead
of a message signature.

The advantage of cryptographic signatures is they prove that the message was
sent by the holder of the private key.  This helps prevent malicious
complaints against a bonded sender.

There are already CAs.  I think that they would work with an organization
such as TRUSTe rather than try to handle complaints themselves.  They could
work with more than one organization.  The exact details about certificate
signing and revocation would need to be worked out.

Other differences of my proposal from the Bonded Sender approach--
  More than one policy  could be chosen.  Getting consensus on just one is
hard.
  Participating servers should require a challenge-response on all mail from
non-participating servers.
  Labeling properties of individual messages and senders is encouraged.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 30 Apr 2003 14:24:50 -0400

>Sorry, but I'm not proposing everybody give up cars.  In fact, my solution

I give up.  You seem unwilling to look beyond the technical and see 
how the real world functions.  A common techie fault.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 30 Apr 2003 14:21:23 -0400

>Excellent question.  I don't know and I do worry about it.

Cache a mapping between IP's and signatures, and fast track those IPs you know?
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 30 Apr 2003 13:44:01 -0600 (MDT)

>Cache a mapping between IP's and signatures, and fast track those IPs you know?

Signature of what?  If you trust IP addresses, then you don't need
any crypto mumbojumbo because IP addresses are practically unforgeable.

If you need a signature of a mail message, then IP addresses are irrelevant.

"Caching signatures" sounds bad, because it suggests a replay attack.

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 30 Apr 2003 17:50:33 -0400 (EDT)

> are actually working well and I have enough evidence to doubt that.

Wouldn't TLS traffic go via port 465 in most cases? I don't think any
of the proposals here are intended to regulate anything except port 25.

In any case, for TLS wouldn't you need explicit cooperation from the the
remote MTA, in which case the pair of you could agree to use a port other
than 25. Or is there a way to use TLS when communicating with strangers?

---

From: Jim Youll <[email-masked]>
Date: Wed, 30 Apr 2003 21:40:14 -0400

>hundreds of thousands of SMTP servers doing point to point connections.

You're missing lots of issues, like all the sites that aren't at the end of
a whomping fast Internet connection... the big messages dribble in over the
slow link and local access is decoupled from link speed. When I put up my
first home Linux server many years ago, it was on a demand-dialed line and
it batched out the locally-gathered mail every 30 minutes..  the ISP was
an MX secondary for inbound mail.

Further, why should an independent organization's e-mail policies be subject
to the wholly unrelated policies of an intermediate party? Should we also
proxy all web serving and retrieval through the ISP too? Shall we ask the ISP
to maintain our e-mail accounts? Do we then have to trust the ISP to store
all these messages? What about privacy?

Since there will be hundreds of thousands of SMTP servers no matter how
loudly anyone here complains, there is little point in trying to shout
against the wind in this way.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 30 Apr 2003 23:17:30 -0400

>any crypto mumbojumbo because IP addresses are practically unforgeable.

The IP does not (at the point of receiving a message) give you as 
much information as crypto, let alone trust.  However you could 
conceive of caching it the IP for a while (just as you cache DNS 
entries for a while) to avoid decrypting each time.  Probably only 
reliable for the immediate sender to your MTA.

I don't know if it makes sense.  That's why there was a question mark 
at the end.