<DKIM> Emails might go to GMail's SPAM folder

[Raphaël]

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.

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)


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)



++




On Thu, Feb 04, 2016 at 10:17:45AM -0300, Raphaël wrote:
> Just got this reply from Laposte (going slightly off-topic for offlineimap) :
> 
> > Bonjour
> > Nous vous remercions pour votre conseil et allons étudier cette question
> > attentivement.
> > Nous étudions également le projet Authenticated Received Chain (ARC)
> > Référence : https://tools.ietf.org/html/draft-andersen-arc-00
> ==
> > hi, thanks, we'll have a look at this.
> > We're also studying ARC: https://tools.ietf.org/html/draft-andersen-arc-00
> 
> still about DMARC
> A receiving email server implementing DMARC is not given other choice
> than respecting the originating server DKIM policy.
> That's the point of DMARC.
> 
> Here, google respects a (somehow partial) RFC that laposte.net
> implements too strictly/blindly.
> 
> Accepting that a user could override DKIM decision is like disabling
> part of the DKIM-spec marking "From:" unvalidated (and permitting an
> attacker could tamper with the From: header, or at least this value of
> From: header).
> 
> Also possible, it's probably not something most DKIM implementations
> permit out-of-the-box (since is far, if not contrary, to the
> specifications).
> 
> But as you stated, maybe Gmail + Contact management integration maybe do
> it and take over DKIM results? 
> 
> Having the possibility for gmail to disable DKIM on an account-scope
> could maybe be technically practicable, but who would really do that?
> 
> Gmail SMTP and IMAP could be blamed for a number of points which
> already show how they care about user choice/freedom, citing only some
> of them:
> 
> - not allowing full use of their SMTP using a non-Gmail.com domain
> - messing-up with From: ("+" delimiter but many other legitimate and
>   useful values than account name)
> - forcefully omitting myself from the reception when sending in a new
>   thread to mailing-list I'm subscribed to
> - always copying to "Sent Mail/" emails sent through their SMTP
> - not implementing sieve filtering
> - webmail keeping large attachment by default in every reply, even for
>   mailing-list, thus putting an unecessary high cost for Gmail
>   non-webmail clients
> 
> 
> Pretty sure that DMARC policy, which could easily stated as "not our bug"
> is even further down their preoccupations.
> 
> All of that does not explain SPAM issues of laposte.net for individual
> email that are frequently experimented (blacklisting sometimes happened
> too), but nowadays email headers are quite verbose.
> 
> 
> best regards
> 
> 
> 
> On Tue, Feb 02, 2016 at 02:57:34AM +0100, Nicolas Sebrecht wrote:
> > On Mon, Feb 01, 2016 at 10:03:23PM -0300, Raphaël wrote:
> > 
> > > Even better, using the DKIM l=<N> field to limit signature scope to the
> > > first <N> bytes of the message's body [1].
> > > With N being the length of the body, it would pass DMarc test since
> > > mailing-list robots usually only append message.
> > > [and an attacker would be given append-only modification permissions]
> > 
> > I'll contact the laposte.net support to get all those relevant points
> > improved.
> > 
> > Where the spam policy hurts is:
> > 
> > - mailing list is not the glitch. At least, not the only one. Mails sent
> >   directly are marked as spam, too.
> > 
> > - I'm not the only one (by far) to be concerned by this issue. Something
> >   with DKIM is clearly failing. And DKIM is a both sides agreement. I'm
> >   blaming Google not only for not having this issue solved but also for
> >   not responding to users on their own forum about this exact same issue.
> >   There are public reports about that since 2013.
> > 
> > - You say that individually marking mails as non-spam is unlikely to
> >   work. If I didn't have positive reports from users who tried, I would
> >   think the same. Anyway, I fully agree with you that it's not a
> >   satisfying way to solve this. And I'm blaming Google to not allow
> >   their users to decide what is good for them (e.g. configure whether
> >   they want or not DKIM tests for an address or a domain). "Unlikely to
> >   work" means not "really acceptable" in this case: they are missing the
> >   point.
> > 
> > 
> > As I said, war against spam is hard. But IMHO, putting users in
> > tricky/impossible situation is the worse thing to do.
> > 
> > I know I'm strong, especially in my blog post, so I understand this
> > might hurt some people.  But I'm sure you're well aware about Google's
> > marketing.  They pretend solving real life problems with great tools and
> > engineering superiority, isn't it? ,-p
> > 
> 

-- 
GPG id: 0xF41572CEBD4218F4