a.smith@??? wrote:
> Quoting a.smith@???:
>
>> Just been looking in the header of one mail, it has "P=spam-scanned" which
>> looks very much like the culprit. Bit of a daft config I have it would
>> seem! So if I remove this from the if where its deciding whether to pass it
>> for spam scanning Im thinking that should sort it out...???
>>
>
> Hmm, I just tried removed the spam-scanned section of this statement:
>
> spamcheck: verify = false condition = \ ${if !or{ \
> {eq{$received_protocol}{asmtp}} \ {eq{$received_protocol}{spam-scanned}} \ }
> {yes} {no}} driver = accept
>
> Any mail is bounced with an error:
>
> "A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error"
>
> Im not sure why that would cause a fatal error in my config. :S
>
> Incidentally I cam across this googling for more info, which is a description
> of how I have spamscanning configured on my system as described by the exim
> FAQ,
>
> http://www.exim.org/exim-html-4.40/doc/html/FAQ.html#TOC243
>
>
> thanks Andy.
>
>
Catching up with your several responses in one go:
- I/We still don't have a clear answer to the 'WHAT' but it looks as if the
intent is to NOT spam-scan your own authenticated users' 'outbound' traffic AND
NOT scan anything already scanned.
That is not hard, but leaving the choice until the router/transport stage is not
a very good way to do it, so you would be ahead to dig into the entire
configuration, come up to speed with Best Current Practice to make use of Exim's
particular strengths, and prepare to make significant configuration changes.
'BCP' is to do anything that could create a rejection entirely within the smtp
session. That can reduce - even eliminate - risk of backscatter spam abuse and
consequnet blacklisting of your server.
To the extent that you care enough about spam scores [1] to at least reject the
very worst of offenders, then spamd should also be called within the smtp
session (DATA phase).
With an 'inherited' configure, there is no simple 'chunk' we could give you, but
here's the gist of it:
- accept only what is at least 'possibly' clean/blameless - then ALWAYS deliver
what you have accepted. Questionable traffic may be marked as such, sequestered
to a quarantine folder, or both. But do not reject it after-the-fact.
- allow authenticated submitters to send of-box ONLY on port 587, ONLY with
SSL/TLS encryption chosen, ONLY once rigourously authenticated.
- 'recognize' your own user pool who arrive on port 587, use TLS encryption, and
successfuly authenticate for *possible* exemption from any of several rules.
Ex; exempt from rDNS check always, exempt from spam check if not Windows OS/MUA,
yet ALWAYS ClamAV check regardless of OS/MUA. Even a *BSD or eCS box can onpass
a WinCrobe or phish if the Luser is careless. As they are.
Your router code attempts to do some of that - but it is an uphill task from
where it sits in the smtp sequence of events.
You've got some research to do - but best to look at recent, not legacy methods.
HTH,
Bill
[1] If one gets serious enough, and only 'IF' truly serious, w/r to using Exim's
best tools, spam scanning is near-as-dammit superfluous. Virus checking remains
a good idea.
