Re: [Asrg] Email Postage (was Re: FeedBack loops)

>  
> Why?  One need not verify that the Pitney-Bowes postage meter is 
> working, or the Post Office has paper stamps in stock to know that 
> their letter needs a stamp and that if you had one it goes on the 
> upper right hand corner of the envelope.
Yes, but the post office does. Otherwise we'd all print our own 
postage.  Again, postage is not a great example because you buy stamps 
to pay for the services of the post office.  Email doesn't have such a 
clear "service provider" as many companies run their own email servers 
and thus an ISP does not provide them email.
>  
>
>     Avoiding both a single point of failure and an N x M problem,
>     while still having acceptable performance, using infrastructure
>     and staffing that can be funded by stamps that are a "reasonable"
>     cost is a minimum there.
>
>  
> These questions do need to be answered for a 
> particular implementation, although there's no reason that all 
> implementation details must be globally identical.  That would only be 
> necessary if all recipients were forced to accept the same "type" of 
> stamp.   Only the framework of how to recognize the need for stamps 
> and the method of affixing them to a message needs to be global.  The 
> rest of the questions related to required infrastructure and risk of 
> failure and staffing concerns should be answered by the 
> implementor, i.e., the recipient, by their choice of stamps they 
> choose to accept. 
If you can't validate the stamps, then who would care that they have 
stamps on them?  Affixing stamps is easy if there's no way for "someone" 
to tell me if the stamp is valid or just something any old party affixed 
like EVERY PHISHING SCAM out there does today.  There's no advantage of 
having a stamp if it's not reliable and meaningful and trusted.
>  
>  Certainly, not every recipient places the same value on assured 
> delivery of messages, or would require the same level of effort for an 
> unknown sender's message to be delivered successfully, so how would we 
> ever come to a consensus of "acceptable performance"?  I suggest we 
> separate the discussion of how to "use" a stamp from the discussion of 
> how reliable/affordable/scaleable/secure stamp franking/verifying 
> routines are.
If there's no value of having the stamp, then this will not reduce 
spam.  It will be like DKIM, SPF and other attempts to reduce spam, but 
will only be able to do so if email systems stop accepting email that 
doesn't have the more trusted characteristic.  DKIM and SPF are free to 
implement, yet they are not used in this manner, and S/MIME would 
support trusted digital certificates for email, all standards-based for 
years, yet it's not used. 

So why build a new "stamps system" that would cost somebody money 
(right?) and would require somebody to check them to make them useful if 
it has no more value than the existing solutions out there today?
David

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