On Mon, 28 Oct 2019 at 09:19, sebb <sebbaz@xxxxxxxxx> wrote: > > On Sun, 27 Oct 2019 at 14:21, Richard > <lists-apache@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > Date: Sunday, October 27, 2019 12:17:36 +0000 > > > From: sebb <sebbaz@xxxxxxxxx> > > > > > >> On Sun, 27 Oct 2019 at 09:32, Richard > > >> <lists-apache@xxxxxxxxxxxxxxxxxxxxx> wrote: > > >> > > >> I agree, there are a range of reasons that a receiving host might > > >> reject a message. When you add in DMARC - because the headers > > >> aren't rewritten - the chances of rejects, and because of that > > >> that someone will get kicked off a list, increase dramatically (at > > >> least for those of us whose ESPs enforce DMARC). > > >> > > >> Indeed, the headers on that message don't include any DMARC > > >> references, and that's the problem. The sender's host/domain > > >> (helios.jpl.nasa.gov) has DMARC set to "p=reject": > > >> > > >> dig txt _dmarc.helios.jpl.nasa.gov > > >> > > >> ;; ANSWER SECTION: > > >> _dmarc.helios.jpl.nasa.gov. 569 IN TXT "v=DMARC1; p=reject; > > >> > > >> which means that messages that purport to be from that host/domain > > >> can't be seen to be being sent from "just anywhere". Because the > > >> sender's message was (re-)sent from an "apache.org" domain/IP it > > >> failed DMARC which got it rejected from DMARC-enforcing ESPs. > > >> > > >> For anyone using a DMARC-enforcing ESP (of which gmail is one), > > >> it's fairly routine to get kicked off (or threatened with removal > > >> from) lists that don't do the necessary rewriting -- which seems > > >> to include most (all?) of the "apache.org" hosted lists. > > > > > > I see, thanks for the clear explanation. > > > > > > I've just checked the DMARC filter, and whilst it removes the DKIM > > > signature, it is also supposed to munge the From line to append > > > '.INVALID'. > > > > > > This does not appear to have happened. > > > > > > The script assumes that the DKIM header comes before the From line; > > > maybe that was not the case here. > > > > > > I assume the From rewriting is intended to disable the DMARC check > > > at the receiving end. > > > > > > There are several examples of the From munging on the list, e.g. > > > > > > http://mail-archives.apache.org/mod_mbox/httpd-users/201910.mbox/%3 > > > c158c6a04-ef01-2fce-bf33-aabc673bbae1@xxxxxxxxxxxxxxxxxxxx%3e > > > > > > > The '.INVALID' "From" rewrite works, at least with my DMARC-enforcing > > ESP, when it's invoked. I got the message you referenced above, as > > well as about 20 others, from this list over the course of the last > > ~4 months that were munged that way. > > Good to know. > > > The filter is missing enough, however, that I have been threatened > > with expulsion from this list at least once over that same period > > (plus 5 times from another ".apache.org" hosted one). > > It does look like the filter does not always work correctly. > > It would be useful to know which messages and lists are involved. > Note that about half apache.org lists use the dmarc filter; the others do not. > > I have raised https://issues.apache.org/jira/browse/INFRA-19347. > > If you could add any relevant details to the issue, that would be great. FTR: the email from helios.jpl.nasa.gov does not have an Authentication-Results: header in it. AFAICT all the other emails with DKIM-Sigs or munged From: headers (i.e. they originally had a DKIM header) have an Authentication-Results header from one of the spamd MTAs. Since the email was definitely seen by spamd3-us-west.apache.org this is a bit odd. Also the X-Spam-Status header does not mention any DKIM tests. This suggests to me that the original email probably did not have a DKIM signature in it. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|