ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"

2009-10-17 01:46:02
On Fri, 16 Oct 2009, hector wrote:
Michael(_at_)talamasca(_dot_)ocis(_dot_)net wrote:
But you don't need to be a vanity domain to *advertise* except-mlist, and
us vanity domains would appreciate it if you do.

If you could Package this and provide it as a persistent protocol
methodology for everyone to follow, then GO WEST!!

The problem is that any solution that doesn't require the intelligence
typically only possessed by vanity domains, will require a global whitelist
of mailing lists -- so that spammers and phishers cannot make fake lists just
to use the back door.

To improve upon except-mlist as I've described it, every mailinglist in the
whitelist must be unforgeable -- either via SPF, or a third-party DKIM.  No
exceptions, since the public whitelist neutralizes the SbO advantage of the
vanity-domain approach.

Then, we have the problem that a site can only publish
"dkim=except-mlist-on-global-whitelist" if it *knows* that none of it's users
subscribe to mailinglists unknown or unacceptable to the GW.

So, we've then made a lateral move from a policy that can only be *applied*
by vanity domains, to one that can only be *advertised* by vanity domains....

It's still a worthy goal, which is why I've suggested that we also reserve a
namespace of policy names which devolve to except-mlist when not specifically
known to a validator.  It just doesn't replace naked except-mlist.

(Actually, I see one escape from the global whitelist -- a sender could
program his mailserver to recognize mail outgoing to trusted mailing lists
and use l=0 signatures in that case.  But that is also practical only for
vanity domain senders.)

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html