Is SRS rewriting absolutely necessary for a forwarding mailserver?

Solution 1:

It seems to me that what your question boils down to is "how many mail servers out there check SPF records on incoming email?". If it's most of them, SRS is an absolute requirement for a forwarding server; if it's none of them, you don't need SRS.

Unfortunately, I can't immediately put my hands on any academic work on this. But since I check SPF on incoming email, I can say with certainty that some mail servers do check it. Any of your clients who have your server forward to accounts on my server will lose email sent from senders who advertise an SPF that ends (as they all should) -all, unless you use SRS. So I can say with certainty that without SRS, some of your customers' email will not be delivered.

I apologise to Marc that I can't read German, so I can't say whether the PDF he quotes advances compelling arguments, but I can reiterate that without SRS, some fraction of your customers' email won't be delivered. I cannot say what that fraction is, but it isn't zero - and that given, I don't think you have any alternative but to run SRS.

I agree that your server will not be helping itself by forwarding SPAM, but in my experience most of the reputational damage is done to its IP address, not the envelope-From domain; this will be done regardless of SRS usage.

The deeper answer to your question is that, between SPF and its (ill-considered and internet-breaking) followup DMARC, it seems to me that mail forwarding services have had their day. I've already required all but one of my users to have final delivery on my server, and that one user will have to change or leave in 2016. Nowadays, many webmail systems will allow integration over multiple mailboxes by collecting off-server mail using IMAP or POP, and many mail clients allow multiple IMAP or POP accounts to present as a single integrated INBOX, so forwarding isn't the boon to centralised reading that it used to be.

In short, I'd say you need SRS in the short term, and a new business model in the longer term.

Solution 2:

SRS seems to be a nice idea on the paper, but doesn't work very well in practice according to the folks of Heinlein Support (they are running a medium sized mail service with over 100000 accounts.)

Details are in their talk, though in German, why: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

The main reason is that SRS is a small patch for serious problems of implementing SPF in reality, because SPF does not cover some common use cases of email very well. For SRS to make sense though it needs to be deployed on a large base of servers, which is unlikely to ever happen. So until it is deployed on that large base of servers, it doesn't make quite much sense at all.

The problem with the large mail providers though is that they nowadays do have a real big user base and they are implementing more and more techniques (the successor for DMARC is already in the pipeline), which does it make more and more difficult for a normal mail server setup to send mails to them in a reliable kind of way.

If you want to get your mail better delivered to the big mail providers like Gmail, Hotmail and so on you should implement at least DKIM and DMARC, but also set it to soft fail at best and maybe implementing some rate limiting mechanisms on the mail delivery would work wonders for you.

This problem with the big providers is the reason why there are nowadays services like Mailchimp, Mandrill or Returnpath. Those providers do pay money to Google&Co. for better delivery quality.