• Home
  • History
  • Annotate
  • current directory
Name Date Size #Lines LOC





Acknowledgements.htmlH A D10-Jan-20053.6 KiB

Changelog.htmlH A D17-Jan-200514 KiB

Greylisting.pmH A D03-Dec-20049.3 KiB

INSTALLH A D02-May-20044.5 KiB

LICENSEH A D02-May-200433

MakefileH A D17-Jan-20053.4 KiB

READMEH A D17-Jan-200513.7 KiB

README.greylistingH A D17-Jan-200512.8 KiB

SA-greylisting-2.4x.diffH A D16-Aug-20048.3 KiB

SA-greylisting-2.6.diffH A D16-Aug-20049.8 KiB

TODOH A D11-Jan-200547

accept.cH A D02-May-20041 KiB

greylistclean.cronH A D18-Jan-20051.2 KiB

localscan_dlopen_exim_4.20_or_better.patchH A D02-May-20049.6 KiB

localscan_dlopen_up_to_exim_4.14.patchH A D02-May-200410.4 KiB

sa-exim.cH A D17-Jan-200545.5 KiB

sa-exim.confH A D17-Jan-200516.3 KiB

sa.html.templateH A D17-Jan-20058.2 KiB

versionH A D17-Jan-20054


3SA-Exim was written by Marc MERLIN <marc_soft@merlins.org>
4You can find the latest version here:
5    http://sa-exim.sf.net/
6or here:
7    http://marc.merlins.org/linux/exim/sa.html
12See the file named INSTALL for installations instructions (either compiled
13in exim, or as a stand-alone shared library)
15If you got sa-exim prepackaged (like on debian), you have to make sure that
16your exim supports a dynamically loadable local_scan (which is true on debian
17and probably on other distros too if they shipped sa-exim as a package), and
18that your exim4.conf file contains the following:
19local_scan_path = /usr/lib/exim4/local_scan/sa-exim.so
20If you are using the split configuration file on debian with the sa-exim deb
21package, you'll be fine. If you're using the monolithic file, you are on your
22own until/unless the sa-exim packages try to do an in place edit (i.e. you have
23to add the above configuration line yourself)
28SA-Exim can add a header with the list of recipients in an Email (including
29Bcced folks).
30X-SA-Exim-Rcpt-To is used to allow you to see who a spam went to easily (i.e.
31without scanning the exim logs), and to write SpamAssassin rules on the envelope
32To (like adding a score if there were too many recipients or a recipient who you
33know only receives spam)
34X-SA-Exim-Rcpt-To is not added anymore by default, you need to enable it by
35setting SAmaxrcptlistlength to a value up to 8000, but if you do add it,
36you should consider removing it in exim's system_filter or in a transport.
37If SARewriteBody is true you should also consider setting
38SAaddSAEheaderBeforeSA to false (see the config) as all the receipients
39will be visible in the attached spam, note that this disables the
40ability to write SpamAssassin rules based on X-SA-Exim-Rcpt-From/To.
41In real life, who a spam was sent to isn't really a problem, but it could be if
42a private message is mis-categorized as spam
43Note however that if you disable X-SA-Exim-Rcpt-To by setting
44SAmaxrcptlistlength to 0, you will not be able to use greylisting, which
45depends on this header (however you'd still be welcome to remove the header in
51You should read sa-exim.conf, all the options there should be well
54Note that the code will not act on any mail before it is flagged as SPAM by SA.
56Having SA flag the mail however doesn't mean the code rejects it or throws
57the alleged spam away, you control what you want to do depending on the score.
58The only restriction is that things happen in this order (for increasing SA
61    - Save in SAnotspamsave if enabled
62    - Save in SAspamacceptsave if enabled
63    - Temporarily reject and optionally save if enabled
64    - Permanently reject and optionally save if enabled
65    - Accept, drop the mail, and optionally save if enabled
66    - Teergrube (i.e. stall) the sender to waste his resources (and yours)
68Note that you cannot set a teergrube threshold of 12, and a permreject
69threshold of 20 (not that it would make much sense anyway).
70Threshold scores should decrease as you apply the highest to the lowest penalty
71(i.e. the rules are run in this order: teergrube, devnull, permreject,
74Now, as of SA-Exim 4.2, things get slightly more complicated as scores are
75actually full exim conditions, and therefore you could have:
76SAteergrube: ${if and { {!eq {$sender_host_address}{}} {!eq {$sender_host_address}{}} } {25}{1048576}}
77This means that if your condition succeeds, the teergrube score is set to 25,
78and if the condition fails, the teergrube score is set to 2^20, which for all
79intents and purposes, disables teergrubing.
80Regardless of what your scores end up being after the conditions are evaluated,
81sa-exim still tests them in this order: teergrube, devnull, permreject,
89A good example of spamassassin configuration would be:
91    report_safe            0
92    use_terse_report       1	# for SA < 3.x
94This will put a non-verbose SPAM-report in the headers, but leave the
95message itself intact for easy analyzing and for easy feeding to
96sa-learn when mis-flagged as spam or ham. The only way to see the
97message is spam, is by looking in the headers.
99If you have an older version of SpamAssassin (<= 2.50), you'd probably
100want to add 'report_header 1' to that list. But this is default and
101un-needed in new versions of SA)
103If you set 'report_safe' to a true value, you might also want to set
104use_terse_report to a false value, in case you'll get the long header
105which might be friendlier to your users.
107For SA before 3.x, add 'always_add_report 1' to always have a spamcheck report
108put in the message. This might be useful to test rules.
109For SA 3.x onward, the syntax you'd want, is:
110add_header                      all Report _REPORT_
112Since SA is usually configured to pass messages on that are beyond the SA
113spam threshold, it can make sense to rewrite the subject line.
114To achieve this, you would use this for SA 2.x:
115    rewrite_subject        1
116    subject_tag            SPAM: _HITS_:
118For SA 3.x, the syntax is:
119    rewrite_header Subject SPAM: _HITS_:
122If you are using SA 2.50 or better, by default, you should probably set:
123    report_safe            0
125Now, if you are willing to take a small speed and I/O hit, you can have
126sa-exim read the body back from SA, and replace the original mail with
127the new body.
129You would use this if you want to set SA's report_safe to 1 or 2 (in
130which case you also have to set SARewriteBody: 1 in SA-Exim's config)
132Note that if you do so, unfortunately archived messages will have the
133body modified by SA. This is not very trivial to fix, so if you archive
134anything, you may not want to use SARewriteBody
138You want to run spamd as such:
139/usr/sbin/spamd -d -u nobody -H /var/spool/spamassassin/
141It may not work if you run spamd with -c (debian default),
142(you shouldn't run spamassassin as root for this purpose anyway (there
143is no reason to, so why take the risk)
145You can edit this in /etc/default/spamassassin (debian) and probably
146/etc/sysconfig/spamassassin (redhat)
148With SA 3.x is better, the updated syntax would look like this:
149/usr/sbin/spamd --max-children 50 --daemonize --username=nobody --nouser-config --helper-home-dir=/var/spool/spamassassin/
155This code works without anything in the exim conf, but you probably want to use
156some knobs to disable scanning for some users (like setting X-SA-Do-Not-Rej
157or X-SA-Do-Not-Run in the rcpt ACL and removing those headers in the right
160See http://marc.merlins.org/linux/exim/#conf and more specifically
163Note that obviously if you set those headers, spammers can set them too, so
164if you are concerned about this, you can either change the header name, or set
165it to something else than 'Yes' and check for that value in sa-exim.conf
166(or as a 3rd option, you can use exim ACL variables to pass values to SA-Exim
167without generating headers; see the section contributed by Chirik, lower in
168this file)
174For a very complete exim4 config, including settings for SA, you should
175look at sa-exim.conf and play with:
177SAEximRunCond: ${if and{ \
178                            {def:sender_host_address} \
179                            {!eq {$sender_host_address}{}} \
180                            {!eq {$h_X-SA-Do-Not-Run:}{Yes}} \
181                        } \
182                    {1}{0} \
183                }
185You may also want to look at my exim4.conf config if you haven't done so yet:
188The check_rcpt ACL has:
189  warn     message       = X-SA-Do-Not-Rej: Yes
190           local_parts   = +nosarej:postmaster:abuse
192  warn     message       = X-SA-Do-Not-Run: Yes
193           hosts         = +relay_from_hosts
195  warn     message       = X-SA-Do-Not-Run: Yes
196           authenticated = *
198Then, you'll want to strip SA headers for messages that aren't local
199This means you should strip them at least in the remote_smtp transport
200with this configuration snippet:
202  # This is generally set on messages originating from local users and it tells
203  # SA-Exim not to scan the message or that the message was scanned.
204  # Let's remove these headers if the message is sent remotely
205  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"
208You can also use another option, which can't be spoofed by a spammer, but
209won't show you why a mail didn't get scanned if it was sent to multiple
210people (which is why I personally prefer the above, even if it's spoofable)
212Contributed by Chirik <chirik@castlefur.com>:
214I have the following:
216SAEximRunCond: ${if !eq {$acl_m0}{do-not-scan} {1} {0}}
217SAEximRejCond: ${if !eq {$acl_m0}{do-not-reject} {1} {0}}
219Then, in my recipient ACL, I have:
221  ##### Checks for postmaster or abuse - we'll scan, still, but not reject
222  ##### Don't reject for certain users
223  warn     local_parts   = postmaster : abuse
224           set acl_m0    = do-not-reject
226  ##### Check for situations we don't even scan (local mail)
227  ##### Don't scan if hosts we relay for (probably dumb MUAs),
228  warn     hosts         = +relay_from_hosts:
229           set acl_m0    = do-not-scan
231  ##### Don't scan non-smtp connections (empty host list)
232  warn     hosts         = :
233           set acl_m0    = do-not-scan
235  ##### Don't scan if authenticated
236  warn     authenticated = *
237           set acl_m0    = do-not-scan
242TEERGRUBING: SAteergrube
244The idea is for mail that you know for sure is spam (I use a threshold of 25),
245you can stall the spammer for as long as possible by sending a continuation
246line every 10 seconds:
247451- wait for more output
248451- wait for more output
249451- wait for more output
252You can go there for details:
255What should you know?
2561) This is obviously going to use up some of your resources
2572) You should not teergrube SMTP servers that relay mail for you, be
258   courteous (set a condition in SAteergrube like in the example
259   provided). Besides they are real mail relays, so they will diligently
260   try to send you the spam over and over for days)
261   (note that you should probably not teergrube mailling lists you subscribed
262   to either, or you risk getting unsubscribed)
263   See a sample in sa-exim.conf for example syntax.
2643) Because of limitations in the current exim code, teergrubing will not work
265   over TLS.
266   This shouldn't be a problem since real spammers should not be using TLS,
267   and you shouldn't teergrube relays that do TLS with you.
268   If you do teergrube a TLS connection, it will break the connection and you
269   will see this in your logs:
27018640m-0000Vb-00 SSL_write error 5
271TLS error (SSL_write): error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
272   This is not ideal, but in real life, that's ok.
278See README.greylisting
284Spams are optionally saved in individual files in a 'new' subdirectory
285of some place like /var/spool/sa-exim/SAteergrube.
287There are two ways to read them:
2881) cat new/*  > /tmp/mailbox, and use  the resulting file as  a standard
289   mbox file with any mail client (if SAPrependArchiveWithFrom is true)
2902) Use a maildir capable mail client, like mutt, and run something like
291   'mutt -f /var/spool/sa-exim/SAteergrube'. This will read the messages in
292   place, since what sa-exim creates looks like a valid Maildir spool.
294If you configured SA-Exim to set X-SA-Exim-Rcpt-To, you can even resend
295archived refused messages to the users they were meant for
297Note that sa-exim runs with the same uid/gid than the exim daemon (something
298like mail, exim, or Debian-Exim), so /var/spool/sa-exim/SAteergrube must exist
299and be writeable by exim.
300SA-Exim will then create (sub-)directories with the permissions 0770 as
301needed (those permissions aren't a configuration option, but you can change
302them after the fact or pre-create the directories with the permissions of your
304Files are created with 0664 permissions so that anyone who has directory access
305can read (and maybe write) the files.
306If you chgrp the parent 'new' directory to a group of your choice, and give it
307permissions 2770 or 2775, the files will be created with that group instead of
308the default exim group
314As of SA-Exim 3.0, SMTP output does not contain the spam score anymore,
315and you can change the messages or re-add the score by changing the
316runtime SAmsg* variables
318All SA-Exim log now looks like this:
319- "SA: PANIC: "		-> severe errors
320- "SA: Warning: "	-> config file parsing errors
321- "SA: Notice: "	-> misc info on what SA-Exim is doing or not doing
322- "SA: Action: "	-> what action SA-Exim took on a mail after scanning
323- "SA: Debug[X]: "	-> misc debug info if enabled
325Marin Balvers has written a nice log parser here:
332Why do I get this in my exim logs?
3342004-05-15 12:43:57 1BP54T-0002gV-Nu TLS send error on connection from internalmx1.company.tld (internalmx.company.tld) []:51552: Error in the push function.
3352004-05-15 12:43:57 TLS recv error on connection from internalmx1.company.tld (internalmx.company.tld)
336[]:51552: The specified session has been invalidated for some reason.
338This is because you are teergrubing a host that is doing TLS. Teergrubing does
339not work with TLS, and people doing TLS with you are probably known relays which
340you should exclude from your teergrube list (SAteergrubecond)


1                          GREYLISTING with SA-Exim
2                          ------------------------
7SA-Exim allows for intelligent greylisting by combining the idea of greylisting
8with Spam scores from SpamAssassin
10If you don't know what greylisting is, you should probably go read up there:
12(note that this implementation works differently than the one described there)
14So, SA-Exim isn't just yet another greylisting implementation. By tying it
15into SA-Exim, and especially by running SA at SMTP time, you can do the
16following things:
17- do not bother greylisting people who send messages detected as spam by SA
18  (indeed, regular greylisting will accept mail from a spammer if he retries
19  or sends it from an open relay)
20  SA-Exim will never greylist, or whitelist a sender based on a mail clearly
21  marked as spam by SA.
23- do not delay mail from people who aren't spamming you (this one is the most
24  important feature of SA-Exim greylisting, as it removes the biggest
25  disadvantage linkes to greylisting)
27- only greylist (and maybe later whitelist) hosts that send you mail with
28  a certain SA score.
33So how does this all work?
34SA comes with a patch for SA 2.x (and a module for SA 3.x) that does the
35following things:
36- add a greylisting rule which gets run at the very end, and where if
37  the score is already higher than a configured value, we do not bother
38  greylisting the host. We just return a rule failure, which doesn't
39  change the score and lets SA-Exim reject the mail as usual
40- if the score is lower than the "surely spam" threshold (shown as 11 in the
41  example below), check for a file in
42  /var/spool/sa-exim/messageids/co/nn/ect/ip/envfrom/envto
43  - if it's there, check if it was written more than x seconds ago (1800s/30mn
44    in the example below)
45    - if so, change the status to whitelisted and return true so that SA applies
46      the whitelist negative score
47    - if not, simply increase counters, host is still greylisted
48  - if the file is not there, create it
49- every x time (like 4 hours or two days), remove all greylist entries that
50  only saw one mail (i.e. still greylisted, not whitelisted yet).
51  This is done with a find cron job
52- every y time (like 1 week), remove whitelisted entries so that your filesystem
53  doesn't clutter up with hosts you're not going to hear from again in a while
56Then, you call the greylisting rule with this (in SA's local.cf)
57# reseval is a special eval which only runs after you have the result from
58# everything else (lets us not greylist a host that is sending spam, otherwise
59# this rule might set a sufficiently negative score that the next spam would
60# be allowed in)
61# Note the 'key' -> 'value'; syntax. It's a special hack to go through SA's
62# config parser. You need to keep that exact syntax
63# greylistsecs: how long you greylist a tuplet because whitelisting it
64# greylistnullfrom: set to 1 to also greylist mail with a null env from
65# greylistfourthbyte: keep the 4 bytes of the connecting host instead of 3
66header 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 )")
67describe GREYLIST_ISWHITE The incoming server has been whitelisted for this rece
68ipient and sender
69score GREYLIST_ISWHITE  -1.5
71Note that SA greylisting depends on X-SA-Exim-Rcpt-To, so you have to ensure
72that SAmaxrcptlistlength is set to a reasonably high value (up to 8000) instead
73of the current default of 0 (you can remove the header in exim's system_filter
74or a transport if you don't want it to show in user's mails, see "privacy
75warning" in README)
78Now, in case you aren't confused yet, you get even more knobs to play with :)
79If a spammer resends you a spam until it gets whitelisted (or typically, it
80gets sent to a relay that resends it to you), even if you are setup to
81accept the spam at the point, you don't want to lower the SA score too much
82just because the mail was resent to you several times (i.e. a rather negative
83score for GREYLIST_ISWHITE). So, you can actually configure SA-Exim to temp
84reject messages on a much higher score than usual, if they don't have the
87In other words, let's say you have this in sa-exim.conf:
88SApermreject: 11.0
89SAtempreject: 3.0
90SAgreylistraisetempreject: 6.5
92If a mail comes in at less than 3.0, the SA patch/module remembers the sending
93server's connecting IP, the env from, and the rcpt to(s), and whitelists those.
94(those will be referred to as tuplets, one for each rcpt to)
96If the score is between 3.0 and 11.0,
97- if at least one of the tuplets is already whitelisted, SA applies the -1.5
98  score and yields an end score below 9.5, Now, at the same time, SAtempreject
99  is temporarily raised by 6.5, so everything under 9.5 is accepted, which
100  basically means that the mail goes through.
101- if none of the tuplets are whitelisted, they get greylisted
102- if they are greylisted, they can get upgraded to whitelisted status if the
103  sending server has been trying for long enough (1800secs in the example given
104  above). At this point the same thing happens as in case #1 and the mail is
105  accepted
107If a tuplet that is going to be whitelisted or greylisted, already is, SA
108updates counters to let you run reports and anything else you want, like
109deciding if or when you'd like to expire the entry
111If by now you wonder why you would want to both decrease the SA score and
112increase the maximum score you'll accept mails on, the reason is as follows:
113You probably don't want to lower the SA score by 8 just because the tuplet
114is whitelisted (not only does it mess with the SA scoring of messages that used
115to be flagged as spam, but a spam with a score of 13.5 would then be lowered
116to 5.5, be temprejected, and be close to the accept range).
117Instead, giving an SA score of -1.5, a message with 13.5 becomes 12.0 and still
118gets rejected right away. You also do not overly (and artifically) lower the
119score of a message, just for SA-Exim's sake
121If you so wish, you can also give the SA rule a score of -0.1, and only
122dynamically raise the tempreject score for messages that are whitelisted.
127It makes little sense to have
128SAtempreject + SAgreylistraisetempreject + SA GREYLIST_ISWHITE > SApermreject
129as there is little point to raise SAtempreject if the message that's
130whitelisted still gets refused by the SApermreject score
132As to whether you want to put more points into SA GREYLIST_ISWHITE or
133SAgreylistraisetempreject, this is your call, but as a general rule, you only
134want to change the SA score in a way that makes sense for spam scoring,
135as it similarly affects the score of all messages, whether SA-Exim sees them
136in the non spam range, tempreject range, or "this is spam that I would never
137let in" range.
142Make very sure that uid nobody can traverse /var/spool/sa-exim and
143create tuplets writeable by nobody (or whoever you run SA as)
145Then, setup a cron job to delete tuplets that are older than 14 days for
146whitelisted entries, and 2 days for greylisted entries (or whatever
147values you fancy).
148Note that because this implementation does not systematically force the senders to resend you mail, unless they sent something that looks too much like spam,
149you will typically see few whitelisted entries, and those will either be
150potential spam that was actually resent to you at least 30mn after the
151initial copy (or whatever value you setup in "header GREYLIST_ISWHITE"), or
152people who sent you several Emails (where the second Email will just happen to
153trigger a whitelisting).
158You should install greylistclean.cron as an hourly cronjob on your system to
159clean up greylisted entries and whitelisted entries that haven't been used in a
161You can optionally modify it to tweak the cleanup times.
164SA PATCH (SA 2.x)
166For all this to work, you also need to patch SA with SA-greylist.diff
167from the source tar (or /usr/share/doc/sa-exim*/ for a precompiled package).
168This patch never made it to the main SA 2.x branch as the developers had mostly
169switched to 3.x where you can use plugins.
170If you still use SA 3.x, you can go to /usr/share/perl5/Mail (or wherever
171appropriate on your system), and run
172patch -p0 -s < /path/to/sa-exim/SA-greylisting.diff
173Note that while the patch works, it will not be maintained anymore since
174it is deprecated for the SA 3.x plugin
177SA PLUGIN (SA 3.x)
179Newer versions of SpamAssassin support plugins, so there is no need to
180patch SA anymore, you can just install the Greylisting.pm module on your
181system and get SA to use it
182This is how you call the module in SA 3.x (i.e. put this in your
185# Note the 'key' -> 'value'; syntax. It's a special hack to go through SA's
186# config parser. You need to keep that exact syntax
187# greylistsecs: how long you greylist a tuplet because whitelisting it
188# greylistnullfrom: set to 1 to also greylist mail with a null env from
189# greylistfourthbyte: keep the 4 bytes of the connecting host instead of 3
190loadplugin Greylisting /usr/share/perl5/Mail/SpamAssassin/Plugin/Greylisting.pm
191header 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 )")
192describe GREYLIST_ISWHITE The incoming server has been whitelisted for this receipient and sender
193score GREYLIST_ISWHITE  -1.5
194# Run SpamAssassin last, after all other rules.
195# (lets us not greylist a host that is sending spam, otherwise this rule might
196# set a sufficiently negative score that the next spam would be allowed in)
197priority GREYLIST_ISWHITE 99999
202What greylisting changes as far as spam accepting or rejection is concerned:
203Once a tuplet has been whitelisted, spam from that host is more likely
204to be accepted until the tuplet expires. In the case of a mailing list,
205unless you run a find / rm based on the creation time and not the last
206modified time, you will then be a bit more likely to accept spam from
207that list.
208If this turns out to not be acceptable in your case, there isn't a whole
209lot you can do about this, except deleting greylist entries for the host
210from cron before they get promoted to whitelist.
212What you can do on top of the existing greylisting code:
213Parse the SA-Exim logs and if you get spam from an IP, you can decide
214to delete greylist entries in /var/spool/sa-exim/tuplets/IP or just
216This may not may not be a good thing if you receive the occasional spam
217from a mailing list as you'll then re-delay mail for that list, but then
218again, it will also remove whitelisting for a host that spammed you once
219with an Email that managed to get under the SA scoring radar
224Depending on your configuration, you may have realized that SA-Exim doesn't
225play very well with secondary MXes for your domain if they don't run SA-Exim
226too (for instance, you'd send a tempreject on spam and clog up your
227secondary, or maybe even teergrube it if you forgot to add your MX's IP
228in the do not teergrube list.
229For greylisting, it's even more simple:
230If your secondary MXes aren't running SA-Exim with greylisting, then
231greylisting's efficiency will be greatly reduced as most spammers will send
232their spams to your secondary MXes which will accept the mail for you,
233even if it's sent only once, and then your MXes will resend the spam to you
234until you accept it (rendering greylisting useless)
236Now, if your secondaries are running greylisting too, most mail will flow
237through with no delay whatsoever. However, in the worst case scenario, a mail
238that isn't spam, but triggers greylisting because its score is high enough to
239generate a tempreject, could be delayed up to twice the whitelisting time
240if it were to go to your secondary MX first (assuming your primary is
241unreachable or temporarily overloaded), and then be resent to your primary
242MX, which would trigger a second greylisting delay
243FIXME: implement a whitelist of sending IPs so that greylisting returns
244whitelisted right away
249The greylisting function works around the SA parser by sending all the options
250as a hash inside a string. In turn, greylisting evals the said string.
251This is a security problem if you allow your users to run custom rules and it
252gives them access to run spamassassin as a user different from their own, or
253in a way that they otherwise wouldn't be able to.
254Do not run greylisting if this a problem for you (in the default SA/SA-Exim
255setup, this shouldn't be a concern since it doesn't even parse users' config