SpamAssassin Rule: ADVANCE_FEE_2

Explanation
A phrase in the email body has been found that is commonly found in advance fee fraud spam.

See Wikipedia for details regarding Advance fee fraud.

SpamAssassin Rule: ALL_TRUSTED
Standard description: Passed through trusted hosts only via SMTP

Explanation
"Trusted" does not mean "trusted to not send spam." It means "trusted to not forge Received: headers."

If your message hits on the ALL_TRUSTED rule, it means that all of the Received: headers in the message were inserted by SMTP relays you have indicated are "TrustedRelays" and the "from" part of the Received: header is also from one of your "TrustedRelays"; consequently, no tests of the source of the message (for example, tests against DNSBlocklists) will be performed.

If that message is obviously spam, and you think it should have been caught by DNS tests, then your trust path is configured incorrectly. See TrustPath and FixingAllTrusted.

SpamAssassin Rule: APOSTROPHE_FROM

Standard description: From address contains an apostrophe

Explanation
The apostrophe character "'" appears in the address part of the From: header.

e.g. <john.o'groats@example.com>

Note that, while the email address specification allows for apostrophes to be included in the local-part of an address, use of apostrophes has been historically discouraged for security and interoperability reasons. As such addresses containing them use may be considered unusual.

SpamAssassin Rule: AWL
Standard description: From: address is in the auto white-list

Explanation
The auto white-list (AWL) keeps track of the scores associated with known senders and pushes the total score for the mail toward the average for the sender. Thus a mail from a previous sender that's otherwise scored higher than average may receive a negative score; a mail scored lower than average may receive a positive score.

See AutoWhitelist for details.

Describe Rules/BASE64 LENGTH 78 79 here.

According to http://en.wikipedia.org/wiki/Base64 , base 64 should only be 76 chars long, so these are out of format.

SpamAssassin Rule: <BASE64_LENGTH_79_INF>
Standard description: base 64 with length 79 and on.

Explanation
see http://wiki.apache.org/spamassassin/Rules/BASE64_LENGTH_78_79

SpamAssassin Rule: BAYES_00

Standard description: Bayes spam probability is 0 to 1%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_05

Standard description: Bayes spam probability is 1 to 5%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_20

Standard description: Bayes spam probability is 5 to 20%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_40

Standard description: Bayes spam probability is 20 to 40%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_50

Standard description: Bayesian spam probability is 40 to 60%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_60

Standard description: Bayes spam probability is 60 to 80%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_80

Standard description: Bayes spam probability is 80 to 95%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_95

Standard description: Bayes spam probability is 95 to 99%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BAYES_99

Standard description: Bayes spam probability is 99 to 100%

Explanation
SpamAssassin includes a Bayesian filter that assigns scores based on the user's previous email history. This can assign both positive and negative scores. For instance, a user may receive a particular spam message several times via a relay identified in a DNSBL, so that SpamAssassin correctly identifies it as spam. If the user receives the same message via a new unlisted relay, the Bayesian algorithm will assign a high score to it based on previous experience.

Conversely, if a user receives a regular newsletter from a fitness club, and one issue makes reference to diet pills and weight loss (which would normally flage the message as spam), the Bayesian algorithm will assign a lower score to it.

SpamAssassin Rule: BLANK_LINES_70_80
Standard description: Message body has 70-80% blank lines

Explanation
<explanation of the rule goes here>

SpamAssassin Rule: BLANK_LINES_80_90

Standard description: Message body has 80-90% blank lines

Explanation
This suggests that the sender is trying to hide content "below the page fold", that the recipient may not scroll down to see. This may include nonsense characters or random text taken from the Web, intended to thwart pattern-matching filters by sending slightly different messages to each recipient.

SpamAssassin Rule: BLANK_LINES_90_100

Standard description: Message body has 90-100% blank lines

Explanation
<explanation of the rule goes here>

SpamAssassin Rule: CHARSET_FARAWAY

Standard description: Character set indicates a foreign language

Explanation
The content of the mail is in a character set not permitted by the value of the ok_locales configuration setting.

The default value of ok_locales is "all", so this rule will only trigger if the value has been locally specified.

See also: Rules/MIME_CHARSET_FARAWAY Rules/CHARSET_FARAWAY_HEADER Rules/CHARSET_FARAWAY_BODY

SpamAssassin Rule: CHARSET_FARAWAY_HEADER

Standard description: A foreign language charset used in headers

Explanation
The character set used in the Subject or other headers does not match that of the message body. This may indicate an attempt to avoid English-language text filters.

SpamAssassin Rule: CK_HELO_DYNAMIC_SPLIT_IP

Standard description: Relay HELO used a suspicious hostname (Split IP)

Explanation
The HELO appeared to be suspicious. This is typically the result of a poorly configured email server advertising itself as XXX-XXX-XXX-XXX.hostname.tld (where XXX is an IP address).

SpamAssassin Rule: DATE_IN_FUTURE_03_06

Standard description: Date: is 3 to 6 hours after Received: date

Explanation
The Date header is normally set to the date that a message was created. In this case, this date is 3 to 6 hours later than the message was received, suggesting that either the message was generated by badly-written mailout software, or the sender's computer clock is wrong.

SpamAssassin Rule: DATE_IN_FUTURE_06_12

Standard description: Date: is 6 to 12 hours after Received: date

Explanation
The Date header is normally set to the date that a message was created. In this case, this date is 6 to 12 hours later than the message was received, suggesting that either the message was generated by badly-written mailout software, or the sender's computer clock is wrong.

SpamAssassin Rule: DATE_IN_FUTURE_12_24

Standard description: Date: is 12 to 24 hours after Received: date

Explanation
The Date header is normally set to the date that a message was created. In this case, this date is 12 to 24 hours later than the message was received, suggesting that either the message was generated by badly-written mailout software, or the sender's computer clock is very wrong.

SpamAssassin Rule: DATE_IN_FUTURE_24_48
Standard description: Date: is 24 to 48 hours after Received: date

Explanation
The Date header is normally set to the date that a message was created. In this case, this date is 1 to 2 days later than the message was received, suggesting that either the message was generated by badly-written mailout software, or the sender's computer clock is very wrong.

SpamAssassin Rule: DATE_IN_FUTURE_48_96

Standard description: Date: is 48 to 96 hours after Received: date

Explanation
The Date header is normally set to the date that a message was created. In this case, this date is 2 to 4 days later than the message was received, suggesting that either the message was generated by badly-written mailout software, or the sender's computer clock is very wrong.

SpamAssassin Rule: DATE_IN_FUTURE_96_XX

Standard description: Date: is 96 hours or more after Received: date

Explanation
The Date header is normally set to the date that a message was created. In this case, this date is more than 4 days later than the message was received, suggesting that either the message was generated by badly-written mailout software, or the sender's computer clock is very wrong.

SpamAssassin Rule: DATE_IN_PAST_03_06

Standard description: Date: is 3 to 6 hours before Received: date

Explanation
The Date: header is checked against the timestamps in the Received: header lines. If the clock generating the Date: header is accurate then the mail was generated 3 to 6 hours before being received by one of the relays.

SpamAssassin Rule: DATE_IN_PAST_06_12

Standard description: Date: is 6 to 12 hours before Received: date

Explanation
The Date: header is checked against the timestamps in the Received: header lines. If the clock generating the Date: header is accurate then the mail was generated 6 to 12 hours before being received by one of the relays. This is unlikely in a normal mail client.

SpamAssassin Rule: DATE_IN_PAST_12_24

Standard description: Date: is 12 to 24 hours before Received: date

Explanation
The Date: header is checked against the timestamps in the Received: header lines. If the clock generating the Date: header is accurate then the mail was generated 12 to 24 hours before being received by one of the relays. This is unlikely with a normal mail client.

SpamAssassin Rule: DATE_IN_PAST_24_48

Standard description: Date: is 24 to 48 hours before Received: date

Explanation
The Date: header is checked against the timestamps in the Received: header lines. If the clock generating the Date: header is accurate then the mail was generated 1 to 2 days before being received by one of the relays. This is unlikely in a normal mail client.

SpamAssassin Rule: DATE_IN_PAST_96_XX

Standard description: Date: is 96 hours or more before Received: date

Explanation
The Date: header is checked against the timestamps in the Received: header lines. If the clock generating the Date: header is accurate then the mail was generated 4 days or more before being received by one of the relays. This is unlikely in a normal mail client.

SpamAssassin Rule: DC_GIF_UNO_LARGO

Standard description: Message contains a single large inline gif

Explanation
The mail contains a single "image/gif" attachment exceeding 180000 pixels in size (e.g. bigger than 600x300).

<!> even though the description specifies "inline", no check for this is made and it will still trigger for normal attachments.

SpamAssassin Rule: DC_IMAGE_SPAM_HTML

Standard description: Possible Image-only spam

Explanation
The mail has at least one large image attachment and a comparatively small amount of text.

<!> Although the rule name contains "HTML", this rule, as well as DC_IMAGE_SPAM_TEXT may also trigger on a plain-text mail with a large image attached. (See: __DC_IMG_HTML_RATIO )

SpamAssassin Rule: DC_IMAGE_SPAM_TEXT
Standard description: Possible Image-only spam with little text

Explanation
The mail has at least one large image attachment and a comparatively small amount of text.

See also: Rules/DC_IMAGE_SPAM_HTML

SpamAssassin Rule: DEAR_SOMETHING
Standard description: Contains 'Dear (something)'

Explanation
The body of the email contains a generically addressed greeting such as "Dear Sir" or "Dear Madam".

The current, case-insensitive, regular expression is

/\bDear (?:IT\W|Internet|candidate|sirs?|madam|investor|travell?er|car shopper|web)\b/i

SpamAssassin Rule: DIET_1
Standard description: Lose Weight Spam

Explanation
The message contains a phrase common to spam promoting weight loss, such as "lose 10lbs".

SpamAssassin Rule: DKIM_ADSP_ALL

Standard description: No valid author signature, domain signs all mail

Explanation
The sender's domain says that it uses DKIM (http://www.dkim.org/) on all email, but no valid signature was found.

That suggests that the message might not have originated with the purported sender.

SpamAssassin Rule: DKIM_ADSP_CUSTOM_HIGH

Standard description: No valid author signature, adsp_override is CUSTOM_HIGH

Explanation
The presence of this test indicates that DKIM support is enabled on the server.

The mail does not contain a valid DKIM signature and the domain of the sending address has been matched by an override setting (adsp_override).

For frequently seen domains that either do not publish an ADSP (Author Domain Signing Practices) records, or where a stronger (or weaker) policy is desired, the values can be specified in the configuration, saving the need for a DNS lookup.

The current default custom_med overrides in 60_adsp_override_dkim.cf include entries for youtube.com.

One reason for not seeing a signature on a mail from an domain which routinely signs them is that the signature header may have been stripped out, for example as part of a mailing-list expander.

SpamAssassin Rule: DKIM_ADSP_CUSTOM_LOW
Standard description: No valid author signature, adsp_override is CUSTOM_LOW

Explanation
The presence of this test indicates that DKIM support is enabled on the server.

The mail does not contain a valid DKIM signature and the domain of the sending address has been matched by an override setting (adsp_override).

For frequently seen domains that either do not publish an ADSP (Author Domain Signing Practices) records, or where a stronger (or weaker) policy is desired, the values can be specified in the configuration, saving the need for a DNS lookup.

One reason for not seeing a signature on a mail from an domain which routinely signs them is that the signature header may have been stripped out, for example as part of a mailing-list expander.

SpamAssassin Rule: DKIM_ADSP_CUSTOM_MED

Standard description: No valid author signature, adsp_override is CUSTOM_MED

Explanation
The presence of this test indicates that DKIM support is enabled on the server.

The mail does not contain a valid DKIM signature and the domain of the sending address has been matched by an override setting (adsp_override).

For frequently seen domains that either do not publish an ADSP (Author Domain Signing Practices) records, or where a stronger (or weaker) policy is desired, the values can be specified in the configuration, saving the need for a DNS lookup.

The current default custom_med overrides in 60_adsp_override_dkim.cf include entries for Yahoo and Google domains.

