>From: li...@rhsoft.net <li...@rhsoft.net> >Sent: Monday, September 12, 2016 12:13 PM >To: users@spamassassin.apache.org >Subject: Re: RCVD_IN_SORBS_SPAM and google IPs
>that's exactly what i *don't* have a contentfilter for to need customers >report their spam and i have to talk with abuse departments to stop it I didn't have to do anything but check my logs to see that it stopped. >> From my experience, they are trustworthy and police their >> outbound spam properly to trust. Otherwise you will block too much >> legit email from their Simple Email Service. >why should i block too much legit mail just because a sender is not >whitelisted? It is possible for your Bayes to score high on a legit email and block it. I don't have hours each week to manually train my Bayes database so I had to find something more "hands off" to augment my pretty good, not perfect, Bayes database. DCC and RAZOR can sometimes push legit email over the block threshold too. MailSpike can be a bit too aggressive sometimes. My main point was that there are different tiers of senders so if you see patterns in your logs you can safely whitelist many senders in the top tier using shortcircuit. Each person has to go by their logs and find those in the top tier senders and then add them to their whitelist_auth list which will help with issues like the subject of this thread. >> https://aws.amazon.com/ses/faqs/ >> They have sending and bounce quotas which are going to catch most >> bad actors using SES. >> >>>the same for "whitelist_auth *@icloud.com" >> >> Apple is also doing a good job of policing their outbound spam >> from icloud.com. My logs show good reputation of the IPs. >> senderscore.org report for 17.164.24.103 has a 98 out of 100 >> as a very high sender which is excellent. >a good job don't help much in case of hacked accounts which are closed >after the damage of sending phising and malware mails already happened There's not much anything can do to block compromised accounts from normally trusted mail servers. Greylisting can help a little but not a lot. >> Those are >> message IDs which wouldn't necessarily match the envelope-from >> used by whitelist_auth. >man i know what i am doing when reading maillogs (besides i knew before >looking in the recent logs that @amazonses.com is not a blindly >trustable envelope) Ok. I understand you know what you are doing now but I didn't know for sure based on your log paste. >from=<01000157007004fc-dd484ffc-155c-48dc-8a7d-b9fbc51b7094-000...@amazonses.com> >from a8-21.smtp-out.amazonses.com[54.240.8.21] >> I don't see an IP address either to check the >> source so that email could have been forwarded >* SPF_PASS >* DKIM_VALID_AU You didn't show the envelope-from the first time so I couldn't have assumed the hits above weren't forwarded. SPF_PASS and DKIM_VALID_AU hits don't prove I was incorrect without showing the original envelope-from.
