Steve Dobson wrote:
> Hi All
>
> I have a standard exim4/SA setup. SA is configured to add headers to an
> email but otherwise leave the message alone. I use exim to then route
> marked spam to a mailbox where I can check for ham.
>
> I've noticed that I'm getting a few false positives because the incoming
> message contains the header "X-Spam-Flag: NO". I've configured exim to
> route emails with the existence of the X-Spam-Flag header as spam.
>
> My reasoning went like this:
>
> 1). My SA configuration only adds the header if the e-mail scores high
> enough to be considered spam other wise that header is not added.
>
> 2). Anyone added the header "X-Spam-Flag: NO" is probably a spammer
> trying to their their spam pass SA.
>
> I don't see the point in running a spam scanner on out going email as
> the other end can't afford to trust the results, but it appears that
> some email admins don't think that way.
>
> So what is the best way of handling spam headers? Should I strip
> headers from any emails received via the SMTP protocol? And if so, how?
> If not what is the best way of dealing with them?
>
> Ta for your advice.
> Steve
>
I'd offer three options:
- first, use spam_score_int in smtp-time acl's to *at least* reject the
very worst of spam. Headers and their format no longer a source of
confusion. And/or you can use it to generate your own X_ headers and
turn SA's OFF.
- second, copy that value into an acl_m variable, as these are stored
with the message until last-copy delivery, and can be read (but not
altered) in routers and transports.
Using an acl_m value/flag/string in a router intead of the spam header
eliminates concern over whether it is *your* spam header, or one that
came in with the dog.
- third, IF you DO still need to add headers of your own,
-- make *some* of them arcane or coded, so they are less likely to be
matched by anything you did NOT generate.
-- *strip those special 'routing' headers* as part of any 'off-box'
delivery process once they have served their purpose. That prevents them
being fed-back or spoofed, and is less irritation to folks who decry
header blocks longer than many messages.
-- *leave* (some of) those headers, plus any 'human readable' ones, on
internal/local delivery.
This combination gives you a debug tool that the acl_m cannot.
The acl_m was simpler to match, and lives though router/transport phase,
but does NOT survive into the mbox or maildir delivery as headers do.
The headers, OTOH, will be in archives months from now, or on any
message a user returns for troubleshooting.
Combination works well for us....
Bill
> P.S. My routers look like this:
>
> begin routers
>
> # Run pass SpamAssassin
> #
> spamchecker:
> no_verify
> domains = +local_domains
> condition = "${if and { {!def:h_X-Spam-Flag:} \
> {!eq {$received_protocol} \
> {spam-scanned}}} {1}{0}}"
> driver = accept
> transport = spamassassin_delivery
>
> # Deliver all spam to a local account for checking
> #
> caught_spam:
> no_verify
> driver = accept
> transport = spam_delivery
> condition = "${if def:h_X-Spam-Flag {yes} {no} }"
>
> notlocal:
> driver = dnslookup
> domains = ! +local_domains
> transport = remote_smtp
>
> # System aliase lookup
> #
> system_aliases:
> driver = redirect
> data = ${lookup{$local_part}lsearch*{/etc/aliases}}
>
> # Standard local delivery
> #
> localuser:
> check_local_user
> driver = accept
> transport = local_delivery
>
>
>
>
