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

From: [email-masked]
Date: Fri, 26 Sep 2003 00:49:27 -0500

>>>But a united front from the internet groups behind a common definition of 
> what levels of consent must be required would help.  

>> I've put in my previous message some of what *I* consider key.

>> I don't think there's any need whatsoever to create a mechanism to tell 
senders 
> what their permission level might or might not be.  I think they should feel 
> OBLIGED to mail at the minimum, least-common-denominator level until the 
> RECIPIENT tells them otherwise (and authorizes such, too, via their 
permissions 
> list).  This is one way to keep senders at arm's length, AND to let the 
Congress 
> and DMA to know that they MUST contact the recipient for "extra" permissions 
> FIRST if they want more than just minimal level of access to the recipient's 
> inbox.

> There might we a useful purpose to create mechanisms for exchanging 
consent so this way we can have a standardized format for an audit trail 
that can prove "opt-in".

Actually, I think there's significant value in NOT making this easy, if for no 
other reason than to strongly encourage senders to NOT "push the envelope" of 
what they can get away with.  I'd like to see mailings kept to the simpler, less 
wasteful, small and universal formats to the degree practical.

Also, it's important to recognize that "proving opt-in" means *nothing* because 
the recipient needs to have the right AT ANY TIME to change their permissions 
associated with the specific sender (to more, or less, permissive).  Just 
because the recipient arguably once "opted in" doesn't mean that the sender has 
the continuing permission to send to them in any given format, or even for that 
matter to send to them anything at all.

I also think that recipients need to have the ability to change their 
permissions according to just about ANY criteria they wish, or might adopt in 
the future, and this suggests AWAY from any kind of standardized list of 
understood "standard permissions".

I firmly believe that recipients MUST continue to hold all the cards here, and 
that they have ALL the power to accept or deny anything at all and for any 
reason they choose, now or whenever they change their mind.

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: Yakov Shafranovich <[email-masked]>
Date: Fri, 26 Sep 2003 01:20:51 -0400

> reason they choose, now or whenever they change their mind.

How would you suggest that recipients would go about granting and 
denying permissions (or consent) if there are no standards in place? Are 
you suggesting that the receiver simply chooses not to receive certain 
kinds of email and that email starts to bounce? 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.

Yakov

---

From: david nicol <[email-masked]>
Date: 28 Sep 2003 19:20:39 -0500

> receiver can use to communicate his consent decisions to his MUA, MTA or 

Why does the standard need to precede the implementation? That happens
to be contrary to IETF practices as I understand them.  If we are talking
about a communication between an end-user to a provider of service
to that end-user, we don't need a standard until there is at least
one implementation.  Current standards in presentation and gathering
are sufficient.  Pay2send uses a clumsy web page to allow account
holders to edit their opt-in lists, but it will be made into a less
clumsy interface, and also a purely-e-mail interface will be provided,
before the pay2send SMTP daemon package version 1 is called complete.

rfc821 Appendix E Reply Code (rfc 2821 sec 4.2.1) protocol
is so rich that there is
room for 5yz codes that would indicate "not wanted due to sender's
absence from receiver's opt-in list and lack of sender being
listed with the appropriate postage stamp authority"

No such code is defined in 2821.4.2.1 but one will have to be
provided as the reply in the pay2send smtp server.  I am planning,
(with approval from my local Perl Mongers chapter) to use
"402 payment required" as the reply code in such a case, after
the defined "402" from HTTP.

Although adding funds to a postage account would seem to be
a user-correctable-only action under 821's guidelines for
selection of a 5yz reply code, it is hoped that a future mail 
system will be able to take care of identifying and transferring
appropriate funds, if possible, without requiring user intervention.

The exact nature of the fund transfer does not need to be part of the
mail transfer protocol.

---

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

> before the pay2send SMTP daemon package version 1 is called complete.

First of all, I meant standards in general, not in the IETF lingo. IETF 
requires at least two interoperable implementations in order for the a 
proposed standard to become an accepted standard. HOWEVER, 
implementations are not required in order to propose a standard as per 
the case with the CRI proposal.

> the defined "402" from HTTP.

You might also want to take a look at RFC 3463 which defines a set of 
extended code. In general it is not a good idea to cross over codes from 
one protocol to another such HTTP to SMTP.

> The exact nature of the fund transfer does not need to be part of the

How would a MUA communicate with a MTA in e-postage system such as 
Pay2Second? Whichever system you suggest or define, still needs to be 
published or covered in some document, which might as well be an ID or RFC.

Once we are establishing a standard for communication between a MUA and 
a MTA, we might as well generalize it as a standard for MUA to 
communicate consent to MTAs. This way other systems beside e-postage can 
be covered such as digital certificates, hashcash, etc. The whole point 
of such consent exchange protocol is so it is general enough not to 
cover a specific implementation, and thus can be used in many types of 
implementations.

Yakov