Subject: Re: [Asrg] Re: 3. Requirements document

From: [email-masked]
Date: Fri, 26 Sep 2003 02:34:39 -0500

> How would you suggest that recipients would go about granting and 
denying permissions (or consent) if there are no standards in place? 

I think that that is an issue to be described by the documentation for the 
software involved, and/or the online help files that accompany it.  I don't 
think there needs to be ANY worldwide consensus on how that needs to be done.

What's more, it might well be COUNTER-PRODUCTIVE to our case just as it's 
counter-productive for so many people to be using the same Outlook and Outlook 
Express E-mail clients;  it just gives spammers a common, familiar base to find 
and exploit "universal" weaknesses in.

Since in a "proper" (IMHO) recipient-chosen, recipient-controlled system there 
is NO need for senders to interact directly with the recipient's chosen software 
(other than just by existing SMTP/POP protocols) I don't think there's any 
pressing need whatsoever for a worldwide permissions-and-control "standard" for 
interacting globally with these programs.  I believe that the market itself will 
sort these things out, to the extent the need to be, in a relatively short time.

I think what's the MOST important is that we get SOMETHING out that 
significantly helps the recipient users, and soon enough that it's still of 
value to them.

> Are you suggesting that the receiver simply chooses not to receive certain 
kinds of email and that email starts to bounce? 

I think the recipient ought to have the choice of how to deal with certain types 
of messages.  "Bounce it" might be one option, although probably not a good one 
since there are NO guarantees that there is even a valid POP3 mailbox at the 
sender end (and even so, that it's possible to determine what that POP3 E-mail 
address might be... clearly, a LOT of spam and viruses go out with forged/bogus 
sender addresses, as we've seen recently).

I believe that in general, either just t-canning (or holding in limbo for some 
time period, pending triage and final resolution) is probably a better approach 
overall.  I think that the best approach for most spam and virus mails, and with 
ultimately the lowest total cost to the Net, is to simply route them all 
(commensurate with the recipient's established and specified permissions rules) 
down a black hole, and the sooner the better after they're sent.

> If so, there is still a need to have some form of a format or standard in 
place that the receiver can use to communicate his consent decisions to his MUA, 
MTA or ISP.

I don't think that that needs to be the result of a worldwide standard, in part 
since the capabilities of different permissions list implementing systems are 
likely to be VERY different, and may result in having quite different needs to 
control those capabilities.

For example, some of these filters might be implemented by Web-based tools, and 
others might be based on E-mail-type control commands.  These two methods are 
likely to be (even VERY!) different.  These are the types of things which 
individual ISPs and software providers are likely to use for 'product 
differentiation' that will give one ISP or software an edge over another.  I 
don't think these NEED to be the result of a 'standards' effort.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

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

---

From: Bart Schaefer <[email-masked]>
Date: Fri, 26 Sep 2003 15:45:11 +0000

On Sep 26,  2:34am, [email-masked] wrote:
} Subject: Re: [Asrg] Re: 3. Requirements document
}
} Since in a "proper" (IMHO) recipient-chosen, recipient-controlled
} system there is NO need for senders to interact directly with the
} recipient's chosen software (other than just by existing SMTP/POP
} protocols) I don't think there's any pressing need whatsoever for a
} worldwide permissions-and-control "standard" for interacting globally
} with these programs. I believe that the market itself will sort these
} things out, to the extent the need to be, in a relatively short time.

I may have missed something in the past part of this discussion, but
what gives you the idea that there is any "direct" interaction with
end-user software implied here?

Or perhaps a better question is, what's your definition of "direct"?

Was the world really a better place when every MTA generated a different
delivery status notification format, most of which were understandable
only by humans?  If so, why has the RFC3464 format become so common?
If not, shouldn't we apply that lesson to another case where a status
notification could be transmitted?

The important thing is a standard way of communicating the recipient's
choice.  There's no implication that anyone other than the recipient has
the right to make that choice, nor that the recipient has to have any
justification for which choice he makes.  It's wasteful of everyone's
resources if the choice is never communicated, i.e., that any no-longer-
wanted messages are simply discarded at the time of delivery.  The point
is to propagate the "discard" decision as close as possible to the sender;
in the case of a known and conscientious sender, ideally the decision
would reach all the way back and the sender would cease to initiate any
further messages.

The fact that there exist messages for which the sender is unknown and
malicious doesn't reduce the need for communication between recipients
and known senders.  In the case of known but oblivious or malicious
senders, a record that consent was revoked (or a lack of record that
consent was ever provided) may be useful in several respects.  At the
same time, a record that consent had at one time been provided is very
useful in cases of malicious or mistaken prosecution, where it is e.g.
the recipient claiming fraud who is in the wrong.

Even when the sender is unknown, it could be useful to communicate the
consent decision to an upstream provider and have the unwanted message
blocked earlier in the transmission process.  Yes, there's a possibility
of misuse or abuse here -- a message could be wrongly blocked upstream --
but guess what:  That's already the case now.  Communicating explicit
consent to the upstream would actually help prevent incorrect blocking,
not encourage it.

} For example, some of these filters might be implemented by Web-based
} tools, and others might be based on E-mail-type control commands.
} These two methods are likely to be (even VERY!) different. These are
} the types of things which individual ISPs and software providers are
} likely to use for 'product differentiation' that will give one ISP
} or software an edge over another. I don't think these NEED to be the
} result of a 'standards' effort.

Obviously not, but that has nothing to do with having a standard for
communicating the resulting consent decision.  Even if the standard
specifies a way to transmit some of the filtering information, there's
no reason that the end-user tool _has_ to transmit it, or to transmit
all of it.  The end-user tool can always apply filters in addition to
those described by the consent communication.

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 26 Sep 2003 16:18:29 -0400

Hi,

FIRST, I will be away for a few days and will try to answer this in 
detail when I get back.

SECOND, off hand I think this fits within the consent model that the 
group has been chartered to create expect with several restrictions such 
as no communications with the senders re: consent, and no 
standardization. I think that a small document summarizing your thoughts 
would serve as a useful tool around which we can center the discussion.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 29 Sep 2003 14:28:39 -0400

> think there needs to be ANY worldwide consensus on how that needs to be done.

What about the MUA communicating with the MTA? Wouldn't a standard way 
of communicating consent between the MUA and MTA help?

> and exploit "universal" weaknesses in.

Does that mean we should abondon SMTP and HTTP since people can find 
holes in them? A protocol that is properly designed and implemented, 
will not be a problem.

> sort these things out, to the extent the need to be, in a relatively short time.

The consent exchange protocol would be useful primarly for telling your 
MTA or ISP on what types of choices you made. Exchanges between senders 
and receivers might only occur in certain cases such as C/R, or opt-in. 
This would depend on how the protocol and the framework are designed.

> significantly helps the recipient users, and soon enough that it's still of 

Definatly.

> down a black hole, and the sooner the better after they're sent.

RFC 3464 defines a DNS format for bounced messages which gets delivered 
with the MAIL FROM <> line in order not to bounce again. If a message 
gets "t-canned" and not delivered, the sender will not find out about it 
and might assume the email went through. This would change the semantics 
of email on the Net which has already begin from the side-effects of 
various spam systems.

> don't think these NEED to be the result of a 'standards' effort.

The consent framework and protocol will define a framework for these 
tools to interoperate. The implementation details of what kind of data 
is exchanged can be left out of the standard.

---

From: [email-masked]
Date: Mon, 29 Sep 2003 18:23:54 -0500

>What about the MUA communicating with the MTA? 

I don't believe that it's necessary to do that.

First of all, either the receiver's mailbox will accept a message in a given 
format or and of a certain type or it won't (and that could be changed by the 
recipient at ANY time prior to the message ACTUALLY BEING SENT).

One tenet of good program design is that you should not encourage a program to 
make irrevocable decisions based on potentially incorrect information.  If the 
recipient tells the sender that (at this precise instant) a given type of mail 
is acceptable, and the sender proceeds to send it, the permissions list could 
still change before the attempted message actually arrives... and then needs to 
be blocked or bounced or T-canned!  Better, I think, to just let them send it 
and then the chips fall where they may when the attempted transmission actually 
arrives.

> Wouldn't a standard way of communicating consent between the MUA and MTA help?

I'm not convinced that we need anything beyond what we already have.  (And 
non-compliant points in the path are STILL going to need to map any "extended 
result codes" to one of the current basic set of results anyhow).

In essence:

   1)  Can't find POP3 server there (no need to retry, probably);

   2)  Can't establish connection with POP3 server (down? backbone problem?  
