Re: [exim-dev] Mailop list: exim and google fighting over DK…

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Graeme Fowler
Data:  
Para: exim-dev
Asunto: Re: [exim-dev] Mailop list: exim and google fighting over DKIM
On 29 Apr 2019, at 19:26, Andrew C Aitchison via Exim-dev <exim-dev@???> wrote:
> I will do so, either here or in that bug, when I can do so without causing more heat.


The gist of the discussion (I’m a mailop subscriber) is manyfold:

1. Google accept messages over IPv6 but require stricter verification over IPv6 than IPv4
2. mailop.org has no SPF record
3. mailop.org can deliver to Google over IPv6
4. Signed messages inbound to mailop.org (and other lists!) from Debian-derived and other setups using the default macro defined in pdkim.h can have headers added which have been declared signed when they’re not present*
5. Adding them invalidates the signature, and if the MLM software doesn’t remove or re-sign the message, that can be problematic if a receiving system is taking extra care with respect to verification
6. It appears Google will reject messages that combine elements 1 thru 5

* this is the bit I’m confused by; I have a large historical pile of messages to lists from me and I can’t see a signature with those headers included despite me using the defaults for a long period.

RFC4871 stated that a suggested list of headers SHOULD be signed, if existing.
RFC6376 dropped the SHOULD and provided an example of what constitutes the “core” of a message.

So *either* the Debian-derived configuration (of which the original poster mentioned they were using unaltered for DKIM purposes, inheriting defaults) does something different to what is expected by defaukt, or Exim’s behaviour changed somewhere after 4.86/4.87 (still trying to pinpoint that) but I can’t see or replicate the issue.

Puzzled, perplexed… and given that this has only just been raised, I’m even more puzzled by it. There must be receivers out there who have insanely strict validation policies who would have seen this before!

Graeme