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

From: hector <[email-masked]>
Date: Fri, 16 Oct 2009 20:15:09 -0400

[email-masked] wrote:

> In theory, a spammer could forge them, since none of them (not even
> spf-discuss!!) use SPF.  

I see in our SPF Mail Summary Reports that you are one of the top
posters. :)

> Loosely, you could say that dkim=except-mlist is equivalent to dkim=unknown
> when the validator is a big ISP, and equivalent to dkim=all when the
> validator is a vanity domain.
> 
> 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!!

--
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Deutschmann <[email-masked]>
Date: Fri, 16 Oct 2009 22:41:58 -0700 (PDT)

> 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 <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: hector <[email-masked]>
Date: Sat, 17 Oct 2009 05:23:54 -0400

I don't quite understand your suggestion. Who is creating this 
DKIM=except-mail ADSP++ record?  The Author Domain or the Mailing list 
Server?  Who owns, creates, maintains, updates this Global White List 
you speak of?

Maybe you might want to write a IETF draft proposal to work out your 
thoughts.

--

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 18 Oct 2009 05:56:23 -0700 (PDT)

On Sat, 17 Oct 2009, hector wrote:
> Server?
The header From: domain, as always.

> Who owns, creates, maintains, updates this Global White List you speak
> of?
Now, this is why dkim=except-mlist-on-global-whitelist is not low-hanging
fruit like dkim=except-mlist.

But the Global Whitelist was not intended as a practical suggestion so
much as a rhetorical device in my argument that dkim=except-mlist can't be
improved upon, despite the fact that it leaves big ISPs (who don't know
what lists their users subscribe to) high and dry.

Basically, it seems inescapable to me that reliable forgery detection
requires the kind of mailserver knowledge that only vanity domains have.
One end of the connection can be a big, ignorant ISP, but either the
recipient or sender mailserver must be aware of all mailinglist
subscriptions.

If neither sender signer nor recipient validator knows which mailinglists
the users use, they are vulnerable to spammers who pretend to be mailing
lists.  Neither SPF nor a hypothetical ADSP-like protocol that covers
List-ID: instead of From: can help here, since the controlling DNS records
will be on enemy territory.

A global whitelist is the obvious answer to that problem.  But since the
GW can't list forgeable mailing lists (since all a spammer needs is a
single forgeable mailing list to spam everyone who trusts the GW), it will
in practice never be able to cover all the real mailinglists people
actually use.  So a sender can only signal (in its ADSP) the validator to
apply the GW, if no user subscribes to an untrusted list and the admin
*knows this*.

Note: If we *accept* the onerous requirements of the GW -- that the sender
mailserver has to be informed of all subscriptions, and that some
cooperation from the listservers is required, I can see better solutions
than the GW.

But I still think it best to drop the costs on the receiver side with
except-mlist.