On 29/04/2019 20:06, Graeme Fowler via Exim-dev wrote: > 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
Bzzt. Stop right there. The ML adds body content. This will invalidate the signature. The header thing, even if you do game it, will not help that. > 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 > -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
