On Fri, 2026-09-04 at 13:58 -0400, Christopher wrote: > I was thinking... I'm actually surprised that sending email from a > different service provider works at all, using a Fedora committer > email address. With modern email security checks, I'm surprised it > doesn't just get blocked since it's not being sent from a > fedoraproject.org SMTP server.
Well, it gets a bit complicated, but the tl;dr is: we tell people not to enforce those checks for fedoraproject.org. There are several relevant mechanisms: SPF, DKIM, and DMARC. SPF is the Sender Policy Framework. It's basically a DNS record on the domain that tells people what domains and/or IP ranges are expected to send mail for addresses in a given domain. fedoraproject.org 's looks like this: v=spf1 a a:mailers.fedoraproject.org ip4:38.145.32.11 ip4:38.145.32.12 ?all I'm not sure what the effect of the bare 'a' is (it might effectively mean 'pass for everything'). But as for the rest, it means the SPF result is a 'pass' if the sender IP has an 'A' record in mailers.fedoraproject.org domain, or if the sender IP is 38.145.32.11 or 38.145.32.1...and the result is 'neutral' in all other cases, that's what `?all` means. So we basically say the SPF check never fails; the worst possible result is 'neutral'. DKIM is DomainKeys Identified Mail. It's again based on DNS records, and the idea is pretty simple: you can publish a DNS record saying that mail originating from your domain must be signed with a given key. (It's more complicated than that, but that's the basic idea). Then you have 'authorized' senders sign with that key. This one is pretty simple: we just don't publish a DKIM record for fedoraproject.org at all. So we're basically saying "there is no DKIM policy, don't ever expect mails from fedoraproject.org to be DKIM-signed". Finally, DMARC is a kinda meta mechanism: it lets you tell recipient systems what you think they should do if mails fail any of the *other* checks. Again, it's a DNS record. The fedoraproject.org DMARC record looks like this: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=0 the key thing there is 'p=none', which basically means "don't do anything on failed checks". The other options are "quarantine" or "reject", both of which are obviously stronger. So essentially we set every dial we can to the "don't worry about it, guys" setting. We're sending the signal that basically any server might be sending out 'valid' fedoraproject.org mail, we just don't know. There is a risk with this: *some* mail systems will treat 'permissive' domains like ours as more likely spam sources, i.e. they'll set their policies so mails from our domains have a lower threshold to be considered spam based on content checks or other rules. Whereas if you have 'strong' policies, they're more likely to treat mail from your domain that passes all the checks as legit even if it gets a higher spam score on other checks. But other than running a public SMTP server and expecting people to use that to send fedoraproject.org mail, there's not much else we can do. > I don't know enough about how this > works to fully consider the pros and cons of alternatives. If Fedora > provided its own SMTP server, then I think it would be easy to > consider alternatives, like Thunderbird. But, I think Fedora would > probably have to provide the ability to create an application password > to authenticate to an SMTP server, because it shouldn't be > unauthenticated, and Fedora's MFA might be a bit troublesome with it. Yeah, I think we basically do not want the trouble of running a public SMTP server. Not sure when was the last time it was considered, though. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @[email protected] https://www.happyassassin.net -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
