Note that SRS usually refers to a specific rewriting scheme, one that never went beyond a draft and wasn't all that useful directly. You can of course use it, but I don't think the specific implementation is that useful. There were people who felt that Gmail should support SRS or that it already did, and that was never true nor useful.
Sender rewriting in general, however, has always had pros and cons. Yes, Gmail recommended on their forwarding page support page to not do rewriting, as at the time that was the better choice for sites that didn't implement sufficient anti-spam before forwarding.. and of course the challenge of how do users handle antispam false positives that weren't forwarded. Note that Gmail's own forwarding always did sender rewriting. With Gmail's turn towards "no auth no entry", the balance has shifted to recommending rewriting. This is because email with only SPF auth will fail to forward (even if it had +all). The only solution to that is to rewrite the sender and have that SPF auth. We should support ARC for this instead, since that's a more "real" solution, we'll see if that happens. ARC would provide a simple way for a receiver to say that they want forwarded mail from this system, and the rest would just work. Anyways, the fact that we now recommend sender rewriting doesn't change all of the original challenges with doing it. One could probably write up a list of more complicated suggestion, such as using a separate domain just for forwarding (and maybe even a separate IP address), try not to forward spam mail, try to reject spam mail at smtp time, have your customers also set up pop fetching to fetch the messages that don't get forwarded... in fact, you could do that even for messages that gmail refuses to accept the forward for instead of bouncing back to the original sender. You could even try only doing sender rewriting for messages which don't have a valid DKIM signature, though with dkim replay attacks that has its own issues. And not rewriting for messages with no authentication at all, so you aren't used for an auth upgrade attack. So many considerations for forwarding. Brandon On Tue, Jul 11, 2023 at 11:52 AM Grant Taylor via mailop <mailop@mailop.org> wrote: > On 7/11/23 10:08 AM, Benny Pedersen via mailop wrote: > > on next hub envelope sender changes, so new spf problem when next hub > > forwards mails > > This behavior is not guaranteed and SHOULD NOT be relied on. If it > works, then great! But don't be surprised if it doesn't work. > > I remember Sender Rewriting Scheme being discussed multiple different > places many different times and the vast majority of people involved in > them loathed the idea of the envelope from address being changed at one > or more hops along the way. > > For a long time Gmail actively discouraged SRS et al. saying that that > they would associate the spam nature with the domain used in the changed > envelope from address, thereby likely associating it with your server > instead of the original purported source. My understanding is that Gmail has (finally?) changed sides and now > agrees that there are times to change the envelope from address, if not > actually recommending it. > > As for Postfix doing this by default, that's a new information to me and > I consider it highly atypical. > > As someone that has gone out of my way to run SRS on emails that I relay > (but not originate) I agree with the idea. But I also think that I'm in > the extreme minority in my belief / support of SRS. I take some comfort > in Postfix (purportedly) defaulting to it. But I still think that I'm > in the minority and that most forwarding will not modify the smtp > envelope from. > > > > Grant. . . . > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
