On Sat, 17 Oct 2009, hector wrote: > I don't quite understand your suggestion. Who is creating this > DKIM=except-mail ADSP++ record? The Author Domain or the Mailing list > 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. ---- Michael Deutschmann <[email protected]> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
