On Tue, Feb 09, 2016 at 12:08:45AM -0300, Raphaël wrote: > Just got a new reply to the ticket from Laposte.net: > > > Bonsoir > > Après vérification, les modifications des Mailing-list ne s'arrêtent > > pas à l'ajout d'un pied de page, le contrôle DKIM seul échoue > > forcément. > > La mise en place de DMARC ne résoud pas cette question. Il faut donc > > ajouter une spécification supplémentaire comme ARC. > == > > hi, > > mailing-list not only change footer. DKIM control alone, always fails > > DMARC does not get to the point. Another spec' is needed, like ARC > > It leads to various interpretations and conclusions.
You're still more lucky than I am. I only had evasive answers when not simply wrong. They finally stopped responding. My ticket gone nowhere. > But since they didn't added an example to their answer we're restricted > to hypothesis about what parts of the email they are annoyed to lose > control for (and to wait for this brand new draft RFC to punch some > holes in this current blacklist-him-by-default policy) My best guess is about the headers. Mailing lists often add headers, for example. Hence, signing all the headers or providing the size of the mail won't help. > It also proves that in the future, email providers will bring > mailing-list MTA in the validation-responsability/party. > Issue: I want to receive my email, even old-school unvalidated ones > Answer: ensure your ML implements ARC-validation > > > But one point against Gmail possibly following blindly DMARC is in the > "2.3. Utility" section of the ARC RFC: > > [ARC] information can assist in determining any local > > policy overrides to for violations of sender domain authentication > > policies. > > what seems to spell like: > > "Gmail is allowed to override Laposte.net "dmarc==fail => SPAM" using a > > "local policy override". > (although I didn't find a case for "local policy override" in DKIM RFC6376) There's no need to have a case about that, IMHO. Stating that local policy override is "allowed" by the specs means that DKIM doesn't aim at becoming the ultimate anti-spam rules everybody must follow. IOW, DKIM provides the HOW TO add a spam checking system to infras, not the WHAT YOU MUST DO with the mails on failures. IMHO, leaving this reponsability to the mail provider (or MDA implementations) is welcome and beyond the RFC. -- Nicolas Sebrecht _______________________________________________ OfflineIMAP-project mailing list: [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/offlineimap-project OfflineIMAP homepages: - https://github.com/OfflineIMAP - http://offlineimap.org
