In fact, the DKIM verification is checking
'dev-return-20369-2380189206=mailto:[email protected]'. Therefore, if
a DKIM signature is added on every apache.org email, it should pass the
verification.
However, now the original DKIM header was appended, resulting in a invalid DKIM
signature.
Here is the header I received:
```
Received: from mxout1-he-de.apache.org (mxout1-he-de.apache.org [95.216.194.37])
by newxmmxsza65-0.qq.com (NewMX) with SMTP id 3CF17A04
for <[email protected]>; Sun, 19 Apr 2026 08:15:15 +0800
Sender: [email protected]
Authentication-Results: mx.qq.com; spf=pass(95.216.194.37) smtp.mailfrom=<dev-
[email protected]>; dkim=fail(Bad
signatur
e) header.d=christopherschultz.net; dmarc=fail(p=NONE sp=NONE pct=100)
heade
r.from=christopherschultz.net
...
...
...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=christopherschultz.net; s=google; t=1776557699; x=1777162499;
darn=community.apache.org;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:to:subject:user-agent:mime-version:date:message-id:from
:to:cc:subject:date:message-id:reply-to;
bh=<REDACTED>
```
On 2026/04/19 23:23:30 Bill Cole wrote:
> On 2026-04-18 at 20:14:58 UTC-0400 (Sat, 18 Apr 2026 20:14:58 -0400)
> Christopher Schultz <[email protected]>
> is rumored to have said:
>
> > Bill,
> >
> > On 4/18/26 9:56 AM, Bill Cole wrote:
> >> On 2026-04-17 at 16:21:27 UTC-0400 (Fri, 17 Apr 2026 16:21:27 -0400)
> >> Christopher Schultz <[email protected]>
> >> is rumored to have said:
> >>
> >>> Hello,
> >>>
> >>> It's odd anyone is blocking messages. apache.org does not have a
> >>> DMARC record, and so anything your email service is blocking is
> >>> non-standard.
> >>
> >> Not relevant.
> >>
> >> As you say, there is no DMARC record for apache.org. That means that
> >> a site which demands DMARC compliance cannot use SPF to validate the
> >> message, because the envelope sender address (a.k.a. Return-Path or
> >> RFC5321.MailFrom) has no record.
> >
> > I'm saying that this is unfair practice. Enforcing DMARC for a sending
> > domain which doesn't request it is punitive, and makes email literally
> > not work. That receiver shouldn't be doing whatever it is they are
> > doing, because it breaks email.
>
> Yes. Microsoft and the handful of other email behemoths have crafted
> policy over the past decade+ to make it hard to be anything but a
> behemoth mail provider. DMARC and DKIM are examples of that.
>
> Microsoft especially cannot be expected ever to be anything *other* than
> unfair. They are the source of this problem but they will never
> recognize that it even is a problem.
>
>
> >> That is salvageable iff the address in the From header
> >> ("RFC5322.From") is in a domain with a DMARC record. In the OP's
> >> case, that's qq.com, which has a 'quarantine' policy in their DMARC
> >> record. To validate that header for DMARC, a DKIM signature from
> >> qq.com needs to exist, and it does. However, the signature is broken
> >> by the fact that the ASF mail system adds a footer.
> > What does qq.com have anything to do with this?
>
> I used his messages as an example. They have a DKIM signature which was
> valid when it hit the Apache mail server, according to a header added by
> that server. It was done by qq.com and had the message not been
> modified, it would have passed DKIM checking at Microsoft. Because his
> From header had a qq.com address, that signature is the only thing that
> could have saved it.
>
> > He's not getting messages sent from *anyone* which come from
> > @[list].apache.org, not just his own.
>
> Correct, because *all* messages from *all* Apache mailing lists that add
> a footer will have exactly the same problem for Microsoft's free email
> addresses. Any original DKIM signatures are invalidated. I think it's
> possible to bypass that for MS365 domains on a source-specific basis but
> free accounts do not get much from MS.
>
> I can't suggest any solution to this in good faith other than: do not
> use Microsoft 's free email accounts, because they are garbage. More
> broadly, any email provider who gives away accounts for free with no
> reasonable limits cannot be trusted to serve users' interests.
>
> ASF is unlikely to do what would be needed to fix it from our end.
> Munging From lines is already done when an author's domain has a
> p=reject policy, it could be expanded to all subscribers but that would
> change how replies to list messages works in ways likely to upset
> existing users. Similarly, encapsulation would work but it is even more
> disruptive to the UX.
>
> --
> Bill Cole
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
