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

Valorie Zimmerman valorie.zimmerman at
Wed Dec 9 10:09:01 GMT 2015

Can we please lower the temperature on this discussion a bit?

On Wed, Dec 9, 2015 at 1:54 AM, Ben Cooksley <bcooksley at> wrote:
> On Wed, Dec 9, 2015 at 4:37 AM, Jan Kundrát <jkt at> wrote:
>> On Tuesday, 8 December 2015 16:09:43 CET, Nicolás Alvarez wrote:
>>> It is irrelevant what our personal preference about doing modifications to
>>> messages is (like the tag in the subject). The fact of life is that there
>>> *are* mail providers out there (like Yahoo) which are already enforcing
>>> DMARC and may reject messages with such DKIM-breaking modifications, and
>>> these mail providers won't change their config to accommodate us.
>> Nicely said. Yes, there are providers such as Yahoo, AOL, and nobody else :)
>> who decided to break a long-working infrastructure. The question is whether
>> we want to join this club.
> What you're basically saying is - you don't care about potential
> contributors who use these service providers.
> Lovely.
> I'm afraid that's unacceptable. A chunk of our users certainly do use
> them, and i'm sure we'd like them to be able to interact with our
> community.
>> Should we start enforcing the same rules that Yahoo is enforcing? (Ben
>> didn't say what SPF and DKIM rules he's planning to publish for,
>> btw.) Do we have many Yahoo/AOL users among our developers?
> The domain owner is actually the one that sets the policy under DMARC.
> All we'd be doing is following their wishes.
> I haven't said anything, because I don't plan to change our own
> policies at this time.
>> Should we start publishing rules which effectively instruct others to
>> discard all e-mails from once they go through a non-DMARC mailing
>> list?
>> Should we discard e-mails which are intended for our developers because they
>> went through a non-DMARC mailing list?
> From the server's point of view, these messages could also be
> forgeries, containing spam, phishing attacks, or otherwise attempting
> to misrepresent the sender.
> If the domain owner has stated the message should have a valid
> signature, we'd be right to follow what they've requested.
>> My answer to these two questions is "no" and "no", obviously. I don't know
>> how else to say this -- Debian is not exactly a small open source project,
>> and their sysadmins apparently haven't cared about DKIM so far. It's a
> DKIM has been around for an extremely long time.
> It means they've not worked on improving their email deliverability.
>> technology which requires Everybody Else™ to perform extra work and to
>> configure new services on the servers which host various mailing lists. Are
> Configuration of new services is not required, as noted in my earlier mail.
>> we seriously trying to push an unspecified number of third-party ML
>> providers to deploy DKIM because Ben decided that it's worth the effort?
> Nice to demonise me here.
> The mailing list hosts don't have to deploy DKIM. All they have to do
> is not break signatures on mails bearing a DKIM signature.
> Which, as I noted in my email is something that only requires a few
> toggles within the Mailman administration interface.
> (And, using the withlist tool can be changed on all lists on an entire
> server with relative ease). This is what Debian has chosen to do.
>> Seriously, the Internet just doesn't work this way. Even if Debian's
>> ifnrastructure is changed, there is still a number of mailing lists which
>> have worked well in the past years, and now they will stop working for
>> accounts.
>> Cheers,
>> Jan
> Regards,
> Ben

Ben isn't the only person wrestling with these issues. We're dealing
with it on a much smaller scale in Linuxchix. Anyone who runs lists is
having to deal with spam, malware, forgeries, phishing, and so forth.

While the tools to mitigate some of this are complicated, we will have
to make changes at some time. I suggest that we calmly pull together
and figure out how we can make KDE email and lists more secure, as
well as all of those lists with which we use our accounts.

We *can* do this, we need to do this, and Ben doesn't have time to do
all the work himself. So we need to do our part to help.


More information about the kde-core-devel mailing list