DDoS?) (retry later, probably);

   3)  Found POP3 server, but no such user there (no need to retry, probably);

   4)  Found POP3 server and user, but mailbox full (might want to retry again 
later);

   5)  Delivered message to POP3 user's mailbox (note that this MIGHT be a 
relay, in which case one cannot really still draw any conclusions about 
SUBSEQUENT deliverability...!) 

Unless any "communication of consent" was done during the time the message was 
being CREATED, at which point ARGUABLY the sender's mail client program MIGHT be 
able to modify the message, by the time it's in transmission it's probably too 
late to do anything about it.  This is ESPECIALLY true if there is a relay 
involved, or if there's a mailing list redistribution perhaps.

And of course, in the case of spammers, there's usually no obvious way to really 
return a meaningful status to the "sender", even if it WERE a good idea to tell 
them anything useful at all about the recipient's presently active level of 
defenses.  Usually the "sender" is either bogus (nonexistent) or innocent 
(joe-jobbed).

If you had a castle being defended by an intelligent forcefield, you don't want 
the message to go back to the enemy that "this castle's defense forcefield is 
programmed to only let in shells carrying less than 30 pounds of explosive!".  
Obviously, in that case, the attacker just configures each of their shells to 
each carry 29.985 pounds of explosive and fires away.  :-(

I think that the recipient ought to be able to choose (and in confidence) their 
own policy regarding what types of messages are bounced, which are refused, 
which are quarantined, which are delivered, which are perhaps forwarded (or 
auto-responded, for that matter), and which are simply routed to the bit bucket. 

>holes in them? 

No.  Those are basic protocols and are needed for the Net to interoperate.  What 
we are talking about here is NOT base functionality.

>A protocol that is properly designed and implemented, 
>will not be a problem.

It's much more difficult to decide what is "properly designed and implemented" 
when you're dealing with several orders of magnitude more degrees of freedom.

>MTA or ISP on what types of choices you made. 

Once these choices go much beyond simple grep-type things (i.e. simple 
braindamaged regex-type pattern matching) you almost really want to be able to 
(at least optionally) do full-fledged programming to describe the 
acceptance/permission process... complex (perhaps nested) if/then/else, compound 
logical expressions, more sophisticated pattern matching, maybe even macros, 
wildcards, macros, function calls, "fuzzy" weighted criteria, maybe even stuff 
requiring use of external programs (e.g. "run PKUNZIP -t on any zipped 
attachments, and then if the CRC isn't correct...:", or "run a virus scan on the 
attachments, and then based on THAT outcome...", etc etc.)  Unsophisticated 
users are likely to use this kind of thing (at least initially!) only at a very 
basic level, such as (in effect) "let Aunt Bertha send me pictures, don't let 
anybody send me executable attachments."  More sophisticated users might need an 
(even QUITE elaborate) set of rules depending upon who is sending, and which of 
the recipient's (perhaps large number of incoming E-mail addresses) they're 
sending to.

Anyhow, I think that the requirements at the recipient end (and variety of 
permission options and criteria) are likely to be varied enough that I don't 
really think there's a whole lot of point in trying to establish standards to 
make those meaningful to describe across a wide variety of diverse programs, 
especially if there are many different levels and versions and implementations 
of software at the originating end(s).

>Exchanges between senders 

I think that C/R is for the most part a nonstarter.  Way too many mailing lists 
and other automated software is already in use and whose owners simply have NO 
ability or willingness to jump through such hoops to get their stuff delivered.

As for opt-in (and I'm a GREAT believer in opt-in) the way to handle that is 
simply to NOT MAIL TO ANYBODY *until* that recipient has given you permission to 
send to them.  And unless you've arranged with the recipient in advance (and 
presumably by whatever mechanism makese sense under the circumstances), the 
sender shouldn't IMHO presume to send anybody bulky HTML-burdened E-mail, or 
attachments of ANY kind.  They ought to send least-common-denominator simple 
ASCII text E-mails unless and until they are given permission to send anything 
beyond that.  

That is NOT the same thing as "go ahead and send anything you feel like, and the 
recipient will tell you if they don't accept that."

Your permissions might not even be based solely on the CONTENT of the E-mail;  
for example, it might be conditional based on something totally alien to the 
sender, such as (to try to prevent inbox overflow) "hold off E-mail containing 
attachments if I've already got attachments [maybe even just ordinary E-mails] 
waiting in my Inbox that haven't been picked up for more than an hour".

There's almost an infinite variety of such kinds of rules one could imagine, and 
I don't think it's either practical OR desirable to try to envision all possible 
ones in advance, or to standardize their descriptions, let alone the 
interactions and priorities of testing/switching/decision trees based on each 
one.  These are going to be determined by the particular features of the 
implementing software, mostly at the recipient end.

>with the MAIL FROM <> line in order not to bounce again. 

That would be fine as one of the options, although I've not seen many messages 
of that sort.  

>If a message 
>and might assume the email went through. 

E-mail has never really been a "guaranteed delivery" medium.  Even if it got 
into the recipient's inbox, that doesn't mean they got around to reading it 
before it timed out, or they changed ISPs and never picked it up, or 
accidentally deleted it unread, or had a disk crash, or whatever,  And (for 
instance) even "confirmed" delivery to a relay doesn't mean that it might not 
have bounced or otherwise gotten lost when relayed.  (Of course, the same is 
true about any "ack" message returned too.)

>This would change the semantics 

I don't think it is a CHANGE of the semantics as much as it is an ACCEPTANCE of 
(and extension to, perhaps) the semantics that have ALWAYS in actuality been 
there.

>> likely to be VERY different, and may result in having quite different needs 
to control those capabilities.

>is exchanged can be left out of the standard.

I understand the desire, but I think it's misguided.  IMHO there's little reason 
to exchange information if the format of the information being exchanged isn't 
useful for any meaningful purpose.  It's sorta like the old programmers' axiom 
of "don't test for errors you don't know how to handle."

For example, for MY personal E-mail filtering system, which is written in 
SPITBOL, I could envision that I might want to program specific little handlers 
describing the logic to be used for handling E-mails with given to/from address 
pairs.  (SPITBOL allows program source code to be read from a data file at 
runtime, precompiled, stored as a variable of type "code" into associative 
tables, re-activated later, etc etc.)  As a bonus, SPITBOL supports what is 
probably just about the most sophisticated and powerful text pattern recognition 
engine and capability of any general-purpose programming language, so I'd want 
the option to use that capability to describe my filters and transforms too.

While capabilities like that make MY filter exceptionally useful, there's no 
reasonable way to presume that someone else (who's likely to be using a tool 
written in something primitive like Perl or whatever) is going to be able to 
make sense of a SNOBOL pattern or logical expression... nor should I cripple my 
own more powerful tool by limiting it to a permissions "standard" based on only 
just braindead regex-style pattern matching descriptions.

So anyhow, now you've got (in your end's Perl-based tool) a totally alien 
SPITBOL-flavored description of my own filters and mail handling criteria 
expressions, and you haven't a clue what they represent.  So what good does it 
have you to have a (even "good") copy of them?

There *might* be a reason to try to standardize stuff like this, IF there were a 
truly compelling argument to be made about why there NEEDED to be a consensus or 
communication between various sorts of different software, or more particularly 
between the sender and the recipients' various mail handling agents.  But I'm 
not convinced that there is in fact much fertile ground there, despite this 
fuzzy sorta warm (but still not very convincing) "there oughtta be a way" 
notion.

What I *actually* expect is more likely to happen, instead, is one or more of 
the following:

  1)  Users are going to give up on the ISPs and IETF really getting a grip on 
