20040813: SPF updated.
20040808: started building this page - first item: SPF.

exiscan is a sourcecode-patch for the exim MTA, which modifies the exim-own ACL system. Exim uses its ACL-system to decide, wether to accept or decline an email - or even just add header-lines or write an entry on the exim logfile. More to this in the exim documentation, Chapter 38
This means, with this patch applied, you are able to run the following checks on emails and reject or add a specfic header then:

• MIME checks
• Antivirus checks
• SPAM-checks using spamassassin
• SPF (sender policy framework)
• some more...

Why?

There are some good reasons to reject a mail that you don't want to deal with as soon as possible. If you use spamassassin, you can reject mails with a pretty high score before they touch your system - and MAYBE this is even a way to unsubscribe from these spam-mailers, if they only get bounces...
Or you can use SPF (that was one of the reasons for me trying exiscan-ACL) to tag incoming mails and score them with spamassassin later on. There are some pretty, nice and nasty things you can do with exiscan-acl - just have a look at http://duncanthrax.net/exiscan-acl/.

HOW - Step 1 - compiling and installing (very short way...)

• get the exim and exiscan source-code from the above mentioned places.
• get and install libspf (there are packages for debian - you can install them)
• decompress exim (tar -xvzf exim-x.yy.tar.bz2) and exiscan (gzip -d exiscan-acl-x.yy-zz.patch.gz)
• enter the exim-sourcedir and patch the source (patch -p1 < ../exiscan-acl-x.yy-zz.patch)
• edit the exim Local/Makefile (copied from src/EDITME) as desired

  with SPF, you have to include the include- and lib-path. Add some lines like the following to the end of Local/Makefile (if you don't need them elsewhere...):
  

  CFLAGS=-DSPF -I/usr/include/spf2
  EXTRALIBS_EXIM=-L/usr/lib -lspf2
  

• compile exim as said in its documentation.

  While doing this, I got some errors in src/spf.h. I had to modify the include-path from spf_alt to:

  #include <spf2/spf.h>
  #include <spf2/spf_dns_resolv.h>
  #include <spf2/spf_dns_cache.h>
  

  Everything worked fine then. Maybe this is only a problem with the debian-libspf - I don't know.

• do a "make install"

  There are many better ways to install software on a linux-system. You could (and in my opinion SHOULD) create a software package in your distribution-own packaging-format first and install this, then. This is a very much cleaner way - because you can uninstall this software at any time and have the correct dependecies set.
  With debian, you can do this with the package checkinstall.
  Or, if there are any people interested in this, I could put my precompiled debian-exim4-package here - just mail me.

SPF

We have already compiled exiscan with SPF-support - so we should have a look at it.
There are some good examples how you could include SPF-ACLs on the exiscan-Homepage, but I like the idea of adding only a SPF-header to all mails which can be parsed by spamassassin. So can modify the spamassassin-score by the SPF result - nice, isn't it?
To do this, I've included the lines

  warn    message       = $spf_received
          spf           = pass : fail : softfail : none : neutral : err_perm : err_temp
          domains	= +local_domains

in acl_check_rcpt just after

  require verify        = sender
  accept authenticated  = *

Probably, you've to move the accept authenticated = * some lines up. This skips adding a tag for all mails relayed via SMTP-Auth (thanks, Tom Kistner!)
With domains = +local_domains only incoming mails will be tagged - relayed mails (without SMTP-authentcation) should get a tag at the recipient MTA - not here. We need this for our relay_from_hosts, cause they don't have to use SMTP-auth.

Every incoming mail should get SPF-tagged, now. This doesn't hurt in any way.
In /etc/spamassassin/local.cf (debian place for SA-config) I added the following SA rules:

  header SPF_CHECK_PASS Received-SPF =~ /^pass/
  describe SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain
  score SPF_CHECK_PASS -1.5

  header SPF_CHECK_FAIL Received-SPF =~ /^fail/
  describe SPF_CHECK_FAIL SPF reports sender host as NOT permitted to send mails from
  score SPF_CHECK_FAIL 0.5

That's one way of dealing with SPF.
There are still some points I don't like (but I've no better solution, so...):

• SPF breaks email forwarding. If you forward an email, the mail comes no longer from the SPF-allowed host. There's a thing called SRS (Sender rewriting scheme) for this - you need to have libsrs2 (Documentation). Maybe easy to implement (I fear, I have to test in the near future) - but reply-tos will look a lot different then (in the worst case like 'SRS1=HHH=forward.com==HHH=TT=source.com=user@relay.com' where 'HHH' are hashes and 'TT' is a time stamp (taken from libsrs docs)).
• SPF can only work reliably if every domain publishes SPF-records AND everyone implements some form of sender rewriting when forwarding mail. Is this somehow realistic? So, only giving SA points is maybe not too bad...