hi
moved this thread to pd-ot@iem.at, and changed the subject to something meaningful...
Zitat von Marco Trevisani marco@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@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