[PD-ot] pd-list classified as spam (was Re: [PD] ..a bit off topics)

[zmoelnig at iem.at]

hi

moved this thread to pd-ot at iem.at, and changed the subject to something 
meaningful...

Zitat von Marco Trevisani <marco at ccrma.stanford.edu>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I tried to add as a "trusted_network" the ip for the iem.whatever.at

what "iem.whatsoever.at" ?
one thing to consider is, that the pd-list emails do originate from 
puredata.info (193.170.191.182) and not from *.iem.at (usually 
193.170.191.180)

> server which appears in all messages, but i found again another message
> from the PD in the spam directory (it might be that the two operations
> overlapped for a second, so i'll see later if it really worked).
>
> One thing the spamassasin seems not to like at all (which is a very
> fixable detail, by the sender of course),it  is when the sender
> computer has a wrong time, usually in the future, compared with the *real*
> universal time (considering the obvious adjustment with different
> timezones) at the moment of sending it.

right; this needs to be fixed on the side of the original sender (i 
just checked and puredata.info was late by 60secs; it is now synched 
again)

>
> Anyway here there is the header and the reason that made spamassasin 
> unhappy...
> [below this message another one with some different explanation]
>
Received: from puredata.info (inf182.kug.ac.at [193.170.191.182])
>        by cm-mail.stanford.edu (8.11.6/8.11.6) with ESMTP id
> 	k7NDu2O29554;
>        Wed, 23 Aug 2006 06:56:02 -0700
> Received: from iem.kug.ac.at ([193.170.191.180] helo=mail.iem.at)
>        by puredata.info with esmtp (Exim 4.50) id 1GFtAJ-0002AA-Cz
>        for pd-list at puredata.info; Wed, 23 Aug 2006 15:53:12 +0200

ah i see: iem.anything.at might be iem.kug.ac.at (and/or inf182.kug.ac.at)


> Content analysis details:   (6.6 points, 3.0 required)

hmm, 3 required points for spam seem a bit tight for me.
(if you have the possibility i'd suggest to use methods like 
greylisting to reduce the initial amount of spam; then you can use a 
higher threshold to filter the rest)

>
> pts rule name              description
> - ---- ----------------------
> - --------------------------------------------------

> 1.4 SPF_SOFTFAIL           SPF: sender does not match SPF record
> (softfail)
>                            [SPF failed: ]
> 2.4 SPF_HELO_SOFTFAIL      SPF: HELO does not match SPF record
> (softfail)
>                            [SPF failed: ]

i am pretty confident that this is wrong if these tests refer to 
iem.at/puredata.info.
afaik, SPF must be implemented by a domain, if you (as a spam-analyser) 
want to use it. neither iem.at nor puredata.info have any  SPF records.

> 1.3 INFO_TLD               URI: Contains an URL in the INFO top-level
> domain

well, this is true: puredata.info is an INFO-tld, and there is nothing 
really wrong with it.
however, i just recently re-assigned pd.iem.at to puredata.info, so i 
might be able to let emails from the list originate from an AT-tld in 
the future.

> 0.0 HTML_MESSAGE           BODY: HTML included in message
> 0.0 BAYES_50               BODY: Bayesian spam probability is 40 to
> 60%

train your ham-box.
here, spamassassin's bayesian network classifies most pd-list mails as 
BAYES_00


mfg.asdr.
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 1718 bytes
Desc: =?utf-8?b?w5ZmZmVudGxpY2hlciA=?=
	=?utf-8?b?UEdQLVNjaGzDvHNzZWw=?=
Url : http://lists.puredata.info/pipermail/pd-ot/attachments/20060825/209b0535/attachment.key