welcomelist_from_dkim author@example.com [signing-domain]
Previously whitelist_from_dkim which will work interchangeably until 4.1.
Works similarly to welcomelist_from, except that in addition to matching an author address (From) to
the pattern in the first parameter, the message must also carry a valid Domain Keys Identified Mail
(DKIM) signature made by a signing domain (SDID, i.e. the d= tag) that is acceptable to us.
Only one welcomelist entry is allowed per line, as in "welcomelist_from_rcvd". Multiple
"welcomelist_from_dkim" lines are allowed. File-glob style characters are allowed for the From
address (the first parameter), just like with "welcomelist_from_rcvd".
The second parameter (the signing-domain) does not accept full file-glob style wildcards, although a
simple '*.' (or just a '.') prefix to a domain name is recognized and implies any subdomain of the
specified domain (but not the domain itself).
If no signing-domain parameter is specified, the only acceptable signature will be an Author Domain
Signature (sometimes called first-party signature) which is a signature where the signing domain
(SDID) of a signature matches the domain of the author's address (i.e. the address in a From header
field).
Since this welcomelist requires a DKIM check to be made, network tests must be enabled.
Examples of welcomelisting based on an author domain signature (first-party):
welcomelist_from_dkim joe@example.com
welcomelist_from_dkim *@corp.example.com
welcomelist_from_dkim *@*.example.com
Examples of welcomelisting based on third-party signatures:
welcomelist_from_dkim jane@example.net example.org
welcomelist_from_dkim rick@info.example.net example.net
welcomelist_from_dkim *@info.example.net example.net
welcomelist_from_dkim *@* mail7.remailer.example.com
welcomelist_from_dkim *@* *.remailer.example.com
def_welcomelist_from_dkim author@example.com [signing-domain]
Previously def_whitelist_from_dkim which will work interchangeably until 4.1.
Same as "welcomelist_from_dkim", but used for the default welcomelist entries in the SpamAssassin
distribution. The welcomelist score is lower, because these are often targets for abuse of public
mailers which sign their mail.
unwelcomelist_from_dkim author@example.com [signing-domain]
Previously unwhitelist_from_dkim which will work interchangeably until 4.1.
Removes an email address with its corresponding signing-domain field from def_welcomelist_from_dkim
and welcomelist_from_dkim tables, if it exists. Parameters to unwelcomelist_from_dkim must exactly
match the parameters of a corresponding welcomelist_from_dkim or def_welcomelist_from_dkim config
option which created the entry, for it to be removed (a domain name is matched case-insensitively);
i.e. if a signing-domain parameter was specified in a welcomelisting command, it must also be
specified in the unwelcomelisting command.
Useful for removing undesired default entries from a distributed configuration by a local or site-
specific configuration or by "user_prefs".
adsp_override domain [signing-practices]
Currently few domains publish their signing practices (RFC 5617 - ADSP), partly because the ADSP rfc
is rather new, partly because they think hardly any recipient bothers to check it, and partly for
fear that some recipients might lose mail due to problems in their signature validation procedures or
mail mangling by mailers beyond their control.
Nevertheless, recipients could benefit by knowing signing practices of a sending (author's) domain,
for example to recognize forged mail claiming to be from certain domains which are popular targets
for phishing, like financial institutions. Unfortunately, as signing practices are seldom published
or are weak, it is hardly justifiable to look them up in DNS.
To overcome this chicken-or-the-egg problem, the "adsp_override" mechanism allows recipients using
SpamAssassin to override published or defaulted ADSP for certain domains. This makes it possible to
manually specify a stronger (or weaker) signing practices than a signing domain is willing to publish
(explicitly or by default), and also save on a DNS lookup.
Note that ADSP (published or overridden) is only consulted for messages which do not contain a valid
DKIM signature from the author's domain.
According to RFC 5617, signing practices can be one of the following: "unknown", "all" and
"discardable".
"unknown": The domain might sign some or all email - messages from the domain may or may not have an
Author Domain Signature. This is a default if a domain exists in DNS but no ADSP record is found.
"all": All mail from the domain is signed with an Author Domain Signature.
"discardable": All mail from the domain is signed with an Author Domain Signature. Furthermore, if a
message arrives without a valid Author Domain Signature, the domain encourages the recipient(s) to
discard it.
ADSP lookup can also determine that a domain is "out of scope", i.e., the domain does not exist
(NXDOMAIN) in the DNS.
To override domain's signing practices in a SpamAssassin configuration file, specify an
"adsp_override" directive for each sending domain to be overridden.
Its first argument is a domain name. Author's domain is matched against it, matching is case
insensitive. This is not a regular expression or a file-glob style wildcard, but limited wildcarding
is still available: if this argument starts by a "*." (or is a sole "*"), author's domain matches if
it is a subdomain (to one or more levels) of the argument. Otherwise (with no leading asterisk) the
match must be exact (not a subdomain).
An optional second parameter is one of the following keywords (case-insensitive): "nxdomain",
"unknown", "all", "discardable", "custom_low", "custom_med", "custom_high".
Absence of this second parameter implies "discardable". If a domain is not listed by a
"adsp_override" directive nor does it explicitly publish any ADSP record, then "unknown" is implied
for valid domains, and "nxdomain" for domains not existing in DNS. (Note: domain validity is only
checked with versions of Mail::DKIM 0.37 or later (actually since 0.36_5), the "nxdomain" would never
turn up with older versions).
The strong setting "discardable" is useful for domains which are known to always sign their mail and
to always send it directly to recipients (not to mailing lists), and are frequent targets of fishing
attempts, such as financial institutions. The "discardable" is also appropriate for domains which are
known never to send any mail.
When a message does not contain a valid signature by the author's domain (the domain in a From header
field), the signing practices pertaining to author's domain determine which of the following rules
fire and contributes its score: DKIM_ADSP_NXDOMAIN, DKIM_ADSP_ALL, DKIM_ADSP_DISCARD,
DKIM_ADSP_CUSTOM_LOW, DKIM_ADSP_CUSTOM_MED, DKIM_ADSP_CUSTOM_HIGH. Not more than one of these rules
can fire for messages that have one author (but see below). The last three can only result from a
'signing-practices' as given in a "adsp_override" directive (not from a DNS lookup), and can serve as
a convenient means of providing a different score if scores assigned to DKIM_ADSP_ALL or
DKIM_ADSP_DISCARD are not considered suitable for some domains.
RFC 5322 permits a message to have more than one author - multiple addresses may be listed in a
single From header field. RFC 5617 defines that a message with multiple authors has multiple signing
domain signing practices, but does not prescribe how these should be combined. In presence of
multiple signing practices, more than one of the DKIM_ADSP_* rules may fire.
As a precaution against firing DKIM_ADSP_* rules when there is a known local reason for a signature
verification failure, the domain's ADSP is considered 'unknown' when DNS lookups are disabled or a
DNS lookup encountered a temporary problem on fetching a public key from the author's domain.
Similarly, ADSP is considered 'unknown' when this plugin did its own signature verification
(signatures were not passed to SA by a caller) and a metarule __TRUNCATED was triggered, indicating
the caller intentionally passed a truncated message to SpamAssassin, which was a likely reason for a
signature verification failure.
Example:
adsp_override *.mydomain.example.com discardable
adsp_override *.neversends.example.com discardable
adsp_override ebay.com
adsp_override *.ebay.com
adsp_override ebay.co.uk
adsp_override *.ebay.co.uk
adsp_override paypal.com
adsp_override *.paypal.com
adsp_override amazon.com
adsp_override ealerts.bankofamerica.com
adsp_override americangreetings.com
adsp_override egreetings.com
adsp_override bluemountain.com
adsp_override hallmark.com all
adsp_override *.hallmark.com all
adsp_override youtube.com custom_high
adsp_override google.com custom_low
adsp_override gmail.com custom_low
adsp_override googlemail.com custom_low
adsp_override yahoo.com custom_low
adsp_override yahoo.com.au custom_low
adsp_override yahoo.se custom_low
adsp_override junkmailerkbw0rr.com nxdomain
adsp_override junkmailerd2hlsg.com nxdomain
# effectively disables ADSP network DNS lookups for all other domains:
adsp_override * unknown
score DKIM_ADSP_ALL 2.5
score DKIM_ADSP_DISCARD 25
score DKIM_ADSP_NXDOMAIN 3
score DKIM_ADSP_CUSTOM_LOW 1
score DKIM_ADSP_CUSTOM_MED 3.5
score DKIM_ADSP_CUSTOM_HIGH 8
dkim_minimum_key_bits n (default: 1024)
The smallest size of a signing key (in bits) for a valid signature to be considered for
welcomelisting. Additionally, the eval function check_dkim_valid() will return false on short keys
when called with explicitly listed domains, and the eval function check_dkim_valid_author_sig() will
return false on short keys (regardless of its arguments). Setting the option to 0 disables a key size
check.
Note that the option has no effect when the eval function check_dkim_valid() is called with no
arguments (like in a rule DKIM_VALID). A mere presence of some valid signature on a message has no
reputational value (without being associated with a particular domain), regardless of its key size -
anyone can prepend its own signature on a copy of some third party mail and re-send it, which makes
it no more trustworthy than without such signature. This is also a reason for a rule DKIM_VALID to
have a near-zero score, i.e. a rule hit is only informational. This option is evaluated on ARC
signatures checks as well.
Install Now
PNG Icons