[Declude.JunkMail] Running declude from another program
Does anybody know if you have to do something special to call declude from another program? I need to run a program before declude is run. David
[Declude.JunkMail] HELOBOGUS only fails with non-local senders
I was scratching my head real hard on this one, but found the answer in the release notes and I think that given changes over time, our friends at Declude should consider revising how this limiting of the HELOBOGUS test works. I noted in the release notes for 1.57 [Beta, 30 Jul 2002] that the HELOBOGUS will now only be tested on non-local senders. With the invention of WHITELIST AUTH, this is unnecessary for any server that is configured for this. Zombie spammers and viruses will often enough forge a local sender in the Mail From along with using bogus HELO names, but the HELOBOGUS test won't trigger in that event due to this old fix. I agree that at the time this was totally necessary just like disabling DUL tests for local senders was, and the only method that could be used was checking the Mail From, but for systems that can whitelist all local users, it would be beneficial to have the added value of these tests under these conditions by way of a switch in the config file. I would imagine that the switch would be in the form of something like LOCALHELOBOGUS ON and LOCALDUL ON. I believe that the DUL part has been discussed before and possibly agreed to that it was a good idea for a future revision. I would hope that the same consideration could be given to the HELOBOGUS skipping of local senders. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] MS-Exchange, Store and Forward and Declude
Colbeck, Andrew wrote: Back in the day, fetching mail for your enterprise via POP was viable. It had everything to do with weak SMTP support and expensive dial on demand style connectivity. Now we have cheap pervasive broadband to the Internet and a heroin-like dependency on email. I didn't think anybody was still using POP this way, unless it was to fetch a few mailboxes from a 3rd party domain to remove a burden on users (or keeping the users firewalled). Incidentally, I've only seen ETRN used once, and that was an Exchange 5.5 server that had dial on demand ISDN and little traffic. It looks like ETRN is what we'll be using. I'm having a bit of trouble with that as well, but that's a question for the IMail list. -- A. Clausen --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] Running declude from another program
Title: Message I don't know the details, but the feature you're looking for is: DAISYCHAIN Andrew 8) -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hayes-MoatsSent: Monday, April 11, 2005 2:16 PMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Running declude from another program Does anybody know if you have to do something special to call declude from another program? I need to run a program before declude is run. David
Re: [Declude.JunkMail] Running declude from another program
David, This is a can of worms if you don't lock the files and hand things off gracefully. Declude is called by IMail with a single argument being Dsame_as_Q_file.same_extension_as_Q_file (http://support.ipswitch.com/kb/IM-2517-DM01.htm). Declude also has a DAISYCHAIN mechanism that you can configure so as to call another program after it is finished. This is covered in the manual. Another option might be to use an external test within Declude to call your program. This is done before actions are taken on the message, and you can do many things regardless of them being related to spam blocking. If things aren't locked appropriately or handled gracefully under all conditions, then you will have problems. Declude has a good deal of experience in handling such things appropriately, and you don't want other processes stealing files from your application or not being able to automatically re-queue them when necessary. This can cause things like leaked viruses and spam along with missing E-mail. Matt David Hayes-Moats wrote: Does anybody know if you have to do something special to call declude from another program? I need to run a program before declude is run. David -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] HELOBOGUS only fails with non-local senders
Matt, (pause while I put on my iron codpiece) this sounds like a good place for an IMail implementation to use SPF records as self-defense. It sounds like what you're looking for is a two-fer that maps valid client space with valid domain names to detect spoofing, and HELOBOGUS will only do part of the job. Or am I just putting words in your mouth? Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, April 11, 2005 2:54 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] HELOBOGUS only fails with non-local senders I was scratching my head real hard on this one, but found the answer in the release notes and I think that given changes over time, our friends at Declude should consider revising how this limiting of the HELOBOGUS test works. I noted in the release notes for 1.57 [Beta, 30 Jul 2002] that the HELOBOGUS will now only be tested on non-local senders. With the invention of WHITELIST AUTH, this is unnecessary for any server that is configured for this. Zombie spammers and viruses will often enough forge a local sender in the Mail From along with using bogus HELO names, but the HELOBOGUS test won't trigger in that event due to this old fix. I agree that at the time this was totally necessary just like disabling DUL tests for local senders was, and the only method that could be used was checking the Mail From, but for systems that can whitelist all local users, it would be beneficial to have the added value of these tests under these conditions by way of a switch in the config file. I would imagine that the switch would be in the form of something like LOCALHELOBOGUS ON and LOCALDUL ON. I believe that the DUL part has been discussed before and possibly agreed to that it was a good idea for a future revision. I would hope that the same consideration could be given to the HELOBOGUS skipping of local senders. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Running declude from another program
On Monday, April 11, 2005, 5:15:59 PM, David wrote: DHM Does anybody know if you have to do something special to DHM call declude from another program? I need to run a program DHM before declude is run. I'm pretty sure that you can get away with this as long as your program is thin enough, passes everything correctly (including the environment), and calls declude for each pass. I'm sure I'll be corrected if I'm wrong. Why do you want to do this? _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster - www.sortmonster.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] Running declude from another program
It is a command line. declude filenameofmessagetobescanned John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hayes-Moats Sent: Monday, April 11, 2005 2:16 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Running declude from another program Does anybody know if you have to do something special to call declude from another program? I need to run a program before declude is run. David
[Declude.JunkMail] Declude 2.0.6
Declude Version 2.0.6 was posted to www.declude.com earlier today. Updated Release Notes and Documentation are also available. Barry --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] HELOBOGUS only fails with non-local senders
Andrew, I think that you misunderstood. If you have a local domain of example.com and an E-mail comes in with a Mail From of [EMAIL PROTECTED] with a HELO of asdfdfasdfsafdsafd.asddsfadfas.asddfs, then HELOBOGUS will not trigger even though this is a bogus HELO. This isn't a bug, this was by design back in the day before you could whitelist authenticated users so that you didn't tag your own users with such tests when they would likely fail them since home PC's tend to not use Internet resolvable HELO names. Now with WHITELIST AUTH, one can safely use this test on all E-mail's that Declude scans, regardless of whether or not the Mail From is a local domain. I also indicated that in addition to the above, there was the known issue (also by design) where Declude disables any IP4R test (possibly others) that contain the letters DUL, DYNA or DUHL in the name for E-mails that have a Mail From that is local to the server, even when forged. My work around for this was to stop using that naming convention for DUL tests since it was only benefiting spammers on my system since I started using WHITELIST AUTH. Unlike the DUL trick, the HELOBOGUS thing can't be worked around. Matt Colbeck, Andrew wrote: Matt, (pause while I put on my iron codpiece) this sounds like a good place for an IMail implementation to use SPF records as self-defense. It sounds like what you're looking for is a two-fer that maps valid client space with valid domain names to detect spoofing, and HELOBOGUS will only do part of the job. Or am I just putting words in your mouth? Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, April 11, 2005 2:54 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] HELOBOGUS only fails with non-local senders I was scratching my head real hard on this one, but found the answer in the release notes and I think that given changes over time, our friends at Declude should consider revising how this limiting of the HELOBOGUS test works. I noted in the release notes for 1.57 [Beta, 30 Jul 2002] that the HELOBOGUS will now only be tested on non-local senders. With the invention of WHITELIST AUTH, this is unnecessary for any server that is configured for this. Zombie spammers and viruses will often enough forge a local sender in the Mail From along with using bogus HELO names, but the HELOBOGUS test won't trigger in that event due to this old fix. I agree that at the time this was totally necessary just like disabling DUL tests for local senders was, and the only method that could be used was checking the Mail From, but for systems that can whitelist all local users, it would be beneficial to have the added value of these tests under these conditions by way of a switch in the config file. I would imagine that the switch would be in the form of something like LOCALHELOBOGUS ON and LOCALDUL ON. I believe that the DUL part has been discussed before and possibly agreed to that it was a good idea for a future revision. I would hope that the same consideration could be given to the HELOBOGUS skipping of local senders. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] 2.06 is out...and with release notes :)
There's some good stuff in there, including some new documented config switches that seem to provide some nice tweaks. More info in the manual as well. I think that I'm finally going to jump on board the 2.x bandwagon and get my feet wet with this version. Matt ALL ADD Enhanced diagnostics to include the ability to send diagnostic information directory to Declude Technical Support. ALL ADD Enhanced logging. ALL ADD ProcessCounter - New application that will show the number of running Declude instances in the Windows system tray. ALL FIX Added resolution to log if the 'Error starting deccon.exe message' was found. JM ADD Added new directives for global.cfg - STOPPROCESSINGONFIRSTDELETE, COPYFILEACTIONWITHHEADERS, ACTIONSONCOPYALL, NOACTIONSONCOPYALLWHENWHITELISTED. JM ADD New configuration file (optional) with new directives - PROCESSES, CONCATENATELOGSTHRESHOLD, CONCATENATELOGS, KEEPINDIVIDUALLOGS, ADJUSTFORLOAD. JM ADD Added the option to hold spam by date - Adding %DATE% to the HOLD action will create date folder which will hold spam. JM ADD (SMARTERMAIL ONLY) Added an overflow process for high volume. JM FIX New DELETE_RECIPIENT action - Use this action to remove a recipient from a multi-receipt email. Prior versions used the DELETE action causing confusion and other issues, DELETE will delete the entire email, DELETE_RECIPIENT deletes individual users. JM FIX (SMARTERMAIL ONLY) COPYFILE directive didn't copy both hdr and eml files -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
