|
Erik, Right now I am using MS SMTP or ORF for address validation, though Sandy has a plug-in for MS SMTP that you can load addresses into for validating addresses, and there is a separate program called IMailUsers.exe that will export a list of addresses from IMail. I don't use ORF to block anything but bad addresses on our primary, but I am using a specialized config to block 97% of incoming messages on our secondary MX records that causes us no false positive issues. This might be a sore subject with some around here, but I am going to swap out MS SMTP/ORF for Alligate very soon. Single box setups with IMail/Declude mostly don't need a pre-scanning/address validating gateway, but for us, we do mostly gateway services and we must have a product that does this because of dictionary attacks and also because of load. IMail/Declude validates addresses already for locally hosted E-mail. Alligate however is working in selective greylisting (so only high spam probability IP's are greylisted), and greylisting stops almost all zombie spam (unless it is relayed), most viruses, and some static spammers that don't requeue. It also offers other forms of security such as Mail Bomb detection, and I know that they are working on some other things along those lines as well. It's not a replacement for IMail/Declude, but if you are looking for a gateway, I would consider this first. This will also run on the same box as IMail/Declude, and it can do address validation from either an import from text file, or in real-time (with caching) by SMTP where the gateway validates addresses by connecting to IMail (or whatever you use). Matt Erik wrote: I agree with you Matt that these type of flaws should be treated with top priorities rather a feature enhancement request. To us, this is SPAM and Declude is to prevent this. A lot has been "broken" in the initial 3.0.6 release and was gradually corrected in other releases (that where working in previous versions of Declude). You and I have been around Declude long enough to see this as well as others.What gateway are you using to "normalizes the headers" before it reaches Declude? If this isn't a priority of Declude to fix; then I'd be interested alternatives. It's the same with Declude's "confirm" (yes a freebie); but has worked since nearly it's concept. -Erik -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Tuesday, March 07, 2006 6:48 PM To: [email protected] Subject: Re: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking Erik, I believe that you can get 3.0 to work for you, but you probably have to tweak the default settings. Out of the box, the default settings seem to cause issues with higher volume hosts, but they can be tweaked. It also appears to be mostly stable now, though I'm not using it either at this moment. I'm don't believe that 3.0.6 will provide resolution for this particular issue, but I wouldn't expect for them to patch the 2.x versions at this point so if it is fixed, it will probably require an upgrade to the new version. Personally, I would like to see things like this handled as top priorities instead of treating them like feature requests. Any bug that causes spam or viruses to be missed is critical in my view, and I'm sure most others around here would agree. I do recognize that Declude wants to re-write large chunks of their code, but in cases like this, it seems appropriate to respond with a more timely fix. I do see this as a disconnect with some of us, but I don't think it is the result of any bad intentions, just a different view of priorities. I would like to help Declude understand why such things need more attention. There is no doubt that the E-mail is 'broken', but both good and bad E-mail comes this way, and as long as our servers will deliver it, and our clients will read it, we need a proper way to handle it. The inability to handle the headers could also be causing other pieces of functionality to not work properly, and the inability to add headers or tag subjects makes this bug cause E-mail to slip when one uses either method for identifying spam after Declude does it's work. Personally, I'm not affected by this bug due to my gateway which normalizes the headers before it reaches Declude, but that gateway will soon change to another product and I'm not sure if I am also going to be affected by this. Matt Erik wrote:John, What David said was in plain text. Did you read it? Quote: "This would be v 3.0.6 (since it does not appear you have upgraded to v 4)". And my response was why he mentioned to upgrade to 4.0 when it's really a canned package of 3.0X. I think my comments were inline. I also wrote that 3.0X does not work for us; I did not say it does not work for you. Does your server receive 15,000 emails a day? Does your server host over 2000 email accounts? Like I said, the 3.0X version does not work for us and from the past emails on this list, others are experiencing the same. I have nothing against Declude as we have continued to renew our agreement as Declude has been productive with us until their 3.0X release and the problem noted in the email. And the problem noted has also been presented by other customers of Declude. So yes, it should brought to the list. Sorry to offend you; read it and move on and learn. As with you, we too have been with Declude for many years. You and I both know of it's up's and down's and learning experience of the "new" Declude owners. -Erik -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John T (Lists) Sent: Tuesday, March 07, 2006 5:41 PM To: [email protected] Subject: RE: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking Erik, I fail to see any where in David's response to you where he is telling you to upgrade to version 4. You post also shows your lack of understanding on the licensing for version 4. As for the actual problem, I have seen this but as David has said every message was spam and had broken headers. So, while I would like to see it fixed, it is no where on my priority list of what I want to see fixed/changed from Declude. As for version 3.0.x, I have been running it for quite a while without reverting back. IMHO, it is in very poor taste to post your message here. Barry's contact information is readily available and if you have issues with Declude you are free to contact him directly. John T eServices For You "Seek, and ye shall find!" -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Erik Sent: Tuesday, March 07, 2006 4:42 AM To: [EMAIL PROTECTED] Cc: [email protected] Subject: RE: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking Another question: Why should we upgrade to 4.0? You charge more for this version as it's a canned package that we don't need. What do you mean by "since it does not appear you have upgraded to v 4"? Are you forcing everyone to pay more for the same product in order to have support? >From others on the list, this problem exists in any of your versions. 2.06.16 runs with us with the exception noted below. Your 3.0X version does not work with us. Every time we've installed it; we've reverted back and from others on the list; it appears it is also the same. It is our understanding that your provide support to those that have a SA with you. We pay you for this. Our SA is current and has been since 2001. Please explain your words. -Erik -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, March 06, 2006 7:19 PM To: [EMAIL PROTECTED] Subject: [139-0B9B7BC7-18FF] Declude not inserting headers and Marking Erik, Our tracking and fixing of bugs is done on the latest version of Declude. This would be v 3.0.6 (since it does not appear you have upgraded to v 4). You will have to install the latest v 3 of the software and report whether you continue to experience this issue. As for the broken headers in general, all instances we have thus far seen of this have been spam sent from broken email clients. Because of the way the emails are processed, making changes at the present time to the header handling creates a high risk of causing serious problems elsewhere in the email. We are in the process of making several changes to the software, among which we have included a complete retooling of the header handling. David Franco-Rocha Declude Technical / Engineering From: "Erik" <[EMAIL PROTECTED]> Sent: Fri, 03 Mar 2006 22:12:23 -0500 To: <[EMAIL PROTECTED]> Subject: Declude not inserting headers and Marking Hello, In a discussion on your list for the thread: "Re: [Declude.JunkMail] Damaged Image Files": Attached is an email with the "broken" image mentioned as well as our Imail log and Declude log of that email. The email "passed" through Declude and did not insert any Declude headers or marking. Note that this email was forwarded; but it was forwarded to another "virtual" domain on the same server; same Imail, same Declude. Running Declude version 2.06.16 / Imail 8.22 -Erik --- 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. --- 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] [139-0B9B7BC7-18FF] Declude not in... Erik
- Re: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude n... Matt
- Re: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declu... Ncl Admin
- Re[2]: [Declude.JunkMail] [139-0B9B7BC7-18FF... Sanford Whiteman
- Re: Re[2]: [Declude.JunkMail] [139-0B9B7... Ncl Admin
- Re[4]: [Declude.JunkMail] [139-0B9B... Sanford Whiteman
- Re: [Declude.JunkMail] [139-0B9... Matt
- Re[2]: [Declude.JunkMail] [... Sanford Whiteman
- RE: Re[2]: [Declude.JunkMail] [139-0B9B7... Craig Edmonds
- Re[4]: [Declude.JunkMail] [139-0B9B... Sanford Whiteman