this problem, and default to using their own widely divergent array of spam 
content-based filtering tools (SpamAssassin or whatever);

  2)  ISPs and domain providers are going to choose one of a perhaps wide 
variety of tools to attack the problem, even perhaps writing one of their own 
(AOL, perhaps, might take this approach) and tailor it precisely to their own 
users and purposes... and use the specificity to differentiate their service 
offering from that offered by other ISPs, and coincidentally to help "lock in" 
their customers who will stay with that ISP or domain provider rather than 
having to "start over" redefining their filters and processes using the 
dissimilar tools offered by competing ISPs.

Alternatively, we might come up with some kind of a standard here which is nice 
but not sufficiently flexible that even after it's adopted net-wide, then some 
ISP comes up with something more powerful and flexible (say, more like a 
SPITBOL-based filter evolved from what I've been using here) and while not being 
standard-compliant, is compelling enough that it makes the "standard" version 
obsolete.  

I think there's a lot to be said for keeping the process single-ended (i.e. not 
doing anything special or even different between sender and recipient agents)... 
in fact, not changing the sender end AT ALL (other than, hopefully, encouraging 
plain ASCII text as the 'standard' format for unexpected transmissions and 
discouraging unexpected attachments and spamming!)

Does that make my thinking clearer?

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 30 Sep 2003 10:01:20 +0100

