Marc Perkel wrote: > > > SPF breaks email forwarding. > > SPF breaks mail forwarding services that are unwilling to expend a little effort to modify their MAIL FROM handling. There's documented ways to do this, you're just unwilling, and instead you'll continue to repeat this partial truth. (everything you say is true, you're just leaving out the details for your own benefit.. ever consider running for public office?)
SPF does break simple mail forwarding that chooses to re-use the MAIL FROM parameter, and that is the method of forwarding you use. However, rewriting the MAIL FROM isn't difficult. Mailing lists do this with great regularity, and they're forwarding mail without being affected by SPF. SPF doesn't break all mail forwarding, it breaks the simple "default to most MTA's" method that you use. Such simple forwarding is really, IMO, intended for "inside your own network" use. I would never expect such a forwarding arrangement to be used on email sent to me without either my prior knowledge, or the knowledge of the owner of the sending domain. If I'm a knowing recipient of such mail, I know that if I'm going to check SPF, I'll have to "go back another header" and check it. This is what I have to do inside my own LAN when my secondary MX forwards to my primary. If I'm a knowing sender using such a relay service, I can adjust my SPF records accordingly. > I haven't found anything I can't use it for that's useful. Since you run such a mail forwarding service, and aren't willing to change your system to make SPF work for your customers, it's not surprising you can't find anything useful about it. Instead you would rather just complain about it (without mentioning you're doing so because it impacts your business.) Personally, I find SPF very useful. whitelist_from_spf a much more reliable and sensible system than whitelist_from_rcvd, provided the sender's domain has SPF records. Assuming that the sender's mailserver is always going to have the same domain-name associated with its RDNS is naive and stupid when you think about larger organizations that have "bought out" smaller companies. The sending servers for those buy-outs are likely to have their old company domain name, but will be sending mail using both the old company and the parent-company domains as senders. SPF can handle that easily. I also find SPF failure a very good reason to greylist a message and/or bump up the score of an email. Since I don't use any forwarders outside of those that I control, I know such messages are likely to be forged. Finally, within a SpamAssassin context, your end users could fix their SPF problems by declaring your servers to be trusted and internal, should any of them run SA after you've already scanned the mail. SA will automatically go back deep enough in the headers to find the host that delivered mail to your server, and check against that.
