Mail Address – CentOS Mail List
I do not think that I have any influence over this issue, other than to change email providers and that, for various security reasons, is not going to happen. Nor, for similar reasons, is it feasible for me to have a second email address just for the CentOS mailing list since I would be unable to use it from my workplace. I do understand your frustration and I am appreciative of the effort that you took to contact me about it. I wish I had some solution for you that was available to me.
The reason that my emails from the CentOS list are marked as spam by Google is that our domain employs DKIM and SPF for outgoing SMTP traffic. The CentOS
mailing list manager is the stock Mailman package provided with CentOS. That version mangles the originator’s mail headers and body, thus invalidating the DKIM signature. It then sends the message out as originating under the original sender’s domain but from an unauthorised SMTP server address, thus triggering the SPF failure.
The reasons that this has become an issue is that Google, Yahoo, AOL and I
believe Microsoft, began enforcing DMARC to varying degrees beginning last April. Google at least forwards my messages on with a warning. I believe that Yahoo simply blocks all my CentOS list traffic.
We have set SPF to a policy of ~all, which is a soft failure. That permits delivery, providing the recipient MX agrees as is the case with Google. It is not permissible for us to authorise an alien IP address as a legitimate source of our SMTP traffic so we cannot eliminate the SPF failure. We can do nothing about the DKIM invalidation since it is Mailman that is changing the headers and appending text to the body after it is signed by our servers.
There is a patch for Mailman to resolve the SPF issue and the DKIM issue with respect to headers, but it has not made it into the RedHat distribution. The body mangling issue is in the hands of the mailing list owner.
I have raised an issue on this:
https://bugzilla.redhat.com/show_bug.cgi?id95359
I also tried building the new Mailman package for CentOS-6. The problem is that the Mailman project does not follow the FHS. Restructuring the source files to properly package on CentOS is simply beyond my limited skills and time. I suspect that the effort involved is why the issue has not made much progress inside RH either.
I am replying to the list as well so that anyone else having the same problem with my traffic is apprised of the cause.
With regrets,
20 thoughts on - Mail Address – CentOS Mail List
If I understand the problem correctly your emails sent out by the CentOS
mailing list (using Mailman) are considered by Google et al to be spam. The fundamental reason you believe is be your site’s usage of DKIM.
Why can’t your site get a cheap VPS anywhere in the world and route outgoing emails, without DKIM, through the VPS ? Cost in EU is less than GBP 80 per annum (circa EUR 96 p.a.) It is easy to achieve using Exim.
But logically that will defeat the whole reason of using DKIM, won’t it?
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Yes, but when the purpose of DKIM is to break lists that forward on your behalf, that is a good thing. But an even easier solution is to use a free email service like gmail/yahoo/hotmail for your mail list activity.
The fundamental reason is because Mailman is rewriting the headers in an incompatible way. It is not his site’s usage of DKIM. This is a known issue with Mailman. (I used to have a good link explaining the issue, but can’t find it now; if I find it later I’ll post it.)
It’d be a lot easier just to drop DKIM, but that’s a bit pointless.
–keith
But …. is not his problem that when he sends an email to this mailing list, Google – when it gets its metaphorical hands on the output from this mailing list, whilst delivering it to some recipients – declares his email as spam ?
Everyone knows that when dealing with large organisations (especially North American ones and their global imitators), one can waste enormous amounts to time pleading with them to do simple and reasonable things properly.
He needs a solution. I proposed what I thought was a relatively quick and cheap solution.
Another solution is for the mailing list to delete all previous headers on receipt of incoming emails – perhaps that might work ?
So we have a 20-year old piece of technology (“mailman”) and a modern proposal (“DKIM”)… and somehow it’s mailman’s fault. Uh huh.
Note; it’s not just mailman that has problems, it’s _any_ mail forwarder. Going back 27 years to my first Unix account, I could create a file called
“.forward” that would forward my mail to another address. This is BROKEN
by DKIM.
Basically DKIM is incompatible with how internet email works.
But here’s the thing… I think DKIM has a potential future; we need to
_change_ how the internet works. So mailman will need to be rewritten;
mail forwarders will need to change. And so on.
I use DKIM on my domain but I specifically set it to “fail safe” (deliver it anyway) because I _know_ the internet, today, isn’t compatible. I get email reports so I can see if spammers _are_ sending as me.
The problem is with domains like yahoo.com who have a “fail deny”
policy. Any yahoo.com sender gets so much mail rejected that many mail lists auto-block yahoo senders these days.
The problem, ultimately, is with senders with a “reject” policy published. DKIM is not compatible with internet email today, and so mail from those senders _will_ be rejected.
Any constructive suggestion how to deal with e-mail of people who moved on? Forwarding is a a solution. What is suggested instead (in the realm of DKIM)?
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
Mailman is by my reckoning only about 15 years old, and DKIM has been around for about a decade. So I’m not really convinced by your argument here.
Plus, it’s not like the Mailman folks themselves are blaming DKIM. Here’s a page they wrote up.
http://wiki.list.org/display/DEV/DKIM
“Make no mistake though, DKIM cannot be ignored”
I haven’t looked very hard, but I haven’t found anything authoritative on Mailman vs. DKIM more recent than 2012 (which itself means they’ve been thinking about it for a long time; the wiki doc talks about another document written in 2009).
Well, someone’s gotta be first, because there’s no way we’ll get everyone agree to switch over on a given date. If Yahoo and Google are doing it they’re forcing the issue sooner rather than later. I’m not sure that’s a bad thing.
–keith
Isn’t this a philosophical question about who the author really is?
That is, does it belong to the original sender or is is something made up by the list that deserves to be signed as though they made it up?
Mailman already has been updated to ameliorate the situation. The patches are applied to the main trunk and the version has been updated. However, CentOS
is, as we all know and love, a decidedly conservative collection of software. In my opinion it is unlikely that we will see any changes to Mailman’s behaviour in 6 and possibly not until 8, although I think it probable that Mailman will be updated for this in 7 at some point.
For the nonce we set SPF policy to softfail and our DKIM policy is quarantine. Thus Google is doing the right thing by flagging my messages through CentOS.org as suspect but forwarding them on for delivery nonetheless. So long as the MX treatment of my messages is consistent and still permits delivery then Google places the disposition in the hands of the recipient.
Yahoo on the other hand does not. If there is an SPF failure then the messages are discarded. I am not sure what effect, if any, DKIM has on Yahoo.
To handle Yahoo subscribers to any ML that we run internally we arbitrarily subscribe those addresses to the digest versions.
If you want to read intelligent people throwing tantrums search at the IETF
mailing list archives for DKIM, DMARC and SPF; and read; and weep.
The problem that DMARC, DKIM, and SPF seek to solve is intractable. So long as the cost of email is borne by the recipients and there are no sensible restrictions of the volume of traffic a single source can generate then unwanted email is going to be created and transmitted. All of this jiggery-pokery respecting message signing and sender policy frameworks just shows how intractable it is.
DMARC is. . ., well I do not know what benefit one obtains by discovering that some IP address on mainland China is again purporting to belong to our domain and sending out email. What news! Next someone will tell me that not everything on the Internet is factual!!
In our case we believe a more pressing problem has to do with authenticated connections between mail servers and the whole sorry mess that is CA driven PKI. The certs and signatures for PKI have to be moved into DNS RRs so that the current system of privately owned CAs just goes away. It is totally flawed as it assumes, and requires, a strict hierarchy for identification. That vision simply does not describe the Internet. Anything that will work for identification on the Internet ultimately will have to resemble DNS.
For SMTP the mail server that connects should always use STARTTLS and have its IP address reverse checked against its A RR to locate an associated RR
something like SSHFP. That then is used to verify its identity and the validity of its certificate. No match no traffic. That will not solve SPAM
and UCEM but that is not the point. It will guarantee that our traffic is moving along verifiable routes and that, for us, is very important.
That also, as a side effect, would hide email headers (meta data) on all point to point connections. Our observations with respect to our own servers are that for correspondents running their own mail servers all, or virtually all, of those connections presently are point to point.
As for the poor sots that have handed over their email service management to Google and the the like. Well those people have nothing to hide. Which is a good thing for them. Because everything they transmit is open to inspection by third parties, trusted or not. And kept forever, whether they wish it or not.
James, thanks a lot for nice write-up!
As far as google and the likes are concerned… even though I’m not using any of them, my messages are too filed there through the ones who use them
(even when it is not straightforward, e.g. when they forward to their … account). Sigh.
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
If Bob already has a Gmail filter set up to tag CentOS list mail, it’s simple to modify that filter to “do not mark as spam”.
That’s a workaround that Bob can control and use to alleviate the situation until the “fixed” Mailman packages reach maturity.
Well, yeah… If I wanted to keep secrets, I wouldn’t be sending them over the internet at all. You don’t really trust your software or other third parties that much, do you?
At least in theory, if you add a sender to your gmail contacts list it is supposed to try to avoid marking subsequent messages from that sender as spam.
over the internet at all. You don’t really trust your software or other third parties that much, do you?
Read my signature.
The point is that it is not what I trust. It is what my correspondents do with their mail irrespective of trust. And that is totally out of my control. Nonetheless, we must take whatever steps we can to protect whatever residual confidentiality there is.
Hmmm, gmail conveniently collapses previously-seen content into an ellipse so that didn’t jump out out me before.
I don’t get your point about gmail then. If you don’t expect internet email to be secure in any case then you won’t send secrets over it and it won’t matter who archives, forwards, or searches it. This is all pretty obvious for public mail lists anyway and there’s not that much point in trying to mix them with even business-level security. I
prefer to have a completely separate account for list use although some companies might be so restrictive as to not let you use even web access to it from work machines.
Indeed, e-mail is not a secure channel of communication (as everyone of us repeats for decades). That is because there are _bad_guys_ doing bad thing
(sniffing packets)… Now we come to the point that some company collects information. In general doing virtually the same thing. And we should feel no disrespect to that company, right? I feel it is unfair to the first category of guys (the bad ones sniffing network traffic).
Do you not have any problem with that? Because I do ;-(
But alas, it is the majority that rules (sort of “democracy” as opposed to
“constitutional republic”).
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
I don’t – for a couple of reasons. First, google doesn’t charge for the service so I’ll use it for what it is: a good place to collaborate, and ignore the fact that it might be a bad place to keep secrets. And public mailing lists are pretty clearly about open collaboration. Second, your, and the recipient’s ISPs are going to be as bad or worse about allowing government spying. They don’t really have any choice about that if they want to exist so I don’t have a real problem with that either, except that they charge us all extra for the capability.
Ummm, at this point is it much more a matter of corporate ownership than anything else. If you don’t like the government, you have to buy a better one.
No, I meant it with respect to google, “metaforically speaking”, not meaning actual government of one sort of another. So, you are in the majority as far as google or other “free” services are concerned, I
figure, and I’m not – in our internet “democracy” that is.
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++