<DKIM> Emails might go to GMail's SPAM folder
raphael.droz at gmail.com
Thu Feb 4 13:17:45 GMT 2016
Just got this reply from Laposte (going slightly off-topic for offlineimap) :
> Nous vous remercions pour votre conseil et allons étudier cette question
> 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
Also possible, it's probably not something most DKIM implementations
permit out-of-the-box (since is far, if not contrary, to the
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
- 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
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.
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 .
> > 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
> 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
> 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
More information about the OfflineIMAP-project