Description^

The sender policy framework (SPF) allows the owner of a domain authorize specific sender IPs / Networks. The idea is to make it impossible to fake sender addresses for any third party.

This is implemented via an additional SPF-type DNS record (most domain owners use a TXT record instead, which is allowed for now). In this record, the owner declares one or multiple IPs or IP ranges (or records, or includes additional DNS records) which are allowed to send from *@hisdomain.tld.

A lot of domains come with SPF records, but many of those use neutral policies (via “qualifiers”) which reduces the grade of usefulness.

decency knows the following SPF responses:

• pass: the SPF record matches the sender IP -> good
• none: no SPF record for this domain
• neutral/neutral_by_default/softfail: the SPF record is probably too slack, probably the sender is not from the allowed range, but the domain owner is “neutral” to all senders not listed and suggests not to block them.
• fail: the SPF record has a valid IP range and the sender is not on it -> bad
• temperror: some temporary error. maybe even on your side (DNS lookup..).
• permerror: probably malformed SPF record or alike
• error: some unknown error

For my opinion, this module is good for slightly negative scorings which might lead to rejecting the mail if any other policy (or content filter) matches too.

Does it support SPF Version 2 ?^

Well.. yes and no. Yes, because it uses Mail::SPF from CPAN which supports spf2.0 which is also known as Sender ID from Microsoft. No, because there is no SPF Version 2 according to the SPF project website – spf2.0 is a naming mistake and not the successor of SPF.

The main difference between those two is the so called “PRA” scope from Sender ID, which is an algorithm to determine the “real sender” of the mail (for simplification: the From-Header). The SPF project sees a negative impact (for the domain holders using spf1) from the Sender ID recommendation to handle “spf1″-records as Sender ID’s “spf2.0/mfrom,pra” records. Basically, the danger might be, that your “MAIL FROM” is correctly validated against your mail server IP (=spf1, spf2.0/mfrom), but the “From” header field – containing something different – is not (=spf2.0/pra).

Due to this warning from the SPF project, the overwhelming majority of spf1 implementations and because the SPF module resides in the policy server, the PRA scope will not be supported.

Critics^

Any spammer can register a valid domain and set a valid SPF record. Thus, being validated against SPF does not imply the mail is SPAM. Only the opposite: a mail is not validated against the SPF record, indicates that the mail is SPAM. Also SPF breaks some (rather) valid scenarios in which one has to send a mail from a certain domain without being able to use the correct sender MTA (eg if your office or your university has strict policies about using SMTP servers).

Configuration^

versions^

Default: [1,2]
Allowed Values: [1], [2], [1,2]

As described above 1 stands for spf1 and 2 for Sender ID (aka spf2.0). You should either enable only 1 or 1 and 2.

weight_pass^

Default: 20
Allowed Values: integer score

The score for valid SPF record checks. Don’t score to high, many spammer have those records, too!

weight_none^

Default: 0
Allowed Values: integer score

Many mail domains don’t have a SPF record. Ignore them, or score them very little negative – or punish them with negative scores, if you can afford that luxury.

weight_neutral, weight_neutral_by_default, weight_softfail^

Default: -10
Allowed Values: integer score

You could assume that the sender is not really allowed, but the domain owner did not want to set a hard policy. However, there are valid reasons for this, too, and you don’t want them to be scored too negatively.

weight_fail^

Default: -30
Allowed Values: integer score

The sender is not allowed to send from this IP. However, there are semi-legal reasons this might happen (eg sending a @gmx.com mail from a company SMTP proxy because you cannot access external SMTP servers). Decide yourself how strict you can be.

weight_temperror, weight_error^

Default: 0
Allowed Values: integer score

The temporary and unknown error should not be scored, because the problem might be on your side!

weight_permerror^

Default: -10
Allowed Values: integer score

This is most likely a malformed SPF record. Should not happen in a correctly administrated zone.

Example^

---
versions: [ 1, 2 ]

weight_pass: 20
weight_none: 0
weight_neutral: -10
weight_neutral_by_default: -10
weight_softfail: -10
weight_fail: -30
weight_temperror: 0
weight_permerror: -10
weight_error: 0

Performance^

Runtime: average 0.2 secs