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

[Ben Cooksley]

On Wed, Dec 9, 2015 at 4:37 AM, Jan Kundrát  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 @kde.org,
> 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 @kde.org 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
> @kde.org accounts.
>
>
> Cheers,
> Jan

Regards,
Ben

>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

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

[Valorie Zimmerman]

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

On Wed, Dec 9, 2015 at 1:54 AM, Ben Cooksley  wrote:
> On Wed, Dec 9, 2015 at 4:37 AM, Jan Kundrát  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 @kde.org,
>> 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 @kde.org 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
>> @kde.org 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 KDE.org 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.

Valorie

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

[Ben Cooksley]

On Wed, Dec 9, 2015 at 5:00 AM, Jan Kundrát  wrote:
> On Friday, 4 December 2015 10:56:42 CET, Ben Cooksley wrote:
>>
>> To be specific I will be enabling the following line:
>>
>> On-BadSignature tempfail
>>
>> within the configuration of OpenDKIM on our servers.
>
>
> Thanks, but that's not a full answer. What is the proposed content of the
> following DNS records?
>
> 1) TXT, kde.org (for the final SPF policy)
> 2) TXT, _dmarc.kde.org (for *our* DMARC policy, which is an extremely
> important piece of missing information)
> 3) TXT, default._domainkey.kde.org (and others which you intend to use)

This whole thread is about INBOUND email - so it is a full answer.

Doesn't have anything to do with outbound, which is remaining unchanged.
None of those records will be changed from their current values (which
in the case of DMARC is nothing)

At some point in the future we may change them, but not at this time.

>
> Cheers,
> Jan

Regards,
Ben

>
>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

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

[Martin Graesslin]

On Wednesday, December 9, 2015 2:09:01 AM CET Valorie Zimmerman wrote:
> 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.

That's what I suggested in one of my mails. We need to tackle this as a 
coordinated project where we keep track on which mailing list got contacted, 
which one changed and so on. I think what some see as a huge problem here is 
that this can be a highly disruptive change to users of @kde.org addresses and 
that the current time frame is too short (Christmas, New Year, etc.).

We need to tackle it as a project and we need to accept that it might take 
half a year or year to ensure that it's not disruptive to our community. I 
don't like spam and forgery and what not and I'm full in support for what our 
sysadmins suggest, but it must not be disruptive. If I'm kicked out of one 
mailing list it will be disruptive to me and render my @kde.org address 
useless and by that harming KDE as an organization. That must not happen. 
Given that we need to tackle it as a coordinated project.

I'm sorry I won't be able to help on that before end of January due to 
personal reasons restricting my spare time.

Btw. this could be nice GCI tasks: contact a mailing list, keep track of it.

Cheers
Martin



signature.asc
Description: This is a digitally signed message part.

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

[Jan Kundrát]

I've taken the liberty to remove the ad-hominem which you used. I'm not 
happy with your approach to this discussion, but I'll try to stick with the 
technical points.


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. Asking 
one's user base to reach every list service administrator out there with a 
"fix your DKIM/DMARC" is not going to work. Deploying DMARC at this point 
in time, when substantial changes are still being worked on, doesn't look 
like a good idea, either. This is all that I'm saying.



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.


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.


2) Some domains might specify DMARC policies which prevent *any* 
distribution of their e-mails over mailing lists. The only solution for 
this problem is rewriting the RFC5322.From header to something like:


From: "Foo Bar via a KDE ML" 

This in turns leads to e-mails where one cannot reply to the original 
author anymore, etc etc etc.


In case someone is still following this thread, let me quote [2] John R. 
Levine, one of the Internet graybeards:



Mailing list apps can't "implement DMARC" other than by getting rid of every 
feature that makes lists more functional than simple forwarders. Given that we haven't 
done so for any of the previous FUSSPs that didn't contemplate mailing lists, because 
those features are useful to our users, it seems unlikely we'll do so now.

If receivers want to implement DMARC policy, they need to make their false 
alarm whitelist first. This appears to be a substantial, perhaps 
insurmountable, hurdle.


"FUSSP" is a "Final Ultimate Solution to the Spam Problem".

That entire thread is worth reading, btw.

Cheers,
Jan

[1] https://tools.ietf.org/html/draft-andersen-arc-00
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg87157.html

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

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

[Boudhayan Gupta]

Hi all,

I'm going recount a personal experience here. I have my own domain
(BaloneyGeek.com) and I use Google Apps for Business for my E-Mail.

