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

[Rolf Eike Beer]

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.

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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20151203/b4c6e2d2/attachment.sig>