Two obstacles to a consent framework.

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.

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

   You want to get mail from [email protected].  Anyone can claim to be
   [email protected].  If you whitelist [email protected], 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.