Subject: [Asrg] 6. Proposals - transparent authentication scheme and cost-shifting

From: "Trusted Mailer Support" <[email-masked]>
Date: Fri, 10 Oct 2003 12:08:36 -0500

I've been following discussions on this mailing list for months now and I've discussed similar issues in face-to-face meetings with the heads of major abuse departments (AOL, Yahoo, MSN, etc.).  I've testified in state senate hearings on several state anti-spam measures on behalf of the Internet Alliance.  I've also met with anti-spam solution providers, including Brightmail and others.   Recently, I took elements from these discussions and joined up with several of us anti-spammer types to draft a Master Solution to the epidemic.   I would like to contribute our work to the public good in hopes that the industry will adopt at least some of these concepts.  It is my hope that these ideas can be further developed in public forums, such as this one, and kept in a nonprofit, public good context.  

The solution holds mailers accountable by offering a transparent authentication scheme that allows ISPs to block spam while delivering legitimate permission-based email on the senders' dime.  At its core, the system essentially blocks all "bulk" email unless the bulk sender has the system's x-header authentication scheme contained within the email header.  The system has several layers of anti-spoofing steps it runs through before accepting the email message (done in a way that will not jam servers and cause deliver delays).  The system then counts the legitimate bulk email and thereafter charges the bulk emailer on a cost-per-thousand basis, with the proceeds covering enforcement with the remainder distributed to participating ISPs as cost of receipt reimbursement.

To earn the trust of participating ISPs and a license to use the x-header authentication scheme, the sender must register with the system: (1) the sender's permission status, (2) legal entity name, (3) sender domain(s), and (4) sender IP address(es).  The sender must also agree to have all email blocked by participating ISPs that do not carry the authentication scheme.  The sender must also agree to permission compliance and unsubscribe process monitoring and agree to pay the tolling system.

The system also offers transparency on a per-send level.  Elements within the x-headers will allow for system admin that question the legitimacy of the deliver to verify the opt-in permission status using a web-based look-up with the following sample output:

Entity: JavaScript Magazine
Status: Legitimate Sender
Permission Status: Double Opt-in
Registered Send Domain(s): JavaScriptMag.com
Registered IP Address(es): 64.123.243.0/24
----------------------------------------- 
Recipient: John Doe
Opt-in Website: JavaScriptMag.com
Opt-in Date: March 13, 2002
Opt-in Confirmation: March 13, 2002 (18:32:56)
Status: Active (no unsubscribe action taken)

Anyway, that's a taste.  Send me an email if you'd like to learn more about the project.

Toby

---

From: Brad Knowles <[email-masked]>
Date: Fri, 10 Oct 2003 22:01:37 +0200

At 12:08 PM -0500 2003/10/10, Trusted Mailer Support wrote:

>                                                           At its core,
>  the system essentially blocks all "bulk" email unless the bulk sender
>  has the system's x-header authentication scheme contained within the
>  email header.

	It will not be an Internet standard for mail with an "X-" header.  Period.

	If you truly want to target an Internet standard, you're going to 
have to target a real header.  You could use an "X-" header during 
transition, but you'd have to have a strong transition plan for how 
you can guarantee that would be replaced with the real operational 
header.

	If you're making a basic error like this at this stage, then one 
of the first things I'd suggest is that you re-read all of the 
relevant RFCs, starting with 2821 and 2822.

	Quote me chapter and verse from the relevant RFCs, from memory. 
I know people who can do it.  You need to be one of those people.

>                 The system has several layers of anti-spoofing steps
>  it runs through before accepting the email message (done in a way that
>  will not jam servers and cause deliver delays).

	As the former Sr. Internet Mail Administrator for AOL, consultant 
on a number of very large-scale e-mail projects, author of an invited 
talk on building large-scale mail systems (presented at LISA 2000), 
and technical reviewer of a couple of related books, I would be very 
interested to hear more about how this system can be made scalable.

>  Anyway, that's a taste.  Send me an email if you'd like to learn more

	Therein lies the problem.  If you really would "...like to 
contribute our work to the public good in hopes that the industry 
will adopt at least some of these concepts", then that discussion 
would have to take place in a group like ASRG, and in a place like 
this mailing list.

	Plenty of people have come to me with a variety of anti-spam 
projects which have required NDA.  I haven't signed one yet.

	I'm going to be a tough nut to crack.  I'm sure I'm not the only 
one.  You're going to have to convince people like me if you want to 
get very far with such a proposal.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

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

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 10 Oct 2003 23:47:11 +0200

On Fri, Oct 10, 2003 at 12:08:36PM -0500, Trusted Mailer Support wrote:
> jam servers and cause deliver delays).  The system then counts the
> legitimate bulk email and thereafter charges the bulk emailer on a
> cost-per-thousand basis, with the proceeds covering enforcement with the
> remainder distributed to participating ISPs as cost of receipt reimbursement.

1) You are talking about the Internet. I live in Europe and just as no
   US company cares about ISPs in Europe, I don't care about and trust
   mailservers in China or anywhere else in the world.
2) Ok, you sent me 35000 messages clasified as bulk in one month. So I
   do charge how much? Does what I get differ from what AOL gets,
   because their userbase is 100 times the size and they won't let you
   in unless you pay .. hmmm ... 100 USD/1000 messages?
3) You sent me 35000 messages clasified as bulk, I'd get 35 USD (dumping
   price). Now you deny it and say it have only been 5000. So where does
   the clearing take place? How much will it cost? Will it be easier
   so *sigh* and say "ok then,  5000".
4) You don't pay the money. And now?
5) You do pay the money. Does that mean you will send me 5 USD through
   some bank account from the US to Germany? Do you have an idea what
   the costs involved in such a transaction are?

> To earn the trust of participating ISPs and a license to use the x-header
> authentication scheme, the sender must register with the system: (1) the
> sender's permission status, (2) legal entity name, (3) sender domain(s),
> and (4) sender IP address(es).  The sender must also agree to have all
> email blocked by participating ISPs that do not carry the authentication
> scheme.  The sender must also agree to permission compliance and
> unsubscribe process monitoring and agree to pay the tolling system.

So, if one of our customers wants to set up a new Newsletter and all
his customers have double opted-in he has to contact all of the ISps that
his customers have contracts with and make contracts with them to get
his Newsletter delivered to his customers that demanded to receive the
Newsletter? Do you mean this serious?

> Anyway, that's a taste.  Send me an email if you'd like to learn more

You said you "like to contribute our work to the public good".
So where is the link to the whitepaper?

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"