Thanks for your responses.
Sorry, forgot temporarily, that SA only classifies spam and other
mechanism's control what is done to it after that. Therefore the issue lies
elsewhere as you rightly say.
It seems that if the sender is <> Exim always delivers it to the inbox,
regardless of the how it was classified. Apparently this is because
mailservers sending notification of undeliverable mail, identify themselves
in this way (for some reason which appears a bit daft to me) and therefore,
everything from <> is automatically delivered to the inbox. Personally, I
want it to be delivered in accordance with the spam classification and will
attempt to modify the Exim config files to reflect this.
Regarding rejecting spam, we reject at SMTP, those who have no valid
return-path or if the sending mailserver is in certain RBL's, otherwise we
accept and deliver almost everything, either to the user's inbox or to their
spam folder.
The exception to the above is if the SA score is exceptionally high (like
TEN ABOVE the spam threshold set by the client), this can only be due to
significant issues in the header of the email, then it won't be delivered
but silently dropped. These emails, generally have 'forged_this' and
'forged_that', no RDNS, via dynamic IP, contain masked link to russian
mailserver pretending to be from Paypal, etc. What possible use could the
email in question (above) be to anyone? It didn't even have any displayed
content and the headers are mainly forged. We have no intention of
delivering that kind of thing and even if it did have a return path, we
wouldn't return it as it would probably be forged too and that would
probably make us spammers.
We used to deliver those too, until certain clients contacted us, saying not
to deliver the obvious stuff. By not delivering that it offers them some,
degree of protection against phishing and also makes checking the spam
folder for ham, easier. So far no complaints, although would happily deliver
even those emails for any user upon request. The BAYES databases are user
trainable too, so we never get any issues. Users can control most aspects of
the service, including disabling it.
Thanks again.
Peter
Karsten Bräckelmann-2 wrote:
>
> On Tue, 2011-05-10 at 23:26 -0700, snowweb wrote:
>> I'm getting many spams in the last few days, with spam scores far above
>> my
>> 4.0 threshold, which are still being delivered. Wondering if it's to do
>> with
>> the fact that they all seem to have no sender.
>
> Uhm, wait -- what else did you expect!?
>
> Sorry if I am mis-interpreting, but what does happen usually with mail
> exceeding your SA score threshold? If they are not delivered, are you
> rejecting them at SMTP stage, or is your mail processing chain first
> accepting the mail, and later *bouncing* identified spam back to the
> usually *forged* sender?
>
>
> To clarify: SA scores a mail. An estimation of how spammy it is. SA does
> NOT deliver or reject mail. Any action whatsoever is the duty of other
> tools in your mail processing chain.
>
> Whatever takes care of identified spam not being delivered is not SA,
> but another tool. Quarantining or proper SMTP rejecting spam would be
> possible with both, a sender address *and* a null sender.
>
> I can see how your tools refuse to *bounce* a mail with a null sender,
> but still silently doing it -- incorrectly! -- if the envelope from
> exists. Which appears to be the difference, why these samples do end up
> delivered regardless.
>
> Bouncing spam is a very bad thing to do. Back-scatter, and a disservice
> to other mail users. Please, do not do it!
>
>
>> Return-path: <>
>> Envelope-to: myu...@mydomain.co.uk
>> Delivery-date: Wed, 11 May 2011 10:25:05 +0800
>> Received: from mail by s1.snowweb.info with spam-scanned (Exim 4.67)
>> id 1QJz6l-0005lL-EX
>> for myu...@mydomain.co.uk; Wed, 11 May 2011 10:25:04 +0800
>> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
>> s1.snowweb.info
>> X-Spam-Flag: YES
>> X-Spam-Level: ******************
> [...]
>
>> By the way, does anyone have the trim email button figured out? I pressed
>> it
>
> Nope. No idea what you're talking about here anyway, but it's not SA.
>
>> and entered the address that I wanted obfuscate, but it didn't seem to
>> obfuscate anything, so I changed my address in the message source
>> manually
>> to myu...@mydomain.co.uk.
>
> Next time, please use example.com and friends for the domain part.
>
>
> --
> char
> *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
> main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8?
> c<<=1:
> (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0;
> }}}
>
>
>
--
View this message in context:
http://old.nabble.com/X-Spam-Status%3A-Yes%2C-score%3D18.4---Still-delivered.-tp31591656p31608305.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
