Barry Shein <bzs(_at_)world(_dot_)std(_dot_)com> writes:
A. There's nothing new here.
B. It remains to be shown that the approach is useful.
C. Repeating once again how these "rules and filters" are somehow
going to magically appear won't make it happen.
D. "For each email user the MUA or the ISP maintains a whitelist..."
MUAs don't maintain whitelists, people do. And that's the crux of
the problem as has been shown repeatedly, people generally don't
know the exact details of where the confirmation of their FTC/AT&T
no-call list is going to come from to put them on their
whitelist. Etc.
That's an important problem, and it's one that the IETF (or some other
body, such as W3C) could help to solve.
Something that would be helpful would be (say) and XML specification
for small documents that web sites could offer for email lists that
they run. Such documents would include information about the
originator address of email from the list (or some other kind of
authenticator), and information for subscribing and unsubscribing from
the list, together with information about the list (description,
perhaps an icon that user agents can use).
I've phrased that poorly in the sense that the same idea would work
for short-term communication agreements (such as information about a
particular order from amazon.com, say). Some documents could specify
an expiry time for this use.
Obviously, email clients would parse such documents, and (after
presenting the information and receiving confirmation) would be able
to set up the whitelist (also perhaps arranging a filter to put email
into a special folder), and then tell the originating site about the
desire to accept communications. (I say "email client" on the grounds
that most people use IE/OE, so their email client is also their web
browser. Obviously it would be slightly more complex if the two are
separate, but still readily doable.)
I'm not sure how the information would be passed to ISPs that offer to
do filtering. As you say, there are privacy issues. However, if
these privacy issues can (to a sufficient extent) be addressed, then a
standardised way for the permission information to be passed to ISPs
would be valuable.
Even in the absence of spam, that would be handy, since it would make
it easy to manage mailing lists (my MUA could show me a list, and
could automatically filter them into folders).
It wouldn't be so valued by many commercial organisations, since
subscribing to their advertising would involve more than not
unchecking a 2x2 pixel checkbox at the end of a long web page, but
that doesn't seem a big disadvantage to me. I think the idea's a
potential win: it would make managing mailing lists (and similar
things, like information about specific things like orders) much
easier, and much more usable.
Given that we're mostly concerned with spam, making whitelists usable
can work with other approaches: something like RMX can make the
whitelist somewhat reliable even when using the originator address as
authenticator; using hashcash (or email stamps or something) would
permit unsolicited email (much interperson email could use hashcash,
for example), provided the sender is willing to pay the cost.
In fact, I think usable whitelists together with hashcash would be a
very nice email system.
[...]
The ISPs maintaining the whitelist has privacy issues (and don't
just jump back to ok then keep it in the MUA, that's a shell game,
if half your proposal lacks merit that's a problem.)
Not too many senators want to tell AOL that they think the email
they get from hotties(_at_)big-butts(_dot_)com is ok and should be allowed
through.
True. ISPs can already see that the senator is receiving email from
hotties(_at_)big-butts(_dot_)com, of course, but you're right that that's a big
step away from knowing that the senator has asked for it.
This seems a general problem where user-controlled filtering can
happen at the ISP: the ISP could record which emails have passed
through, and can make inferences about what email the user wants to
receive. The better the quality of filtering that's being used, the
better the quality of the inference.
Ideas like hashing (especially with salts and other tricks) can reduce
the privacy implications of exposing the database that the ISP needs
to keep, but the ISP itself can just watch the traffic.
[...]
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg