Re: [Asrg] 4d. Consent Framework -Two obstacles to a consent framework (was Re: Two obstacles to a consent framework.)
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
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
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
This is also a technological limitation. RMX/SPF aims at this
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.
Asrg mailing list