Am 12.09.2016 um 18:53 schrieb David Jones:
*>From:*li...@rhsoft.net <li...@rhsoft.net>
*>Sent:* Monday, September 12, 2016 8:47 AM
*>To:* users@spamassassin.apache.org
*>Subject:* Re: RCVD_IN_SORBS_SPAM and google IPs
Am 12.09.2016 um 15:37 schrieb David Jones:
Has RCVD_IN_SORBS_WEB been considered for adjustment as well? It's
hitting a lot more ham than spam here, including mail from facebook.
You should be safely whitelisting any major senders like Facebook at
the MTA level and in SA:
whitelist_auth *@amazonses.com
for sure *not* since that would whitelist anything hosted on the amazon
cloud instances which is *not* amazon stuff itself
don't confuse major good senders with hosted crap of endcustomers
@amazonses.com != @amazon.com
I know the difference between amazonses.com and amazon.com. I have
only had 1 instance of spam from amazonses.com and Amazon blocked
it quickly.
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
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?
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
Everyone doesn't have to whitelist_auth the same senders. I only
wanted to show that this is a valid way to reduce false positives
for transient things like Google IPs in SORBS RBL.
[root@mail-gw:~]$ cat maillog | grep
01000157007004fc-dd484ffc-155c-48dc-8a7d-b9fbc51b7094-000...@email.amazonses.com
Sep 6 18:58:47 mail-gw postfix/cleanup[5554]: 3sTCVH11mDz9bQ:
message-id=<01000157007004fc-dd484ffc-155c-48dc-8a7d-b9fbc51b7094-000...@email.amazonses.com>
Sep 6 18:58:52 mail-gw spamd[1086]: spamd: result: Y 14 -
BAYES_99,BAYES_999,BOGOFILTER_SPAM,CUST_DNSBL_19_SPAMCANN,CUST_DNSWL_5_ORG_N,CUST_DNSWL_8_TL_N,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_D>OMAINS,HTML_MESSAGE,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK,RCVD_IN_MSPIKE_H2,RP_MATCHES_RCVD,SPF_PASS,T_OBFU_ATTACH_MISSP,URIBL_LOC>AL
scantime=5.0,size=13908,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=/run/spamassassin/spamassassin.sock,mid=<01000157007004fc-dd484ffc-155c->48dc-8a7d-b9fbc51b7094-000...@email.amazonses.com>,bayes=1.000000,autolearn=disabled,shortcircuit=no
Did you check the envelope-from address of that message?
surely - in fact i found the message-id after grep for envelopes in
milter-reject-log and *then* seeked for the classification
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)
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
I would need to see
the full headers and the message body since it did hit so many rules
and high Bayes
no you don't - the destination of that mail was our sysadmin-address
*never* used for subscribe anywhere nor as envelope-sender, it's only
mentioned on http error pages (non 2xx response)
