Daniel McDonald wrote:
> And, uridnsbls look at body text for uris embedded inside the message,
> something that postfix doesn't do terribly well (which is why you need to
> test these sorts of things after normalizing the text, which SpamAssassin
> does very well..)
*nod* Yeah, that too; I've b
On 1/4/13 8:38 AM, "Kris Deugau" wrote:
> Alexandre Boyer wrote:
>> Hi there,
>>
>> Why dont you perform those checks at the pre-data level, within postfix?
>
> Because you don't absolutely trust the DNSBL as a one-shot
> "this-is-spam" test, but you want to use its data to influence the
> spam
Alexandre Boyer wrote:
> Hi there,
>
> Why dont you perform those checks at the pre-data level, within postfix?
Because you don't absolutely trust the DNSBL as a one-shot
"this-is-spam" test, but you want to use its data to influence the
spam/not-spam decision.
-kgd
Hi there,
Why dont you perform those checks at the pre-data level, within postfix?
It's faster and cuts a lot of treatment for the data analysis.
The way you are doing is the way I would do, but someone on the list might
have a better way.
Alex, from N7.
Hello list,
I'm a relatively new user o
Hello list,
I'm a relatively new user of Spamassassin.
My setup is a postfix + amavisd-new + spamassassin stack, with amavisd-new
acting as before-queue filter. My use case is filtering submissions by
untrusted users (customers of the company I work for); sasl authentication is
mandatory.
I'm t
