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

Rolf Eike Beer kde at
Fri Dec 4 10:38:58 GMT 2015

Am 04.12.2015 11:08, schrieb Ben Cooksley:
> On Fri, Dec 4, 2015 at 9:01 AM, Rolf Eike Beer 
> <kde at> wrote:

>> Think of SPF: I sent an email to a 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 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

Has KDE implemented this in the last few weeks? Before it was not.

>> 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,,



More information about the kde-core-devel mailing list