Change to Mail Infrastructure - SPF and DKIM verification will now be enforced

[Ben Cooksley]

On Thu, Dec 3, 2015 at 11:54 PM, Jan Kundrát <jkt at kde.org> wrote:
> On Thursday, 3 December 2015 07:13:07 CET, Ben Cooksley wrote:
>>
>> I will be re-enabling DKIM validation in one week's time - which will
>> then break subscriptions to Debian mailing lists (as any email from
>> anyone who has enabled DKIM which hits their lists will not be
>> accepted by KDE email infrastructure)
>
>
> Ben, could you please briefly explain your idea about how a complying
> mailing list service should behave? Suppose that I have an installation of
> mlmmj which:
>
> - mangles the Subject header,
> - preserves the original From header,
> - maybe replaces a Reply-To with the ML's address,
> - introduces a bunch of specific List-* headers,
> - otherwsie doesn't manipulate the MIME tree or the message texts.
>
> What should I do to make sure that this service continues working once you
> flip the switch?
>
> I would like to have more information about what you mean by "DKIM
> validation" -- what specific steps are you going to introduce, and how is
> the end result going to react to a missing or invalid DKIM signatures.
>
> Also, quoting RFC 6376, section 6.3:
>
>   In general, modules that consume DKIM verification output SHOULD NOT
>   determine message acceptability based solely on a lack of any
>   signature or on an unverifiable signature; such rejection would cause
>   severe interoperability problems.  If an MTA does wish to reject such
>   messages during an SMTP session (for example, when communicating with
>   a peer who, by prior agreement, agrees to only send signed messages),
>   and a signature is missing or does not verify, the handling MTA
>   SHOULD use a 550/5.7.x reply code.
>
> That seems in line with what e.g. GMail is doing, only enforcing DKIM
> validation for notoriously faked domains like eBay and PayPal where the
> phishing potential is high.

To be specific I will be enabling the following line:

On-BadSignature         tempfail

within the configuration of OpenDKIM on our servers.

This means you have two choices in regards to your mailing lists:
1) Resign the emails with your own signature - which will make them
validate (this is what our infrastructure presently does)
2) Cease tampering with emails. In particular the body and subject
will always be signed and thus shouldn't be modified. Other headers
will depend on the mail sender, most are fairly sensible and thus
compatible with mailing lists such as Mailman.

Note that in the long run with DMARC looming you will need to switch
to #2 anyway, and keeping your current behaviour will likely lead to
mail from people who use Yahoo / AOL / etc ending up in the spam
folder with many mailing list members. I'll be starting a discussion
regarding taking this step on KDE systems at some point in the near
future (switching to DMARC compatible policies).

For more information, please see http://wiki.list.org/DEV/DMARC

>
> With kind regards,
> Jan

Regards,
Ben

>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/