>result codes" to one of the current basic set of results anyhow).

Let's put it like this:

Would it be a "good thing" to reject unwanted mail as near the sender as
possible?
    yes / no

Will it be impossible (in most cases) for a recipient to directly configure
an upstream MTA
    yes / no

Will MUA / MTA be from a diverse set of vendors
    yes / no

If you answered mainly "yes" then you'll likely need a standards based
consent /policy expression do-dad.

If you answered mainly "no" then you'll need to think about the problem
more.

The "end-to-end consent" systems are particular cases of the general 
"consent in the MTS" question. If you don't believe that end-to-end consent
is workable or required (although the consent-token / proof-of-work / CR
crew will disagree with you) - you're still left with the general question.

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 30 Sep 2003 14:34:18 -0400

Jon Kyme wrote:

>>>Wouldn't a standard way of communicating consent between the MUA and MTA
>>
>>help?
>>

Just wanted to add that the notion of consent in messaging is not new. 
Various Instant Messaging (IM) systems have that notion although not as 
detailed as we are planning on doing in email. EVEN though most of 
today's IM systems are run by a single service provider, Jabber and 
similar systems do not. Also, the IETF IMPP WG defined a bunch of RFCs 
and IDs for IM services that operate on many servers - kind of like the 
current email system. For example, take a look at RFC 2778, in 
particular the section 4 - "Security Considerations":

<snip>
    This document provides a model and vocabulary for systems with
    certain intrinsic security issues. In particular, presence and
    instant messaging systems must deal with "the three S's": STALKING,
    SPOOFING, and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER
    INFORMATION are intended to deal with STALKING.  The several kinds of
    authentication mentioned for INSTANT MESSAGE SERVICE and PRESENCE
    SERVICE are intended to deal with SPOOFING. DELIVERY RULES are
    intended to deal with SPAM.
<snip>

With the three problems being a subset of our issues as follows (the 
spam definition might be useful for us as well):

<snip>
o SPAM: unwanted INSTANT MESSAGES.
o SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL.
o STALKING: using PRESENCE INFORMATION to infer the whereabouts of a
       PRINCIPAL, especially for malicious or illegal purposes.
<snip>

They use several mechanisms to address these problems. While STALKING is 
not an issue for us, SPAM and SPOOFING is. The following mechanisms are 
used for controlling SPAM and SPOOFING which are similar to the consent 
rules we discussed some time ago within the consent framework:

<snip>
o DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE
       delivers received INSTANT MESSAGES to INSTANT INBOXES. For each
       INSTANT INBOX, the applicable DELIVERY RULES are manipulated by
       the INBOX USER AGENT of a PRINCIPAL that controls the INSTANT
       INBOX.
       Motivation: We need a way of talking about filtering instant
       messages.

o INSTANT MESSAGE SERVICE: accepts and delivers INSTANT MESSAGES.
   -- May require authentication of SENDER USER AGENTS and/or INSTANT
          INBOXES.
<snip>

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 30 Sep 2003 15:07:00 -0400

Dennis Gearon wrote:

> 
> Yakov Shafranovich wrote:
> 
>> Jon Kyme wrote:
>>
> I think it eventually has to come down to an access list, IF someone 
> wants to keep spam down in their inbox.
> 
> And that means that email is at first part of a communication 
> relationship,  a secondary medium. Telephone, letter, and in person 
> methods will be used for initial validation. "Hey Joe, I want to be able 
> to contact you by email, will you put me on your access list, OK?" 
> Anyone got any real objections to that assumption?
> 

I think a lot of people have that objection. Someone has told me 
off-list that this assumption has been one of the biggest problems with 
the ASRG's charter and the notion of consent in it:

<snip>
You don't need advance consent to communicate with people. Consent can 
be revoked, but we would oppose any systems that retract it in advance. 
In free societies unsolicited communication is allowed.
<snip>

Keep in mind that the consent framework does not assume that. Rather 
this option is left to the implementors. Some existing systems such as 
C/R already have that assumption.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 30 Sep 2003 23:27:21 -0400

> I don't believe that it's necessary to do that.

