On 29/04/2019 20:33, Brielle Bruns via Exim-dev wrote: > Heya, original cause of the havoc on mailop here! > > I'll try and answer whatever questions I can. See below. > > > On 2019-04-29 19:06, Graeme Fowler wrote:> 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.
4.87 introduced support for oversigning. > Version: 4.92-2~bpo9+1 > > My configuration files are ancient. IIRC, I originally built them from > the debian config back around 2005 or 2006 (We've actually been using > exim since 2003). They got updated over the years as needed and include > a bunch of special stuff that is integrated with my DNSbl work. > > So, the DKIM section is based on what I found in Debian's config. Under > the remote_smtp transport, I have the following: > > dkim_domain = DKIM_DOMAIN > dkim_selector = DKIM_SELECTOR > dkim_private_key = DKIM_PRIVATE_KEY > dkim_canon = DKIM_CANON You'll get the default headers signed, then. That includes signing the lack-of-presence of a header in the set. However: it's irrelevant. The ML adding a header making the signature bad does not matter. The ML also appends to the body... making your signature bad. That's what signatures are for (I'm sure you know this, just wanting to be clear in case...) So. DKIM signatures do not survive transmission through a ML. (Sometime phrased as "DKIM breaks mailinglists"). The DKIM RFCs say "do not treat a lack of verifiable DKIM signature as cause for rejecting a message". Google is ignoring that, and the brou-ha-ha is not really, IMHO, Exim's problem. It's a 800Kg gorilla problem. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
