The Doctor wrote:
> 1)
>
> REwriting the subject line to include potential spam warning
>
> I have in the configuration file
>
> acl_check_data:
>
> # Deny if the message contains a virus. Before enabling this check, you
> # must install a virus scanner and set the av_scanner option above.
> #
> deny malware = *
> message = This message contains a virus ($malware_name).
>
> # test reject spam at high scores (> 41)
> drop message = This message is denied by policy : $spam_score spam points
> spam = nobody:true
> condition = ${if> {$spam_score_int}{409}{1}{0}}
>
>
> # Add headers to a message if it is judged to be spam. Before enabling this,
> # you must install SpamAssassin. You may also need to set the spamd_address
> # option above.
> #
> warn spam = nobody
> message = Subject: {SPAM?} $rh_subject:
> add_header = X-Spam_score: $spam_score\n\
> X-Spam_score_int: $spam_score_int\n\
> X-Spam_bar: $spam_bar\n\
> X-Spam_report: $spam_report
>
> # Accept the message.
>
> accept
>
>
> end conf
>
> What is the corect way to rewrie the subject line?
'Correct' depends on what you want.
This preserves the original but stuffs a word in at the beginning:
message = Subject: *Suspect* $h_Subject:
CAVEAT: Unless you specifically strip the ORIGINAL 'Subject:' it will
still exist, just be pushed down, and 'usual' no longer displayed even
in view-headers of an MUA. It WILL still show if they have a true 'View
ALL headers' or if view message source is used.
Generally more good than harm to leave that in place.
>
> 2)
>
> RBLs
>
> I have
>
>
> #############################################################################
> # There are no default checks on DNS black lists because the domains that
> # contain these lists are changing all the time. However, here are two
> # examples of how you can get Exim to perform a DNS black list lookup at this
> # point. The first one denies, whereas the second just warns.
> #
> deny message = rejected because $sender_host_address is in a black l
> ist at $dnslist_domain\n$dnslist_text
> dnslists = sbl-xbl.spamhaus.org : zen.spamhaus.org : dnsbl.njabl.org
> : combined.njabl.org : dev.null.dk : relays.visi.com : bl.spamcop.net : iscbl.an
> ti-spam.org.cn : cbl.anti-spam.org.cn : cblplus.anti-spam.org.cn : cblless.anti-
> spam.org.cn : hostkarma.junkemailfilter.com=127.0.0.2
> log_message = found in $dnslist_domain
> #
> # warn dnslists = sbl-xbl.spamhaus.org: \
> # zen.spamhaus.org : \
> # dnsbl.njabl.org : \
> # combined.njabl.org : \
> # dev.null.dk : \
> # relays.visi.com : \
> # bl.spamcop.net : \
> # iscbl.anti-spam.org.cn : \
> # cbl.anti-spam.org.cn : \
> # cblplus.anti-spam.org.cn : \
> # cblless.anti-spam.org.cn : \
> # hostkarma.junkemailfilter.com=127.0.0.2
> # add_header = X-Warning: $sender_host_address is in a black list a
> t $dnslist_domain
> #log_message = found in $dnslist_domain
> #############################################################################
>
>
> end conf.
>
> IS the syntax correction.
>
Pass. I suggest changing it. Dramatically.
IF you are doing a deny on rDNS fail at acl_smtp-connect, you will very
rarely find a surviving arrivee in any RBL.
Twelve RBL's are also far too many.
First of all, many of those you list have an 'aggregate' or combined
list that combines their sub-lists. Parse just that one and save resources.
Second, not all are as professional maintained, ergo can be less
reliable, or have higher 'false positive' rates. Do some research.
I get by with just four, but only rarely even make a call to ANY of
them, as it is a last-mile, last resort check if made at all.
> 3) How do I subject any mail coming from the LAN for spam and Virus testing?
>
IF it is on an smtp connection via submission port 587, you can use the
$interface_port variable to choose different behaviour for peer-MTA
(port 25) or user base (port 587).
But you do not HAVE to treat them differently.
And probably 'should not' if there is even ONE WinBox in, or visiting,
your environment.
IF you provide Webmail AND it directly invokes the Exim binary on the
box which hosts it, THEN you must expect the odd WinBox in an Internet
Cafe or such, and WILL need to duplicate your calls to AV and content
scanners in an 'acl-not_smtp' clause.
'acl_not_smtp' is in effect, an extra 'DATA phase-only' structure, as
there are no direct equivalents to the other smtp session phases when an
on-box binary is invoked... AND .. and on-box binary invocation bypasses
ALL other acl_smtp_* tests.
> 4) How can I use something like antiword in Exim?
>
It is possible with specialty router/transports that hand-off to it
before heading to mailstore.
But there isn't much point. Too much risk of munging something important
to the recipient, and far, far, too many Win-proprietary file types to
justify the quite substantial work.
.doc is one of the few that are EASY, and that is still a waste of time.
Easier - and far more 'honest' to just ban or strip them, as many MLM
provide for.
What works for us is to reject the known-worst (executable, registry)
WinCrobe file types in a simple acl:
= asp:bat:btm:cmd:com:cpl:dll:exe:jsp: \
lnk:msi:pif:prf:reg:scr:vbs:url:dmg:sip:sh:wmf
... then also option ON the ClamAV heuristic that smacks those carrying
Win-MACRO's,
# With this option enabled OLE2 files with VBA macros, which were not
# detected by signatures will be marked as
# "Heuristics.OLE2.ContainsMacros".
# Default: no
OLE2BlockMacros yes
(some say this causes 'false' positives, so YMMV).
.. optionally VIP whitelist the few regular correspondents from whom we
actually *need* to see .doc files.
These days, enough of the more careless WinSerfen have been hammered by
Mac users and even other WinSerfs with scar tissue on their nether
parts, that the wiser ones have switched to .pdf attachments instead.
ELSE at least ZIP'ing .doc files on which they 'must' collaborate with
OTHER WinSerfs.
NB; On the reverse, MORE WinSerf than ever before are 'composing' with
their MSO manure forks, but the result has often shifted - not even with
their knowledge - to being converted to plaintext if it has no
formating, ELSE (very bad) html when their MUA sends what they THOUGHT
was an .rtf or .doc composition.
Other than roughly quadrupling the message byte count, that is largely
harmless, as html is easier to de-fang than nearly any other format.
Above all - remember two things;
1) Very few acl operate in a vacuum. Direct cutting-in of someone else's
code snippets needs a recce to insure that the dependencies are met, and
conflicts avoided.
- start with 'warn' verbs, or at least 'defer' rather than 'deny'
- Stick a 'logwrite' in right after the verb, optionally copying entry
variable contents to log, to see if they are being 'traversed' or
skipped, and with what info they were entered.
- Use a 'log_message', optionally copying relevant variable content to
log, to see if they are actually being triggered, and on what criteria.
- set 'log_selector = +all' for extensive testing.
Back down the log_selector and comment OFF at least the 'logwrites' once
testing is complete.
- USE Exim's superb debug-run feature. See also 'exiwhat' and 'eximstats'
2) Expect YOUR overall environment to be different in at least some ways
from that of others, and plan to customize accordingly.
That is NOT the same as having to reinvent the wheel. Just picking the
right sort of tires for where you travel.
HTH,
Bill
--
韓家標
