RE: [Declude.JunkMail] Manual

[Markus Gufler]

As I can remember the latest "release" was from 07/23/2003. (yes 6 months ago)   Normaly we've downloaded only releas versions because the time between beta-tests and releases was relative short. But after the date above there was only betas and "interims". In the meantime there was a lot of news, discussions, changes and new spam fighting tecniques in this communitiy but none of them found the way to a release or the manual. On the other side spammers hasn't stopped to improve their sending tecniques, and has also begun to actively fight antispam sources (IP blacklists...)   Some weeks ago I paid the Declude SA fee, in the hope that soon will going on something. In the last six months I've posted a lot of suggestions, that in part was repeated from other subscribers later. For example: Check if MAILFROM, EHLO, COUNTRY,... are nearly the same (I'm not sure if already existant tests like HEURISTICS, take care of this) Configurable HOLD action to move hold messages into different file system folders. New COPYSMD action to look what's happen nearly under the own hold threeshold, without breaking the delivery of legit messages. This should help us to improve filter settings and avoid FP's Dynamically disabling of ressource intensive tests (like decoding, external tests, large filter files, ...) based on the average cpu usage. This not to run great part only with the half tests. Such a feature will allow us to use much larger and complexer tests (like reg.expressions) then now without having any problem durring peaks. Holding messages between 100 and 120% of the hold weight and re-test them 15 or 30 minutes later on IP blacklists. If positive HOLD, if negative REQUEUE Extra points for certain combinations of positive test results. Optional time-based basic weight: So Mailservers with a clear defined business/free time can add a slight basic weight between 24 and 06 o clock. At the moment we use the latest beta but I stopped going to interims because I fear that then shortly we will have "beta-interims" and so on. SKIPIFWEIGHT, SPF and Co. are interesting new tecniques and I hope they will be shortly available in a release version.   I personaly prefer 1+1+1+1+1.....+1   then 1+1+1  ...    +5    .....   +7 ...  +2   Paying a SA it's ok. But waiting for a new release for over 6 months it's not so good. Ok it's not so bad as paying the IMail SA and receiving a v8 with nearly no noticeable new functionality. At the moment the only thing that will bring me to v8 is the need of declude's SMTPAUTH whitelisting.   Markus     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee Sent: Friday, January 23, 2004 11:31 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Manual I think this is the best idea. This also give the admin that wants to or needs to use the new features/bug fixes can and they understand their functionality. This also gives the admin the ability to decide wether using the beta is worth the hassle of possible bugs in features they are not currently ready to use. but they can understand the new features that are in the beta with out spending valuable time trolling the archives for possible outdate information on the beta features.   Scott how does this suggestion sound????? A seperate manpage just for the beta features???? Who cares if it does not look pretty!!!!     Kevin Bilbee -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of paul Sent: Friday, January 23, 2004 1:20 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Manual I'll add my .02 worth to this discussion:   What I feel would be the best as a user:   1: Maybe instead of 1.76 beta to 1.77 beta, it should've been 1.76 Release, with an update to the manual about the new features of 1.76.   2: Betas should have a page devoted to the new features with a disclaimer "These may not be in the next release - use at your own risk" That way, those that don't use the betas and wait for an actual release get what they want, and beta users get what they want as well.   Paul