A couple of months ago I shifted DNS providers and took the
opportunity to properly set up E-Mail verification and signing. Using
Google's documentation, I enabled SPF, and then tested. Then I enabled
DKIM and tested.

So far, everything was fine.

Then I enabled DMARC and all hell broke loose. Even though Google's
configuration checker gave me a green tick on DMARC configuration, I
couldn't send mail to any non Google-handled e-mail ID, without it
being sent to spam. I know this because I tested with one Windows Live
Mail (or whatever they call it these days) account and one Yahoo
account. Both of them had a history of receiving e-mails from me.

I would also get an XML file delivered to my inbox from every single
e-mail server that handled my mail, with stats of how many mails they
handled, how many passed auth, how many failed and how many were sent
to spam. Apart from the annoyance of receiving tens of these mails per
day, I noted that every single provider (other than Google) was
failing auth on all my mails and sending them to spam.

I dug around multiple docs (including RFC 7489, Google's docs, etc)
and couldn't find any configuration errors I'd made.

In they end I had to roll back DMARC (which took two days to propagate
across all DNS caches, btw), while keeping SPF and DKIM enabled.
Everything has been fine since then.

So here's my two cents - SPF **should** always be enabled, that's the
bare minimum you can do. DKIM enforces SPF using signing, so if you
guys can implement that well, awesome. But be very careful when
dealing with DMARC. From what I saw when I tried to set it up, no
e-mail provider other than Google knows what to do with it.

-- Boudhayan

Re: Why is C90 enforced in KDE?

[Michael Pyne]

On Sun, December 6, 2015 16:08:04 Antonio Rojas wrote:
> Hi,
>  Kipi-plugins fails to build with flex 2.6. This is due to the autogenerated
> code in libpanorama containing //-style comments, which are disallowed in
> C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect,
> since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What
> is the reason for this? And is there any way to force using C99?

I'm not sure offhand... it may be due to trying to support builds using MSVC 
on Windows (which has poor C99 or later support). On the other hand even MSVC 
supports //comments in C code.

I think there's some way to get CMake to add compiler flags for .c files in 
particular; another option is to have flex generate a .cpp file, assuming that 
the code being generated is safely in the common subset of C and C++.

Regards,
 - Michael Pyne

Re: Why is C90 enforced in KDE?

[Boudhayan Gupta]

On 10 December 2015 at 12:04, Boudewijn Rempt  wrote:
> I'm right now using msvc 2015 myself -- which gives other problems with
> other
> dependencies.

Microsoft now has clang (running on the Microsoft Code Generator as
well as LLVM) - maybe we could look into using that on Windows? It's
supposed to be an (optional, IIRC) part of VS2015 and will be
continually supported and updated.

So if we can kick out cl.exe support, that's one less compiler
frontend to support. Note that clang with Microsoft CodeGen is
theoretically pretty much the same as cl.exe (in both cases the AST is
converted to machine code by MSCG only), except that with clang we get
superior parser and C++11/14 and C90 support.

-- Boudhayan

Re: Why is C90 enforced in KDE?

[Boudewijn Rempt]

On Thu, 10 Dec 2015, Boudhayan Gupta wrote:


On 10 December 2015 at 12:04, Boudewijn Rempt  wrote:

I'm right now using msvc 2015 myself -- which gives other problems with
other
dependencies.


Microsoft now has clang (running on the Microsoft Code Generator as
well as LLVM) - maybe we could look into using that on Windows? It's
supposed to be an (optional, IIRC) part of VS2015 and will be
continually supported and updated.

So if we can kick out cl.exe support, that's one less compiler
frontend to support. Note that clang with Microsoft CodeGen is
theoretically pretty much the same as cl.exe (in both cases the AST is
converted to machine code by MSCG only), except that with clang we get
superior parser and C++11/14 and C90 support.


Well, it's more like "building boost with msvc 2015 doesn't add the compiler
version number to the dll names, which means that the cmake code that looks for
boost fails to find the dll's, even though they are there, because the name
pattern cmake is hard-coded for fails, so you need to manually rename the
dll's" or "msvc 2015 still insists on really small stacks, so g'mic's stack
based recursive parser, which needs 8mb of stack minimum, runs out of stack".

It's all those effing little things that add up and make building an application
with a few dozen dependencies a herculean task. And every dependency seems to
have _something_. In the Qt4 days, Qt didn't want to link to zlib.lib, it needed
libzlib.lib, for instance.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org