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

[Ben Cooksley]

On Fri, Dec 4, 2015 at 11:38 PM, Rolf Eike Beer
<kde at opensource.sf-tec.de> wrote:
> Am 04.12.2015 11:08, schrieb Ben Cooksley:
>>
>> On Fri, Dec 4, 2015 at 9:01 AM, Rolf Eike Beer <kde at opensource.sf-tec.de>
>> wrote:
>
>
>>> 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
>
>
> Has KDE implemented this in the last few weeks? Before it was not.

We have not implemented SRS at this time, as it has not been necessary thus far.

>
>>> 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.
>
>
> Well, nice try. Out of 5 mail providers I checked 3 failed: AOL, GMX.de,
> Web.de.

That doesn't surprise me. Somehow it must work fine for AOL however,
as otherwise they would have issues corresponding with Yahoo users.

>
> Greetings,
>
> Eike

Regards,
Ben