I'm sorry, I made a mistake. DKIM is still verifying christopherschultz.net.
But, munging the 'From' address does not affect the reply, because the reply uses the `In-Reply-To` header. By the way, if the DKIM is corrupted, this email should normally be rejected, as it might sent from an attacker. My QQ.com would mark it as 'Sender cannot be verified, may be forged, please treat with caution', and then it landed in the spam folder. In the future, I suspect it might be blocked, just like Outlook. 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] > >
