On 2026-04-19 at 21:16:56 UTC-0400 (Mon, 20 Apr 2026 09:16:56 +0800)
2380189206 <[email protected]>
is rumored to have said:
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.
You are misinterpreting the Authentication-Results header. That header
records both SPF and DKIM results. SPF relates to the smtp.mailfrom
parameter, DKIM relates to the header.d parameter.
That's just how DKIM works. The signature on a message MUST be in the
same domain as the From header for it to be valid for DMARC use.
I suggest you re-read RFCs 6376, 7208, and 7489.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Bill Cole
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
