COPYRIGHTS
----------
SA-Exim was written by Marc MERLIN <marc_soft@merlins.org>
You can find the latest version here:
    http://sa-exim.sf.net/
or here:
    http://marc.merlins.org/linux/exim/sa.html

greylisting was written by and is copyright Mark Lawrence <nomad@null.net>


INSTALL
-------
See the file named INSTALL for installations instructions (either compiled
in exim, or as a stand-alone shared library)

If you got sa-exim prepackaged (like on debian), you have to make sure that
your exim supports a dynamically loadable local_scan (which is true on debian
and probably on other distros too if they shipped sa-exim as a package), and
that your exim4.conf file contains the following:
local_scan_path = /usr/lib/exim4/local_scan/sa-exim.so
If you are using the split configuration file on debian with the sa-exim deb
package, you'll be fine. If you're using the monolithic file, you are on your
own until/unless the sa-exim packages try to do an in place edit (i.e. you have
to add the above configuration line yourself)


UPGRADING
---------
Deleting greylisting tuplets pre-4.2.1:
If you are installing this package yourself, and ever installed the old
greylistclean.cron which contained the complicated shell commands to clean
old tuplets, you should stop using those commands and upgrade to greylistclean.
Upgrading Greylisting.pm should also create safer tuplets without whitespace,
but it's better to get rid of the old shell cron jobs either way


PRIVACY WARNING
---------------
SA-Exim can add a header with the list of recipients in an Email (including
Bcced folks).
X-SA-Exim-Rcpt-To is used to allow you to see who a spam went to easily (i.e.
without scanning the exim logs), and to write SpamAssassin rules on the envelope
To (like adding a score if there were too many recipients or a recipient who you
know only receives spam)
X-SA-Exim-Rcpt-To is not added anymore by default, you need to enable it by
setting SAmaxrcptlistlength to a value up to 8000, but if you do add it,
you should consider removing it in exim's system_filter or in a transport.
If SARewriteBody is true you should also consider setting
SAaddSAEheaderBeforeSA to false (see the config) as all the recipients
will be visible in the attached spam, note that this disables the
ability to write SpamAssassin rules based on X-SA-Exim-Rcpt-From/To.
In real life, who a spam was sent to isn't really a problem, but it could be if
a private message is mis-categorized as spam
Note however that if you disable X-SA-Exim-Rcpt-To by setting
SAmaxrcptlistlength to 0, you will not be able to use greylisting, which
depends on this header (however you'd still be welcome to remove the header in
system_filter)


CONFIGURATION
-------------
You should read sa-exim.conf, all the options there should be well
documented.

Note that the code will not act on any mail before it is flagged as SPAM by SA.

Having SA flag the mail however doesn't mean the code rejects it or throws
the alleged spam away, you control what you want to do depending on the score.
The only restriction is that things happen in this order (for increasing SA
scores)

    - Save in SAnotspamsave if enabled
    - Save in SAspamacceptsave if enabled
    - Temporarily reject and optionally save if enabled
    - Permanently reject and optionally save if enabled
    - Accept, drop the mail, and optionally save if enabled
    - Teergrube (i.e. stall) the sender to waste his resources (and yours)

Note that you cannot set a teergrube threshold of 12, and a permreject
threshold of 20 (not that it would make much sense anyway).
Threshold scores should decrease as you apply the highest to the lowest penalty
(i.e. the rules are run in this order: teergrube, devnull, permreject,
tempreject)

Now, as of SA-Exim 4.2, things get slightly more complicated as scores are
actually full exim conditions, and therefore you could have:
SAteergrube: ${if and { {!eq {$sender_host_address}{127.0.0.1}} {!eq {$sender_host_address}{127.0.0.2}} } {25}{1048576}}
This means that if your condition succeeds, the teergrube score is set to 25,
and if the condition fails, the teergrube score is set to 2^20, which for all
intents and purposes, disables teergrubing.
Regardless of what your scores end up being after the conditions are evaluated,
sa-exim still tests them in this order: teergrube, devnull, permreject,
tempreject)




CONFIGURING SPAMASSASSIN
------------------------
A good example of spamassassin configuration would be:

    report_safe            0
    use_terse_report       1	# for SA < 3.x

This will put a non-verbose SPAM-report in the headers, but leave the
message itself intact for easy analyzing and for easy feeding to
sa-learn when mis-flagged as spam or ham. The only way to see the
message is spam, is by looking in the headers.

If you have an older version of SpamAssassin (<= 2.50), you'd probably
want to add 'report_header 1' to that list. But this is default and
un-needed in new versions of SA)

If you set 'report_safe' to a true value, you might also want to set
use_terse_report to a false value, in case you'll get the long header
which might be friendlier to your users.

For SA before 3.x, add 'always_add_report 1' to always have a spamcheck report
put in the message. This might be useful to test rules.
For SA 3.x onward, the syntax you'd want, is:
add_header                      all Report _REPORT_

Since SA is usually configured to pass messages on that are beyond the SA
spam threshold, it can make sense to rewrite the subject line.
To achieve this, you would use this for SA 2.x:
    rewrite_subject        1
    subject_tag            SPAM: _HITS_:

For SA 3.x, the syntax is:
    rewrite_header Subject SPAM: _HITS_:


If you are using SA 2.50 or better, by default, you should probably set:
    report_safe            0

Now, if you are willing to take a small speed and I/O hit, you can have
sa-exim read the body back from SA, and replace the original mail with
the new body.

You would use this if you want to set SA's report_safe to 1 or 2 (in
which case you also have to set SARewriteBody: 1 in SA-Exim's config)

Note that if you do so, unfortunately archived messages will have the
body modified by SA. This is not very trivial to fix, so if you archive
anything, you may not want to use SARewriteBody


Important:
You want to run spamd as such:
/usr/sbin/spamd -d -u nobody -H /var/spool/spamassassin/

It may not work if you run spamd with -c (debian default),
(you shouldn't run spamassassin as root for this purpose anyway (there
is no reason to, so why take the risk)

You can edit this in /etc/default/spamassassin (debian) and probably
/etc/sysconfig/spamassassin (redhat)

With SA 3.x is better, the updated syntax would look like this:
/usr/sbin/spamd --max-children 50 --daemonize --username=nobody --nouser-config --helper-home-dir=/var/spool/spamassassin/



CONFIGURING EXIM4.CONF
----------------------
This code works without anything in the exim conf, but you probably want to use
some knobs to disable scanning for some users (like setting X-SA-Do-Not-Rej
or X-SA-Do-Not-Run in the rcpt ACL and removing those headers in the right
places)

See http://marc.merlins.org/linux/exim/#conf and more specifically
http://marc.merlins.org/linux/exim/exim4-conf/exim4.conf

Note that obviously if you set those headers, spammers can set them too, so
if you are concerned about this, you can either change the header name, or set
it to something else than 'Yes' and check for that value in sa-exim.conf
(or as a 3rd option, you can use exim ACL variables to pass values to SA-Exim
without generating headers; see the section contributed by Chirik, lower in
this file)



EXIM4 INTEGRATION / NOT SCANNING YOUR OWN MAILS
-----------------------------------------------
For a very complete exim4 config, including settings for SA, you should
look at sa-exim.conf and play with:

SAEximRunCond: ${if and{ \
                            {def:sender_host_address} \
                            {!eq {$sender_host_address}{127.0.0.1}} \
                            {!eq {$h_X-SA-Do-Not-Run:}{Yes}} \
                        } \
                    {1}{0} \
                }

You may also want to look at my exim4.conf config if you haven't done so yet:
http://marc.merlins.org/linux/exim/#conf

The check_rcpt ACL has:
  warn     message       = X-SA-Do-Not-Rej: Yes
           local_parts   = +nosarej:postmaster:abuse

  warn     message       = X-SA-Do-Not-Run: Yes
           hosts         = +relay_from_hosts

  warn     message       = X-SA-Do-Not-Run: Yes
           authenticated = *

Then, you'll want to strip SA headers for messages that aren't local
This means you should strip them at least in the remote_smtp transport
with this configuration snippet:

  # This is generally set on messages originating from local users and it tells
  # SA-Exim not to scan the message or that the message was scanned.
  # Let's remove these headers if the message is sent remotely
  headers_remove = "X-SA-Do-Not-Run:X-SA-Exim-Scanned:X-SA-Exim-Mail-From:X-SA-Exim-Rcpt-To:X-SA-Exim-Connect-IP"


