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

[Ben Cooksley]

On Fri, Dec 4, 2015 at 9:01 AM, Rolf Eike Beer <kde at opensource.sf-tec.de> wrote:
> Am Donnerstag, 3. Dezember 2015, 11:54:43 schrieb Jan Kundrát:
>> 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?
>
> This is actually a flaw in those standards: they think that everyone you
> communicate with will comply. If you as a mailing list service do not then
> everyone that sends to your list will eventually get in trouble if you do not
> rewrite the message or resigns it.
>
> Think of SPF: I sent an email to a kde.org email address only some weeks ago.
> My domain sets a SPF policy. The KDE server accepts this (it's actually
> correct), and then sends the mail on (unaltered). Now the next server also
> checks SPF and will reject the mail, because the KDE server is not allowed to
> send mail for my domain. Now you have 2 ways out: either the KDE server
> rewrites the "mail from" header (what you will later find as Return-Path in the
> mail header), or the final destination says allows the user to say "hey, I use
> those kde.org server as a forwarder to me, so whatever SPF says, mails from
> that host are fine". Both ways work, both are fine, but both require some sort
> of action somewhere on the path.

Rewriting to workaround SPF restriction is also standardised - as a
mechanism known as SRS - see http://www.openspf.org/SRS

>
> That part is simple. For DKIM stuff get's more complicated because you
> sometimes _have_ to modify the body, e.g. when you need to base64- or qp-
> recode parts of the mail because the receiving mail server does not support
> 8bit-transfer (which is an issue by itself, but still sadly legal). So with
> DKIM you are actually screwed at this point. The only good way it is again to
> permit your users to ignore DKIM signatures from certain hosts (e.g. if you
> subscribe to a Debian list, then simply ignore DKIM for the Debian servers).
> Finding out those itself is not an easy task either.
>
> So all in all one can enable DKIM for list services, but for user accounts it
> should be opt-in with an easy way to whitelist certain hosts for relaying.
> Everything else is just asking for endless bounces.

Note that DKIM senders and receivers are usually running on modern
infrastructures, so 8bit transfer shouldn't be an issue.
For user to user transmission, there is no reason why mail bodies
would be modified.

As for user to list to user transmission, please see
http://wiki.list.org/DEV/DMARC for ways in which DKIM validity can be
retained or ensured with lists.

Whitelisting shouldn't be required...

Note that DMARC permits enforcement of the presence of DKIM signatures.

>
>> 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.
>
> No, this means that a mail should not be rejected if there is _no_ signature,
> or a malformed one. If a domain publishs that it does DKIM signing and mails
> are expected to be correctly signed, then rejecting on a invalid signature is
> actually fine (and the sole purpose of this RfC).
>
> Greetings,
>
> Eike

Cheers,
Ben