This thread has been covered in depth for a while now, but I noticed something noteworthy.
On Monday, 6 April 2020 19:13:06 BST Stefan Schmiedl wrote:
> "Michael Orlitzky" <m...@gentoo.org>, 06.04.2020, 19:35:
> > On 4/6/20 1:32 PM, J. Roeleveld wrote:
> >> The messages were missing due to the MX being unavailable for a short
> >> period. Retries were not attempted as I would have received them.
> >>
> >> The spam filter is configured with certain mailing lists whitelisted.
> >
> > Here is proof that the Gentoo list server retries after ~8 minutes:
> >
> > Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT
> > from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable;
> > from=<gentoo-announce+bounces-2524-michael=orlitzky....@lists.gentoo.org>,
> > to=<mich...@orlitzky.com>, proto=ESMTP, helo=<lists.gentoo.org>
> >
> > Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass
> > (mailfrom) identity=mailfrom; client-ip=208.92.234.80;
> > helo=lists.gentoo.org; envelope-from
> > =gentoo-announce+bounces-2524-michael=orlitzky....@lists.gentoo.org;
> > receiver=<UNKNOWN>
> >
> > I'm not saying you're lying about what happened, but that the conclusion
> > you're drawing from it is premature. The Gentoo list server (and every
> > other real MTA) retries deliveries. If you lost a message, I'd bet
> > that's not the reason why.
>
> And here's an example for J. Roeleveld's observed missed original
> messages:
>
> A few days ago I sent a message to this list. As usual, I received
> a bunch of DMARC reports from mailservers rejecting the messages.
>
> > From: "Seznam.cz" <forensicdm...@seznam.cz>
> > This is a spf/dkim authentication-failure report for an email message
> > received>
> > from IP 208.92.234.80 on Sun, 05 Apr 2020 22:14:23 +0200.
> >
> > The message below did not meet the sending domain's dmarc policy.
The reason your message was *rejected*, rather than failed to be delivered/
gone missing, was because there is a DKIM failure in its headers. This is not
the non-delivery failure Joost was talking about when an MX server has gone
offline.
> The headers of that rejected message start with
>
> > Received: from lists.gentoo.org (unknown [208.92.234.80])
> >
> > by email-smtpd3.ng.seznam.cz (Seznam SMTPD 1.3.108) with ESMTP;
> > Sun, 05 Apr 2020 22:14:22 +0200 (CEST)
>
> This means that folks @seznam.cz (among others) will not get to see
> this message unless somebody replies to it from a domain that uses
> a less restrictive combination of SPF, DKIM and DMARC rules.
I would think the @seznam.cz recipient server obliges by following the DMARC
policy published, but ... the tag "p=none" in _dmarc.xss.de TXT means it
should neither reject, nor quarantine the message. :-/
This is what I see here in the headers delivered by Stephan via the gentoo-
user M/L:
Authentication-Results: <my_Vhost_server>;
dkim=fail header.d=xss.de; <== DKIM checks failed ==
spf=pass (sender IP is 208.92.234.80)
[snip ...]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xss.de;
s=s1;
h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-
To:Subject:To:Message-ID:From:Date:Sender:Reply-To:Cc:Content-ID:Content-
Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-
Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-
Owner:List-Archive;
bh=IcmyWppZGnE0ObrMblHXHftN8IgNTO770eJL89ETQwQ=;
b=g+t6Zx2l9CbrtDTrLtTlyRMSPvuW4LQZ2s0aBdpPEOjp+jp7IutK42gCOTzgq/BH5Lj+/
TLm3dD7ctngYCiMmPlMQlevvDFteUSgueZ 7vKRd87NpPM9O0G9rd+xT84em298YzVm0GAIBSv/
4hb2StCOaC5TcDkKrtOw1vAc5i30=;
I've split the DKIM header above to illustrate a point. Assuming the digital
signatures are correct, the only thing I noticed being different from other
DKIM headers which do not fail, is the sequence of the various DKIM tags
above. I don't know if this is important - the DKIM RFC needs reading more
than once to understand it - but here it goes:
In other messages the 'bh=' hash is before the 'h=' string. The sequence of
tags is:
bh=.....;
h=......;
b=.......
In Stefan's message the sequence is different:
h=......;
bh=.....;
b=.......
Perhaps the order in which recipients servers parse the headers cause the DKIM
check to fail?
signature.asc
Description: This is a digitally signed message part.
