Community
Participate
Working Groups
Bug 541216 and Bug 522316 made lots of progress on fixing this type of issue. Thanks for all the effort. However this morning I am still seeing DMARC failures, so I report them here in the hope that it is useful to try and resolve them. Today's one was from @st.com. This is the header, let me know if you want more: Authentication-Results: mx.google.com; arc=fail (signature failed); spf=pass (google.com: domain of srs0=9wyv=hy=eclipse.org=cdt-dev-bounces@bounce2.pobox.com designates 173.228.157.41 as permitted sender) smtp.mailfrom="SRS0=9WYv=HY=eclipse.org=cdt-dev-bounces@bounce2.pobox.com"; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=st.com
Sorry - I missed a line from the header in Comment 0: Received-SPF: pass (google.com: domain of srs0=9wyv=hy=eclipse.org=cdt-dev-bounces@bounce2.pobox.com designates 173.228.157.41 as permitted sender) client-ip=173.228.157.41; Authentication-Results: mx.google.com; arc=fail (signature failed); spf=pass (google.com: domain of srs0=9wyv=hy=eclipse.org=cdt-dev-bounces@bounce2.pobox.com designates 173.228.157.41 as permitted sender) smtp.mailfrom="SRS0=9WYv=HY=eclipse.org=cdt-dev-bounces@bounce2.pobox.com"; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=st.com FWIW an email from ST directly to me passes DMARC: Received-SPF: pass (google.com: domain of srs0=r03d=hy=st.com=torbjorn.svensson@bounce2.pobox.com designates 64.147.108.51 as permitted sender) client-ip=64.147.108.51; Authentication-Results: mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=xRmegnbT; arc=pass (i=2 spf=pass spfdomain=st.com dkim=pass dkdomain=st.com dmarc=pass fromdomain=st.com); spf=pass (google.com: domain of srs0=r03d=hy=st.com=torbjorn.svensson@bounce2.pobox.com designates 64.147.108.51 as permitted sender)
Sigh. I'm going to use cdt-dev as a guinea pig, and have set dmarc_moderation_action to 'munge' for domains that publish a dmarc policy of reject/quarantine. If that makes things better, I'll roll out the change to all lists. -M.
Torbjörn, can you send an email to cdt-dev when you can? Thanks.
Matt, thanks for your help!
(In reply to Jonah Graham from comment #3) > Torbjörn, can you send an email to cdt-dev when you can? Thanks. Mail sent and this time I also revived it. Not sure about the headers though...
(In reply to Eclipse Webmaster from comment #2) > If that makes things better, I'll roll out the change to all lists. It is better - gmail does not mark it as spam, still fails DMARC though (I have no idea if that is expected or not): Received-SPF: pass (google.com: domain of srs0=xp3k=h2=eclipse.org=cdt-dev-bounces@bounce2.pobox.com designates 173.228.157.42 as permitted sender) client-ip=173.228.157.42; Authentication-Results: mx.google.com; arc=fail (signature failed); spf=pass (google.com: domain of srs0=xp3k=h2=eclipse.org=cdt-dev-bounces@bounce2.pobox.com designates 173.228.157.42 as permitted sender) smtp.mailfrom="SRS0=Xp3K=H2=eclipse.org=cdt-dev-bounces@bounce2.pobox.com"; dmarc=fail (p=QUARANTINE sp=REJECT dis=NONE) header.from=eclipse.org
Can you email webmaster the entire header trace? -M.
(In reply to Eclipse Webmaster from comment #7) > Can you email webmaster the entire header trace? > > -M. Sent, subject "full emails for Bug 571408"
Having been through both header traces I think that the DMARC failure is to be expected. When the from: is @st.com the mail flow is: st.com->microsoft.com->eclipse.org->pobox.com->gmail Which looks pretty suspicious. But if we 'munge' the from: the chain looks more like: eclipse.org->pobox.com->gmail Gmail is probably less likely to interpret that short chain as spam. So the step through pobox.com should fail DMARC checking every time for either mail flow, since it's acting as a relay so it's not the 'source' domain. @Jonah do you see that same DMARC failure for other messages(not just those passing through eclipse.org)? -M.
Emails from st.com directly to my inbox are passing DMARC - same source address and same @kichwacoders.com address. An example of which is Comment 1, second part. I'll send the whole email to webmaster@ in a moment.
Well after looking at some more traces provided by Jonah it's still unclear to me why this is happening. I'm hoping that the next DMARC report from google might provide some insight, but they are pretty sparse so it's a bit of a long shot. -M.
I've been through the DMARC reports(for the time period in question), and all I see is the occasional DKIM/SPF failure. But there isn't enough information for me to determine if these were messages sent directly(bugzilla) or indirectly(mailing list). So for right now we may have to live with the occasional DMARC failure. I have turned on the same dmarc munge option for another list, so if more people report issues receiving mail on other lists, I'll roll it out globally. -M.
@Matt - it looks like you changed the From address for problematic emails to be "Torbjorn SVENSSON via cdt-dev <cdt-dev@eclipse.org>" and have rolled out the dmarc munge option on other lists too. This seems like a good step forward. The emails are still arc=fail, but are not being marked by gmail as spam.
(In reply to Jonah Graham from comment #13) > and have rolled out the dmarc munge option on other lists too. Right I forgot to mention that. Well at least no-one has complained that it's broken things :) > The emails are still arc=fail, but are not being marked by gmail as spam. I'll live with this for now, as long as you're getting the messages in your inbox. -M.
The last Eclipse Foundation Community Newsletter was categorised as SPAM because of a DMARC failure.
@sap.com implements strict DMARC policy. Mails sent from @sap.com to Eclipse mailing lists will not reach anyone else on the mailing list with an @sap.com address, due to DMARC failure. This is because the "FROM" header doesn’t match the "MAIL FROM" header: Example: MAIL FROM: eclipse-ide-wg-steering-bounces@eclipse.org FROM: someone@sap.com. Related: https://serverfault.com/a/678335 Is there anything that can be done on Eclipse mailing list side to get this working?
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/567.