You can also use another option, which can't be spoofed by a spammer, but
won't show you why a mail didn't get scanned if it was sent to multiple
people (which is why I personally prefer the above, even if it's spoofable)

Contributed by Chirik <chirik@castlefur.com>:
----------------------------------------------------------------------------
I have the following:

SAEximRunCond: ${if !eq {$acl_m0}{do-not-scan} {1} {0}}
SAEximRejCond: ${if !eq {$acl_m0}{do-not-reject} {1} {0}}

Then, in my recipient ACL, I have:

  ##### Checks for postmaster or abuse - we'll scan, still, but not reject
  ##### Don't reject for certain users
  warn     local_parts   = postmaster : abuse
           set acl_m0    = do-not-reject

  ##### Check for situations we don't even scan (local mail)
  ##### Don't scan if hosts we relay for (probably dumb MUAs),
  warn     hosts         = +relay_from_hosts:127.0.0.1/8
           set acl_m0    = do-not-scan

  ##### Don't scan non-smtp connections (empty host list)
  warn     hosts         = :
           set acl_m0    = do-not-scan

  ##### Don't scan if authenticated
  warn     authenticated = *
           set acl_m0    = do-not-scan
----------------------------------------------------------------------------



TEERGRUBING: SAteergrube
------------------------
The idea is for mail that you know for sure is spam (I use a threshold of 25),
you can stall the spammer for as long as possible by sending a continuation
line every 10 seconds:
451- wait for more output
451- wait for more output
451- wait for more output
(...)

You can go there for details:
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html

What should you know?
1) This is obviously going to use up some of your resources
2) You should not teergrube SMTP servers that relay mail for you, be
   courteous (set a condition in SAteergrube like in the example
   provided). Besides they are real mail relays, so they will diligently
   try to send you the spam over and over for days)
   (note that you should probably not teergrube mailling lists you subscribed
   to either, or you risk getting unsubscribed)
   See a sample in sa-exim.conf for example syntax.
3) Because of limitations in the current exim code, teergrubing will not work
   over TLS.
   This shouldn't be a problem since real spammers should not be using TLS,
   and you shouldn't teergrube relays that do TLS with you.
   If you do teergrube a TLS connection, it will break the connection and you
   will see this in your logs:
18640m-0000Vb-00 SSL_write error 5
TLS error (SSL_write): error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
   This is not ideal, but in real life, that's ok.



GREYLISTING
-----------
See README.greylisting



READING ARCHIVED SPAMS
----------------------
Spams are optionally saved in individual files in a 'new' subdirectory
of some place like /var/spool/sa-exim/SAteergrube.

