Qpsmtpd:sender permitted from

PERLDOC

Qpsmtpd#Plugins

NAME

SPF - implement Sender Permitted From

SYNOPSIS

Prevents email sender address spoofing by checking the SPF policy of the purported senders domain.

Sets the transaction note spf_pass_host if the SPF result is pass.

DESCRIPTION

Sender Policy Framework (SPF) is an email validation system designed to prevent source address spoofing. SPF allows administrators to specify which hosts are allowed to send email from a given domain by creating a specific SPF record in the public DNS. Mail exchangers then use the DNS to verify that mail is being sent by a host sanctioned by a given domain administrators. -- http://en.wikipedia.org/wiki/Sender_Policy_Framework

The results of a SPF query are stored in a transaction note named 'spfquery';

CONFIGURATION

In config/plugins, add arguments to the sender_permitted_from line.

  sender_permitted_from reject 3

reject

Set to a value between 1 and 6 to enable the following SPF behaviors:

 1 annotate-only, add Received-SPF header, no rejections.
 2 defer on DNS failures. Assure there's always a meaningful SPF header.
 3 rejected if SPF record says 'fail'
 4 stricter reject. Also rejects 'softfail'
 5 reject 'neutral'
 6 reject if no SPF records, or a syntax error

Most sites should start at level 3. It temporarily defers connections (4xx) that have soft SFP failures and only rejects (5xx) messages when the sending domains policy suggests it.

SPF levels above 4 are for crusaders who don't mind rejecting some valid mail when the sending server administrator hasn't dotted his i's and crossed his t's. May the deities bless their obsessive little hearts.

no_dmarc_policy

When used with the dmarc plugin, you don't want sender_permitted_from to reject anything, because dmarc needs to check the sender's domain policy. So you'll most likely have reject 1. But then, if the sender's domain has no dmarc policy, you might want to reject solely based on SPF result. This is what this setting is for. A first hook runs at the mail stage and evaluate SPF. Then a second hook runs at the data_post stage (after dmarc), so you have a second chance to reject.

Like reject, you can set a value to indicate how agressive you want to be:

  0 do not reject (default)
  1 reject if SPF record says 'fail'
  2 stricter reject. Also rejects 'softfail'
  3 reject 'neutral'
  4 reject if no SPF records, or a syntax error

Just like reject, the recommanded value is 1. 2 will be a bit more agressive. 3 and 4 will most likely reject some valid emails.

So, for example, you can use something like this:

sender_permetted_from reject 1 no_dmarc_policy 1 dkim reject 0 dmarc reject 1 reporting 1

Note this setting will only have effect if:

  * dmarc plugin is used, and loaded after sender_permetted_from in your plugin's config
  * the reject value is either 1 or 2 (meaning, no reject at the mail stage)
  * dmarc ran with no error
  * the sender's domain has no dmarc policy published (that means, no _dmarc DNS entry)

Note that if a domain has a dmarc "p=none" policy, then this setting has no effect. Only if there's no dmarc policy at all it'll be used.

SEE ALSO

 http://spf.pobox.com/
 http://en.wikipedia.org/wiki/Sender_Policy_Framework

TODO

Check the scope of the SPF policy. If it's too broad (ie, the whole internet is valid), apply karma penalty Examples of too broad: +all,

ACKNOWLDGEMENTS

The reject options are modeled after, and aim to match the functionality of those found in the SPF patch for qmail-smtpd.

AUTHOR

 Matt Simerson - 2013 - populate dmarc_spf note with SPF results
 Matt Simerson - 2012 - increased policy options from 3 to 6
 Matt Simerson - 2011 - rewrote using Mail::SPF
 Matt Sergeant - 2003 - initial plugin

---