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

Thomas Friedrichsmeier thomas.friedrichsmeier at
Thu Dec 10 19:36:25 GMT 2015


On Wed, 09 Dec 2015 11:51:43 +0100
Jan Kundrát <jkt at> wrote:
> There is active work within the DMARC WG, with first drafts being
> published only *two months ago* [1]. My suggestion for everybody who
> doesn't have time to follow this process is to sit back, relax, and
> watch the IETF come up with a solution, and *then* start implementing
> their suggestions.

I believe this is going partially off-topic, but as I have recently
(and entirely unrelatedly) run into this issue as a list admin, let me
just tell you:

The problem is real today.

You may not be noticing it as a list-admin, yet, if you don't have a
high enough rate of yahoo-users posting to the list, but if you have
*any* yahoo-users posting to your list, then your mailing list is
already broken for a share of your subscribers, today. For
rkward-devel, as I have found out the hard way, the share of affected
subscribers was slightly above 10%.

The solution you are referring to, above, is not real today. But
workarounds exist.


> You're saying that it's easy to configure a ML to stop breaking DMARC 
> signatures. I disagree. Here's my reasoning:
> 1) Full compliance with DMARC requires a substantial reduction of
> features which distinguish mailing lists from dumb forwarders. This
> includes:
> - the Reply-To munging,
> - adding a [prefix] to subject headers,
> - automatic signatures,
> - in case of overly strict DKIM setup, the various List-* headers
> which are actually mandated by RFCs to be automatically added.

Yes, I am not really happy with removing these features either (not
counting the fourth, which *is* a rather theoretical problem at this
point of time, as far as I am aware). And I do hope to recover these
features, once a better solution comes into existence. But seriously,
the choice between clinging to these features and excluding 10% of
current subscribers, 10+x% of future subscribers was easy to me.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the kde-core-devel mailing list