RE: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
Title: Message 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 PMTo: [EMAIL PROTECTED]Subject: [139-0B9B7BC7-18FF] Declude not inserting headers and MarkingErik,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-RochaDeclude Technical / Engineering From: "Erik" [EMAIL PROTECTED]Sent: Fri, 03 Mar 2006 22:12:23 -0500To: [EMAIL PROTECTED]Subject: Declude not inserting headers and MarkingHello,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 Imaillog and Declude log of that email.The email "passed" through Declude and did not insert any Declude headers ormarking.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
Re[3]: [Declude.JunkMail] spf breaks email forwarding -
On 11:39 PM 3/6/2006 -0500, it would appear that Sanford Whiteman wrote: Sure it is, SPF is NOT an RFC and if the email follows RFC then it is legit. I'm afraid you have a rather exaggerated opinion of the relevance of RFCs, and of the concept of domain ownership. RFCs are meaningless when it comes to the acceptable use of your domain (which is protected by law, not at all by RFC). . . not to mention that the SMTP RFCs are widely disregarded in spamfighting: I'm sure you have several policies which do not respect all RFC MUSTs and SHOULDs. Please don't assume that you have any idea how my policies are set. The courts have affirmed that a domain owner solely controls the use of the domain, even if it is not a distinctly registered trade or service mark (US Code Title 15, Chapter 22, Subchapter III, ยง 1127). Anyone else is simply using the mark at the will of the owner and is not protected any way by RFC. US Code v. RFC = no contest! Good to know, next time I have to make sure that my servers can communicate properly with the rest of the world, I'll be sure to check the relevant case law first. After all, I'm sure the courts will help me do a much better job than by following the RFCs. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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] How to add extra points to this
One problem with a combo on INVURIBL and SNIFFER is that they may both be detecting on the same thing the URL links. I find it best to use combos on different elements. - Original Message - From: Goran Jovanovic To: Declude.JunkMail@declude.com Sent: Monday, March 06, 2006 5:17 PM Subject: RE: [Declude.JunkMail] How to add extra points to this Hi Andrew, I was thinking specifically of a combo filter of both SNIFFER and INVURIBL and then adding keywords. The current campaign of one or two munged words and then news in the subject line is annoying me since it seems to be able to slip through in the early stages. I have already create a combo filter that helps a bunch, DUL space and then adding some more for SNF and URI. I suppose adding a combo of SNF and URI by themselves could also work. Goran Jovanovic Omega Network Solutions From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Monday, March 06, 2006 6:09 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] How to add extra points to this "I will think about a special filter test with a keyword what should be able to get rid of more of this SPAM." Goran, I suggest that making a "combo" test that awards more weight when both Message Sniffer and your URI external test trigger will be a better value for you, as it will be far more wide-ranging than merely adding keywords for the current campaign. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran JovanovicSent: Monday, March 06, 2006 1:31 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] How to add extra points to this And just for the record the CBL, SBL, and SBL-XBL tests that you mentioned are now listed are all the same thing; only CBL is really listing the IP address, while SBL and SBL-XBL are including the CBL result. Our favorite R. Scott Perry has added a little summary at the top of DNSSTUFF when you look up an IP in the SPAM databases. I just did a cut and paste from there. I only test the combined sbl-xbl.spamhaus.org zone. I may decide to go to adding weight for Countries but I find that a bit risky. I have many different customers. I will think about a special filter test with a keyword what should be able to get rid of more of this SPAM. Thanks Goran Jovanovic Omega Network Solutions From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Monday, March 06, 2006 3:03 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] How to add extra points to this Message Sniffer plus any URI blacklist testis a powerful and reliable combination. You could add keywords to make it an even stronger weight if you wanted to maintain that. You could also implement the COUNTRY filter and give a little nudge weight for CO (Colombia) if you think you get very little spam from there; if you do, I'd suggest adding Brazil, Peru and Venezuela in there too. And just for the record the CBL, SBL, and SBL-XBL tests that you mentioned are now listed are all the same thing; only CBL is really listing the IP address, while SBL and SBL-XBL are including the CBL result. Scott recently posted to the list a whole handful of "combo" tests that he finds reliable. If you're not keeping messages from this list, you might want to check the web archive for his posting(s). Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran JovanovicSent: Monday, March 06, 2006 7:36 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] How to add extra points to this Hi Here are the headers from a bunch of SPAM that is slipping through. Subject: Re: Para7mcy news To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] REV DNS: corporativos244254-29.etb.net.co Date: 06 Mar 2006 at 02:42:18 Tests Failed: IPNOTINMX [0], NOLEGITCONTENT [0], SNIFFER [7], INV-URIBL [15], SIZE-BT-1KB-5KB [1] Weight: 23 Spool File: De7c016fa0086126d.smd To view the E-mail, just click the attachment. Headers: Received: from nicsweb.com [201.244.254.29] by mail1.omeganetworksolutions.net (SMTPD32-8.15) id A7C116FA0086; Mon, 06 Mar 2006 02:41:53 -0500 Message-ID: [EMAIL PROTECTED] Reply-To: "Pallav
[Declude.JunkMail] How to filter for this?
In the headers of messages there is this line Received: from spambag [70.69.167.210] by warp8.com I want to filter on the spambag portion of that line. What filter could I use to accomplish this? Thanks. Chuck Schick Warp 8, Inc. (303)-421-5140 www.warp8.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] How to filter for this?
HELO 1 IS SPAMBAG - Original Message - From: Chuck Schick [EMAIL PROTECTED] To: Declude. JunkMail Declude.JunkMail@declude.com Sent: Tuesday, March 07, 2006 9:41 AM Subject: [Declude.JunkMail] How to filter for this? In the headers of messages there is this line Received: from spambag [70.69.167.210] by warp8.com I want to filter on the spambag portion of that line. What filter could I use to accomplish this? Thanks. Chuck Schick Warp 8, Inc. (303)-421-5140 www.warp8.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 inserting headers and Marking
Title: Message Erik, I fail to see any where in Davids 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. Barrys 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: Declude.JunkMail@declude.com 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
RE: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
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: Declude.JunkMail@declude.com 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: Declude.JunkMail@declude.com 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.
RE: [Declude.JunkMail] How to add extra points to this
Yes, there is an overlap between an external URIBL test and Message Sniffer in that Sniffer cross references hits against at least one SURBL list to gauge the worthiness of a rule. However, what is often confused is the untrue assertion that Message Sniffer imports SURBL to construct rules. Let me say again: it doesn't. I am not saying that Matt or Scott said this, I'm just laying down some groundwork. Now, Message Sniffer catches far more messages than any URIBL does, and I have no idea which lists Goran or anyone else might use. There will be some intersection between the two; and it is messages that fall into that intersection that I would suggest amplifying with more weight so as to be able to tend Declude to catching spam rather than passing it as ham. I agree with both Matt and Scott that false positives are thereby exacerbated, however, I think the risk is very small. I would suggest that to make a happy medium, that one implements their weighting system to get spam to HOLD status, but not to DELETE status. I would also encourage anyone wanting to do this to refer to Scott's posting a week or so ago that was a fine example of how to create a useful "combo" test. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott FisherSent: Tuesday, March 07, 2006 6:54 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] How to add extra points to this One problem with a combo on INVURIBL and SNIFFER is that they may both be detecting on the same thing the URL links. I find it best to use combos on different elements. - Original Message - From: Goran Jovanovic To: Declude.JunkMail@declude.com Sent: Monday, March 06, 2006 5:17 PM Subject: RE: [Declude.JunkMail] How to add extra points to this Hi Andrew, I was thinking specifically of a combo filter of both SNIFFER and INVURIBL and then adding keywords. The current campaign of one or two munged words and then news in the subject line is annoying me since it seems to be able to slip through in the early stages. I have already create a combo filter that helps a bunch, DUL space and then adding some more for SNF and URI. I suppose adding a combo of SNF and URI by themselves could also work. Goran Jovanovic Omega Network Solutions From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Monday, March 06, 2006 6:09 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] How to add extra points to this "I will think about a special filter test with a keyword what should be able to get rid of more of this SPAM." Goran, I suggest that making a "combo" test that awards more weight when both Message Sniffer and your URI external test trigger will be a better value for you, as it will be far more wide-ranging than merely adding keywords for the current campaign. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran JovanovicSent: Monday, March 06, 2006 1:31 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] How to add extra points to this And just for the record the CBL, SBL, and SBL-XBL tests that you mentioned are now listed are all the same thing; only CBL is really listing the IP address, while SBL and SBL-XBL are including the CBL result. Our favorite R. Scott Perry has added a little summary at the top of DNSSTUFF when you look up an IP in the SPAM databases. I just did a cut and paste from there. I only test the combined sbl-xbl.spamhaus.org zone. I may decide to go to adding weight for Countries but I find that a bit risky. I have many different customers. I will think about a special filter test with a keyword what should be able to get rid of more of this SPAM. Thanks Goran Jovanovic Omega Network Solutions From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, AndrewSent: Monday, March 06, 2006 3:03 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] How to add extra points to this Message Sniffer plus any URI blacklist testis a powerful and reliable combination. You could add keywords to make it an even stronger weight if you wanted to maintain that. You could also implement the COUNTRY filter and give a little nudge weight for CO (Colombia) if you think you get very little spam from there; if
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: Declude.JunkMail@declude.com 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: Declude.JunkMail@declude.com 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
RE: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
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: Declude.JunkMail@declude.com 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: Declude.JunkMail@declude.com 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
RE: [Declude.JunkMail] SmarterMail 3 / Declude 4
One limitation in SmarterMail is you can't turn off the built-in webmail commands for mark as spam which is used to build the spam/ham queues for the internal Bayesian filters. Since we aren't using the SmarterMail filters, this is basically a confusing no op option for our users and we would prefer to hide this choice but there is no option to turn it off and the skins customization does not allow this kind of change (at this time the entire skins thing is broken as it has not been upgraded to v3.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Robertson Sent: Monday, March 06, 2006 11:14 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SmarterMail 3 / Declude 4 Declude's integration with SmarterMail's spam system is something we had been waiting on for over a year. Declude passes the final weight back to SM, and SM decides what to do with the message. This means you can set different actions for each user or domain based on whatever weight is best for them. Some admins might take this for granted, but using SM 2.x with Declude always felt like you were patching together content filters to try to trick SM into reading Declude's recommendation. Basically everything built into SM to handle spam now works, including: domain and user level trusted senders; whitelisting from address books and Unmark as Spam; and whitelisting thru SM only applies to the user/domain it was set for (whereas whitelisting thru Declude would whitelist the message for every recipient). In addition, the SM spam setting for message forwarding (i.e. - Do not forward spam level medium and above) actually works. Very useful. In short, the SM 3/Declude 4 combo is an incredible improvement over the previous version. Declude just assigns the weight -- SM handles delivering, modifying or deleting the message. I can't comment on SMTP blocking. We use gateways to filter all incoming mail, so we don't use that feature. I'd be interested to hear whether it actually does use Declude to block at the SMTP level. Hope that helps, Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Jay Sudowski - Handy Networks LLC Sent: Monday, March 06, 2006 9:51 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] SmarterMail 3 / Declude 4 I'm wondering if anyone is running SmarterMail 3 / Declude 4 and can explain the greater integration that SmarterMail now has with Declude, and how you've been dealing with that so far. Most intriguing is this potential feature from SmarterMail manual: Declude Declude integration allows you to use Declude products in conjunction with the SmarterMail weighting system. Configuration of Declude is done through the Declude product, and all you need to do in SmarterMail is enable the spam check. -- AND -- SMTP Blocking This tab allows you to set up extra spam checks that block emails at delivery if a certain amount of spam checks fail. Enable SMTP Spam Blocking - Check this box to turn on this feature. SMTP Block Threshold - An email must score this value or higher in order to be blocked. The score is established by the settings on the Spam Checks tab. Does this mean that it's now possible to reject messages using Declude at the SMTP session level? Thanks! - Jay Sudowski // Handy Networks LLC Director of Technical Operations Providing Shared, Reseller, Semi Managed and Fully Managed Windows 2003 Hosting Solutions Tel: 877-70 HANDY x882 | Fax: 888-300-2FAX www.handynetworks.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. --- 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 inserting headers and Marking
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: Declude.JunkMail@declude.com 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
Re: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
Might be a sore spot for some, but others of us have done that a while back. MS SMTP and all of that stuff was painful and the solution you are going to seems to work flawlessly for us. Has cut the load that we have on the Imail/Declude Server a bunch. And I plan to expand the thing to a couple of more backup Gateways on different Class C's when I get some free time. At 02:03 PM 3/7/2006 -0500, you wrote: This might be a sore subject with some around here, but I am going to swap out MS SMTP/ORF for Alligate very soon. --- 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[4]: [Declude.JunkMail] spf breaks email forwarding -
Please don't assume that you have any idea how my policies are set. I'm not assuming: you've made some of them public. For example, you touted day-of-week and hour tests as effective gauges of spamminess. Note that I don't disagree at all with your conclusions about these tests. I mention such positions to show that they are certainly counter to your prior claim that RFC-compliance alone ensures legitimacy. More important, since it would be impossible to get real effectiveness out of any anti-spam solution without following internal policies that countermand RFC compliance, it is safe to say that _everyone_ who is satisfied with Declude does not treat the RFC compliance of incoming sessions/messages as grounds for whitelisting! You simply wouldn't be here if you took that much stock in RFCs; it doesn't matter that you haven't revealed your whole config. AFAIK, the only people who treat the RFCs with that much respect are the academic anti-spam-is-fascism advocates (at least, those few who are actually sincere and not trolls for the direct matrketing industry). Good to know, next time I have to make sure that my servers can communicate properly with the rest of the world, I'll be sure to check the relevant case law first. After all, I'm sure the courts will help me do a much better job than by following the RFCs. Don't really see much there to mock, but knock yourself out. US Code protects your right to restrict the use of domains you own in any MAIL FROM. The law therefore protects your ability to publish policies for your domain that are expressly intended to affect how and where non-owners of your domain may use the domain, as long as (and I did mention this caveat before) such protection does not contradict a right expressly granted by a separate contract. There is no generic, assumed right that a non-owner has to the use of a domain. Look, I know you're very put out by SPF. You know you don't have the kind of userbase, and the kind of relationship with your users, that would let you publish a policy. That's just fine. I have clients that can't publish SPF either, so I'm not telling you that you have to find a way to make it work. I'm telling you that it does work for some very significant domains, domains with very large legal departments at that, and there is no legal argument against it. There may be an RFC argument against it -- *if* in every area you treat RFC-compliant senders as trusted senders. But I think due to the nature of this mailing list, there is a justifiable presumption of guilt in that department. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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[2]: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
Might be a sore spot for some, but others of us have done that a while back. MS SMTP and all of that stuff was painful. . . Painful? Using MS SMTP *just for address validation* was painful? Let me ask that again. *Painful*? OS-bundled app, huge capacity, simple setup, huge user community. . . painful. Spamvertised app, commercial pricing. . . wonderful. Great, score another one for spam. I continue to be amazed. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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: Re[2]: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
Using other's mailing lists for support and public documentation, ldap, VBS scripts. And free vs. free and both IMHO are equal amounts of spam. Tarpitting, country blocking and native Win service and about five minutes of my time. Sorry and it wasn't just address validation. Unix sendmail is free as well. Wonder why everyone went to Imail. H. At 05:29 PM 3/7/2006 -0500, you wrote: Might be a sore spot for some, but others of us have done that a while back. MS SMTP and all of that stuff was painful. . . Painful? Using MS SMTP *just for address validation* was painful? Let me ask that again. *Painful*? OS-bundled app, huge capacity, simple setup, huge user community. . . painful. Spamvertised app, commercial pricing. . . wonderful. --- 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] spf breaks email forwarding -
Hey, Nick. I spent some timepoking at this with a stick. Since I just use IMail as a gateway so that I can use Declude... I've had no use for IMail mailboxes or forwarding, so it was all new to me. The real answer is that you should lobby Ipswitch to implement that sender re-writing in their forwarding (what the heck... all of SPF plus the bells and whistles while they're at it). If you can garner support from other people to make the same request, all the better. You can also tell your client "Sorry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to Adelphia's wishes,I can't forward it. However, if you do have Adelpha forward the mail to me, I can filter out the spam and viruses, and you can use POP/IMAP to retrievethe good mailfrom my server." As a new policy, you would want to double-check that any mailbox for which you do forwarding doesn't send mail from some domain that has a tight SPF, or whomever you're fowarding to (e.g. surfglobal.net) will see you as a spammer. If you want to perservere and build your own forwarding system, what I found was that: 1) Just doing a "forward" action on a mailbox was functionally identical to making an IMailmailbox with a rule that says "if sender email contains '@' then forward the mail to [EMAIL PROTECTED]" and that this forwardingviolates SPF for a domain like Adelphia.com. 2) It's not easy but it's not impossible to instead use a Program Alias instead. That program alias would call a batch file with optional parameters (let's say we provide two in our configuration). That batch then receives a %3 parameter added on that contains a tmp*.tmp filename which isreally a D*.SMD file with a different name in the \imail\spool folder. The first thing the batch would do is some sanity checks. You would have to avoid mail loops and other badnessby making sure that this is a message that should be forwarded, e.g. not a bounce message from whomever you're forwarding messages to! If it is crap, it should delete the tmp*.tmp file and exit. The second thing the script would do is manufacture a Q*.SMD file. Since you've already got the D*.SMD file, if you can just manufacture an appropriate Q*.SMD file, you can have IMail re-send the message while passing on the complete headers and without having to do any editing of the D*.SMD file although there probably are useful smarty pants edits (e.g. changing the "From:" line to something like "From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]" orinserting the frills Received-SPF: header). Here's the format of the Q*.SMD file, as per the venerable R. Scott Perry: http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg64280.html The "S" sender row would normally be[EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there. The "R" recipient row would then be the 3rd party destination, e.g. [EMAIL PROTECTED] In my testing it seemed that also using the "N" original recipient row to the sender field would preserve the "Reply-To:" as the original sender but that may have been an artifact of bad thinking on my part (you'd best extract the original Declude spoolname from the tmp*.tmp file and use that to extract the MAILFROM for that message from the sys*.txt file! [To get that, you must use the "XSENDERON" option in your global.cfg file]) The "Q" file row defines the fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD format; you can just specify the tmp*.tmp file here. The "H" host row is just your normal name for the IMail host. The "I" guid row contains the long id number that IMail will use in the sys*.txt file to identify this message. Ideally this would be unique every time; however for testing you could write out the same row every time. Here's a sample: QC:\IMail\spool\tmp1B.tmpHmail.madriver.comIc507787800822fbdWC:\IMailS[EMAIL PROTECTED]NRCPT TO:[EMAIL PROTECTED]R[EMAIL PROTECTED] The third thing the script would dois tohave IMail deliver the message. Here's how to re-queue a single Q*.SMD + D*.SMD pair: http://support.ipswitch.com/kb/IM-2623-DM02.htm The short version being that if you make sure that the Q*.SMD file (which can be any filename) contains the "Q" row and a fully qualified D*.SMD file (which can be any filename) you can just call: smtp32.exe Qxxx.SMD and IMail will queue it up immediately. Ta-dah! Easy as world peace. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick HayerSent: Saturday, March 04, 2006 1:13 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] spf breaks email forwarding - Matt wrote: Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF.SRS is a work around - and I'm simply asking if anyone has implemented it on
Re[4]: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
Using other's mailing lists for support and public documentation, ldap, VBS scripts. And free vs. free and both IMHO are equal amounts of spam. IIS SMTP has extremely active newsgroups with Microsoft employees and MVPs watching it closely, and I don't think you will find any _competitive_ spam there (cross-posts about erectile dysfunction are not the issue). There are equal amounts of spam *where* and *where*, again? Anyway, the issue was never the sending of spam to private lists, it's your _willing acceptance_ of spam on an _anti-spam_ list. Also, free vs. free? Since when? The other product is not a free product; it was spamvertised here as a commercial offering. What kind of spin is going on here? Tarpitting, country blocking and native Win service and about five minutes of my time. Sorry and it wasn't just address validation. Just as I thought, it wasn't just address validation. . . so it's complete apples-and-oranges and an irrelevant comparison (IIS SMTP vs. the other product). Of course, IIS SMTP doesn't have the bells and whistles built into _many_ standalone MTAs (not just this particular other product). Everybody knows that. And most of those MTAs are competitors to IMail/SmarterMail/Declude in some fashion. And yet, oh-so-curiously, every other one of those vendors hasn't seen fit to spam this list. Guess they haven't discovered this free billboard space yet. Unix sendmail is free as well. Wonder why everyone went to Imail. H. Are you seriously suggesting that setting up IIS SMTP with address validation vs. setting up the other product was as hard for you as setting up sendmail vs. IMail? Have you ever set up sendmail? Or was it that trying to make IIS SMTP do other things it doesn't do _at all_, even with third-party add-ons, was as hard as setting up sendmail? Well, that'd be quite an understatement, since not being able to perform a function _at all_ is way beyond difficult, no? And another reason that the comparison is irrelevant. This remains an amazing example of selling out the anti-spam community and somehow still getting kudos. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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[2]: [Declude.JunkMail] spf breaks email forwarding -
If you want to perservere and build your own forwarding system, what I found was that. . . Andrew, I like your workaround with the Program Alias. However, I think that instead, if people are willing to wait a few weeks to a month, I can find time to put out a full-fledged external test for Declude that does much the same thing, without having to forge brand-new Q files and so on, honoring IMail-level forwards. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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] spf breaks email forwarding -
Ok, I'll bite. SRS is not part of SPF, it is just another protocol/method. SPF has a problem in that it only suggests the "possibility" of forgeries, yet some have put in place strict rules that take this beyond the suggestion. SRS is just one of several different proposed solutions for handling forwarded E-mail. It has the most clout of all of them because it was also loosely defined by SPF's creator as being a solution to the forwarding problem in a paper on their site (if I recall correctly). The bottom line here is that implementing SPF does not require implementing SRS. Their strategy for combining these things (and others), is far from clear at this time. Back to SRS. SRS isn't just simply changing the Mail From address, it is a system that requires both the encoding and parsing of the Mail >From addresses, and it requires both the sending and receiving MTA to be SRS aware. The following is from what is apparently the master SRS document located at http://www.libsrs2.org/srs/srs.pdf : The SRS scheme must ensure that it is not possible to construct an SRS address which forwards mail to an arbitrary user. This is achieved by introducing a cryptographic element into addresses such that it is possible to spot tampering with the destination user or host fields. The actual SRS address format looks like this: [EMAIL PROTECTED] The fields are as follows: SRS0: This identities the address as an SRS address. This allows hosts to distinguish easily between ordinary email addresses and SRS return addresses directed to the same mail server. The 0 is in some sense a version number for the protocol; it is used later. HHH: This is a cryptographic hash of the fields timestamp, hostname and local-part. This hash may only be generated or validated by someone in possession of the secret key used in the cipher, that is to say, forward.com. If a spammer tries to forge an SRS address, he will not be able to generate a valid hash, and forward.com will simply reject the mail. TT: This limits the validity of an SRS address. It is expected that bounces will return within a few days, at most a month, of an email being sent. If a spammer gets hold of an SRS address for a user, then they can use the SRS system to bounce mails to that user. The limited validity of the timestamp reduces considerably the value to the spammer of the SRS system, since none of his target addresses is valid for more than a few days. The spammer cannot falsify the timestamp in an SRS address because this would cause a failure of the cryptographic check on the forwarder. Hostname: The hostname of the original sender and final recipient for bounces. local-part: The local-part of the original sender and final recipient for bounces. The order of the hostname and local-part was chosen to allow the use of the = character as a separator. There is also an SRS1 format in addition to the SRS0 format above. SRS1 is for forwarding things that have already been forwarded by SRS. It's in the paper. One big caveat that the paper notes is the violation of RFC's 2821 and 2822 where there is a 64 character limit to the user address, and this limit is enforced by MailGuard and Cisco PIX, and I would imagine other MTA's. SRS "adds 21 characters plus two local hostnames as overhead to the local part" the paper explains. Maybe they should rewrite RFC 2811 and 2822 before releasing this? Another caveat is that hosts or admins that aren't SRS aware may improperly identify the forwarder's domain as being the source of spam. Another big issue is that SPF does not specify the mechanism for validating forwarding, and there are 4 other competing solutions that are summarized (not fully) on the following page: http://www.michaelbrumm.com/spf-forwarding.html The recommended forwarding mechanism for the proposed marrying of SPF and Caller ID is to add the "SUBMITTER" parameter to ESMTP. Even the SPF page on SRS mentions this as an alternative/replacement. None of this information seems to have been updated since somewhere in 2004. Note to Sandy: I think that Declude locks the Q* file, and if so, writing a Declude plug-in won't work. Besides that, it would only be a partial implementation of true SRS since the MTA needs to be aware in order to prevent forgeries. Matt Colbeck, Andrew wrote: Hey, Nick. I spent some timepoking at this with a stick. Since I just use IMail as a gateway so that I can use Declude... I've had no use for IMail mailboxes or forwarding, so it was all new to me. The real answer is that you should lobby Ipswitch to implement that sender re-writing in their forwarding (what the heck... all of SPF plus the bells and whistles while they're at it). If you can garner support from other people to make the same request, all the better. You can also tell your client "Sorry, Adelphia controls how [EMAIL PROTECTED] email is moved around and since the destination you want adheres to
Re: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
Sandy, I don't want to have a flame war here, but I do want to encourage discussions that are beneficial to both myself and the community at large. The Declude list is frequented by many non-Declude users for the very reason that it isn't just simply a support group for a product (even if it was originally designed to be that), it has instead become a forum for exchanging valuable information, sometimes even reaching beyond spam and virus prevention. I am the person that brought up Alligate, and I did so in response to someone asking me what I am using for a gateway. I also of course mentioned VamSOFT's ORF, which market's itself as a full fledged anti-spam gateway (but falls far short to Declude). In fact, you were the person that lead me to ORF, and that was on this list: http://www.mail-archive.com/declude.junkmail@declude.com/msg16032.html I am very thankful that you did that because I had to have a solution, and I have shared information and scripts with others to be used with ORF, and made several other converts. Likewise, I wouldn't be staying true to the community spirit if I didn't divulge my appreciation for what Alligate does, and how it is a much better alternative for those of us that absolutely must have an address validating and pre-scanning gateway. In the same light, Declude also competes with IMail's own offering, and Declude definitely favors the SmarterMail implementation due to their much tighter relationship with SmarterTools, yet there is plenty of discussion on the IMail list of Declude, and such discussions have never been banned. Alligate also is the company that publishes the MXRate IP4R test that was most recently discussed last week, and I am aware that Brian and Barry are friendly and have talked occasionally over the past couple of years. The Alligate Gateway is competitively priced, and designed exclusively as an enhancement to products like IMail/SmarterMail with Declude. While there are other such solutions out there, nothing lays a hand on it's functionality, and there are some very nice things in beta that will propel it even farther forward. For Erik, who asked the question that prompted my reply, the latest Alligate Gateway will definitely solve almost all of his issues with malformed spam since it is zombie generated, and the gateway's greylisting support will block pretty much all zombie spam, and regardless of whether or not it normalizes the malformed headers. From the sounds of things, Declude is going to need some time to rewrite the code that processes the headers, which would be welcomed, but not necessarily timely enough for some in light of current circumstances. If conversations like this are beaten down or censored, this list will cease to be a free (mostly) exchange of expert ideas and opinions, and in turn it will become nothing more than a support list with newbs asking the same questions over and over and over again, and instead of us answering the questions, that would mostly be left to Declude to answer (like the SmarterMail forum) as the experts seek open forums in which to discuss what we do here. I'm not saying that your opinions are without any merit, but they, like mine, are just opinions, and I hope that we all continue to share them. I have no doubt that you will disagree with some of this, but let's just agree to disagree and spare the list from less productive discussions. Matt Sanford Whiteman wrote: Using other's mailing lists for support and public documentation, ldap, VBS scripts. And free vs. free and both IMHO are equal amounts of spam. IIS SMTP has extremely active newsgroups with Microsoft employees and MVPs watching it closely, and I don't think you will find any _competitive_ spam there (cross-posts about erectile dysfunction are not the issue). There are "equal amounts of spam" *where* and *where*, again? Anyway, the issue was never the sending of spam to private lists, it's your _willing acceptance_ of spam on an _anti-spam_ list. Also, "free vs. free"? Since when? The other product is not a free product; it was spamvertised here as a commercial offering. What kind of spin is going on here? Tarpitting, country blocking and native Win service and about five minutes of my time. Sorry and it wasn't just address validation. Just as I thought, it wasn't just address validation. . . so it's complete apples-and-oranges and an irrelevant comparison (IIS SMTP vs. the other product). Of course, IIS SMTP doesn't have the bells and whistles built into _many_ standalone MTAs (not just this particular other product). Everybody knows that. And most of those MTAs are competitors to IMail/SmarterMail/Declude in some fashion. And yet, oh-so-curiously, every other one of those vendors hasn't seen fit to spam this list. Guess they haven't discovered this free billboard space yet. Unix sendmail is free as well. Wonder why
Re[2]: [Declude.JunkMail] spf breaks email forwarding -
Back to SRS. SRS isn't just simply changing the Mail From address, it is a system that requires both the encoding and parsing of the Mail From addresses, and it requires both the sending and receiving MTA to be SRS aware. The following is from what is apparently the master SRS document. . . I'm not going for an SRS implementation, but a simple method of performing server-side envelope sender address rewriting. The implementation is not intended for use by dedicated forwarders, who must by necessity assume the pass-through of both messages and DSNs. Rather, it is intended for mailbox providers to pre-fetch IMail account- and mailbox-level forwards and rewrite accordingly. Things will break: bounces of forwarded mail will not be returned to the original sender, and this breakage is by design. But SPF 1.0 checks will pass, which is the matter under discussion. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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[2]: [Declude.JunkMail] [139-0B9B7BC7-18FF] Declude not inserting headers and Marking
In fact, you were the person that lead me to ORF, and that was on this list: http://www.mail-archive.com/declude.junkmail@declude.com/msg16032.html I, *who have no business relationship with Vamsoft*, am proud to have recommended their product. Why is it so hard to get across that a vendor spamming the list, unsolicited, is not the same as a user recommending their preferred product? And why is it so hard to get across that your recommendation of your now-preferred product, which you found out about _because_ it was spamvertised on this list, is different from as a user recommending a product that has not sold out the ethics of the anti-spam community on this very list? In the same light, Declude also competes with IMail's own offering, and Declude definitely favors the SmarterMail implementation due to their much tighter relationship with SmarterTools, yet there is plenty of discussion on the IMail list of Declude, and such discussions have never been banned. There have not been unsolicited product announcements from Declude on the IMail list. Alligate also is the company that publishes the MXRate IP4R test that was most recently discussed last week, and I am aware that Brian and Barry are friendly and have talked occasionally over the past couple of years. Is _that_ the new spin? Hey, lots of people have talked to Barry. Does that mean everyone gets one free billboard? Let me ask you something: does the fact that you, Matt, offer free filters that help the anti-spam community mean that you can promote your outsourced anti-spam service in a brand-new, out-of-context product announcement? If yes, why so, and why haven't you availed yourself of the marketing opportunity? If no, why not? The Alligate Gateway is competitively priced, and designed exclusively as an enhancement to products like IMail/SmarterMail with Declude. I utterly disbelieve that premise, since I know that the same company sells a full version that is a full-on competitor, and since I also know that the gateway is no more targeted for Declude environments than it could be deemed a targeted enhancement for any environment that lacks its functionality. I also know that the other product has many, many competitors who do not spam. And if competitively priced cancels out spamminess, you'd better tweak your filters! While there are other such solutions out there, nothing lays a hand on it's functionality. . . Do you think that's the reason that other vendors haven't spammed the list? Because they just don't have the functionality to back it up? Ah. . . no. Gateway appliances? Carrier-class MTAs? Of course they lay more than a hand on its functionality. They just wouldn't think of stepping in here. I'm not saying that your opinions are without any merit, but they, like mine, are just opinions, and I hope that we all continue to share them. I have no doubt that you will disagree with some of this, but let's just agree to disagree and spare the list from less productive discussions. You're trying to shut me down as if this is off-topic, but it's not. I believe that people's acceptance of spamvertising on this list calls into question the supposedly ethical core of fighting unsolicited mail. Some people are willing to overlook business practices that represent what their own company stands against, if the products being spamvertised help them make money. Of course, many of us profit (by software licensing, hourly consulting rate, or hosting fees) from the additional workload spam has placed on IT, but we usually don't put those cards on the table so blatantly. Apparently, I am not yet jaded enough to let this go. I'm sure I will let it go soon enough. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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.