There are two ways to read them:
1) cat new/*  > /tmp/mailbox, and use  the resulting file as  a standard
   mbox file with any mail client (if SAPrependArchiveWithFrom is true)
2) Use a maildir capable mail client, like mutt, and run something like
   'mutt -f /var/spool/sa-exim/SAteergrube'. This will read the messages in
   place, since what sa-exim creates looks like a valid Maildir spool.

If you configured SA-Exim to set X-SA-Exim-Rcpt-To, you can even resend
archived refused messages to the users they were meant for

Note that sa-exim runs with the same uid/gid than the exim daemon (something
like mail, exim, or Debian-Exim), so /var/spool/sa-exim/SAteergrube must exist
and be writeable by exim.
SA-Exim will then create (sub-)directories with the permissions 0770 as
needed (those permissions aren't a configuration option, but you can change
them after the fact or pre-create the directories with the permissions of your
choice)
Files are created with 0664 permissions so that anyone who has directory access
can read (and maybe write) the files.
If you chgrp the parent 'new' directory to a group of your choice, and give it
permissions 2770 or 2775, the files will be created with that group instead of
the default exim group



LOG AND SMTP OUTPUT
-------------------
As of SA-Exim 3.0, SMTP output does not contain the spam score anymore,
and you can change the messages or re-add the score by changing the
runtime SAmsg* variables

All SA-Exim log now looks like this:
- "SA: PANIC: "		-> severe errors
- "SA: Warning: "	-> config file parsing errors
- "SA: Notice: "	-> misc info on what SA-Exim is doing or not doing
- "SA: Action: "	-> what action SA-Exim took on a mail after scanning
- "SA: Debug[X]: "	-> misc debug info if enabled

Marin Balvers has written a nice log parser here:
http://nossie.addicts.nl/projects/sa-exim-stats/



FAQ
---
Why do I get this in my exim logs?

2004-05-15 12:43:57 1BP54T-0002gV-Nu TLS send error on connection from internalmx1.company.tld (internalmx.company.tld) [192.168.1.1]:51552: Error in the push function.
2004-05-15 12:43:57 TLS recv error on connection from internalmx1.company.tld (internalmx.company.tld)
[192.168.1.1]:51552: The specified session has been invalidated for some reason.

This is because you are teergrubing a host that is doing TLS. Teergrubing does
not work with TLS, and people doing TLS with you are probably known relays which
you should exclude from your teergrube list (SAteergrubecond)

                          GREYLISTING with SA-Exim
                          ------------------------


INTRODUCTION
------------
SA-Exim allows for intelligent greylisting by combining the idea of greylisting
with Spam scores from SpamAssassin

If you don't know what greylisting is, you should probably go read up there:
http://projects.puremagic.com/greylisting/
(note that this implementation works differently than the one described there)

So, SA-Exim isn't just yet another greylisting implementation. By tying it
into SA-Exim, and especially by running SA at SMTP time, you can do the
following things:
- do not bother greylisting people who send messages detected as spam by SA
  (indeed, regular greylisting will accept mail from a spammer if he retries
  or sends it from an open relay)
  SA-Exim will never greylist, or whitelist a sender based on a mail clearly
  marked as spam by SA.

- do not delay mail from people who aren't spamming you (this one is the most
  important feature of SA-Exim greylisting, as it removes the biggest
  disadvantage linkes to greylisting)

- only greylist (and maybe later whitelist) hosts that send you mail with
  a certain SA score.


IMPLEMENTATION
--------------
So how does this all work?
SA comes with a patch for SA 2.x (and a module for SA 3.x) that does the
following things:
- add a greylisting rule which gets run at the very end, and where if
  the score is already higher than a configured value, we do not bother
  greylisting the host. We just return a rule failure, which doesn't
  change the score and lets SA-Exim reject the mail as usual
- if the score is lower than the "surely spam" threshold (shown as 11 in the
  example below), check for a file in
  /var/spool/sa-exim/messageids/co/nn/ect/ip/envfrom/envto
  - if it's there, check if it was written more than x seconds ago (1800s/30mn
    in the example below)
    - if so, change the status to whitelisted and return true so that SA applies
      the whitelist negative score
    - if not, simply increase counters, host is still greylisted
  - if the file is not there, create it
- every x time (like 4 hours or two days), remove all greylist entries that
  only saw one mail (i.e. still greylisted, not whitelisted yet).
  This is done with a find cron job
- every y time (like 1 week), remove whitelisted entries so that your filesystem
  doesn't clutter up with hosts you're not going to hear from again in a while


Then, you call the greylisting rule with this (in SA's local.cf)
# reseval is a special eval which only runs after you have the result from
# everything else (lets us not greylist a host that is sending spam, otherwise
# this rule might set a sufficiently negative score that the next spam would
# be allowed in)
# Note the 'key' -> 'value'; syntax. It's a special hack to go through SA's
# config parser. You need to keep that exact syntax
# greylistsecs: how long you greylist a tuplet because whitelisting it
# greylistnullfrom: set to 1 to also greylist mail with a null env from
# greylistfourthbyte: keep the 4 bytes of the connecting host instead of 3
header GREYLIST_ISWHITE reseval:greylisting("( 'dir' => '/var/spool/sa-exim/tuplets'; 'method' => 'dir'; 'greylistsecs' => '1800'; 'dontgreylistthreshold' => 11; 'connectiphdr' => 'X-SA-Exim-Connect-IP'; 'envfromhdr' => 'X-SA-Exim-Mail-From'; 'rcpttohdr' => 'X-SA-Exim-Rcpt-To'; 'greylistnullfrom' => 0; 'greylistfourthbyte' => 0 )")
describe GREYLIST_ISWHITE The incoming server has been whitelisted for this rece
ipient and sender
score GREYLIST_ISWHITE  -1.5

Note that SA greylisting depends on X-SA-Exim-Rcpt-To, so you have to ensure
that SAmaxrcptlistlength is set to a reasonably high value (up to 8000) instead
of the current default of 0 (you can remove the header in exim's system_filter
or a transport if you don't want it to show in user's mails, see "privacy
warning" in README)


Now, in case you aren't confused yet, you get even more knobs to play with :)
If a spammer resends you a spam until it gets whitelisted (or typically, it
gets sent to a relay that resends it to you), even if you are setup to
accept the spam at the point, you don't want to lower the SA score too much
just because the mail was resent to you several times (i.e. a rather negative
score for GREYLIST_ISWHITE). So, you can actually configure SA-Exim to temp
reject messages on a much higher score than usual, if they don't have the
GREYLIST_ISWHITE tag.

In other words, let's say you have this in sa-exim.conf:
SApermreject: 11.0
SAtempreject: 3.0
SAgreylistraisetempreject: 6.5

If a mail comes in at less than 3.0, the SA patch/module remembers the sending
server's connecting IP, the env from, and the rcpt to(s), and whitelists those.
(those will be referred to as tuplets, one for each rcpt to)

If the score is between 3.0 and 11.0,
- if at least one of the tuplets is already whitelisted, SA applies the -1.5
  score and yields an end score below 9.5, Now, at the same time, SAtempreject
  is temporarily raised by 6.5, so everything under 9.5 is accepted, which
  basically means that the mail goes through.
- if none of the tuplets are whitelisted, they get greylisted
- if they are greylisted, they can get upgraded to whitelisted status if the
  sending server has been trying for long enough (1800secs in the example given
  above). At this point the same thing happens as in case #1 and the mail is
  accepted

If a tuplet that is going to be whitelisted or greylisted, already is, SA
updates counters to let you run reports and anything else you want, like
deciding if or when you'd like to expire the entry

If by now you wonder why you would want to both decrease the SA score and
increase the maximum score you'll accept mails on, the reason is as follows:
You probably don't want to lower the SA score by 8 just because the tuplet
is whitelisted (not only does it mess with the SA scoring of messages that used
to be flagged as spam, but a spam with a score of 13.5 would then be lowered
to 5.5, be temprejected, and be close to the accept range).
Instead, giving an SA score of -1.5, a message with 13.5 becomes 12.0 and still
gets rejected right away. You also do not overly (and artifically) lower the
score of a message, just for SA-Exim's sake

If you so wish, you can also give the SA rule a score of -0.1, and only
dynamically raise the tempreject score for messages that are whitelisted.


SCORE SETUP
-----------
It makes little sense to have
SAtempreject + SAgreylistraisetempreject + SA GREYLIST_ISWHITE > SApermreject
as there is little point to raise SAtempreject if the message that's
whitelisted still gets refused by the SApermreject score

As to whether you want to put more points into SA GREYLIST_ISWHITE or
SAgreylistraisetempreject, this is your call, but as a general rule, you only
want to change the SA score in a way that makes sense for spam scoring,
as it similarly affects the score of all messages, whether SA-Exim sees them
in the non spam range, tempreject range, or "this is spam that I would never
let in" range.


FILE SETUP
----------
Make very sure that uid nobody can traverse /var/spool/sa-exim and
create tuplets writeable by nobody (or whoever you run SA as)

Then, setup a cron job to delete tuplets that are older than 14 days for
whitelisted entries, and 2 days for greylisted entries (or whatever
values you fancy).
Note that because this implementation does not systematically force the senders to resend you mail, unless they sent something that looks too much like spam,
you will typically see few whitelisted entries, and those will either be
potential spam that was actually resent to you at least 30mn after the
initial copy (or whatever value you setup in "header GREYLIST_ISWHITE"), or
people who sent you several Emails (where the second Email will just happen to
trigger a whitelisting).


FILE SETUP
----------
You should install greylistclean.cron in /etc/cron.d/ on your system to
call greylistclean and clean up greylisted entries and whitelisted entries
that haven't been used in a while.
You can optionally modify it to tweak the cleanup times.
Note that you need to tweak greylistclean.cron to match the user spamd runs
as if you aren't using the recommended --username=nobody


SA PATCH (SA 2.x)
-----------------
For all this to work, you also need to patch SA with SA-greylist.diff
from the source tar (or /usr/share/doc/sa-exim*/ for a precompiled package).
This patch never made it to the main SA 2.x branch as the developers had mostly
switched to 3.x where you can use plugins.
If you still use SA 3.x, you can go to /usr/share/perl5/Mail (or wherever
appropriate on your system), and run
patch -p0 -s < /path/to/sa-exim/SA-greylisting.diff
Note that while the patch works, it will not be maintained anymore since
it is deprecated for the SA 3.x plugin


