On Tue, Jul 7, 2020 at 9:55 PM Grant Taylor via mailop <mailop@mailop.org> wrote:
> On 7/7/20 5:07 PM, Brandon Long via mailop wrote: > > At least at Gmail, we usually recommend that you don't use SRS, > > that you leave the original envelope from intact. > > > > https://support.google.com/mail/answer/175365?hl=en > > I have always questioned the veracity of that recommendation. > > > This helps us to know the email was forwarded and limits the bad > > reputation effects of forwarding spam. > > I believe that Google is quite capable and that they could undo SRS > rewriting to deduce the original SMTP envelope recipient. > SRS isn't a thing, though. It was a one-off proposal, it's not a standard. In terms of VERPs in use on the internet, it's not even that popular compared to the proprietary ones used by large providers. With SRS you're saying you want the mail to auth as you but not be from you? What are you asking? There may be an opportunity to abuse this, but I suspect some relatively > simple tests could reduce the risk. Namely, do an MX and SPF lookup on > the unrewritten recipient, and then see if the source makes sense. > There's no authentication there for the original address, we won't do anything with it. Even if we trusted the forwarder to honestly rewrite, there's no indication the original was authenticated. That's the point of ARC, for the relay to tell us what the original auth was and separately determine whether we should believe them. > but if you're having spam reputation issues from your forwarding, > > then perhaps that's the wrong choice. And maybe the right answer > > also depends on where you're forwarding to. > > > > One would also hope that in the future using ARC would be an even > > better way to denote forwarding, but we're a ways from that being a > > solution right now. In my perfect world, mailbox providers like Gmail > > would allow end users to specify forwarding information similar to > > what we have for "inbound relays" for GSuite, but the feature never > > made it above the line for implementation. > > I question if we will ever get to a point that ARC will be viable for > small / individual server operators. :-( > I mean, right now there's probably a floor for volume for DKIM/SPF reputation for us, so yes, ARC will likely suffer from the same issue. Any level would work for whitelisting on a per receiver basis, of course. If you only send a couple messages a day, there's just no statistical signal. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop