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.
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.
Note that we don't follow this advice when using Gmail forwarding so that we can trap bounces and disable forwards, but we have the benefit of a very good spam filtering and massive non-spam volumes as we are not a strictly forwarding service.Which is another way of saying that there are arguments both ways,
;-)
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. :-(
There was a large discussion on here a while back about forwarding vs pop/imap, I'm not sure if the consensus has really moved on that... I think many suggested doing both, aggressive spam filtering before forwarding for fastest delivery, and back up pop fetching to handle false positives.As for "can't tell whether it was spam or not"... I find it hard to believe that you're getting blocked for only allowing through that level of spam unless your overall volumes are tiny.
Small / individual server operators. :-[ -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
