Subject: Re: [Asrg] 7a: To consent, or not to consent

From: "Alan DeKok" <[email-masked]>
Date: Tue, 02 Sep 2003 11:23:08 -0400

Brad Knowles <[email-masked]> wrote:
> 	This doesn't work if people start adopting RMX-like solutions, 
> and I have a dozen e-mail addresses.  Or .forwards.  Or 
> /etc/alias-based mailing lists.  Or other reasons for attempting to 
> use legitimate third-party relays.

  You now have a choice:

  a) establish a framework so that every party to those email
     messages has sufficient information to verify (at some level)
     that the other parties have consented to the email being sent.
     (end user, ISP, MTA's, sender, recipient, etc.)

  b) decide that's too complicated, and avoid communicating consent.

  The first choice involves re-designing the Internet from scratch (by
some accounts), and will cost billions of dollars, and take decades to
implement.  The second choice involves keeping the status quo, in
which case we've decided to NOT fight spammers, and ASRG should
therefore be disbanded.

  I sincerely hope there are other alternatives.

  Alan DeKok.

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

---

From: Liudvikas Bukys <[email-masked]>
Date: Tue, 02 Sep 2003 12:13:51 -0400

Alan DeKok wrote:
------- Forwarded Message
>From: "Alan DeKok" <[email-masked]>
>To: [email-masked]
>Subject: Re: [Asrg] 7a: To consent, or not to consent
>In-Reply-To: Your message of "Sat, 30 Aug 2003 22:25:31 +0200."
             <a06001a88bb76b751470d@[10.0.1.2]> 
>Message-Id: <[email-masked]>
>
------- End of Forwarded Message

Here's an alternative:

(c) 1. Establish a framework for end-to-end consent negotiation.
    2. As an optimization for performance and division of labor,
       support some mechanisms for communicating consent information
       from the recipient to enterprise or ISP systems with more
       bandwidth or computational power.

Trying to build a framework that every mail-handling party hooks
into is a chimera chase.  Not only is it too complex, it also opens
up whole new messy opportunities for DoS attacks upon the framework
itself.

End-to-end is sufficient but may bottleneck.

Limited delegation and information sharing fixes the bottlenecks,
and requires connectivity and information sharing only between
parties that can arrange their own contractual and performance
expectations.

Any more than that is mostly cost and little benefit.

---

From: Troy Rollo <[email-masked]>
Date: Fri, 5 Sep 2003 18:20:03 +1000

>      (end user, ISP, MTA's, sender, recipient, etc.)
...
> implement.

It does not. If the protocol is added as a direct query protocol (that is, not
as part of the transport itself), it can be deployed witout any basic change
to the network, provided it is done by means of the sender *querying* for
consent. The SMTP banner and BMPP approaches are examples of this.
--
Troy Rollo				Chairman, CAUBE.AU
[email-masked]			Executive Director, iCAUCE

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 2 Sep 2003 15:17:53 -0400

Yes, we can take a subset of consent-based delivery and implement
it...and then let it evolve.  We need a small..initial success that's
extensible.

We could start with something like CRI...and then build on it.  We don't
need to paint a Mona Lisa.  We just need something that will 
a) work
b) work quickly

though we don't need something that catches like wildfire...just a small
success.