On Wed, Jan 15, 2025 at 07:03:23PM +0100, Björn Persson wrote: > Kevin Fenzi wrote: > > On Wed, Jan 15, 2025 at 04:15:11PM +0100, Cristian Le via devel wrote: > > > On 1/15/25 2:33 PM, Fabio Valentini wrote: > > > > > > > No, AFAIK the <username>@fedoraproject.org email alias should work for > > > > all users who are in CLA+1 or something (so it should work for all > > > > members of the "packager" group, for example, since signing the CLA is > > > > prerequisite for joining the "packager" group). > > > > > > Indeed you are right, I have tried it out and something is setup there. But > > > the way it is setup guarantees it will break for most cases and it should be > > > discouraged. > > > > Well, it will break for senders who's mail domain sets reject on SPF and > > who's recipient domain actually rejects those emails instead of just > > marking them as less valid. > > > > > I have tried to send a message from my work email to > > > lecris@xxxxxxxxxxxxxxxxx, and I got an SPF check failure. From the error > > > message I see the failure is that <user>@fedoraproject.org tries to > > > impersonate the sender (in this case my work email) and the sender's SPF > > > does not allow that IP address. > > > > Yeah, if your work email rejects such messages then indeed it will not > > work in that case. > > > > Now, we could look at setting up some kind of rewriting thing that takes > > the emails, rewrites them to come from some fedoraproject address and > > set reply-to to the real sender. This would be a net new block of work > > someone would have to implement, test, deploy and maintain it. > > If it's only SPF, then it should be enough to use the forwarding > server's own domain in the SMTP session, like list servers always do. > SPF asks the receiving server to validate the hostname given in > HELO/EHLO and the return address given in MAIL FROM in SMTP. A correct > SPF implementation will only look at the SMTP envelope, not the email > header. > > The problems usually arise when the sender has a DMARC rule that forbids > forwarding and the recipient enforces DMARC, because DMARC imposes > requirements on the From field of the email header. That, I believe, is > when this mailing list rewrites the From field, and the forwarding > alias server would have to do the same. You can tell which posters have > strict DMARC rules by the "via devel" that gets appended to their names. NB, the "From" rewriting with "via devel" is generally only needed if someone's domain has configured SPF and DMARC, but has *not* also configured DKIM. DMARC checks pass if either SPF or DKIM checks pass. So as long as Fedora's forwarding logic *keeps* the existing DKIM signature, and does not touch any part of the mail covered by the DKIM signature, it shouldn't matter if SPF fails. When debugging people's broken mail servers I usually end up pointing them to this: https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html NB Fedora could optionally also add its own DKIM signature, as long as it preserves the senders original DKIM signature. I would just say any domain with SPF + DMARC, but without DKIM just has a broken mail config & not our problem. All use of mailing lists is doomed in that scenario unless every list takes countermeasures to rewrite From. Not worth the hassle for Fedora IMHO. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
