On 29 Apr 2019, at 19:26, Andrew C Aitchison via Exim-dev <[email protected]> 
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
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Reply via email to