On 28 Apr 2019, at 2:19, Brielle Bruns wrote:
On 4/27/2019 11:19 PM, Bill Cole wrote:
Basically DKIM on my EXIM server is configured in the default way
which Debian’s config file sets it up once you provide it with the
necessary keys for signing. If it’s got something that they need
to fix to make it behave better, I’m all for getting that
together.
I guess that means that Exim on Debian has matched one of the most
famous "features" long touted for Exchange...
You should be able to modify the header selection for signing in the
Exim config and you should do so with thoughtfulness, rather than
simply accepting a packager's defaults.
I just went through the config, now that I'm back in front of a
laptop. Debian's setup is very basic, no fluff, and relies on the
defaults that are set by the developers.
EXIM is generating that list based on RFC 4871 (Section 5.5 lists
recommended).
1. 4871 was obsoleted by 6376, published September 2011.
2. Section 5.5 has text as well as a list of headers, making those
recommendations conditional. Your signatures violate the recommendations
of that section.
EXIM Doc - see dkim_sign_headers
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-dkim_and_spf.html
Its a default config that is in all EXIM setups unless explicitly
overriden otherwise.
Huh. Yup. That's an error.
Sure, it looks like it may be overzealous in its inclusion,
It also violates both the RFC they claim to be following AND the one
that it was obsoleted by almost 8 years ago.
but that's a change in behavior that could be suggested to the EXIM
developers to make it a bit more tolerant of what you are suggesting.
Indeed. As an Exim user, you may wish to take this up with the
developers or take ownership of your own configuration, as clearly they
don't understand the DKIM spec.
For a long time, I refused to insert DKIM headers on the grounds it
created situations like this.
It does not need to create situations like THIS. THIS is the result of
unwise choices by multiple parties, most significantly by Google.
A broader range of possible problems can be avoided by taking care to
create robust signatures rather than fragile ones.
But, you can thank certain large providers who make some hurdles if
you don't have DKIM signed messages.
This is still mostly limited to SMTP over IPv6, which I have not yet
needed to resort to.
DMARC elicits the same 'Fuck that' response from me. I implement
something with regards to it only because I need mail to go through.
I don't disagree. I do think it is most pragmatic to implement such
things in ways that break less rather than trying to make the flaws
stand out as chronic breakage.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