Just for the record, I meant the receiver's MTA and MUA.

> recipient at ANY time prior to the message ACTUALLY BEING SENT).

So do you want this to happen at the receiver's MUA? What about his MTA?

> and then the chips fall where they may when the attempted transmission actually 

I see consent as something subject to change at all times. In theory the 
receiver will set his consent policy (at MTA or MUA level). The sender 
will send a message and may receive a consent token back. However, 
nothing prevents the receiver from changing consent policies midstream. 
In that case the original consent token is revoked on the receiver's 
side and the sender will receive a notification either via email or at 
the time he tries to contact the receiver.

> result codes" to one of the current basic set of results anyhow).

I am refering to the receiver's MTA and MUA, not the senders. Want to 
make sure we are on the same page.

> auto-responded, for that matter), and which are simply routed to the bit bucket. 

Once again the consent policy we are talking about is being set by the 
receiver and communciated to his MTA/MUA and possible the ISP. In 
certain cases portions of the policy MAY BE shared with the senders in 
accordance with the rules that the receiver set. Examples of these might 
be C/R systems or hashcash systems. Another example would be your 
attachement-free system where the sender might be optionally notified 
that permission is needed before attachments. That notification would in 
fact be considering having the receiver share a portion of this consent 
policy with the sender.

> of software at the originating end(s).

HTTP is currently being used for many other things besides HTML. There 
is no reason why a transport protocol cannot be used to exchange consent 
rules that are pretty complicated as long as its pretty generic. 
However, there are many basic things in consent that will remain the 
same across all or most systems. Certain types of consent tokens such as 
digital certificates, hashcash, C/R, etc. also would benefit greatly 
from being standarding so the systems using them can interoperate (which 
is the thrust of the CRI proposal). There are many benefits to 
standardizing portions of consent systems, while leaving many portions 
to the implementors.

> ability or willingness to jump through such hoops to get their stuff delivered.

Nevertheless people use these systems, and we should consider them as 
well (a protocol such as CRI or a larger consent protocol is support by 
mailing lists, etc. can alleviate the problem but not make it go away). 
Plus in certain places C/R is great - such as confirming whether people 
actually want to subscribe to a mailing list.

> recipient will tell you if they don't accept that."

A consent standard may help to grant and store record of that grant of 
consent once the receiver decides to opt-in. I am not advocating 
communicating consent after the email is sent, rather this is something 
to be left to the implementors to decide. People who want to receive 
email before exchanging consent can do so, others can choose not to.

> implementing software, mostly at the recipient end.

That's is correct. That's why we are not seeking to define the 
implementation details, rather just the framework and protocols to help 
consent systems interoperate. For example, two specific consent systems 
can be build in completely different ways but they can still benefit 
from a common protocol in cases like C/R, hashcash, digital signatures, 
etc.

> fuzzy sorta warm (but still not very convincing) "there oughtta be a way" 

There are plenty of reasons. Simply speaking there are no protocols for 
spam tools to talk to each other. And as much as we may hate "opt-in" 
having a standard for audit trails as a side benefit might help.

> content-based filtering tools (SpamAssassin or whatever);

They have already done that and if you have noticed the ASRG is not 
exactly popular in the newsgroups :)

> dissimilar tools offered by competing ISPs.

They have already begun using tools. We are seeking a way to unify them.

> standard-compliant, is compelling enough that it makes the "standard" version 

We are not seeking to create a standard implementation - we are only 
seeking a generic framework and some protocols, and formats. ALL or MOST 
of the implementation details will be left upto the implementors. I 
think we need to clear this point up.

Additionally as a long term goal we might seek to change the 
architechture and email standards on the entire Internet such as (gasp) 
kill or change SMTP. As a short-term that is not possible, but as a 
long-term goal it might become an option. That is something that only 
the IETF can accomplish since they are the keepers of SMTP and related 
standards.

> discouraging unexpected attachments and spamming!)

We would seek to address the receiver first and his MTA. Then we can 
work our way from there upstream. Also, BCPs - plenty of possibilities 
there.

> Does that make my thinking clearer?

A bit but I am still not on the same page as you. I also want to make it 
clear that "consent" is not the only options available to us. Even 
though the charter focuses on consent it is not cast in stone and can be 
changed if a strong enough reason arises. So we are open to other 
"non-consent" possibilities, but as of now, the consent framework is 
looking to be a good direction to research.

Yakov