• Home
• About
• Download
• Contact, Support & Imprint
• License & Disclaimer
• Roadmap
• Changelog
• Tutorials
  • Install
  • Configure Doorman Server
  • Configure Detective server
  • Doorman and Detective interaction
• Configuration
  • Cache & Database
  • Defender
  • Detective
    • Archive
    • Bogofilter
    • ClamAV
    • CRM114
    • DeepDNSBL
    • DKIM Sign
    • DKIM Verify
    • DSPAM
    • HoneyCollector
    • Razor
    • SpamAssassin
  • Doorman
    • Association
    • Basic
    • CWL and CBL
    • DNSBL
    • Geo Weight
    • Greylist
    • Honeypot
    • Sender Permit
    • SPF

SPF

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 basically states "here are the IPs i allowed to send from, but if anybody else sends from another IP - that's OK, too".. 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 in the Doorman 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 Sender ID (spf2.0) and SPF (spf1) is the so called "PRA" scope from Sender ID, which is an algorithm to determine the "real sender" of the mail (for simplification: "what is in 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 or 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 Doorman 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 not SPAM. Only the opposite: a mail is not validated against the SPF record, indicates that the mail might be 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 external SMTP servers).

Configuration

versions

Allowed Values: [1], [2], [1,2]
Default: [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

Allowed Values: Score
Default: 20

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

weight_none

Allowed Values: Score
Default: 0

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

Allowed Values: Score
Default: -10

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

Allowed Values: Score
Default: -30

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

Allowed Values: Score
Default: 0

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

weight_permerror

Allowed Values: Score
Default: -10

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

Depends on the speed of your DNS server.