Now I see that whitelist_from_rcvd is probably the best all around. As explained here:
*whitelist_from_rcvd a...@lists.sourceforge.net <mailto:a...@lists.sourceforge.net> sourceforge.net* Works similarly to whitelist_from, except that in addition to matching a sender address, a relay's rDNS name or its IP address must match too for the whitelisting rule to fire. The first parameter is a sender's e-mail address to whitelist, and the second is a string to match the relay's rDNS, or its IP address. Matching is case-insensitive. This second parameter is matched against the TCP-info information field as provided in a FROM clause of a trace information (i.e. the Received header field, see RFC 5321 <http://www.ietf.org/rfc/rfc5321.txt>). Only the Received header fields inserted by trusted hosts are considered. This parameter can either be a full hostname, or the domain component of that hostname, or an IP address in square brackets. The reverse DNS lookup is done by a MTA, not by SpamAssassin. In case of an IPv4 address in brackets, it may be truncated on classful boundaries to cover whole subnets, e.g. |[10.1.2.3]|, |[10.1.2]|, |[10.1]|, |[10]|. CIDR notation is currently not supported, nor is IPv6. The matching on IP address is mainly provided to cover rare cases where whitelisting of a sending MTA is desired which does not have a correct reverse DNS configured. In other words, if the host that connected to your MX had an IP address 192.0.2.123 that mapped to 'sendinghost.example.org', you should specify |sendinghost.example.org|, or |example.org|, or |[192.0.2.123]| or |[192.0.2]| here. Note that this requires that |internal_networks| be correct. For simple cases, it will be, but for a complex network you may get better results by setting that parameter. It also requires that your mail exchangers be configured to perform DNS reverse lookups on the connecting host's IP address, and to record the result in the generated Received header field according to RFC 5321 <http://www.ietf.org/rfc/rfc5321.txt>. e.g. whitelist_from_rcvd j...@example.com example.com whitelist_from_rcvd *@axkit.org sergeant.org whitelist_from_rcvd *@axkit.org [192.0.2.123] On 01/28/2018 04:52 PM, David Jones wrote: > On 01/28/2018 02:25 PM, Benny Pedersen wrote: >> Chip skrev den 2018-01-28 21:01: >>> I see that makes sense. Thanks for the clarity. >>> >>> However how do you get to 150? >>> >>> good DKIM = 100 >>> good SPF = 100 >>> >>> That totals 200 >> >> one more reason not to use it >> >> use domain based whitelist_auth not just global all that is dkim pass >> or spf pass >> > > He is not using this SA instance in a typical mail filtering way. He > is trying to do some sort of analysis of spoofing based on SPF_PASS > and DKIM_VALID_AU. I am still not sure how spoofing can be determined > without some form of spammyness taken into consideration. > > If you whitelist_auth the commonly spoofed brands/companies, then > spoofing should score well above zero but how do you determine > spoofing from regular spam without manually checking? > > >> if you want spammers control what is spam or not cuntinue helping >> them :=) >> >> meta DMARC_SPAM (!DKIM_VALID_AU && !SPF_PASS) >> >> && means AND so both need to be not pass > >
