Temporary block of @canonical.com sending to @lists.ubuntu.com

[Thomas Ward]

I reject your approach and proposal Robie. I explained why already in 
Matrix, but will offer the same explanation below.

On 2026-01-09 11:20, Robie Basak wrote:
> [writing as one member of the Ubuntu Technical Board]
>
> There is currently a technical problem affecting those with
> @canonical.com addresses using mailing lists hosted at
> @lists.ubuntu.com. To mitigate the impact, I propose to temporarily
> block, at mailing list level, emails from @canonical.com reaching
> @lists.ubuntu.com at all. Even better if Canonical IS could please do
> this at MTA level.
>
> At the moment, my best understanding of the problem is:
>
> 1. @canonical.com sets a DMARC policy.
>
> 2. When a @lists.ubuntu.com mailing list distributes an email sent by
> someone with a @canonical.com address, those emails do not comply with
> the @canonical.com DMARC policy.
>
> 3. When the email infrastructure of a third party subscriber to a
> @lists.ubuntu.com mailing list receives such an email and enforces the
> sender's DMARC policy, the email is rejected. As far as I can tell, this
> includes all mailing list subscribers who use Gmail and Fastmail.
>
> 4. The mailing list handler at @lists.ubuntu.com handles the rejection
> by (eventually) unsubscribing third party subscribes that enforce
> @canonical.com's own DMARC policy.

I already explained a solution in Ubuntu Governance on Matrix, but I'll 
detail below here.

Since Mailman 2.something, when DMARC became the standard of things for 
mail enforcement over six years ago with widespread adoption, the option 
has always been available to allow one of three solutions for messages 
and DMARC handling:

  1. Do nothing (what is set now)

  2. Munge the from address so the "From" address is the mailing list 
instead of the original sender (for instance, the "From" address on this 
message would be From: "Thomas Ward via Mailing List" 
<technical-board at lists.ubuntu.com> for the  message to the tech board if 
we enabled it on the Tech Board list)

  3. Wrap the message in an outer envelope as an attachment, and the 
'outer envelope' is from the list instead of the sender.  This isn't 
aesthetically pleasing.

The implied 4th option is to reject DMARC-enforced email sources, which 
really is *useless* in the long term.

---

Years ago at this point, when DMARC enforcement was becoming standard, I 
addressed this with commits to Launchpad Itself, changing the email 
handling for sending bug email to use the "Munge From" approach for all 
messages. When that was done, all bug mail was sent as "Original Sender" 
<bugnumber at bugs.launchpad.net> when that change implemented. So replies 
go to the bug mail and are sent as Launchpad, solving the DMARC rejections.

Mailman's "Munge From" option is basically that.

*However, I believe the general consensus was to leave things alone 
because this introduces some odd behaviors in some mail clients with the 
'reply' button.* While Thunderbird is smart enough to ID replying to 
individual senders or to lists, including with "Munge From" (because a 
reply-to is set to the original sender's address), other mail clients 
when you hit "Reply" will reply to the mailing list address that is in 
the munged "From" header.

So while it solves hte DMARC delivery problem, it also introduces 
"replying to the original message sender" caveats.

In my opinion, using the DMARC mitigations of "Munge From" introduce the 
least invasive change and approach to solving message delivery for 
people from Canonical to lists.  Simply blocking canonical.com addresses 
doesn't *help* anything, when a simple "Munge From" option can solve the 
delivery problem overall.

It can be enabled on a list-by-list basis by going into the list's admin 
panel, "Privacy Settings", "Sender Filters" and then adjusting the 
"Action to take when anyone posts to the list from a domain with a DMARC 
Reject/Quarantine Policy" option to "Munge From".

Lists we don't admin, etc. will have to be done by IS, but it's a 
minimally-invasive change.  Just a dash time consuming.  THIS SAID, I 
know for a fact that Aaron P. and Mauro both want to solve this DMARC 
problem for Canonical/Ubuntu globally (not just with Canonical domained 
emails but issues related to ubuntu.com and lists.ubuntu.com as well), 
and have Canonical's IS director on 'speed dial' with me for this. (I'm 
adding both to the CC list).


Thomas Ward, CISSP
Ubuntu Technical Board Member
LP: ~teward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20260109/e59c8307/attachment.html>