One reason for not seeing a signature on a mail from an domain which routinely signs them is that the signature header may have been stripped out, for example as part of a mailing-list expander.

SpamAssassin Rule: DKIM_ADSP_DISCARD

Standard description: No valid author signature, domain signs all mail and suggests discarding the rest

Explanation
The sender's domain says that it uses DKIM (http://www.dkim.org/) on all email, but no valid signature was found. The sender's domain policy suggests discarding this message.

That suggests that the message might not have originated with the purported sender.

SpamAssassin Rule: DKIM_ADSP_NXDOMAIN

Standard description: No valid author signature and domain not in DNS

Explanation
The presence of this test indicates that DKIM support is enabled on the server.

The mail does not contain a valid DKIM signature and the domain of the sending address is not in the DNS

One reason for not seeing a signature on a mail from an domain which routinely signs them is that the signature header may have been stripped out, for example as part of a mailing-list expander.

SpamAssassin Rule: DKIM_POLICY_SIGNALL

Standard description: Domain Keys Identified Mail: policy says domain signs all mails

Explanation
The sender's domain says that it uses DKIM (http://www.dkim.org/) on all email, but no valid signature was found.

That suggests that the message did not in fact originate with the purported sender.

SpamAssassin Rule: DKIM_POLICY_SIGNSOME
Standard description: Domain Keys Identified Mail: policy says domain signs some mails

Explanation
The sender's domain says that it uses DKIM (http://www.dkim.org/) on some email, but no valid signature was found.

That suggests that the message might not have originated with the purported sender.

SpamAssassin Rule: DKIM_POLICY_TESTING

Standard description: Domain Keys Identified Mail: policy says domain is testing DK

Explanation
The sender's domain says that it is testing DKIM (http://www.dkim.org/)

SpamAssassin Rule: DKIM_SIGNED
Standard description: Domain Keys Identified Mail: message has a signature

