ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: 3. Requirements document (proposal for extended SMTP reply code 402)

2003-09-28 17:21:34
On Fri, 2003-09-26 at 00:20, Yakov Shafranovich wrote:

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


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.




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg