Possible fixes from most trivial to more effort/controversy:
Fix #1: the HELO name is bastion.fedoraproject.org. This SHOULD resolve to the (legitimate) connect IP(s) used by the forwarder. This alone would allow identifying and whitelisting the authentic forwarder. I don't know what the compete IP list should be, but I have observed attempted alias forwarded emails to me from 209.132.181.3.
Fix #2: provide a sender policy (SPF) record for bastion.fedoraproject.org (or other arbitrary designated forwarding domain). Even though it is not used in MAIL FROM, the resulting flexible IP list can be used to whitelist the fedoraproject forwarder, by designating the forwarding domain as a "trusted forwarder" (even if it does not actually appear in MAIL FROM). See http://www.openspf.org/
Fix #3: implement SRS using the domain from fix #2. This avoids forging the sender MAIL FROM on forwarded emails by actually using the forwarder domain in MAIL FROM, while still allowing transparent "bounces" by encoding the original MAIL FROM in localpart. There are many implementations, my own is https://github.com/sdgathman/pysrs
E.g. my own forwarder (with forwarding domain gathman.org) encodes MAIL FROM like this:
Return-Path: SRS0=J6lMd=LT=e.vetsfirstchoice.com=suite22@gathman.org
The forwarded MAIL FROM is not forged (and doesn't need forwarder whitelisting), and the original MAIL FROM is easily (manually or programatically) reconstructed as suite22@e.vetsfirstchoice.com. The preceding chars are a coded timestamp and small crypto sig to prevent using replay attacks to send bounce spam using the forwarder as a relay. Thus forwarded mail from me to fedoraproject aliases would have MAIL FROM looking something like:
SRS0=P3Txd=LT=gathman.org=stuart@bastion.fedoraproject.org
When do you need this? (YYYY/MM/DD) 2018/09/30 ASAP. But any deadline is arbitrary. People can always email directly.
When is this no longer needed or useful? (YYYY/MM/DD) N/A Correct DNS is needed for the foreseeable future - until email is obsolete.
If we cannot complete your request, what is the impact? Cannot whitelist the fedoraproject.org forwarder, and thus cannot receive emails to sdgathman@fedoraproject.org (as allowing anyone to forward is out of the question - there are hundreds of forged emails daily to me alone that must get rejected.)
I have no problem with fix #1. We can set bastion01.fedoraproject.org and bastion02.fedoraproject.org to helo with their real correct names.
For fix #2, I am against adding SPF records, as I find them pretty harmful. Isn't it your job on the client end to decide what trusted forwarders you want to allow? I guess you just want some SPF record to use to do this dynamically? Can you point to any software that does this? Additionally, people sending to you with @fedoraproject.org addresses they locally setup do not even pass through our servers.
For fix #3, I am pretty against doing any re-writing of from. Also this runs into the same issue with people using fedoraproject.org aliases sent directly from their clients.
If you like we can discuss this at our next meeting or on the mailing list for more opinions.
Metadata Update from @kevin: - Issue priority set to: Next Meeting (was: Needs Review)
A sender policy for bastion.fedoraproject.org does not affect MAIL FROM fedoraproject.org in any way. It only affects MAIL FROM bastion.fedoraproject.org. Since you currently don't send any email from bastion.fedoraproject.org, that is not current a problem. At that point, the policy simply functions, as you put it, "some SPF record to use to do this dynamically". In software that checks SPF, you can often put such a domain in a "trusted_forwarder" config. That is what I would like to do. If you can't do so, I can add a local override to supply an sender policy that I try to guess from comments on IRC and such - but that is obviously far from ideal.
The key concept is that an SPF record is functionally a set of IPs. It is useful for publishing an official set of IPs in DNS. Detecting forged MAIL FROM is the primary intended application, but not the only one.
If you use a different HELO for each mail server, that makes your HELO valid - which is a good thing. But whitelisting your forwarder still requires an unofficial list of server hostnames. From IRC comments, I hear that the current list is: bastion01.fedoraproject.org bastion02.fedoraproject.org
But having every user of the forwarding service (that blocks forged MAIL FROM) keep that list current is not ideal.
Conclusion. I won't push #3, but I urge #2 as your objection doesn't apply (since the domain is not used in MAIL FROM).
Since you currently don't send any email from bastion.fedoraproject.org, that is not current a problem
That is not the case. We send tons of emails via bastion.fedoraproject.org. Many of them from our notification system (notifications@fedoraproject.org), some from mailing lists (whatever@lists.fedoraproject.org), some administrative emails to admins, and some few from applications (bodhi sends emails from bodhi@fedoraproject.org).
None of those examples you just listed use bastion.fedoraproject.org as the MAIL FROM. SPF records only affect MAIL FROM.
Ah, I see I have misunderstood what you were suggesting...
So, yeah, we could add a SPF record for bastion.fedoraproject.org... but how do people know to use that to know it's a "trusted forwarder" rather than anything else? Normal SPF processing wouldn't look since it's not the domain used in the mail from, is there some tool or configuration that does do this?
Mail systems that check SPF and can whitelist alias forwarders, can usually use an SPF domain instead of a list of IPs. I will know to use that particular domain, because I suggested it. As to how other Fedora members will know to use that domain - that is a good question. Maybe a note where you configure email forwarding? (If there is any such configuration - I didn't notice it.) I'll go look at my Fedora account to see if I can see a good place.
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Next Meeting)
So, we had to add a stupid SPF record for gmail. :(
Does this meet your needs now, or did you still want one for bastion.fedoraproject.org ?
I see you added a sender policy for MAIL FROM fedoraproject.org that seems to coincide with the servers using a HELO of bastion.fedoraproject.org.
1) Yes, that is sufficient for whitelisting purposes. The obvious domain (from HELO) was bastion.fedoraproject.org, but after scratching my head as to what domain you might have added a sender policy for to satisfy gmail, I finally guessed fedoraproject.org.
2) Your HELO is still invalid: does not resolve to the connect ip (the older standard) and does not have a sender policy either. (Ideally, it should have both, but certainly the former.)
3) Using fedoraproject.org for HELO on your bastion.. MTAs would now be considered correct for SPF aware MTAs. But not for older software that only checks the original SMTP RFC requirement that it resolve via DNS A/AAAA records to the connect ip.
4) You don't have to duplicate any code for bastion.fedoraproject.org. As long as the legitimate MTAs for bastion.fedoraproject.org are the same as those for fedoraproject.org, you can use:
bastion.fedoraproject.org IN TXT "v=spf1 redirect=fedoraproject.org"
It might actually be clearer to do it the other way around, but it is slightly more efficient the way you have it if fedoraproject.org is going to be queried more often (as I suspect is the case).
That will make your HELO valid for SPF aware MTAs.
Done.
:mailbox_closed:
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.