Explanation
The message is signed using DKIM (http://www.dkim.org/)

SpamAssassin Rule: DKIM_VERIFIED

Standard description: Domain Keys Identified Mail: signature passes verification

Explanation
The message is signed using DKIM (http://www.dkim.org/) and the signature was verified

SpamAssassin Rule: DNS_FROM_DOB

Standard description: Sender from new domain (Day Old Bread)

Explanation
The domain of the sender is listed in the DNSBL dob.sibl.support-intelligence.net - which lists domains registered in the last five days.

See also: Rules/URIBL_RHS_DOB

SpamAssassin Rule: DNS_FROM_SECURITYSAGE

Standard description: Envelope sender in blackholes.securitysage.com

Explanation
This rule is obsolete, and was removed in October 2007.

See: http://www.sso.ca/

SpamAssassin Rule: DOMAIN_RATIO

Standard description: Message body mentions many internet domains

Explanation
<explanation of the rule goes here>

SpamAssassin Rule: DRUGS_ERECTILE

Standard description: Refers to an erectile drug

Explanation
A phrase in the email body has been found that is commonly found in spam promoting cures for erectile dysfunction.

SpamAssassin Rule: DYN_RDNS_AND_INLINE_IMAGE
Standard description: Contains image, and was sent by dynamic rDNS

Explanation
The mail contains an image attachment, and the was received by the last trusted relay from an IP address with a reverse DNS name that suggests it is dynamically allocated.

SpamAssassin Rule: EMAIL_ROT13
Standard description: Body contains a ROT13-encoded email address

Explanation
ROT13 is defined as: The simple Caesar-cypher encryption that replaces each English letter with the one 13 places forward or back along the alphabet, so that "The butler did it!" becomes "Gur ohgyre qvq vg!" This test indicated an e-mail address was encoded using ROT13. This is normally done to hide the identity of the recipient used for list washing.

SpamAssassin Rule: EXTRA_MPART_TYPE
Standard description: Header has extraneous Content-type:...type= entry

Explanation
Message may be Multipart/Related as per RFC 2387, which is over-complicated for normal email

SpamAssassin Rule: FAKE_REPLY_C

Standard description: none

Explanation
The mail's subject begins "Re: ", indicating a reply, but does not include the References: header.

(This meta rule currently only triggers if the user agent matches a version known to include a References: header but not an In-Reply-To: header. Other rules originally covered a lack of In-Reply-To: )

Details of References: and In-Reply-To: are in RFC 2822 sec 3.6.4

SpamAssassin Rule: FB_GAPPY_ADDRESS
"Gappy" means, the email message body contains some words that were written spaced, for example F o o b a r instead of Foobar

Describe Rules/FB_SSEX here.

matches /\bssex\b/ This matches the word "ssex".

Doesn't match words like "Sussex" or "Essex" because \b means "word boundary".

It has also been disabled for years, with a score of 0. Please upgrade your spamassassin install, and run sa-update from cron daily.

SpamAssassin Rule: FH_DATE_PAST_20XX

Standard description: The date is grossly in the future.

Explanation
The rule matches the year (a string of four numbers) in the Date header, and checks if it is between 2010/2020 (depending on version) and 2099.

Note: the original rule in 3.2 started matching legitimate dates from 2010-01-01. See issues #5852 and #6269. If you are seeing this issue, you need to run the "sa-update" command.

If you need to disable this test manually, place the following in your local.cf file:

score FH_DATE_PAST_20XX 0.0
Note that this test is still in the default ruleset, albeit set to trigger after 2020. That's a short-term fix; the long-term fix is being worked on in this Bugzilla item.

SpamAssassin Rule: FH_FROMEML_NOTLD

Standard description: E-mail address doesn't have TLD (.com, etc.)

Explanation
The sender's address does not have a full Internet domain. The mail may have arrived from a misconfigured local machine that only used its local name (e.g. bilbo@hobbit), or else it is an attempt to disguise the real sender.

SpamAssassin Rule: FH_HELO_AMOST_IP

Standard description: Helo is almost an IP addr.

Explanation
An untrusted relay used a hostname (FQDN) as a HELO argument during a SMTP transaction that contains a series of numbers that might represent an IPv4 address.

One likely reason for this is that the hostname is taken from the reverse DNS entry used to indicate a dynamically allocated address (see also Rules/HELO_DYNAMIC_DHCP).

SpamAssassin Rule: FH_HELO_EQ_D_D_D_D

Standard description: Helo is d-d-d-d

Explanation
This rule checks the HELO identifier of the last untrusted relay and matches if the HELO argument contains four numbers (1 to three digits in length) separated by dashes. This is a common method for encoding IPv4 addresses into reverse DNS entries for dynamically allocated address ranges.

Since it is not usually expected that servers are given canonical hostnames that encode their IPv4 addresses, the means that the mailer process is probably using information from reverse DNS for its configuration. This indicates that it is not a normally configured mail server, and may well be a bot running on a hijacked PC.

See also Rules/HELO_DYNAMIC_IPADDR

SpamAssassin Rule: FM_DOESNT_SAY_STOCK

Standard description: It's a stock spam but doesn't say stock

Explanation
This meta rule matches mail that appears to include stock symbols and mention prices, but that doesn't include the word "stock".

SpamAssassin Rule: FM_VIAGRA_SPAM1114

Standard description: Signs of a Viagra spam 11/14/2006

Explanation
This is a meta-rule that applies to messages with a Message-Id that begins "000001c" and matches one of the following regexps in its body:

m'c[il1]a[a-z]{2,7}\shttp://'i

m'v[il1]a[a-z]{2,7}\shttp://'i

m'\bv[a-z01 ]{0,3}a.{5,25}http://'i

m'PH[A-Za-z]{6,10}\b.{3,29}\shttp://'

SpamAssassin Rule: FORGED_MSGID_HOTMAIL

Standard description: Message-ID is forged, (hotmail.com)

Explanation
The message headers include a Message-ID characteristic of Hotmail, but the message was not received from the Hotmail domain.

SpamAssassin Rule: FORGED_MUA_OUTLOOK

Standard description: Forged mail pretending to be from MS Outlook

Explanation
The message headers include those generated by Microsoft Outlook, such as X-Mailer, but the syntax is not the same as created by genuine Microsoft software.

This suggests that the message was created by a mailout program rather than a user with a Microsoft email client.

SpamAssassin Rule: FORGED_OUTLOOK_HTML
Standard description: Outlook can't send HTML message only

Explanation
The message contains only an HTML part, but pretends to be generated by Microsoft Outlook. This suggests the message is generated by a badly-written mailout program, rather than a genuine Outlook client.

SpamAssassin Rule: FORGED_OUTLOOK_TAGS

Standard description: Outlook can't send HTML in this format

Explanation
The message headers include those generated by Microsoft Outlook, such as X-Mailer, but the HTML is not the same as created by genuine Microsoft software.

SpamAssassin Rule: FORGED_RCVD_HELO

Standard description: Received: contains a forged HELO

Explanation
Every outgoing mail server SHOULD announce its FQDN (fully qualified Domain Name) in the first line of the SMTP session (note, only EHLO is REQUIRED to be a valid FQDN), however, many anti-spam systems at large ISP's and email providers are rejecting email sessions and email from hosts that appear to 'forge' their HELO line.

Many 'default' installations may 'forge' a helo line of 'localhost.localdomain', or 'localhost'. Or in the case of Microsoft Exchange server inside a local network, it may (by default) use the LOCAL name, associated with the LOCAL, internal ip address, not the external name for the external ip address.

Further Info
Example: Microsoft server at ip address 192.168.1.2, internal name is mail.local. External (Natted, public ip address) is 204.89.240.175, external name is not.mail.spammertrap.com

The 'received' line looks like this: Received: from mail.local (not.mail.spammertrap.com [204.89.240.175])

To Fix: Make sure the FQDN hostname and IP address match REVERSE and Forward DNS lookups. Then see the documentation for your OUTBOUND mail server.

Note: this rule is not part of SpamAssassin 3.2's standard ruleset! I've no idea why. -MrElvey

SpamAssassin Rule: FORGED_YAHOO_RCVD

Standard description: 'From' yahoo.com does not match 'Received' headers

Explanation
The address in the From: header contains a Yahoo address, but the Received headers do not show the mail originating from yahoo.com servers.

SpamAssassin Rule: FREEMAIL_FROM

Standard description: Sender email is freemail

Explanation
This test indicates the FreeMail plugin is active in the local configuration.

The domain of the sender has been identified as that of a free email provider. (e.g. gmail.com or hotmail.com)

Further Info

The default list of known freemail domains is distributed in 20_freemail_domains.cf.

Local configuration can be modified to add or whitelist domains:

ifplugin Mail::SpamAssassin::Plugin::FreeMail
freemail_domains example.com
freemail_whitelist example.org
endif

Describe Rules/FROM_BLANK_NAME here.

The "From:" header contains a blank name, matching this regular expression: /(?:\s|^)"" <\S+>/i . For example:

From: "" <foo@example.com>

This is legal, but rare and pointless.

SpamAssassin Rule: FROM EXCESS BASE64

Standard description: From: base64 encoded unnecessarily

Explanation
The From: line has been encoded, but can already be expressed in US-ASCII. This is likely an obfuscation technique.

Further Info

Mail header encoding is defined in RFC 2047.

SpamAssassin Rule: FROM_ILLEGAL_CHARS

Standard description: From: has too many raw illegal characters

Explanation
The From header contains 8-bit and other illegal characters that should be MIME encoded, as described in RFC 2045

This suggests that the sender is using badly-written mailout software, rather than a regular email program.

SpamAssassin Rule: FROM_LOCAL_NOVOWEL

Standard description: From: localpart has series of non-vowel letters

Explanation
The localpart (left of the "@") contains a row of 7 non-vowel characters. This is a good indication that this isn't a valid personal email address being used.

SpamAssassin Rule: FROM_MISSPACED

Standard description: From: missing whitespace

Explanation
In the From: header, the whitespace separating the display name from the angle brackets containing the email address is missing. Invalid formatting of headers can prevent various validation checks from succeeding, and also indicates the software used to send mail does not conform to this standard.

For example:

From: Example Sender<sender@example.com>

(Note that many mail clients, when formatting the received mail for reading, will display the missing space.)

Further Info

Mail header encoding is defined in RFC 5322.

SpamAssassin Rule: FS_NEW_XXX

Standard description: Subject looks like Fharmacy spams.

Explanation
The subject header field matches the regexp /^Re: news? [a-z]{1,5}$/

e.g: Subject: Re: new pill

SpamAssassin Rule: FS_START_DOYOU2
Standard description: Subject starts with Do you dream,have,want,love, etc.

Explanation
As per the description, the Subject: header line begins with "Do you like" or similar.

SpamAssassin Rule: FUZZY_CPILL
Standard description: Attempt to obfuscate words in spam

Explanation
This rule matches what appears to be an attempt to obfuscate the word "Cialis" - a brand-name for Tadalafil, a drug used for treating erectile disfunction.

Further Info

This rule uses the ReplaceTags plugin.

SpamAssassin Rule: FUZZY_OCR

Standard description: Mail contains an image with common spam text inside

Explanation
This is not a standard Spamassassin rule, but is generated by the FuzzyOcrPlugin.

SpamAssassin Rule: FUZZY_XPILL

Standard description: Attempt to obfuscate words in spam

Explanation
Message contains the name of a pharmaceutical product written to avoid keyword filtering.

SpamAssassin Rule: GTUBE
Standard description: Generic Test for Unsolicited Bulk Email

Explanation
This rule is used to test spam detection machinery. Presence of the GTUBE marker in email should always trigger spam detection.

SpamAssassin Rule: HABEAS_ACCREDITED_COI
Standard description: Habeas Accredited Confirmed Opt-In or Better

Explanation
The IP address of the sender was whitelisted by Return Path, an online reputation accreditor. An DNS lookup is made using the DNSBL service provided by habeas.com to determine the assigned "Permission Level" of the sender. The value returned for this test is from 10 to 39.

10 to 39 : Personal, transactional, and Confirmed Opt In

40 to 59 : Secure referrals and Single Opt In
60 to 99 : Checked but not accredited by Return Path.
Further Info

Spam sent from a Safelisted IP address should be reported to habeas.com@abuse.net .

History
The Safelist program was originally operated by Habeas, which was purchased by Return Path in 2008.

SpamAssassin Rule: HABEAS_ACCREDITED_SOI
Standard description: Habeas Accredited Opt-In or Better

Explanation
The IP address of the sender was whitelisted by Return Path, an online reputation accreditor. An DNS lookup is made using the DNSBL service provided by habeas.com to determine the assigned "Permission Level" of the sender. The value returned for this rule is from 40 to 59.

10 to 39 : Personal, transactional, and Confirmed Opt In
40 to 59 : Secure referrals and Single Opt In

60 to 99 : Checked but not accredited by Return Path.
Further Info

Spam sent from a Safelisted IP address should be reported to habeas.com@abuse.net .

History
The Safelist program was originally operated by Habeas, which was purchased by Return Path in 2008.

SpamAssassin Rule: HABEAS_CHECKED

Standard description: Habeas Checked

Explanation
The IP address of the sender was checked by Return Path, an online reputation accreditor. An DNS lookup is made using the DNSBL service provided by habeas.com to determine the assigned "Permission Level" of the sender. The value for this rule is from 60 to 99.

10 to 39 : Personal, transactional, and Confirmed Opt In
40 to 59 : Secure referrals and Single Opt In
60 to 99 : Checked but not accredited by Habeas.

This rule has an insignificant effect on the score, compared to HABEAS_ACCREDITED_COI and HABEAS_ACCREDITED_SOI.

Further Info

Spam sent from a Safelisted IP address should be reported to habeas.com@abuse.net .

History
The Safelist program was originally operated by Habeas, which was purchased by Return Path in 2008.

SpamAssassin Rule: HASHCASH_20

Standard description: Contains valid Hashcash token (20 bits)

Explanation
The sender added a unique unspent Hashcash token to the message, indicating that it is unlikely to be bulk email

See HashCash.

SpamAssassin Rule: HASHCASH_21

Standard description: Contains valid Hashcash token (21 bits)

Explanation
The sender added a unique unspent Hashcash token to the message, indicating that it is unlikely to be bulk email

See HashCash.

SpamAssassin Rule: HASHCASH_22
Standard description: Contains valid Hashcash token (22 bits)

Explanation
The sender added a unique unspent Hashcash token to the message, indicating that it is unlikely to be bulk email

See HashCash.

SpamAssassin Rule: HASHCASH_23

Standard description: Contains valid Hashcash token (23 bits)

Explanation
The sender added a unique unspent Hashcash token to the message, indicating that it is unlikely to be bulk email

See HashCash.

SpamAssassin Rule: HASHCASH_24

Standard description: Contains valid Hashcash token (24 bits)

Explanation
The sender added a unique unspent Hashcash token to the message, indicating that it is unlikely to be bulk email

See HashCash.

SpamAssassin Rule: HASHCASH_25

Standard description: Contains valid Hashcash token (25 bits)

Explanation
The sender added a unique unspent Hashcash token to the message, indicating that it is unlikely to be bulk email

See HashCash.

SpamAssassin Rule: HASHCASH_2SPEND

Standard description: Hashcash token already spent in another mail

Explanation
The sender added an unexpired Hashcash token to the message which has been marked as already spent. This may indicate that the message is spam.

See HashCash.

SpamAssassin Rule: HASHCASH_HIGH

Standard description: Contains valid Hashcash token (> 25 bits)

Explanation
The sender added a unique unspent Hashcash token to the message, indicating that it is unlikely to be bulk email

See HashCash.

SpamAssassin Rule: HELO_DYNAMIC_DHCP

Standard description: Relay HELO'd using suspicious hostname (DHCP)

Explanation
An untrusted relay used a hostname (FQDN) as a HELO argument during a SMTP transaction that appears to suggest a dynamically allocated hostname. For example "dhcp192-0-2-32.example.com".

This style of hostname is commonly found in the reverse DNS records for dynamically allocated addresses. It's possible that a spam-engine on a hijacked PC will use a reverse DNS lookup of its own address to formulate a valid HELO argument.

Further Info

See also Rules/HELO_DYNAMIC_IPADDR

The IETF's dnsop working group has a draft memo regarding a suggested naming scheme for reverse DNS.

SpamAssassin Rule: HELO_DYNAMIC_IPADDR

Standard description: Relay HELO'd using suspicious hostname (IP addr 1)

Explanation
The sender was identified by an upstream relay as using a numeric HELO address. It is probably not a regular email client using an authorized relay.

SpamAssassin Rule: HELO_DYNAMIC_IPADDR2

Standard description: Relay HELO'd using suspicious hostname (IP addr 2)

Explanation
The sender was identified by an upstream relay as using a numeric HELO address. It is probably not a regular email client using an authorized relay.

SpamAssassin Rule: HELO_LH_LD

Standard description: none

Explanation
One of the untrusted mail relays identified itself as localhost.localdomain in the SMTP session. This indicates a poorly configured server, possibly one not intended for sending mail.

SpamAssassin Rule: HS_INDEX_PARAM

Standard description: Link contains a common tracker pattern.

Explanation
The mail contains a URL which includes a query parameter, such as http://example.com/?12345 . These URLs are often used in mass mailouts to track individual responses.

SpamAssassin Rule: HTML_EXTRA_CLOSE

Standard description: HTML contains far too many close tags

Explanation
The message contains unbalanced HTML. This suggests that it was not generated by a normal email client or HTML editor, but by some mailout software that is trying to hide hashbusting text or otherwise avoid filters.

SpamAssassin Rule: HTML_FONT_LOW_CONTRAST

Attempts to hide message (probably scored nicely by bayes )

For example light gray on white or dark gray on black...

bgcolor="#f7f7f7" color:"#ffffff"

Expand/correct this PLEASE.

SpamAssassin Rule: HTML_FONT_SIZE_HUGE

Standard description: HTML font size is huge

Explanation
Message is HTML with some text in an unnaturally large font size

SpamAssassin Rule: HTML_FONT_SIZE_LARGE

Standard description: HTML font size is large

Explanation
Message is HTML with some text in an unnaturally large font size

SpamAssassin Rule: HTML_IMAGE_ONLY_04

Standard description: HTML: images with 0-400 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_ONLY_08

Standard description: HTML: images with 400-800 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_ONLY_12

Standard description: HTML: images with 800-1200 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_ONLY_16

Standard description: HTML: images with 1200-1600 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_ONLY_20

Standard description: HTML: images with 1600-2000 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_ONLY_24

Standard description: HTML: images with 2000-2400 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_ONLY_28

Standard description: HTML: images with 2400-2800 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_ONLY_32

Standard description: HTML: images with 2800-3200 bytes of words

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_RATIO_02

Standard description: HTML has a low ratio of text to image area

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_RATIO_04

Standard description: HTML has a low ratio of text to image area

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_RATIO_06

Standard description: HTML has a low ratio of text to image area

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_IMAGE_RATIO_08

Standard description: HTML has a low ratio of text to image area

Explanation
This may indicate a message using an image instead of words in order to sidestep text-based filtering.

SpamAssassin Rule: HTML_MESSAGE

Standard description: HTML included in message

Explanation
HTML messages are more visually attractive than plain text.

SpamAssassin Rule: HTML_MIME_NO_HTML_TAG

Standard description: HTML-only message, but there is no HTML tag

Explanation
The Content-type indicates an HTML message, but the content doesn't include an <html> tag.

SpamAssassin Rule: HTML_MISSING_CTYPE

Standard description: Message is HTML without HTML Content-Type

Explanation
The message is HTML, but lacks the MIME Content-Type header required by RFC 2045. This probably indicates a message generated by a badly-written email application, rather than a standard email client.

SpamAssassin Rule: HTML_OBFUSCATE_05_10

Standard description: Message is 05% to 10% HTML obfuscation

Explanation
The message includes HTML with obfuscated text, such as unnecessary hex-encoding of ASCII characters. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTML_OBFUSCATE_10_20

Standard description: Message is 10% to 20% HTML obfuscation

Explanation
The message includes HTML with obfuscated text, such as unnecessary hex-encoding of ASCII characters. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTML_OBFUSCATE_20_30
Standard description: Message is 20% to 30% HTML obfuscation

Explanation
The message includes HTML with obfuscated text, such as unnecessary hex-encoding of ASCII characters. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTML_OBFUSCATE_30_40
Standard description: Message is 30% to 40% HTML obfuscation

Explanation
The message includes HTML with obfuscated text, such as unnecessary hex-encoding of ASCII characters. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTML_OBFUSCATE_50_60
Standard description: Message is 50% to 60% HTML obfuscation

Explanation
The message includes HTML with obfuscated text, such as unnecessary hex-encoding of ASCII characters. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTML_OBFUSCATE_70_80
Standard description: Message is 70% to 80% HTML obfuscation

Explanation
The message includes HTML with obfuscated text, such as unnecessary hex-encoding of ASCII characters. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTML_OBFUSCATE_90_100
Standard description: Message is 90% to 100% HTML obfuscation

Explanation
The message includes HTML with obfuscated text, such as unnecessary hex-encoding of ASCII characters. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTML_SHORT_LINK_IMG_2
Standard description: HTML is very short with a linked image

Explanation
The message is HTML with only a link to an external image. This may indicate an attempt to avoid text-based filters.

SpamAssassin Rule: HTML_SHORT_LINK_IMG_3
Standard description: HTML is very short with a linked image

Explanation
The message is HTML with only a link to an external image. This may indicate an attempt to avoid text-based filters.

SpamAssassin Rule: HTTPS_IP_MISMATCH
Standard description: IP to HTTPS link found in HTML

Explanation
Looks for links that look like this:

<a href="http://1.2.3.4/">https://www.paypal.com/</a>

Often found in phishing attempts, seldom seen in legitimate e-mail.

SpamAssassin Rule: HTTP_ESCAPED_HOST
Standard description: Uses %-escapes inside a URL's hostname

Explanation
The message includes HTML with an obfuscated URL. This is probably an attempt to avoid text-based filters

SpamAssassin Rule: HTTP_EXCESSIVE_ESCAPES
Standard description: Completely unnecessary %-escapes inside a URL

Explanation
Contains a URL with letters replaces by hex codes e.g. %55 for "U". This indicates an attempt to avoid domain or text-based filtering, and indicates the message is probably spam.

SpamAssassin Rule: INTERRUPTUS
Standard description: Message looks to contain HTML-interrupted text

Explanation
Looks for <HTML> code to interrupt plain text words in an attempt to hide what that word is. Common with drug spam, seen like: VIA<FOO></FOO>GRA

SpamAssassin Rule: INVALID_DATE
Standard description: Invalid Date: header (not RFC 2822)

Explanation
The Date header in the message is not compliant with RFC 2822 Sec. 3.3

This suggests the sender is using a badly-written mailout program rather than a regular email client.

SpamAssassin Rule: INVALID_DATE_TZ_ABSURD
Standard description: Invalid Date: header (timezone does not exist)

Explanation
The Date header includes an impossible UTC offset, e.g. more than +/- 13 hours This suggests the message was generated by badly-written mailout software.

SpamAssassin Rule: <INVALID MSGID>
Standard description: Message-Id is not valid, according to RFC 2822

Explanation
Matches Message-ID headers that exist but do not meet a lenient definition of valid syntax. Exempts cases of embedded comments in Message ID's

SpamAssassin Rule: INVALID_TZ_CST
Standard description: Invalid date in header (wrong CST timezone)

Explanation
The Date header includes a UTC offset which is not valid for CST (Central Standard Time). This suggests the message was generated by badly-written mailout software.

SpamAssassin Rule: INVALID_TZ_EST
Standard description: Invalid date in header (wrong EST timezone)

Explanation
The Date header includes a UTC offset which is not valid for EST (Eastern Standard Time). This suggests the message was generated by badly-written mailout software.

SpamAssassin Rule: JM_REACTOR_MAILER
Standard description: Header patterns indicative of "Reactor Mailer" ratware

Explanation
This matches a series of signatures in the mail header indicating it was sent by the "Reactor Mailer" / Trojan.Srizbi .

SpamAssassin Rule: MIME_BAD_ISO_CHARSET
Standard description: MIME character set is an unknown ISO charset

Explanation
The charset attribute of the MIME Content-Type: header is checked. A flag is raised if it is an ISO character set not recognised by the test.

Further Info

This rule checks the value of "mime_bad_iso_charset" set by MIMEEval.pm .

MIME headers are defined in RFC 2045

Valid charsets are registered with IANA.

SpamAssassin Rule: MIME_BASE64_BLANKS
Standard description: Extra blank lines in base64 encoding

Explanation
Looking for extra blank lines to appear in the BASE64 encoding. Built into EvalTests.pm

SpamAssassin Rule: MIME_BASE64_NO_NAME
Standard description: base64 attachment does not have a file name

Explanation
Normally base64 encoded attachments have some sort of file name, this indicates one is missing.

SpamAssassin Rule: MIME_BASE64_TEXT
Standard description: Message text disguised using base64 encoding

Explanation
The message contains text that has been encoded using Base64 content transfer encoding but does not use a character set known to require it. This does not apply to text in the UTF-8 or big5 character sets.

This technique is assumed to be used by spammers as a form of obfuscation, presumably to bypass filters that are not MIME-aware.

Further Info

For details on Base64 encoding see RFC 2045 sec 6.8

This rule is known to trigger false positives in some circumstances. See (buglist)

SpamAssassin Rule: MIME_HEADER_CTYPE_ONLY
Standard description: 'Content-Type' found without required MIME headers

Explanation
The specified Content-type for the mail is something other than "text/plain", so the headers must conform to the MIME specification, but one or more of the following headers have not been provided:

MIME-Version:
Content-Transfer-Encoding:
Content-Disposition:
This suggests that the message was generated by a badly-written mailout program rather than by a normal email client.

Further Info

While the MIME-Version: header is mandatory (RFC 2045 § 4) the Content-Transfer-Encoding: header defaults to "7bit" if not present (RFC 2045 § 6.1) and the Content-Disposition: header is considered optional (RFC 2183 § 2).

SpamAssassin Rule: MIME_HTML_MOSTLY
Standard description: Multipart message mostly text/html MIME

Explanation
The message has an HTML part much larger than the alternative text part, suggesting an attempt to avoid text-based filtering. Normal multipart messages have essentially the same content in each format.

SpamAssassin Rule: MIME_HTML_ONLY
Standard description: Message only has text/html MIME parts

Explanation
Indicates the message lacks the plain text alternative part.

SpamAssassin Rule: MIME_HTML_ONLY_MULTI

Standard description: Multipart message only has text/html MIME parts

Explanation
A multipart message usually has HTML and plain text alternatives of the same content. One with only HTML parts may indicate an attempt to avoid text-based filters.

SpamAssassin Rule: MIME_MISSING_BOUNDARY
Standard description: MIME section missing boundary

Explanation
Looks to see if any multipart boundaries are not "balanced"

SpamAssassin Rule: MIME_QP_LONG_LINE
Standard description: Quoted-printable line longer than 76 chars

Explanation
The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long. See RFC 2045.

Further Info

Although the Quoted-Printable specification requires lines be no more than 76 characters, many implementations ignore this and use a suggested line limit from RFC 5322 of 78 characters. Therefore it is not unusual to see this rule triggered by non-spam. See Bug 5491.

SpamAssassin Rule: MISSING_DATE
Standard description: Missing Date: header

Explanation
The message does not contain a Date: header. The relevant standards specify that mails should include a Date: header.

Further Info

The Date header is detailed in RFC 2822 sec 3.6.1.

SpamAssassin Rule: MISSING_HEADERS
Standard description: Missing To: header

Explanation
The mail header does not contain a To: line.

Further Info

The To: header is described in RFC 2822 sec 3.6.3 - note that it is not a mandatory field, but it is considered unusual for MUA software not to add it.

SpamAssassin Rule: MISSING_MID
Standard description: Missing Message-Id: header

Explanation
The message does not contain a Message-Id header. The relevant standards specify that mails should have Message-Id headers. All properly written Mail User Agent (or Mail Submission Agent) software is expected to add a Message-Id header.

This suggests that the mail was sent by badly-configured mailout software rather than by a normal email client.

Further Info

The Message-Id header is detailed in RFC 2822 sec 3.6.4.

SpamAssassin Rule: MISSING_MIMEOLE
Standard description: Message has X-MSMail-Priority, but no X-MimeOLE

Explanation
The message is pretending to be generated by a Microsoft email program which uses the extension header X-MSMail-Priority, but is missing the extension header X-MimeOLE which is characteristic of Microsoft email.

This suggests that the sender is using badly-written mailout software, rather than a genuine Microsoft email program.

SpamAssassin Rule: MISSING_MIME_HB_SEP
Standard description: Missing blank line between MIME header and body

Explanation
The format for e-mail requires a blank line between the headers and the body of a message, the lack of one causes this rule to fire.

SpamAssassin Rule: MISSING_SUBJECT
Standard description: Missing Subject: header

Explanation
The message does not have a Subject header.

Further Info

The Subject header is an optional field described in RFC 2822.

SpamAssassin Rule: MPART_ALT_DIFF
Standard description: HTML and text parts are different

Explanation
The mail contains the content in both HTML and plain text format, but their content is (very probably) different. This suggests that the sender is not using a normal mail client, and is attempting to evade filtering by using a message which looks different to humans and mail filters.

SpamAssassin Rule: MPART_ALT_DIFF_COUNT
Standard description: HTML and text parts are different

Explanation
The mail contains the content in both HTML and plain text format, but their content is (very probably) different - the number of words is significantly different in the two versions. This suggests that the sender is not using a normal mail client, and is attempting to evade filtering by using a message which looks different to humans and mail filters.

SpamAssassin Rule: MSGID_FROM_MTA_HEADER
Standard description: Message-Id was added by a relay

Explanation
The Message-Id header appears above at least one Received header in the message. This is a good indication that the Message-Id was generated by a relay, rather than by the user agent. This may be an indication of poorly behaved mailing software.

Further Info

Message-Id is defined as an optional field that should be present ( RFC 2822 sec 3.6.4).

SpamAssassin Rule: MSGID_MULTIPLE_AT
Standard description: Message-ID contains multiple '@' characters

Explanation
The Message-Id: header contains more than one "@" characters, rendering it invalid. Invalid Message-Id headers have been seen generated by some types of spamming software.

Further Info

The syntax for the Message-Id field is defined in RFC 2822 sec 3.6.4, as well as recommended algorithms.

Bug #5707 suggests that Microsoft Office Outlook 12.0 (a.k.a Office Outlook 2007) generates invalid Message-Id fields, triggering this rule.

Note: Since dot-atom-text does not include the @ symbol, multiple instances usually indicate an invalid Message-Id. However it is possible for a syntactically valid (per RFC2822) Message-Id field to contain multiple "@" symbols under the circumstances that the id-left component consists of a double-quoted string (where qtext can contain %d64, although this format is now marked as obsolete by RFC5322) or inside id-right as part of a literal address string. For example:

{{{Message-Id: <"12345@example.org"@host.example.com>

Message-Id: <12345@[123@456]> Message-Id: <"12345@example.org"@[123@456]>}}} This particular usage, however, is not currently covered by this rule and is not known to be in the wild.

SpamAssassin Rule: MSGID_NO_HOST

Standard description: Message-Id has no hostname

Explanation
Normal Message-ID: headers look something like

Message-ID: <gibber.ish@somehost.tld>

A message ID without anything after the @ fires MSGID_NO_HOST

SpamAssassin Rule: MSGID_OUTLOOK_INVALID
Standard description: Message-Id is fake (in Outlook Express format)

Explanation
The Message-Id header has the format of one generated by Microsoft Outlook Express, which is based on the date, but the inferred date is inconsistent with other date headers.

Describe Rules/MSGID SPAM CAPS here.

MSGID or message-id is unique identifier in the email header. The same message ID may not be reused during the lifetime of any email with the same message ID. (It is recommended that no message ID be reused for at least two years.) In order to conform to RFC 822, the Message-ID must have the format

"<" "unique" "@" "full domain name" ">"

this rule activates when "unique" is all in capitals.

SpamAssassin Rule: MSOE_MID_WRONG_CASE
Standard description: none

Explanation
The mail identifies itself as being sent using Microsoft Outlook Express, however the header is "Message-Id:" rather than "Message-ID:".

SpamAssassin Rule: MULTIPART_ALT_NON_TEXT
Standard description: eval:check_ma_non_text()

Explanation
<explanation of the rule goes here>

SpamAssassin Rule: NA_DOLLARS
Standard description: Talks about a million North American dollars

Explanation
The body of the mail makes reference to millions of US or Canadian dollars, a common signature that can help identify scam emails.

SpamAssassin Rule: NML_ADSP_CUSTOM_MED
Standard description: ADSP custom_med hit, and not from a mailing list

Explanation
The presence of this test indicates that DKIM support is enabled on the server.

This is a meta rule which matches a mail not containing a valid DKIM signature where the domain of the sending address has been matched by an override setting (adsp_override), and where the mail does not appear to have come via a mailing list or remailer.

See DKIM_ADSP_CUSTOM_MED

SpamAssassin Rule: NO_DNS_FOR_FROM
Standard description: Envelope sender has no MX or A DNS records

Explanation
The return address is fake. The sender has no interest in knowing whether the message was delivered or not, and does not wish anyone to receive a large number of delivery failed reports.

SpamAssassin Rule: NO_REAL_NAME
Standard description: From: does not include a real name

Explanation
Normally a "From" header looks like:

From: "John Doe" <johndoe@somedom.tld>

This rule fires when no name is given in the from header.

SpamAssassin Rule: NO_RELAYS
Standard description: Informational: message was not relayed via SMTP

Explanation
This indicates no "Received" headers in the mail.

SpamAssassin Rule: NUMERIC_HTTP_ADDR
Standard description: Uses a numeric IP address in URL

Explanation
Contains a URL with a numeric address, such as http://192.168.36.67 This may indicate a webserver set up quickly without a DNS entry, or an attempt to avoid domain-based filtering. This indicates the message may be spam or phishing.

SpamAssassin Rule: PART_CID_STOCK
Standard description: Has a spammy image attachment (by Content-ID)

Explanation
HTML message contains an inline image with a Content-ID header characteristic of some mailout software used for spam.

SpamAssassin Rule: PLING_QUERY
Standard description: Subject has exclamation mark and question mark

Explanation
This rule matches subject lines that contain both an exclamation mark (a pling) and a question mark.

Subject: Do you want a larger pling? Act now!

SpamAssassin Rule: PYZOR_CHECK
Standard description: Listed in Pyzor (http://pyzor.sf.net/)

Explanation
Pyzor is a collaborative, networked system to detect and block spam using digests of messages. It uses a fuzzy checksum technique to identify message bodies based on signatures submitted by users, or inferred by other techniques such as high-confidence Bayesian or DNSBL entries.

Pyzor initially started out to be merely a Python implementation of Razor, but due to the protocol and the fact that Razor's server is not Open Source or software libre, Frank Tobin decided to implement Pyzor with a new protocol and release the entire system as Open Source and software libre.

SpamAssassin Rule: RATWARE_MS_HASH
Standard description: Bulk email fingerprint (msgid ms hash) found

Explanation
The Message-Id in the header seems to be generated using a scheme found in Microsoft software, but has no other identifiers to confirm that this software was used. This is known to be a possible ratware identifier.

SpamAssassin Rule: RATWARE_OUTLOOK_NONAME
Standard description: Bulk email fingerprint (Outlook no name) found

Explanation
The Message-Id in the header seems to be generated using a scheme found in Microsoft software, but is missing a specific identifier to confirm that this software was used.

Further Info

See also: Rules/RATWARE_MS_HASH

SpamAssassin Rule: RAZOR2_CF_RANGE_51_100
Standard description: Razor2 gives confidence level above 50%

Explanation
Vipul's Razor is a distributed, collaborative, spam detection and filtering network. It uses a fuzzy checksum technique to identify message bodies based on signatures submitted by users, or inferred by other techniques such as high-confidence Bayesian or DNSBL entries.

SpamAssassin Rule: RAZOR2_CF_RANGE_E4_51_100
Standard description: Razor2 gives engine 4 confidence level above 50%

Explanation
Vipul's Razor is a distributed, collaborative, spam detection and filtering network. It uses a fuzzy checksum technique to identify message bodies based on signatures submitted by users, or inferred by other techniques such as high-confidence Bayesian or DNSBL entries.

SpamAssassin Rule: RAZOR2_CF_RANGE_E8_51_100
Standard description: Razor2 gives engine 8 confidence level above 50%

Explanation
Vipul's Razor is a distributed, collaborative, spam detection and filtering network. It uses a fuzzy checksum technique to identify message bodies based on signatures submitted by users, or inferred by other techniques such as high-confidence Bayesian or DNSBL entries.

SpamAssassin Rule: RAZOR2_CHECK
Standard description: Listed in Razor2 (http://razor.sf.net/)

Explanation
Vipul's Razor is a distributed, collaborative, spam detection and filtering network. It uses a fuzzy checksum technique to identify message bodies based on signatures submitted by users, or inferred by other techniques such as high-confidence Bayesian or DNSBL entries.

SpamAssassin Rule: RCVD_BAD_ID
Standard description: none

Explanation
One of the trace fields (Received: headers) contains an unusually formatted ID parameter.

Further Info

Note: matching this rule does not necessarily infer that the Received: header is invalid or non-standard, only unusual.

The format of the Received: header is defined in RFC 2821 sec 4.4 (which references atext defined in RFC 2822 ) and allows for characters beyond the ASCII alpha/digit/underscore/minus usually seen in IDs.

SpamAssassin Rule: <RCVD_HELO_IP_MISMATCH>
Standard description: HELO and IP do not match, but should

Explanation
Checks if a HELO string is an IP, and if it is, that it matches the actual IP (or is in the same /24). (It doesn't fire if the HELO string is a hostname or private (RFC 1918) or trusted IP.)

SpamAssassin Rule: RCVD_ILLEGAL_IP
Standard description: Received: contains illegal IP address

Explanation
A check is made of the IP addresses listed in the Received lines in the mail header using RelayEval.pm. This test identifies IPv4 addresses that are invalid according the the allowable address space, as well as addresses that should never be seen as a source of mail.

The valid, but unusable, address ranges are as follows:

0/8 Reserved
1/8 Unallocated
2/8 Unallocated
7/8 Live allocation - US DoD
127/8 Loopback range (excepting localhost 127.0.0/24)
223/8 Unallocated
224/4 Multicast
Note that ranges currently marked "Unallocated" will probably be allocated by IANA at some point in the future.

Failure of this test suggests that the mailout software added extra message headers to disguise the real source of the message, or else is not using a professionally run network.

Further Info

See also: IANA IPv4 Allocation RFC 3330 Special-Use IPv4 Addresses

7.0.0.0/8 is allocated to the US Department of Defense. It was previously listed by IANA as 'Reserved' causing it to be added to "network bogon" lists. For its current use, it is not expected that traffic originating from this range will routed outside of this range. However, it's not clear that legitimate mail headers wouldn't contain IP addresses from this range.

SpamAssassin Rule: RCVD_IN_BL_SPAMCOP_NET
Standard description: RBL: Received via a relay in bl.spamcop.net

Explanation
A relay in the message's Received headers was listed in the Spamcop DNSBL; see http://spamcop.net/ .

Further Info

For the SpamCop URI block list see Rules/URIBL_SC_SURBL .

SpamAssassin Rule: RCVD_IN_BRBL_LASTEXT
Standard description: None

Explanation
The last external relay in the Received chain was listed in the DNSBL Barracuda Reputation Block List (BRBL).

The Barracuda Reputation Block List (BRBL) is based on the Barracuda Reputation System and operates collaboratively to fight spam. The BRBL provides a list of IP addresses which are sending spam. The Barracuda Reputation system uses automated collection methods to add and delete IP addresses from the BRBL.

Further Info

See: http://www.barracudacentral.org/rbl/removal-request for details on requesting removal from this list.

SpamAssassin Rule: RCVD_IN_BSP_OTHER
Standard description: Sender is in Bonded Sender Program (other relay)

Explanation
The sender's IP address was listed by the Sender Score Certified DNSBL white list, operated by Return Path.

Further Info

Spam sent from a Certified IP address should be reported to senderscorecertified.com@abuse.net .

History
The Bonded Sender Program (BSP) program was originally operated by Ironport, and was sold to Return Path in 2005. It was later renamed to Sender Score Certified (SSC), following many improvements to the membership criteria.

Bug #5977 mentions a lack of a clear complaint procedure available to the SpamAssassin community. This has now been resolved.

SpamAssassin Rule: RCVD_IN_BSP_TRUSTED
Standard description: Sender is in Sender Score Certified (trusted relay)

Explanation
The sender's IP address was listed by the Sender Score Certified DNSBL white list, operated by Return Path.

Further Info

Spam sent from a Certified IP address should be reported to senderscorecertified.com@abuse.net .

History
The Bonded Sender Program (BSP) program was originally operated by Ironport, and was sold to Return Path in 2005. It was later renamed to Sender Score Certified (SSC), following many improvements to the membership criteria.

Bug #5977 mentions a lack of a clear complaint procedure available to the SpamAssassin community. This has now been resolved.

SpamAssassin Rule: RCVD_IN_DNSWL_HI
Standard description: Sender listed at http://www.dnswl.org/, high trust

Explanation
dnswl.org is a community-driven project to prevent false positives. dnswl.org provides a DNS-based whitelist of known legitimate hosts in different categories/trust levels.

The policy says for trust level "hi": High Never sends spam.

Report Problems
If you get spam from IPs that hit this rule, you can report them here: http://www.dnswl.org/registerreporter.pl

As with many SpamAssassin network rules, it is important to make sure you have your trusted_networks / internal_networks (TrustPath) configured correctly to ensure that the test is run against the correct IP.

IPs that are not listed which should be can be reported here: http://www.dnswl.org/request.pl

You can also contact the maintainers of this data at admins@dnswl.org

SpamAssassin Rule: RCVD_IN_DNSWL_LOW
Standard description: Sender listed at http://www.dnswl.org/, low trust

Explanation
dnswl.org is a community-driven project to prevent false positives. dnswl.org provides a DNS-based whitelist of known legitimate hosts in different categories/trust levels.

The policy says for trust level "low": Low Occasional spam occurrences, actively corrected but less promptly.

Report Problems
IPs sending spam are expected to hit this rule, but if you get so many emails sending spam, and none sending non-spam, that you think it shouldn't be listed, you can report them here: http://www.dnswl.org/registerreporter.pl

As with many SpamAssassin network rules, it is important to make sure you have your trusted_networks / internal_networks (TrustPath) configured correctly to ensure that the test is run against the correct IP.

IPs that are not listed which should be can be reported here: http://www.dnswl.org/request.pl

You can also contact the maintainers of this data at admins@dnswl.org

SpamAssassin Rule: RCVD_IN_DNSWL_MED
Standard description: Sender listed at http://www.dnswl.org/, medium trust

Explanation
dnswl.org is a community-driven project to prevent false positives. dnswl.org provides a DNS-based whitelist of known legitimate hosts in different categories/trust levels.

The policy says for trust level "med": Medium Extremely rare spam occurrences, corrected promptly.

Report Problems
If you get spam from IPs that hit this rule, you can report them here: http://www.dnswl.org/registerreporter.pl

As with many SpamAssassin network rules, it is important to make sure you have your trusted_networks / internal_networks (TrustPath) configured correctly to ensure that the test is run against the correct IP.

IPs that are not listed which should be can be reported here: http://www.dnswl.org/request.pl

You can also contact the maintainers of this data at admins@dnswl.org

SpamAssassin Rule: RCVD_IN_DNSWL_NONE
Standard description: Sender listed at http://www.dnswl.org/, no trust

Explanation
dnswl.org is a community-driven project to prevent false positives. dnswl.org provides a DNS-based whitelist of known legitimate hosts in different categories/trust levels.

The policy says for trust level "None":

Legitimate mail server, may also send spam. This is the default for some categories (eg Email Marketing Provider)

Report Problems
IPs sending spam are expected to hit this rule, but if you get so many emails sending spam, and none sending non-spam, that you think it shouldn't be listed, you can report them here: http://www.dnswl.org/registerreporter.pl

As with many SpamAssassin network rules, it is important to make sure you have your trusted_networks / internal_networks (TrustPath) configured correctly to ensure that the test is run against the correct IP.

IPs that are not listed which should be can be reported here: http://www.dnswl.org/request.pl

You can also contact the maintainers of this data at admins@dnswl.org

SpamAssassin Rule: RCVD_IN_DOB
Standard description: Received via relay in new domain (Day Old Bread)

Explanation
The mail was relayed via a server using a domain listed in the DNSBL dob.sibl.support-intelligence.net - which lists domains registered in the last five days.

Further Info

See also: URIBL_RHS_DOB DNS_FROM_DOB

SpamAssassin Rule: RCVD_IN_DSBL
Standard description: Received via a relay in list.dsbl.org

Explanation
The last external relay the mail passed through matched an entry on the dsbl.org, a DNSBL listing open relays, badly-installed CGI scripts and open SOCKS and HTTP proxies.

Further Info

Note: As of September 2008 the DSBL is permanently offline. #5988

This test can be disabled by setting its score to 0.

score RCVD_IN_DSBL 0

SpamAssassin Rule: RCVD_IN_IADB_VOUCHED
Standard description: ISIPP IADB lists as vouched-for sender

Explanation
The sending host in the first trusted Received: header is a "Vouched listing" in the Institute for Social Internet Public Policy (ISIPP) Accreditation Database (a DNS Whitelist).

Further Info

Sites sending spam from IADB vouched IP addresses can be reported to abuse@suretymail.com.

SpamAssassin Rule: RCVD_IN_MAPS_DUL
Standard description: Relay in RBL, www.mail-abuse.org/rbl/

Explanation
The message was received via a relay listed in the DNSBL dialups.mail-abuse.org.

The criteria for listing is that the relay address appears to be dynamically allocated, indicating that it is probably a customers computer and not a properly configured mail relay

Since 2005, mail-abuse.org is operated by Trend Micro

SpamAssassin Rule: RCVD_IN_MAPS_NML
Standard description: Relay in NML, www.mail-abuse.org/nbl/

Explanation
The message was received via a relay listed in the DNSBL nonconfirm.mail-abuse.org. This DNSBL is no longer documented.

Since 2005, mail-abuse.org is operated by Trend Micro

SpamAssassin Rule: RCVD_IN_MAPS_RBL

Standard description: Relay in RBL, www.mail-abuse.org/rbl/

Explanation
The message was received via a relay listed in the DNSBL blackholes.mail-abuse.org.

The criteria for listing is that the relay address may be a multi-hop (multiple IP) open relay, a spam source, or a spam support service

Since 2005, mail-abuse.org is operated by Trend Micro

SpamAssassin Rule: RCVD_IN_MAPS_RSS
Standard description: Relay in RSS, www.mail-abuse.org/rss/

Explanation
The message was received via a relay listed in the DNSBL relays.mail-abuse.org.

The criteria for listing is that the relay address appears to be that of an "open relay" that will relay email from unauthenticated and untrusted users.

Since 2005, mail-abuse.org is operated by Trend Micro

SpamAssassin Rule: RCVD_IN_NJABL_CGI
Standard description: NJABL: sender is an open formmail

Explanation
See: http://www.njabl.org/

SpamAssassin Rule: RCVD_IN_NJABL_DUL
Standard description: NJABL: dialup sender did non-local SMTP

Explanation
See: http://www.njabl.org/

SpamAssassin Rule: RCVD_IN_NJABL_MULTI
Standard description: NJABL: sent through multi-stage open relay

Explanation
See: http://www.njabl.org/

SpamAssassin Rule: RCVD_IN_NJABL_PROXY
Standard description: NJABL: sender is an open proxy

Explanation
See: http://www.njabl.org/

Further Info

This DNSBL is also available via a Spamhaus ZEN lookup. See RCVD_IN_XBL.

SpamAssassin Rule: RCVD_IN_NJABL_RELAY
Standard description: NJABL: sender is confirmed open relay

Explanation
See: http://www.njabl.org/

SpamAssassin Rule: RCVD_IN_NJABL_SPAM
Standard description: NJABL: sender is confirmed spam source

Explanation
See: http://www.njabl.org/

SpamAssassin Rule: <RCVD_IN_PBL>
Standard description: Received via a relay in Spamhaus PBL

Explanation
The PBL official page and description is here and that page can also be used to look up an IP in the PBL.

The Spamhaus PBL is a DNSBL database of end-user IP address ranges which should not be delivering unauthenticated SMTP email to any Internet mail server, except those provided for specifically by an ISP for that customer's use. The PBL helps networks enforce their Acceptable Use Policy for dynamic and non-MTA customer IP ranges.

In other words, it lists IP addresses that are not expected to host a normal mail server, and the PBL has Self-Service removal and IP owner management mechanisms.

Further Info

Common Problems
If this rule triggers based on mails received from large mail providers (eg. United Internet / GMX or Google), chances are that SpamAssassin has a wrong view of what constitutes the local network. Unless SpamAssassin runs on, for example, a United Internet server, the Received: lines indicating that some United Internet server has taken up the message from a dynamic IP (no matter what that line says about authentication credentials) should not be evaluated; RCVD_IN_PBL is a last_internal rule. (It should trigger, however, if a server under local administration has accepted the message from a dynamic IP without indicating that proper authentication has happened).

In such situations, make sure that the TrustPath is configured correctly, and that SpamAssassin is actually working on the right headers (which can be an issue with some spamass-milter configurations).

SpamAssassin Rule: RCVD_IN_PSBL
Standard description: Received via a relay in PSBL

Explanation
The last external relay in the Received chain was listed in the DNSBL The Passive Spam Blocklist (PSBL).

The Passive Spam Block List, or PSBL, uses the Spamikaze software, which works in a really simple way. If one of my spamtraps receives email from a certain IP address, then that IP address gets listed. After a certain time the IP address times out and is automatically dropped from the list.

Further Info

See: https://psbl.org for details on removing addresses from this list.

SpamAssassin Rule: RCVD_IN_RP_RNBL
Standard description: Relay in RNBL, https://senderscore.org/blacklistlookup/

Explanation
The last external relay in the Received chain was listed in the DNSBL Return Path Reputation Network Blacklist (RNBL).

Reputation Network Blacklist is based on real time data compiled through our cooperative Reputation Network.

Further Info

See: https://senderscore.org/rtbl/ for details on requesting removal from this list.

SpamAssassin Rule: RCVD_IN_SBL
Standard description: Received via a relay in Spamhaus SBL

Explanation
The headers indicate the mail was sent via a server listed on the Spamhaus Block List (DNSBL).

The Spamhaus Block List (SBL) is a realtime database of IP addresses of spam-sources, including known spammers, spam gangs, spam operations and spam support services. SBL listings are made according to policies outlined in SBL Policy & Listing Criteria.

Further Info

For the body URI check see URIBL_SBL, and for other Spamhaus.org RBL listings see RCVD_IN_XBL RCVD_IN_PBL.

SpamAssassin Rule: RCVD_IN_SORBS_BLOCK
Standard description: SORBS: sender demands to never be tested

Explanation
This check tests the IP address of the last untrusted relay against the DNSBL maintained by SORBS.

ref

A listing indicates that the administrator of the mail relay has demanded that they never be tested by SORBS.

SpamAssassin Rule: RCVD_IN_SORBS_DUL
Standard description: SORBS: sent directly from dynamic IP address

Explanation
The last external relay in the Received chain was listed in the SORBS "DUL" list, which lists dynamic IP addresses that should not be emitting SMTP traffic directly.

SpamAssassin Rule: RCVD_IN_SORBS_HTTP
Standard description: SORBS: sender is open HTTP proxy server

Explanation
This check tests the IP address of the last untrusted relay against the DNSBL maintained by SORBS.

ref

A listing indicates that email may be sent through a webserver proxy by an unauthorized and unauthenticated user.

SpamAssassin Rule: RCVD_IN_SORBS_SMTP
Standard description: SORBS: sender is open SMTP relay

Explanation
This check tests the IP address of the last untrusted relay against the DNSBL maintained by SORBS.

ref

A listing indicates that email may be sent through a SMTP proxy by an unauthorized and unauthenticated user.

SpamAssassin Rule: RCVD_IN_SORBS_SOCKS
Standard description: SORBS: sender is open SOCKS proxy server

Explanation
This check tests the IP address of the last untrusted relay against the DNSBL maintained by SORBS.

ref

A listing indicates that email may be sent through a SOCKS proxy by an unauthorized and unauthenticated user.

SpamAssassin Rule: RCVD_IN_SORBS_WEB
Standard description: SORBS: sender is an abuseable web server

Explanation
This check tests the IP address of the last untrusted relay against the DNSBL maintained by SORBS.

web.dnsbl.sorbs.net
List of web (WWW) servers which have spammer abusable vulnerabilities (e.g. FormMail scripts) Note: This zone now includes non-webserver IP addresses that have abusable vulnerabilities. ref

Further Info

<!> This test may be applied to all untrusted relays, and not just the last untrusted relay? - see #4516.

SpamAssassin Rule: RCVD_IN_SORBS_ZOMBIE
Standard description: SORBS: sender is on a hijacked network

Explanation
This check tests the IP address of the last untrusted relay against the DNSBL maintained by SORBS.

ref

This is a list of networks hijacked from their original owners, some of which have already used for spamming.

SpamAssassin Rule: RCVD_IN_XBL
Standard description: Received via a relay in Spamhaus XBL

Explanation
The mail was received from a server listed in the Spamhaus Exploits Block List DNSBL, which lists hijacked PCs infected by illegal 3rd party exploits.

The XBL wholly incorporates data from two highly-trusted DNSBL sources, with tweaks by Spamhaus to maximise the data efficiency and lower False Positives. The main components are:

the CBL (Composite Block List) from cbl.abuseat.org

the NJABL Open Proxy IPs list from www.njabl.org.

SpamAssassin Rule: RCVD_NUMERIC_HELO
Standard description: Received: contains an IP address used for HELO

Explanation
In an SMTP session the argument to the first command a client sends (EHLO or HELO) should be the client identifier. RFC2821 specifies the fully-qualified domain name of the SMTP client, the older standard RFC821 refers to the host name.

In situations that the client does not have a meaningful domain name the client SHOULD send an address literal (an IP address enclosed by square brackets).

If a Received: header is parsed that indicates the EHLO/HELO identifier was given as an IP address, but not enclosed by square brackets, this is in violation of the RFC.

SpamAssassin Rule: RDNS_DYNAMIC
Standard description: Delivered to trusted network by host with dynamic-looking rDNS

Explanation
The reverse DNS of the last untrusted relay is checked, if authentication is not used, against a number of rules that attempt to determine if the IP address is static, or dynamically allocated. Legitimate mail servers would usually be expected to have static allocations.

There are no widely adopted standards for indicating the allocation type in reverse DNS, however it is possible to interpret the naming conventions used by some sites to derive this information. Reverse mapped names that contain sections matching strings such as "dynamic", "dhcp", "adsl" etc. may be matched by this rule, as may names that contain strings of numbers.

Further Information

The IETF's dnsop working group has a draft memo regarding a suggested naming scheme and a draft memo regarding the use of reverse DNS for testing.

SpamAssassin Rule: RDNS_NONE
Standard description: Delivered to trusted network by a host with no rDNS

Explanation
This test checks to see if there is a PTR record (reverse DNS) for the last untrusted relay, which points to a domain with a matching A record. The name is a little confusing, because it's Forward Confirmed reverse DNS that we're looking for, not just any PTR record.

Note that this may be done by interpreting information in the relevant Received header - if reverse DNS checks are not performed by the first trusted relay, or if they are not recorded in the Received header, this test will be triggered (regardless of the actual rDNS status).

The IETF's dnsop working group has a draft memo regarding the use of reverse DNS for testing.

SpamAssassin Rule: REMOVE_BEFORE_LINK
Standard description: Removal phrase right before a link

Explanation
A phrase such as "unsubscribe here", "no thanks", or "not interested" appears in the message body no more than five characters before a URL

SpamAssassin Rule: REPTO_QUOTE_YAHOO
Standard description: Yahoo! doesn't do quoting like this

Explanation
The Reply-To header is in a different format than that used by the purported sender at yahoo.com.

This suggests that the message was not, in fact, sent from a Yahoo address.

SpamAssassin Rule: RFC_ABUSE_POST
Standard description: Both abuse and postmaster missing on sender domain

Explanation
This test indicates the DNSEval plugin is active in the local configuration.

The domain of the sender has been checked against the DNS-based blocklist at RFC-Ignorant.Org and has been identified as not having a working "abuse@" or "postmaster@" address for the domain.

Further Info

This rule has been removed from SpamAssassin.

As of October 2012 this DNSBL will be unavailable.

SpamAssassin Rule: RP_MATCHES_RCVD
Standard description: Envelope sender domain matches handover relay domain

Explanation
Checks if domain name of an envelope sender address matches the domain name of the first untrusted relay (if any), or any trusted relay otherwise.

For example:

If the envelope sender is john@example.com and the last untrusted relay in the received-path ends in "example.com" this rule will be matched.

Return-path: <john@example.com>

Received: from untrusted-relay.example.com ([203.113.0.2]) by trusted-relay.example.org; Mon, 19 Sep 2011 18:35:58 +0000

Rule was previously named T_RP_MATCHES_RCVD.

SpamAssassin Rule: SB_GIF_AND_NO_URIS
Standard description: none

Explanation
The mail has an attachment of the MIME-type "image/gif" but the body does not contain a URI and an email address.

SpamAssassin Rule: SPAMMY_XMAILER
Standard description: X-Mailer string is common in spam and not in ham

Explanation
This rule checks for specific Microsoft Outlook Express version strings in the X-Mailer: header and matches versions that are more commonly seen in spam than non-spam mail.

SpamAssassin Rule: SPF_FAIL
Standard description: SPF: sender does not match SPF record (fail)

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The sender's domain is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

This often breaks where users have forwarded their email to another domain, but the forwarding mechanism is not SPF-aware. Such a user would see SPF_FAIL tags on some of their incoming mail.

Fail
A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright.

From RFC 4408

SpamAssassin Rule: SPF_HELO_FAIL
Standard description: SPF: HELO does not match SPF record (fail)

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The domain in the HELO command is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

In a normal mail client, the HELO command uses the internet name of the computer sending the mail, so that someone might use their computer 1-2-3-dyn.bigisp.com to send mail through bigisp.com's mail relay, which has an SPF record indicating that that's allowed.

Fail
A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright.

If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see RFC 2821) and, if supported, the 5.7.1 Delivery Status Notification (DSN) code (see RFC 3464), in addition to an appropriate reply text. The check_host() function may return either a default explanation string or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the checking software, it should be made clear that the text is provided by the sender's domain. For example:

From RFC 4408

SpamAssassin Rule: SPF_HELO_NEUTRAL
Standard description: SPF: HELO does not match SPF record (neutral)

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The domain in the HELO command is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

In a normal mail client, the HELO command uses the internet name of the computer sending the mail, so that someone might use their computer 1-2-3-dyn.bigisp.com to send mail through bigisp.com's mail relay, which has an SPF record indicating that that's allowed.

Neutral
The domain owner has explicitly stated that he cannot or does not want to assert whether or not the IP address is authorized. A "Neutral" result MUST be treated exactly like the "None" result; the distinction exists only for informational purposes. Treating "Neutral" more harshly than "None" would discourage domain owners from testing the use of SPF records (see Section 9.1).

From RFC 4408

SpamAssassin Rule: SPF_HELO_PASS
Standard description: SPF: HELO matches SPF record

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The domain in the HELO command is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

In a normal mail client, the HELO command uses the internet name of the computer sending the mail, so that someone might use their computer 1-2-3-dyn.bigisp.com to send mail through bigisp.com's mail relay, which has an SPF record indicating that that's allowed.

Pass
A "Pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity.

From RFC 4408

SpamAssassin Rule: SPF_HELO_SOFTFAIL
Standard description: SPF: HELO does not match SPF record (softfail)

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The domain in the HELO command is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

In a normal mail client, the HELO command uses the internet name of the computer sending the mail, so that someone might use their computer 1-2-3-dyn.bigisp.com to send mail through bigisp.com's mail relay, which has an SPF record indicating that that's allowed.

Soft Fail
A "SoftFail" result should be treated as somewhere between a "Fail" and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.

The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the first time the message is received, but accept it the second time.

From RFC 4408

SpamAssassin Rule: SPF_NEUTRAL
Standard description: SPF: sender does not match SPF record (neutral)

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The sender's domain is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

This often breaks where users have forwarded their email to another domain, but the forwarding mechanism is not SPF-aware. Such a user would see SPF_FAIL tags on some of their incoming mail.

Neutral
The domain owner has explicitly stated that he cannot or does not want to assert whether or not the IP address is authorized. A "Neutral" result MUST be treated exactly like the "None" result; the distinction exists only for informational purposes. Treating "Neutral" more harshly than "None" would discourage domain owners from testing the use of SPF records (see Section 9.1).

From RFC 4408

SpamAssassin Rule: SPF_PASS
Standard description: SPF: sender matches SPF record

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The sender's domain is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

This often breaks where users have forwarded their email to another domain, but the forwarding mechanism is not SPF-aware. Such a user would see SPF_FAIL tags on some of their incoming mail.

Pass
A "Pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity.

From RFC 4408

SpamAssassin Rule: SPF_SOFTFAIL
Standard description: SPF: sender does not match SPF record (softfail)

Explanation
SPF (Sender Policy Framework) is an open standard specifying a technical method to prevent sender address forgery. The sender's domain is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.

This often breaks where users have forwarded their email to another domain, but the forwarding mechanism is not SPF-aware. Such a user would see SPF_FAIL tags on some of their incoming mail.

Soft Fail
A "SoftFail" result should be treated as somewhere between a "Fail" and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.

The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the first time the message is received, but accept it the second time.

From RFC 4408

SpamAssassin Rule: STOX_REPLY_TYPE
Standard description: none

Explanation
The mail's content type is "text/plain" and has the "reply-type=original" attribute.

Further Info

There is no IANA registration for the MIME "text/plain" Media Type sub-parameter "reply-type" at this time. This is a non-standard and undefined parameter.

However this parameter does appear to be used in Microsoft software such as Outlook Express (ref).

SpamAssassin Rule: SUBJECT_FUZZY_TION
Standard description: Attempt to obfuscate words in Subject:

Explanation
The message subject seems to contain an attempt to obscure "tion" - commonly used as a suffix to create a noun from a verb.

This test uses the ReplaceTags plugin.

This rule was committed with the message "rule promotions".

SpamAssassin Rule: SUBJECT_IN_BLACKLIST
Standard description: Subject: contains string in the user's black-list

Explanation
This test is for an optional plugin that allows the user to define subjects that are blacklisted.

SpamAssassin Rule: SUBJECT_NEEDS_ENCODING
Standard description: none

Explanation
The Subject: header line contains characters outside of the US-ASCII range that have not been encoded with Base64 or Quoted-Printable encoding. This violates the RFC standards for mail headers. Properly behaved MUAs would be expected not to do this.

MIME mail header encoding is defined in RFC 2047.

SpamAssassin Rule: SUBJ_ALL_CAPS
Standard description: Subject is all capitals

Explanation
The Subject: line in the mail header contains all capital letters. This test is only applied to multi-word subject lines over a certain length containing letters in an ASCII-based character-set.

SpamAssassin Rule: SUBJ_ILLEGAL_CHARS
Standard description: Subject: has too many raw illegal characters

Explanation
The Subject header contains 8-bit and other illegal characters that should be MIME encoded, as described in RFC 2045

This suggests that the sender is using badly-written mailout software, rather than a regular email program.

SpamAssassin Rule: SUBJ_RE_NUM
Standard description: Subject is faking 'The Bat!' responses

Explanation
The Subject line in the mail's header looks like "Subject: Re[2]: something". This is an unusual use of "Re" in the subject line, but it is apparently a signature of 'The Bat!'.

Further Info

Advice on the use of "Re:" is in RFC 2822 sec 3.6.5

SpamAssassin Rule: SUSPICIOUS_RECIPS
Standard description: Similar addresses in recipient list

Explanation
The recipients listed in the To: Cc: and Bcc: header fields are checked. If there are more than a specific number of addresses present (5 or more) the addresses are compared to look for similarities.

SpamAssassin Rule: TRACKER_ID

Standard description: Incorporates a tracking ID number

Explanation
Looks for a tracking number usually found near the end of the message. Notes in rule file indicate it was added around Jul 5th, 2002.

SpamAssassin Rule: TVD_ACT_193
Standard description: Message refers to an act passed in the 1930s

Explanation
For some reason, many spam messages have referred to the "Smoot-Hawley Tariff Act" from the 1930's. Read more here.

SpamAssassin Rule: TVD_APPROVED
Standard description: none

Explanation
The body of the mail contains a phrase similar to "you're approved".

SpamAssassin Rule: TVD_FINGER_O2
Standard description: none

Explanation
This rule matches the Content-Type headers of the type "text/plain" that also have all three of the following properties

format=flowed
charset="Windows-1252"
reply-type=original
Apparently a known spam signature.

Further Info

Mails matching this rule will also match STOX_REPLY_TYPE.

SpamAssassin Rule: TVD_PH_BODY_ACCOUNTS_PRE
Standard description: none

Explanation
The body of the mail matches phrases such as "accounts suspended", "account credited", "account verification".

/\baccounts? (?:[a-z_,-]+ )+?(?:record[a-z]*|suspen[a-z]+|notif(?:y|ication)|updated|verifications?|credited)\b/

SpamAssassin Rule: TVD_RCVD_IP
Standard description: None

Explanation
Checks if the most recently addded Recieved: header begins with "from " followed by a hostname that starts with four groups of digits separated by non-alphanumeric characters (e.g. "." or "-").

This is usually an indication that the hostname is derieved from a public or private IPv4 address scheme. Since these types of addresses are commonly distrubuted to end users rather than mail servers they are often seen in spam sent directly from end user hosts.

For example:

Received: from 212-98-43-121.static.adslpremium.ch ([212.98.43.121]:3607 helo=xtqq.adslpremium.ch)

Received: from 68.207.230.213.client.lchost.net ([213.230.207.68] helo=smtp.fifambeie.co.uk)

On servers that also act as smarthosts for machines usually matching this pattern, this rule should be switched off.

Further Info

Note: this rule (and TVD_RCVD_IP4) will also match IPv4 addresses not enclosed in square brackets. This is an implementation error in your mail server software, as IP addresses should be enclosed in brackets. See RFC 5321 §4.1.2.

SpamAssassin Rule: TVD_RCVD_IP4
Standard description: (none)

Explanation
Received via an IPv4 relay which appears to neither have a reverse DNS entry, or identify itself with a HELO or EHLO command.

This suggests that the message is not coming from a legitimate email sender.

SpamAssassin Rule: TVD_RCVD_SINGLE
Standard description: Unfortunately I can find no descriptor for this rule in my searching thus far.

Explanation
Based on my limited knowledge of Perl, it appears from this line "Received =~ /from\s+(?!localhost)[\s.a-z0-9-]+\s/" that the TVD_RCVD_SINGLE header is used when a "Received" line in the SMTP Transmission header contains "localhost" as a server name.

Further Info
At the time of this writing the default score was +1.351 (see share/spamassassin/72_active.cf).

SpamAssassin Rule: TVD_SPACE_RATIO
Standard description: eval:tvd_vertical_words('0','10')

Explanation
According to a comment in the rules file "it's the ratio of spaces to non-spaces in each paragraph. apparently messages where generally there are lots of spaces mean the message is spam."

Extra space in HTML messages will be ignored in mail clients, but may not be ignored in pattern-matching filters. Slightly different messages may be sent to each recipient to avoid filtering.

Further Info

Commited to main rules as revision 378252.

SpamAssassin Rule: T_RP_MATCHES_RCVD
Standard description: Envelope sender domain matches handover relay domain

Explanation
Check if domain name of an envelope sender address matches a domain name of the first untrusted relay (if any), or any trusted relay otherwise

Further Info
Implemented in SpamAssassin >= 3.003

SpamAssassin Rule: T_TO_NO_BRKTS_FREEMAIL
Standard description: none

Explanation
This test indicates the FreeMail plugin is active in the local configuration.

Either the From: or Reply-To: header contains a free mail address (See Rules/FREEMAIL_FROM or Rules/FREEMAIL_REPLYTO) and the To: header doesn't contain angle brackets (e.g. is just an email address without an associated name).

SpamAssassin Rule: T_TVD_FW_GRAPHIC_ID1
Standard description: (none)

Explanation
Message has distinctive Content-Id pattern seen in spam

SpamAssassin Rule: UNIQUE_WORDS
Standard description: Message body has many words used only once

Explanation
<explanation of the rule goes here>

SpamAssassin Rule: UNPARSEABLE_RELAY
Standard description: Informational: message has unparseable relay lines

Explanation
The Received: lines from the email are analyzed to determine the relay path. This rule matches mail that contains one or more Received: lines that cannot be parsed to extract this information.

Note that this is an "informational" rule -- in other words, it is not intended to differentiate spam from nonspam, and should not have a significant score.

Further Info

The format of Received: header lines is detailed in RFC 5321 § 4.4

SpamAssassin Rule: UNWANTED_LANGUAGE_BODY
Standard description: Message written in an undesired language

Explanation
The content of the mail appears to be in a language not permitted by the value of the ok_languages configuration setting.

Further Info

The default value of ok_languages is "all", so this rule will only trigger if the value has been locally specified.

SpamAssassin Rule: URG_BIZ
Standard description: Contains urgent matter

Explanation
The body of the mail contains a phrase regarding some urgent matter, such as "urgent reply" or "urgent business proposal"

SpamAssassin Rule: URIBL_AB_SURBL
Standard description: Contains an URL listed in the AB SURBL blocklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL AbuseButler URI Blacklist (SURBL).

AbuseButler is kindly providing its top 400 or so Spamvertised Sites which have been most often reported over the past 7 days. The philosophy and data processing methods are similar to the sc.surbl.org data, and the results are similar, but not identical. Data sources for AbuseButler include SpamCop and native AbuseButler reporting.

Further Info

See: http://www.surbl.org http://www.abusebutler.com

SpamAssassin Rule: URIBL_BLACK
Standard description: [Body] Contains an URL listed in the URIBL blacklist

Explanation
From the about page

"black.uribl.com - This lists contains domain names belonging to and used by spammers, including but not restricted to those that appear in URIs found in SPAM. This list has a goal of zero False Positives. This zone rebuilds frequently as new data is added."

SpamAssassin Rule: URIBL_DBL_ABUSE_BOTCC
Standard description: Contains an abused botnet C&C URL listed in the DBL

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL Spamhaus Domain Block List (DBL).

The Spamhaus DBL is a realtime database of domains (typically web site domains) found in spam messages.

In this case the domain found in the email has been found acting as a botnet command and control source.

Further Info

Removal requests can be made via https://www.spamhaus.org/lookup/

See also: URIBL_SBL

SpamAssassin Rule: URIBL_DBL_ABUSE_REDIR
Standard description: Contains an abused redirector URL listed in the DBL blacklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL Spamhaus Domain Block List (DBL) listed as a redirector that has been used for abuse (this may include widely used url-shortening services for example).

The Spamhaus DBL is a realtime database of domains (typically web site domains) found in spam messages.

Further Info

Confirmation and removal requests can be made via http://www.spamhaus.org/lookup/

See also: URIBL_SBL

SpamAssassin Rule: URIBL_DBL_SPAM
Standard description: Contains an URL listed in the DBL blocklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL Spamhaus Domain Block List (DBL).

The Spamhaus DBL is a realtime database of domains (typically web site domains) found in spam messages.

Further Info

Removal requests can be made via http://www.spamhaus.org/lookup/

See also: URIBL_SBL

SpamAssassin Rule: URIBL_GREY
Standard description: Contains an URL listed in the URIBL greylist

Explanation
From the uribl.com about page

"grey.uribl.com - This lists contains domains found in UBE/UCE, and probably honour opt-out requests. This list can and probably will cause False Positives depending on your definition of SPAM. This zone rebuilds several times a day as necessary."

SpamAssassin Rule: URIBL_JP_SURBL
Standard description: Contains an URL listed in the JP SURBL blocklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL jwSpamSpy + Prolocation data source URI Blacklist (SURBL).

Joe Wein's jwSpamSpy program forms the basis of the JP data, being used both by Joe's own systems and also Raymond Dijkxhoorn and his colleagues at Prolocation. Prolocation is processing more than 300,000 likely unsolicited messages per day using jwSpamSpy plus their own policies and adding them to Joe's data. The resulting list has a very good detection rate around 80% and a very low false positive rate around 0.01%.

Further Info

See: http://www.surbl.org http://www.jwspamspy.net/

SpamAssassin Rule: URIBL_OB_SURBL
Standard description: Contains an URL listed in the OB SURBL blocklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL Outblaze URI Blacklist (SURBL).

Outblaze describes the data as coming from spam trap message body analysis and from user reports via a "this is spam" button. SURBL applies additional policies to its version of the Outblaze URI data that are published as ob.surbl.org. The user reports are also used, but not directly.

Further Info

See: http://www.surbl.org http://www.outblaze.com

SpamAssassin Rule: URIBL_RED
Standard description: Contains an URL listed in the URIBL redlist

Explanation
From the about page.

"red.uribl.com - This list contains domains that are not listed on black and are either very young (domain age via whois), or use whois privacy features to protect their identity. This list is automated in nature, so please use at your own risk."

SpamAssassin Rule: URIBL_RHS_ABUSE
Standard description: Contains an URI listed in abuse.rfc-ignorant.org

Explanation
The message contains a URI whose domain is listed in the DNSBL abuse.rfc-ignorant.org.

The criteria for listing is that the domain rejects email sent to the standard complaint address abuse@<domain> specified in RFC 2142

Further Info

This rule is disabled in SpamAssassin 3.2 (see bug 6526)

As of October 2012 this DNSBL will be unavailable.

SpamAssassin Rule: URIBL_RHS_BOGUSMX
Standard description: Contains an URI listed in bogusmx.rfc-ignorant.org

Explanation
The message contains a URI whose domain is listed in the DNSBL bogusmx.rfc-ignorant.org.

The criteria for listing is that the domain's MX records are not in compliance with current RFC guidelines. For example, an MX record must not point to an unroutable address such as those listed in RFC 5735

Further Info

This rule is disabled in SpamAssassin 3.2 (see bug 6526)

As of October 2012 this DNSBL will be unavailable.

SpamAssassin Rule: URIBL_RHS_DOB
Standard description: Contains an URI of a new domain (Day Old Bread)

Explanation
The mail contains a URI containing a domain listed in the DNSBL dob.sibl.support-intelligence.net - which lists domains registered in the last five days.

SpamAssassin Rule: URIBL_RHS_DSN
Standard description: Contains an URI listed in dsn.rfc-ignorant.org

Explanation
The message contains a URI whose domain is listed in the DNSBL dsn.rfc-ignorant.org.

The criteria for listing is that the servers listed in the domain's MX records must accept messages with the empty sender address (MAIL FROM:<>) so that Delivery Status Notification (DSN) messages can be delivered. The basis for this is section 5.2.9 of RFC 1123 and section 4.5.5 of RFC 5321

Further Info

This rule is disabled in SpamAssassin 3.3 (see bug 6526)

As of October 2012 this DNSBL will be unavailable.

SpamAssassin Rule: URIBL_RHS_POST
Standard description: Contains an URI listed in postmaster.rfc-ignorant.org

Explanation
The message contains a URI whose domain is listed in the DNSBL postmaster.rfc-ignorant.org.

The criteria for listing is that the domain rejects email sent to the mandatory notification address postmaster@<domain> specified in RFC 5321

Further Info

This rule is disabled in SpamAssassin 3.2 (see bug 6526)

As of October 2012 this DNSBL will be unavailable.

SpamAssassin Rule: URIBL_RHS_TLD_WHOIS
Standard description: Contains an URI TLD listed in whois.rfc-ignorant.org

Explanation
The message contains a URI whose top-level domain is listed in the DNSBL whois.rfc-ignorant.org.

The criteria for listing is that the top-level domain does not possess a public whois server as specified in RFC 1032, meaning that contact information for the domain administrator cannot be determined using standard tools.

Further Info

This rule is disabled in SpamAssassin 3.2 (see bug 6526)

As of October 2012 this DNSBL will be unavailable.

SpamAssassin Rule: URIBL_RHS_WHOIS
Standard description: Contains an URI listed in whois.rfc-ignorant.org

Explanation
The message contains a URI whose domain is listed in the DNSBL whois.rfc-ignorant.org.

The criteria for listing is that the domain does not have valid contact information on a whois server as specified in RFC 1032

Further Info

This rule is disabled in SpamAssassin 3.2 (see bug 6526)

As of October 2012 this DNSBL will be unavailable.

SpamAssassin Rule: URIBL_SBL
Standard description: Contains an URL listed in the SBL blocklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the Spamhaus Block List (DNSBL).

The Spamhaus Block List (SBL) is a realtime database of IP addresses of spam-sources, including known spammers, spam gangs, spam operations and spam support services. SBL listings are made according to policies outlined in SBL Policy & Listing Criteria.

Further Info

For the Received header check see RCVD_IN_SBL, and for other Spamhaus.org RBL listings see RCVD_IN_XBL RCVD_IN_PBL.

See also: URIBL_DBL_SPAM, URIBL_DBL_ABUSE_REDIR

SpamAssassin Rule: URIBL_SC_SURBL
Standard description: Contains an URL listed in the SC SURBL blocklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL SpamCop URI Blacklist (SURBL).

sc.surbl.org contains domains and a few web site IP addresses processed from SpamCop URI reports, also known as "spamvertised" sites. The reports are not used directly, but are subject to extensive processing.

Further Info

See: http://www.surbl.org http://www.spamcop.net

For the SpamCop relay block list see Rules/RCVD_IN_BL_SPAMCOP_NET .

SpamAssassin Rule: URIBL_WS_SURBL
Standard description: Contains an URL listed in the WS SURBL blocklist

Explanation
The mail body contains a URI containing a domain that has matched an entry on the DNSBL Bill Stearns URI Blacklist (SURBL).

ws.surbl.org has records from Bill Stearns' former SpamAssassin ruleset sa-blacklist, plus some other manual lists.

Further Info

http://www.surbl.org http://www.sa-blacklist.stearns.org/sa-blacklist/

SpamAssassin Rule: URI_WP_HACKED
Standard description: URI for compromised WordPress site, possible malware

Explanation
The body of the email contains URIs that might indicate a compromised WordPress host. (e.g. contains links to php or html sources within "/wp-content/" or "/wp-includes/" directories.)

SpamAssassin Rule: USER_IN_DEF_WHITELIST
Standard description: From: address is in the default white-list

Explanation
The From: address was listed in the default whitelist. The whitelist contains a series of addresses and domains that are allowed to relay for that address.

From 60_whitelist.cf

These should be addresses which send mail that is often
tagged (incorrectly) as spam; it also helps that they be addresses of big
companies with lots of lawyers, so if spammers impersonate them, they'll get
into big trouble, so it doesn't provide a shortcut around SpamAssassin.

SpamAssassin Rule: USER_IN_WHITELIST
Standard description: From: address is in the user's white-list

Explanation
A user or site administrator has added the sender's address to a list of trusted addresses.

Use of this setting is not recommended, since it blindly trusts the message, which is routinely and easily forged by spammers and phish senders. The recommended solution is to instead use whitelist_auth or other authenticated whitelisting methods, or whitelist_from_rcvd.

Further Info

See 'whitelist_from' in e.g. SpamAssassin Configuration File

SpamAssassin Rule: USER_IN_WHITELIST_TO
Standard description: User is listed in 'whitelist_to'

Explanation
If the given address appears as a recipient in the message headers (Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will be whitelisted. Useful if you're deploying SpamAssassin system-wide, and don't want some users to have their mail filtered

Further Info

See 'whitelist_to' in e.g. SpamAssassin Configuration File

SpamAssassin Rule: US_DOLLARS_3
Standard description: Mentions millions of $ ($NN,NNN,NNN.NN)

Explanation
Message body mentions millions of dollars

SpamAssassin Rule: WEIRD_PORT
Standard description: Uses non-standard port number for HTTP

Explanation
The mail contains an HTTP URI that uses an non-standard port (i.e. something other than 80, 8080, or 443).

Further Info

Ports are considered standard if registered with IANA.

SpamAssassin Rule: WEIRD_QUOTING
Standard description: Weird repeated double-quotation marks

Explanation
It's looking for \042\223\224\262\263\271 to be repeated twice, followed by a non-space between 0-16 then another pair of \042\223\224\262\263\271

SpamAssassin Rule: WHOIS_DMNBYPROXY
Standard description: Contains URL registered to Domains by Proxy

Explanation
Domain names are extracted from any URL found the body of the mail and looked up, via DNS, using bl.open-whois.org. This lists domains that have been registered through services that allow private, or anonymous, registrations.

If the lookup returns 127.0.0.15 this means it was registered using Domains by Proxy.

Further Information
This rule uses the URIDNSBL plugin.

SpamAssassin Rule: WHOIS_NETSOLPR
Standard description: URL registered as a NetSol Private Registration

Explanation
Domain names are extracted from any URL found the body of the mail and looked up, via DNS, using bl.open-whois.org. This lists domains that have been registered through services that allow private, or anonymous, registrations.

If the lookup returns 127.0.0.4 this indicates it was registered using Network Solutions Private Registration.

Further Information
This rule uses the URIDNSBL plugin.

SpamAssassin Rule: X_IP
Standard description: Message has X-IP header

Explanation
The message contains an "X-Ip:" header. The rules commit log describes it as a "not-quite-perfect-but-still-good header existence test". Presumably it is commonly used in spam for tracking purposes.