ietf-asrg
[Top] [All Lists]

Re: [Asrg] 4d. Consent Framework -Two obstacles to a consent framework (was Re: Two obstacles to a consent framework.)

2003-10-02 11:50:35
Yakov Shafranovich wrote:

[Please following the posting guidelines, subject has been changed. Mod.]

Meng Weng Wong wrote:

On Wed, Oct 01, 2003 at 10:02:57PM -0400, Yakov Shafranovich wrote:
| | Personally, I feel that the consent approach is correct.
|
I agree.  Here is my perspective on the issue.

Consent-based email is already possible.  Any MTA is free to reject any
message for any reason.  The problem lies in distinguishing wanted mail
from unwanted.  There are two parts to this problem.  The first is a
problem in politics; the second, deception.

1) The difference between "wanted" and "unwanted" is a personal decision.

   Historically, ISPs have had to decide site-wide policies by fiat.
   Such policies try to do the best thing for the greatest number, and
   are essentially political: no matter what you do, there is always a
   minority who'll be guaranteed to be upset.

   Today it is hard for individual persons to express their preferences
   at the SMTP front line.

   The major MTAs are constructed on the philosophy of "be liberal in
   what you receive."  They did not anticipate that one day they might
   need to represent their recipients' preferences when talking to the
   SMTP client.  If one user wants to use one DNSBL, and another user
   wants to use a different one, too bad.  Everybody eats the same meal.

   It doesn't have to be that way.  At root, even though its symptoms
   are social, this is a technical problem with a technical solution.

   Everybody should not have to do what the majority wants to.

   Everybody should get to do what they want to do.

   At Pobox.com we are developing an SMTP proxy, intended for use with
   Postfix but adaptable to other MTAs, which will perform per-user
   database lookups.

   With this technology, individual users can choose their own consent
   mechanisms such as DNSBLs, RHSBLs, sender address verification,
   unknown sender domain policy, whitelists, blacklists, you name it.

   That way, if they're not happy with the defaults, they are free to
   make their own decisions.  If they don't like blackholes.easynet.nl,
   they can use sbl.spamhaus.org.  If they don't like sender address
   verification, they can turn it off or reduce a 5xx reject to an
   advisory header.

   That solves the first problem.


The consent framework does not specify where and how the processing take place. As I stated in a separate message, that is left to the implementors. This can be done on an MTA level with the user specifying settings - the more users will demand it, the more ISPs will support it. It can also be done by the MUA or via a proxy. The solution you are proposing is one of many possibilities.


2) Even if you have comprehensive sender whitelists and blacklists,
   they are beggared by the problem of forgery.

   You want to get mail from service(_at_)paypal(_dot_)com(_dot_)  Anyone can 
claim to be
   service(_at_)paypal(_dot_)com(_dot_)  If you whitelist 
service(_at_)paypal(_dot_)com, you will
   get spam.

This is also a technological limitation. RMX/SPF aims at this problem.

   Widespread adoption of an RMX/SPF strategy by industry leaders will
   solve the second problem.

Once we overcome these two obstacles, we can move on to more interesting
things, like reimagining email and building automated reputation systems.

In the consent framework input can come from many sources. The person's email address in a white-list is only one such source. Forgin can be mitigated by analyzing the source IP of the message against blacklists, sending a C/R message, digitial signatures, RMX, etc. There are many solutions possible, all of which will fit within the consent framework if there are standards in place for them to work with each other.

Yakov


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



<Prev in Thread] Current Thread [Next in Thread>