[spamdyke-users] Can't avoid spam check after auth
Hello, I am en *very* new user of spamdyke. I reached it looking for how to avoid Qmail (in a Plesk enviroment) mark own users as spam altough they get authenticated. I could install and get all working. But what I see is that incoming mail (from genuine users) still is getting high level of spam, inspected by spamassassin. Can any one give some tip to avoid this ?. Thank you very much. Jorge. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Databases revisited
lenn...@wu-wien.ac.at wrote: > Dear all, > > I have been reading up on the discussions on this list as well as the > concerns about databases in the FAQ. Whilst I concur with most of the > points wrt. to a fully fledged SQL database, I think that CDBs are > ideally suited for the purposes of spamdyke. Sam states in the FAQ > that speed, memory, concurrency, portability and availability are not > a concern with CDBs and I agree, especially on the speed issue. After > all, that was what the hash file format was designed for. > > That leaves accessibility and safety for CDBs. It is true that the > database itself is in binary form (that is where the speed comes > from), which means that they cannot be easily viewed and checked for > errors. At the same time, they are read only and are usually generated > from a plain text file as input. There is no reason to not have that > text file sitting next to the actual database file, which means we > have all the advantages of a plain text file plus the speed benefit of > CDBs, which can be substantial for a lot of entries. The only > additional step required (by the admin) would be to convert the text > file into the CDB. We could also have the best of both worlds like > this. Suppose we have this entry in the configuration file: > > recipient-blacklist-file=/etc/spamdyke/recipient-blacklist > > > First, we look for a file with the name > /etc/spamdyke/recipient-blacklist.cdb. If it exists, we assume it is a > CDB version of /etc/spamdyke/recipient-blacklist and look up whatever > we need there. If recipient-blacklist.cdb has an earlier modification > time than recipient-blacklist (we get that for free anyway with a > stat() on both files), we could help the admin by printing a warning > that the CDB is probably out of date and read from recipient-blacklist > instead. If recipient-blacklist.cdb does not exist, we use > recipient-blacklist in ASCII format like before. > > > Another version of this would be to have lots of new configuration > options like: > > recipient-blacklist-file-cdb=/etc/spamdyke/recipient-blacklist.cdb > > That makes it possible to name the database file arbitrarily. If we > want the safety checks like in the example above we could make it > mandatory to name the ASCII input file for the CDB database file: > > recipient-blacklist-file=/etc/spamdyke/recipient-blacklist > recipient-blacklist-file-cdb=/etc/spamdyke/recipient-blacklist.cdb > > That way all the fallbacks to ASCII plus warnings can be implemented at > the cost of more configuration entries. > > > What do you think? > What problem specifically would this address? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Can't avoid spam check after auth
Jorge Minassian wrote: > Hello, > > I am en *very* new user of spamdyke. > I reached it looking for how to avoid Qmail (in a Plesk enviroment) > mark own users as spam altough they get authenticated. > I could install and get all working. > But what I see is that incoming mail (from genuine users) still is > getting high level of spam, inspected by spamassassin. > Can any one give some tip to avoid this ?. > > Thank you very much. > Jorge. I don't know about plesk. Qmail-Toaster can avoid this by having users submit via port 587 (the submission port) which does not invoke spamassassin. Does plesk have port 587 set up? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Databases revisited
Eric Shubert wrote:
> lenn...@wu-wien.ac.at wrote:
>> Dear all,
>>
>> I have been reading up on the discussions on this list as well as the
>> concerns about databases in the FAQ. Whilst I concur with most of the
>> points wrt. to a fully fledged SQL database, I think that CDBs are
>> ideally suited for the purposes of spamdyke. Sam states in the FAQ
>> that speed, memory, concurrency, portability and availability are not
>> a concern with CDBs and I agree, especially on the speed issue. After
>> all, that was what the hash file format was designed for.
>>
>> That leaves accessibility and safety for CDBs. It is true that the
>> database itself is in binary form (that is where the speed comes
>> from), which means that they cannot be easily viewed and checked for
>> errors. At the same time, they are read only and are usually generated
>> from a plain text file as input. There is no reason to not have that
>> text file sitting next to the actual database file, which means we
>> have all the advantages of a plain text file plus the speed benefit of
>> CDBs, which can be substantial for a lot of entries. The only
>> additional step required (by the admin) would be to convert the text
>> file into the CDB. We could also have the best of both worlds like
>> this. Suppose we have this entry in the configuration file:
>>
>> recipient-blacklist-file=/etc/spamdyke/recipient-blacklist
>>
>>
>> First, we look for a file with the name
>> /etc/spamdyke/recipient-blacklist.cdb. If it exists, we assume it is a
>> CDB version of /etc/spamdyke/recipient-blacklist and look up whatever
>> we need there. If recipient-blacklist.cdb has an earlier modification
>> time than recipient-blacklist (we get that for free anyway with a
>> stat() on both files), we could help the admin by printing a warning
>> that the CDB is probably out of date and read from recipient-blacklist
>> instead. If recipient-blacklist.cdb does not exist, we use
>> recipient-blacklist in ASCII format like before.
>>
>>
>> Another version of this would be to have lots of new configuration
>> options like:
>>
>> recipient-blacklist-file-cdb=/etc/spamdyke/recipient-blacklist.cdb
>>
>> That makes it possible to name the database file arbitrarily. If we
>> want the safety checks like in the example above we could make it
>> mandatory to name the ASCII input file for the CDB database file:
>>
>> recipient-blacklist-file=/etc/spamdyke/recipient-blacklist
>> recipient-blacklist-file-cdb=/etc/spamdyke/recipient-blacklist.cdb
>>
>> That way all the fallbacks to ASCII plus warnings can be implemented at
>> the cost of more configuration entries.
>>
>>
>> What do you think?
>>
>
> What problem specifically would this address?
>
Let me field this one. The problem is that spamdyke is simply too effective to
be as simple as it appears to be - and we can't have hobby software showing up
software created by large corporations. Spamdyke lacks a certain
enterprisiness It needs more grown up technologies, and sql is a good
starting point. Next, we can workout how to use xml somehow. Maybe for
configuration files!
--
Jacob Briggs
Systems Engineer
Core Technology Limited
Level 1, NZX Centre
11 Cable Street
Wellington
Phone +64 4 801 2250
--
Private Object doAnythingConceivable(String whatToDo, Object whatToDoItWith) {
.
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