SA PLUGIN (SA 3.x)
------------------
Newer versions of SpamAssassin support plugins, so there is no need to
patch SA anymore, you can just install the Greylisting.pm module on your
system and get SA to use it
This is how you call the module in SA 3.x (i.e. put this in your
/etc/spamassassin/local.cf)

# Note the 'key' -> 'value'; syntax. It's a special hack to go through SA's
# config parser. You need to keep that exact syntax
# greylistsecs: how long you greylist a tuplet because whitelisting it
# greylistnullfrom: set to 1 to also greylist mail with a null env from
# greylistfourthbyte: keep the 4 bytes of the connecting host instead of 3
loadplugin Greylisting /usr/share/perl5/Mail/SpamAssassin/Plugin/Greylisting.pm
header GREYLIST_ISWHITE eval:greylisting("( 'dir' => '/var/spool/sa-exim/tuplets'; 'method' => 'dir'; 'greylistsecs' => '1800'; 'dontgreylistthreshold' => 11; 'connectiphdr' => 'X-SA-Exim-Connect-IP'; 'envfromhdr' => 'X-SA-Exim-Mail-From'; 'rcpttohdr' => 'X-SA-Exim-Rcpt-To'; 'greylistnullfrom' => 1; 'greylistfourthbyte' => 0 )")
describe GREYLIST_ISWHITE The incoming server has been whitelisted for this recipient and sender
score GREYLIST_ISWHITE  -1.5
# Run SpamAssassin last, after all other rules.
# (lets us not greylist a host that is sending spam, otherwise this rule might
# set a sufficiently negative score that the next spam would be allowed in)
priority GREYLIST_ISWHITE 99999


