Subject: RE: [Asrg] Proposal for Opt-Out

From: "Eric D. Williams" <[email-masked]>
Date: Fri, 28 Mar 2003 11:32:31 -0500

Hello all; (new to the RG and list...

This message I think presents a fundamental problem that I have not seen 
addressed (or at least referred to to-date) in the discussion, perhaps a 
reading of the archives is in order or a document archive contains such.  What 
I am referring to is a Statement of Requirements that enumerates an acceptable 
solution.  Below is such a beginning, and without such a document I don't think 
much headway can be made.

In addition, methods for addressing this "engineering" issue could quickly 
devolve to a 'religious war' of principle OR, an unwanted debate that has no 
objective technical basis.  As this is the case, and with due reference to the 
discussion below, I feel a discussion thread or drafting activity - which would 
be happy to participate in 
http://new.infobro.com/AboutUS/People/EricWilliams/ericwilliams.html - on a 
specific, logical and concise requirement document is suggested.

Taking a language from the note below:

> 1. We stop forgeries of mail headers and force all senders to reveal
> their name (but that I mean source, not actual name for personal emails,
> etc).

Requirement 1)  The proposal MUST address the issue of RFC821 [or envelope 
protocol] originating MTA/MUA authenticity.

> 2. We provide means for mail servers to authenticate in such a way that
> spammer can not easily change just their domain or their ip and begin
> sending email again (they'd soon be detected and their mail server
> blacklisted).

See Requirement 1).

> 3. Law outlaws sending unsolicited commercial email

Requirement 2) The proposal SHOULD be amenable to legislation, in place or 
pending as close as possible.

> 4. ISPs use filtering to get rid of unwanted spam that may still path
> through the cracks (i.e. spammer got new mail server and it has not been
> blacklisted yet or they hijacked the server, etc. etc.)

Requirement 3) The proposal MUST provide a flexibility for integration with 
other ANTI-SPAM (UBE/UCE) approaches [it shouldn't break anything].

Requirement 4) The proposal SHOULD provide implementation specifics that 
address the issues of privacy, security and which reflect end use choices, of 
either providers or users.

Requirement 5) The proposal SHOULD/MAY [not sure how strong this would be as a 
requirement] include a mechanism for implementation in messaging relay systems 
(MX hosts), end use 'post offices' (MTAs), and end node mail recipient systems 
(MUAs).  Proposals that include only one of these messaging system components 
MUST include mechanisms for interaction with the other components.

Requirement 6) The proposal MAY include a method for extension to or 
integration with other protocols, e.g. HTTP, that may be used to relay 
messages.

I feel there are many more 'technical' requirements which can be discussed in 
turn, but first some requirements may be in order.  In any event, these at 
least provide a strawman from which further discussion may be derived and do 
appear to satisfy the framework described in the charter.

my $.02

-----
Eric Williams
PGP Public Key
http://new.infobro.com/KeyServ/EricDWilliams.asc
Finger Print: 1055 8AED 9783 2378 73EF  7B19 0544 A590 FF65 B789

On Thursday, March 27, 2003 11:33 PM, [email-masked] [SMTP:[email-masked]] 
wrote:
> On Fri, 28 Mar 2003, Kee Hinckley wrote:
>
> > At 6:11 PM -0800 3/27/03, [email-masked] wrote:
> > >Opt-out will not be effective all by itself.
> >
> > Of the proposals we have seen so far, which would change the dynamics
> > of opt-out as I've described them?
> The proposals offered so far are incomplete, that is why we all can not
> decide on any one... But I'll tell general solution:
>
> 1. We stop forgeries of mail headers and force all senders to reveal
> their name (but that I mean source, not actual name for personal emails,
> etc).
>
> 2. We provide means for mail servers to authenticate in such a way that
> spammer can not easily change just their domain or their ip and begin
> sending email again (they'd soon be detected and their mail server
> blacklisted).
>
> 3. Law outlaws sending unsolicited commercial email
>
> 4. ISPs use filtering to get rid of unwanted spam that may still path
> through the cracks (i.e. spammer got new mail server and it has not been
> blacklisted yet or they hijacked the server, etc. etc.)
>
> This leaves commercial opt-in email lists where company is setup as real
> business that does not hide itself and they get permission to send user an
> information on their product (airline ticket offers) but you do not want
> to receive "extra" advertisements of credit card offers as you're not
> interested in that. This is where opt-out system comes in and helps,
> it regulates commercial email and forces them to respect your wishes.
> Now the system I described allows for automated white-listing of certain
> commercial emails where users want to receive them - that will help on
> filters and allow them to be more effective and have less false-positives.
>
> --
> William Leibzon
> Elan Communications Inc.
> [email-masked]
>
>
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Fri, 28 Mar 2003 07:33:51 -0800 (PST)

> addressed (or at least referred to to-date) in the discussion, perhaps a 
We have this on our "Work Items" list and nobody before did it. 
I think you just volunteered - congrats and thank you!

> reading of the archives is in order or a document archive contains such.
There were couple emails early on that I remember that contained
some kind of list of requirements. I'll try to find it out and send to you
and the list to help it out.

> protocol] originating MTA/MUA authenticity.
There is actually some difference between authenticity between MTAs and 
authenticiy of origin (i.e. so that email headers are not forged). That
is why I put it as #1 & #2. I have to think a little bet to see if I can 
find how to fraze requirement for my #2 below.
 
> pending as close as possible.
Good. I don't like wording "pending as close as possible". Just "amenable 
to legislation" is enough.
 
> other ANTI-SPAM (UBE/UCE) approaches [it shouldn't break anything].
Ok with above 

But there should be SEPARATE requirement that 
"Proposal SHOULD NOT break existing email communication infrastructure"

> either providers or users.
Make it "providers and end-users"
 
> MUST include mechanisms for interaction with the other components.
I'm ok with the above, I did not quite understand why it needed.

> integration with other protocols, e.g. HTTP, that may be used to relay 
Because it says "MAY" this can not be part of the REQUIREMENTS. And I do 
not see why fraze like that is needed.

----
William Leibzon
Elan Communications Inc. 
[email-masked]