I designed a similar system to what Andris Reinman mentioned for our outbound mail system which hosts about 80k email accounts. This is a 4 tier system; low spam probability, medium spam probability, high spam probability, blatant spam. After the message is scored we use postfix header routing to route delivery to the correct outbound servers. We have 2 VM's that handle good mail, 1 for medium and one for high scoring spam, the blatantly marked spam is held in a quarantine queue for 5 days then discarded.
With this setup we rarely have problems with forwards to any providers. The scoring system uses MailScanner which heavily depends on SpamAssassin so it took about 4 months to adjust rules since outbound mail is not quite like inbound mail which SpamAssassin was designed for. After the initial adjustment and training it now takes a few hours per week to maintain the system. It works very well, we had a lot of outbound mail problems before we implemented this solution in mid 2016. --Bryan On Wed, Nov 8, 2017 at 3:18 PM, Andris Reinman <andris.rein...@gmail.com> wrote: > We at Zone.ee handle redirects to Gmail (or to any target actually) in 3 > steps: > > 1. If the message does not get any spam points (we use Rspamd) then we > forward the message through our normal redirect IP range (3 IPs that > equally share the messages) > 2. If the message gets spam points but not enough to discard it, then we > route this message through a dedicated spam IP, the rDNS name for it even > includes "spam" in it. if this IP gets blocked then we do not care too much > about it. > 3. If the redirected message gets a lot of spam points then we just > discard it with no action (no bounce messages etc.) > > Regards, > Andris Reinman > > 2017-11-08 21:46 GMT+02:00 Brandon Long via mailop <mailop@mailop.org>: > >> Yes, forwarding spam to us is generally a really poor idea, especially >> over ipv6 [image: ]. >> >> The 18 is more of a source code, ie the source of the rejection, not >> really a specific error code. They're not generally useful to end users. >> >> We've discussed before that one thing that may work best is to forward >> the non-spam, and have the user use pop3 to fetch the spam. >> >> GSuite users can also denote a host as an inbound gateway to get around >> this problem, but I was never able to get the resources to have gmail users >> have the same ability. It's possible this is something we could use arc >> for. >> >> Brandon >> >> >> On Wed, Nov 8, 2017 at 11:41 AM Alan Hodgson <ahodg...@lists.simkin.ca> >> wrote: >> >>> On Wed, 2017-11-08 at 12:20 -0700, Warren Volz wrote: >>> >>> All, >>> >>> One of my users has their account setup to forward mail to Gmail. >>> Recently I've started to see lots of rejects that look like the following: >>> >>> <us...@gmail.com> (expanded from <us...@somelocaldomain.net>): host >>> gmail-smtp-in.l.google.com[2607:f8b0:400e:c04::1a] said: 550-5.7.1 >>> [ipv6 address 18] Our system has detected that >>> 550-5.7.1 this message is likely suspicious due to the very low >>> reputation >>> of 550-5.7.1 the sending IP address. To best protect our users from spam, >>> the 550-5.7.1 message has been blocked. Please visit 550 5.7.1 >>> https://support.google.com/mail/answer/188131 for more information. >>> p26si2014836pli.781 - gsmtp (in reply to end of DATA command) >>> >>> I've looked over the forwarding best practices provided by google and we >>> are not modifying the envelope sender. I'd rather not start throwing away >>> what our filter marks as spam since I leave that up to the user, but is >>> that the only way to stop the bounces? Also, is the "18]" an artifact or >>> some kind of error? >>> >>> Thanks for the help. >>> >>> >>> IMO, you really can't forward mail to Gmail; they will block you if you >>> forward any spam at all. >>> >>> Gmail accounts can be setup to pull mail in via POP-3, that's a far >>> better way for them to get their mail. >>> _______________________________________________ >>> mailop mailing list >>> mailop@mailop.org >>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >>> >> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