SA-EXIM NEW BEHAVIOR CONCERNS
-----------------------------
What greylisting changes as far as spam accepting or rejection is concerned:
Once a tuplet has been whitelisted, spam from that host is more likely
to be accepted until the tuplet expires. In the case of a mailing list,
unless you run a find / rm based on the creation time and not the last
modified time, you will then be a bit more likely to accept spam from
that list.
If this turns out to not be acceptable in your case, there isn't a whole
lot you can do about this, except deleting greylist entries for the host
from cron before they get promoted to whitelist.

What you can do on top of the existing greylisting code:
Parse the SA-Exim logs and if you get spam from an IP, you can decide
to delete greylist entries in /var/spool/sa-exim/tuplets/IP or just
/var/spool/sa-exim/tuplets/IP/envfrom
This may not may not be a good thing if you receive the occasional spam
from a mailing list as you'll then re-delay mail for that list, but then
again, it will also remove whitelisting for a host that spammed you once
with an Email that managed to get under the SA scoring radar


GREYLISTING AND MXES
--------------------
Depending on your configuration, you may have realized that SA-Exim doesn't
play very well with secondary MXes for your domain if they don't run SA-Exim
too (for instance, you'd send a tempreject on spam and clog up your
secondary, or maybe even teergrube it if you forgot to add your MX's IP
in the do not teergrube list.
For greylisting, it's even more simple:
If your secondary MXes aren't running SA-Exim with greylisting, then
greylisting's efficiency will be greatly reduced as most spammers will send
their spams to your secondary MXes which will accept the mail for you,
even if it's sent only once, and then your MXes will resend the spam to you
until you accept it (rendering greylisting useless)

Now, if your secondaries are running greylisting too, most mail will flow
through with no delay whatsoever. However, in the worst case scenario, a mail
that isn't spam, but triggers greylisting because its score is high enough to
generate a tempreject, could be delayed up to twice the whitelisting time
if it were to go to your secondary MX first (assuming your primary is
unreachable or temporarily overloaded), and then be resent to your primary
MX, which would trigger a second greylisting delay
FIXME: implement a whitelist of sending IPs so that greylisting returns
whitelisted right away


SECURITY
--------
The greylisting function works around the SA parser by sending all the options
as a hash inside a string. In turn, greylisting evals the said string.
This is a security problem if you allow your users to run custom rules and it
gives them access to run spamassassin as a user different from their own, or
in a way that they otherwise wouldn't be able to.
Do not run greylisting if this a problem for you (in the default SA/SA-Exim
setup, this shouldn't be a concern since it doesn't even parse users' config
files)