On 01/06/10 22:35, a.smith@??? wrote:
> Ok,
>
> think Ive got it.Quoting a.smith@???:
>
>> 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"
>
> That it gets in a loop sending the mail for spamchecking if I removed
> that exception.
Of course it does. That condition is there specifically to prevent the
loop which you have just encountered.
Your configuration is setup in a way which is generally used for
per-user or per-domain scanning, something which cannot be handled by
ACLs because they only do per-message scanning. However, from the little
bit of your config. you've shown it doesn't appear that the pipe to
spamc is actually performing either per-user or per-domain scanning, so
it seems superfluous.
> And thats what spammers are exploiting, they send with
> protocol spam-scanned and my dumb mail config accepts the mails
> without spam checking them.
Incoming messasges cannot have the made-up "spam-scanned" protocol. This
protocol is entirely ficticous and is created by your config. for the
Exim process which handles the message after it's gone through the spamc
pipe.
What happens is that Exim, when processing a message, gets to the
spamcheck router and has to decide whether to use this router. It will
process the message via the spamcheck_pipe transport if it passes the
condition. The condition is that the received_protocol is not
spam-scanned or esmtpa. If the message is processed by the
spamcheck_pipe transport it is piped to spamc:
transport_filter = "/usr/local/bin/spamc -u mailnull"
and on to Exim:
command = "/usr/local/sbin/exim -oMr spam-scanned -bS"
and re-processed, now with the protocol spam-scanned so it will fail the
spamcheck router condition second time around. Without the check for
spam-scanned the router will again match, and the message will be
processed by the spamcheck_pipe transport...
> What I can do is change the spam-scanned
> string to some other value and also change the value that spamassassin
> is using (which is what I hadnt done before that was causing a loop)
> and assuming the spamers aren´t going to do an analysis of my
> individual config then they will be blocked (or rather they wont evaid
> being scanned by spamassassin).
>
> lets see how we go... :P
I predict that nothing will change.
It's most likely an error somewhere in your setup which means that the
messages which should be going through the SA spamc pipe are not getting
checked. What is there in the messages which makes you sure they are not
being scanned? If the delivery indicates that the protocol spam-scanned
is set it means that they have definitely been handled by that
transport. It's very likely that some spam will get through even when
scanning is working. Unless you set the threshold so low that you catch
all spam, then your false postive rate goes up and that's much worse
than false negatives.
--
Nigel Wade
