RE: [Declude.JunkMail] Declude 2.0 -> crash
Yes, it's occurring with 2.04. I agree with Scott in principle - it is better to determine the underlying cause of a problem, than to quick-fix the symptom. Too often have I seen short-term solutions cover up big issues that ended up having a much bigger impact later. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Saturday, February 12, 2005 12:40 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Declude 2.0 -> crash Hi Scott, Just to clarify...is this problem occurring with 2.04? Just wanted to check before I updated. Thanks, Darin. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0 -> crash
Hi Scott, Just to clarify...is this problem occurring with 2.04? Just wanted to check before I updated. Thanks, Darin. - Original Message - From: "R. Scott Perry" <[EMAIL PROTECTED]> To: Sent: Friday, February 11, 2005 7:43 PM Subject: RE: [Declude.JunkMail] Declude 2.0 -> crash >We've gone back to 1.82 as well. > >We'll wait again until 2.0 is proven stable. Declude hasn't been like what >has been in the past. Just to let people know a bit about this -- the source of the crash was identified pretty quickly. And a change could have been made almost as quickly to prevent the crash. However, in this case, the D*.SMD files (the ones containing the E-mail body) were disappearing -- a situation that should (in theory) never happen. There are causes for this (such as an on-access virus scanner), but they aren't very common. So my advice was that rather than just fix the crash, further investigation should be done to determine why those files were disappearing. That way, we can have a new release that fixes the crash without running the risk of people noticing a new problem (that they weren't seeing simply because the crash occurred). With software, there are often minor issues that come up that don't get addressed because they seem so minor or aren't being reported. Yet many times when this happens, a bigger bug appears later that would have been fixed if the minor issue had been dealt with right away. I've seen this a number of times with software I've worked on that nobody but myself runs. One out of a hundred times, something that isn't quite right will appear. The thought process is "Gee, it would be a good idea to look into that to see why it happened, but it would be a lot of work tracking it down; I'll deal with that later." With a program that only I run, that's fine. But for software that 1,000s of people are running, most of whom consider E-mail to be mission critical, I think it is best to wait and have it done right. And, to take credit away from where it should be taken (or whatever the opposite of "giving credit where it is due" is), the crash is occurring in code that I wrote. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0 -> crash
We've gone back to 1.82 as well. We'll wait again until 2.0 is proven stable. Declude hasn't been like what has been in the past. Just to let people know a bit about this -- the source of the crash was identified pretty quickly. And a change could have been made almost as quickly to prevent the crash. However, in this case, the D*.SMD files (the ones containing the E-mail body) were disappearing -- a situation that should (in theory) never happen. There are causes for this (such as an on-access virus scanner), but they aren't very common. So my advice was that rather than just fix the crash, further investigation should be done to determine why those files were disappearing. That way, we can have a new release that fixes the crash without running the risk of people noticing a new problem (that they weren't seeing simply because the crash occurred). With software, there are often minor issues that come up that don't get addressed because they seem so minor or aren't being reported. Yet many times when this happens, a bigger bug appears later that would have been fixed if the minor issue had been dealt with right away. I've seen this a number of times with software I've worked on that nobody but myself runs. One out of a hundred times, something that isn't quite right will appear. The thought process is "Gee, it would be a good idea to look into that to see why it happened, but it would be a lot of work tracking it down; I'll deal with that later." With a program that only I run, that's fine. But for software that 1,000s of people are running, most of whom consider E-mail to be mission critical, I think it is best to wait and have it done right. And, to take credit away from where it should be taken (or whatever the opposite of "giving credit where it is due" is), the crash is occurring in code that I wrote. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0 -> crash
Good reminder for me - Nothing will ever be like it was. Software development is an insane business. One of the reasons I got out of it. I've value the support I get from Declude and Sniffer folks. I would rather pay these guys money to help me fight the bad guys by listening and trying to provide some code that works in the end versus paying a bazillion bucks for Microsoft products that they think will save me. After the last couple years I've learned to be able to back out an upgrade within a few minutes. I always expect something to happen. Not all the time mind you but right now I know the company needs some more time to settle down. Keep the heat on since I have no desire to rob a bank to replace the support and functionality these products give me. And gotta add the list participants are equally excellent assets to the battle. Gotta run ... Imail web service just went down. Michael Jaworski Puget Sound Network, Inc. (206) 217-0400 (800) 599-9485 --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0 -> crash
We've gone back to 1.82 as well. We'll wait again until 2.0 is proven stable. Declude hasn't been like what has been in the past. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Saturday, February 12, 2005 12:12 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Declude 2.0 -> crash Well, about an hour ago they had to leave for the weekend. I watched my system a little longer - and eventually seeing a crash every few minutes (due to high load), I had to go back to 1.82. Best Regards Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, February 11, 2005 11:30 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Declude 2.0 -> crash Andy, just for kicks, can you exclude any scanning of smd, _md, ~md files and such. John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0 -> crash
Well, about an hour ago they had to leave for the weekend. I watched my system a little longer - and eventually seeing a crash every few minutes (due to high load), I had to go back to 1.82. Best Regards Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, February 11, 2005 11:30 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Declude 2.0 -> crash Andy, just for kicks, can you exclude any scanning of smd, _md, ~md files and such. John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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.
[Declude.JunkMail] Website - version number on webpage
Thumbs up for putting the current version number on the main Declude web page.
RE: Re[4]: [Declude.JunkMail] domain name a name
I personaly agree completely with Pete's arguments. I've asked over a year ago the first time for custom hold folders. The benefit of "keep and check again later" is only one offered by custom hold folders. Fortunately v2 now has custom hold folders. I've also mentioned months ago what Matt said: requeuing and call Declude with a VB-Script. I personaly would have this functionality not to Delay a lot of legit mails in order to catch also a few spam messages that slip trough. The idea is to bring out of the review range as much messages as possible. Independently if reviewing is done by one operator or on client side. The goal is to have as less messages as possible in this range. Both Operators and clients are human and after days of seeing only spam in the review folder, this humans will stop watching attentive for legit messages. In order to avoid FP's I believe we all have configured our review range pretty conservative and usualy find 0,00x % of false positives durring review. So the delayed messages are at 99,99x% spam, and so it's absolutely no problem if they are delayed several hours (cached DNS, Filter-Updates, ...) If this idea it's worth would only show up a practical test with a report what percentage of the review range would recieve a higher weight after some hours... Markus > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox > Sent: Friday, February 11, 2005 8:19 PM > To: Declude.JunkMail@declude.com > Subject: Re: Re[4]: [Declude.JunkMail] domain name a name > > Hmmm...some of our customers are constantly in contact with > new personnel, even new businesses, that they work with in a > consulting role. This absolutely would not work for them, as > the delays would be unacceptable. In their case, they'd > rather see a few of the Rx spam messages get through than > have a delay on new ham. Wouldn't work for me either for > similar reasons. > > Though it's certainly an idea if it can be turned off on a > per-domain, possibly even per-user basis. A few of our > customers might go for it, but most would rather deal with > the 0.5% that slip through. > > Darin. > > > - Original Message - > From: "Pete McNeil" <[EMAIL PROTECTED]> > To: "Darin Cox" > Sent: Friday, February 11, 2005 9:49 AM > Subject: Re[4]: [Declude.JunkMail] domain name a name > > > On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: > > DC> Hi Pete, > > DC> Right... but the first few typically slip through before > they're added > to > DC> your filters (like they would for anyone)...so we add > them on the first > DC> report to us as well. > > I'll raise the feature request again --- as soon as I get my > flameproof suit on: > > Declude should have a test/feature to delay a message by x hours if > the sender is not recognized. This gives all filtering mechanisms time > to adapt to new spam sources. Once the delay time has expired the > message is passed through as if it were new so that the presumably > updated BLs, filters, etc will have the ability to filter the message > (if needed). > > To revive and put to rest past arguments about this: > > Big reason not to do this: It is unforgivable and in all other ways a > bad idea to delay any message by any amount of time and huge amounts > of money or even lives may be lost if this happens. > > To which I contend... > > If this is the first time you have ever received a message from a > particular source then there is no expectation yet for the time to > delivery and email systems in general may impose end-to-end delays of > between minutes to hours depending upon many unknown factors at any > time (queues, down servers, down connectivity, graylisting (force > retry at first connect)). > > Since only _new_ connections would be effected, this feature would go > almost un-noticed in the vast majority of cases. All other email > sources, where there is an expectation, would be passed at full speed > with normal filtering. > > Also, IF you happen to be in a position where you really can't afford > to impose any delays on new messages then: A) You probably aren't > filtering anyway since that would be dangerous [ a conflict in policy > ] and B) You _can_ turn it off ;-) > > Those are my thoughts on that ( once again ). > > _M > > /M retreats to underground bunker & activates shields at full power. > > > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.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 was scanned for viruses by Declude Virus > (http://www.declude.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.Junk
Re: [Declude.JunkMail] domain name a name
Yeah, I raised the idea of Whois registration date checks a few months ago and was shot down...for various legitimate reasons. I've thought about the gibberish vs. real domain check as well...problem is it can be very difficult, if not impossible to determine that. Acronyms could be impossible to determine from gibberish domainsthough perhaps a combo test with a whois reg. date check might help the accuracy a bit. However, only about half of the domain names we see like this are gibberish. Many are portions of doctor or prescription-like words stuck together. We could add a small weight to domains that have these fragments, but I wouldn't be comfortable holding on just thatand many of these initial spams don't fail any other of our tests. Another possibility that comes to mind is recording the total number of identical message bodies that come in over a given time. If more than X in period Y, then signal a body filter to hold it. This would catch a lot of bulk mailers, though, and could easily be defeated by simply varying each message body by a few characters. Darin. - Original Message - From: "Nick" <[EMAIL PROTECTED]> To: Sent: Friday, February 11, 2005 9:46 AM Subject: Re: [Declude.JunkMail] domain name a name On 11 Feb 2005 at 8:51, Darin Cox wrote: Hi Darin - > Most of what slips through our filters is exactly this. Unfortunately > I know of no way to block this short of reacting to the first one seen > and adding a body filter for the URL Same here and that is exactly what I do. Mike had a good idea by using a registration date as a penalty, another idea was something along the lines some sort on non-english test for domain names contained in the body - however I have no idea how to do that - -Nick > > - Original Message - > From: "Nick" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, February 09, 2005 12:25 PM > Subject: Re: [Declude.JunkMail] domain name a name > > > I am seeing more and more I guess one would call throw-away domains > like: > > .hdcnsowp.com > .hcnmvkofut.com > .eisopfkcnjt.com > .edhcbxgsyi.com > > These are generally in the body of an email; is there a way to > determine if a domain is in readable format? I would not fail an > email over this but it would be nice to punish the email at least to > some degree - > > -Nick > > > > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.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 was scanned for viruses by Declude Virus > (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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: Re[4]: [Declude.JunkMail] domain name a name
Hmmm...some of our customers are constantly in contact with new personnel, even new businesses, that they work with in a consulting role. This absolutely would not work for them, as the delays would be unacceptable. In their case, they'd rather see a few of the Rx spam messages get through than have a delay on new ham. Wouldn't work for me either for similar reasons. Though it's certainly an idea if it can be turned off on a per-domain, possibly even per-user basis. A few of our customers might go for it, but most would rather deal with the 0.5% that slip through. Darin. - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Darin Cox" Sent: Friday, February 11, 2005 9:49 AM Subject: Re[4]: [Declude.JunkMail] domain name a name On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC> Hi Pete, DC> Right... but the first few typically slip through before they're added to DC> your filters (like they would for anyone)...so we add them on the first DC> report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker & activates shields at full power. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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: Re[4]: [Declude.JunkMail] domain name a name
Postfix with postgrey does exactly this. Delays 5 minutes and maintains a db of subnet, sender & recipient combo. Mike - Original Message - From: "Colbeck, Andrew" <[EMAIL PROTECTED]> To: Sent: Friday, February 11, 2005 13:56 Subject: RE: Re[4]: [Declude.JunkMail] domain name a name I meant to also add that I recently had many hours of planned downtime on my MTA in my absolute lowest ham window - late Saturday evening through early Sunday morning. I saw very little spam increase once the MTA was back up. This tells me that the spammers have not yet implemented full MTAs that retry their queued spam. An MTA that tells them to try again later (greylisting) would work well for me. If greylisting that was configurable by hours was available to me, I might turn it off during business hours for maximum "safety". I would also want a feature to gather addresses/domains/IPs from my outbound mail to create an autowhitelist*. Andrew 8) * http://eservicesforyou.com/ John Tolmachoff, do you still sell AutoWhite? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 11, 2005 6:49 AM To: Darin Cox Subject: Re[4]: [Declude.JunkMail] domain name a name On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC> Hi Pete, DC> Right... but the first few typically slip through before they're DC> added to your filters (like they would for anyone)...so we add them DC> on the first report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker & activates shields at full power. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] domain name a name
I agree, the mechanics are simple. The difficulties lie in gathering the information in the database and gauging how long to wait before re-testing, and how to get fresh results. For example, DNS cacheing will mean that you get the same results from your IP4R tests if you do them only a short time later. Much the same applies to Message Sniffer, whose updates currently average about 6 hours apart. I've no idea how fast SURBL is actually updated with a given URI, but I believe they make hourly updates (for the SpamCop derived one, at least). Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Friday, February 11, 2005 10:55 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] domain name a name I don't think that I am really interested in this personally, but you could probably fairly easily write a script that acted as an external test in Declude that would check the special HOLD directory for files older than X number of minutes, move the D* files back into the spool and call Declude with the location of the Q* file. You would probably want to limit the number of reprocessed E-mails for each attempt to a small number so that you don't overwhelm your server. You could also just simply dump them into an overflow directory and have Declude take care of the reprocessing priority itself. I'm guessing that this could be done in less than 100 lines of VBScript and it would be rather straightforward to code. Matt Colbeck, Andrew wrote: >Pete I agree with you. Graylisting or greylisting would be a great add >on to Declude. > >I've hoped for this in an MTA, but it doesn't look like CPHZ will go >that way, and since Ipswitch only adopts antispam measures that Declude >already has , it won't be coming from them. SmarterMail may well >be more receptive to suggestions. > >The current Declude architecture could do it however, as evidenced by >the nifty logic which implements the Overflow folder. Instead of the >MTA rejecting the message with a 5xx error, Declude would tuck away the >new message Q*.SMD and D*.SMD in a folder, and re-scan the messages in >that folder that have aged sufficiently and take the usual actions. > >This could also be a relatively easy 3rd party add-on, and is made a >little easier now that Declude 2.0 supports a HOLD with a specified >folder name. > >For those who want to learn more about greylisting, I suggest this: > >http://projects.puremagic.com/greylisting/ > >Andrew 8) > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil >Sent: Friday, February 11, 2005 6:49 AM >To: Darin Cox >Subject: Re[4]: [Declude.JunkMail] domain name a name > > >On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: > >DC> Hi Pete, > >DC> Right... but the first few typically slip through before they're >DC> added to your filters (like they would for anyone)...so we add them >DC> on the first report to us as well. > >I'll raise the feature request again --- as soon as I get my flameproof >suit on: > >Declude should have a test/feature to delay a message by x hours if the >sender is not recognized. This gives all filtering mechanisms time to >adapt to new spam sources. Once the delay time has expired the message >is passed through as if it were new so that the presumably updated BLs, >filters, etc will have the ability to filter the message (if needed). > >To revive and put to rest past arguments about this: > >Big reason not to do this: It is unforgivable and in all other ways a >bad idea to delay any message by any amount of time and huge amounts of >money or even lives may be lost if this happens. > >To which I contend... > >If this is the first time you have ever received a message from a >particular source then there is no expectation yet for the time to >delivery and email systems in general may impose end-to-end delays of >between minutes to hours depending upon many unknown factors at any >time (queues, down servers, down connectivity, graylisting (force retry >at first connect)). > >Since only _new_ connections would be effected, this feature would go >almost un-noticed in the vast majority of cases. All other email >sources, where there is an expectation, would be passed at full speed >with normal filtering. > >Also, IF you happen to be in a position where you really can't afford >to impose any delays on new messages then: A) You probably aren't >filtering anyway since that would be dangerous [ a conflict in policy ] >and B) You _can_ turn it off ;-) > >Those are my thoughts on that ( once again ). > >_M > >/M retreats to underground bunker & activates shields at full power. > > > >--- >[This E-mail was scanned for viruses by Declude Virus >(http://www.declude.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.Junk
RE: [Declude.JunkMail] Multiple Duplicate Recipients
That's another thing I want to see in a "next generation" MTA; I want to incrementally punish a message that is destined for multiple addresees who are not in my addresss book. Right now, I can manually do it because I have a gateway scenario, so all addresses are currently allowed by the MTA. I then have a Declude JunkMail Pro filter that adds weight when certain unlikely names are in the ALLRECIPS. That technique will go away for me when I actually implement envelope rejection. Why? Oh, that's because most of the spam I see that throws extra, guessed, recipients in does so in the BCC line, they don't appear in the header. So if I have envelope rejection in the MTA, when Declude sees the message, it has no idea that there were extra, bogus recipients in the original recipient list. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Geiser Sent: Friday, February 11, 2005 6:15 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Multiple Duplicate Recipients Hello, All, A type of "obvious" spam that we receive has the same recipient listed multiple times in the X-Note: Recipient(s): field, e.g. X-Note: Recipient(s): [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] When I see this in the headers I know immediatelty that is spam. It would be great if Declude could have a test built into it in which you could punish e-mail if it had x number of multiple duplicate recipients. If this functionality does not exist I would like to put in a development request for it. Thanks In Advance, Dan Geiser [EMAIL PROTECTED] --- E-mail scanned for viruses by Nexus (http://www.ntgrp.com/mailscan) --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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: Re[4]: [Declude.JunkMail] domain name a name
I meant to also add that I recently had many hours of planned downtime on my MTA in my absolute lowest ham window - late Saturday evening through early Sunday morning. I saw very little spam increase once the MTA was back up. This tells me that the spammers have not yet implemented full MTAs that retry their queued spam. An MTA that tells them to try again later (greylisting) would work well for me. If greylisting that was configurable by hours was available to me, I might turn it off during business hours for maximum "safety". I would also want a feature to gather addresses/domains/IPs from my outbound mail to create an autowhitelist*. Andrew 8) * http://eservicesforyou.com/ John Tolmachoff, do you still sell AutoWhite? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 11, 2005 6:49 AM To: Darin Cox Subject: Re[4]: [Declude.JunkMail] domain name a name On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC> Hi Pete, DC> Right... but the first few typically slip through before they're DC> added to your filters (like they would for anyone)...so we add them DC> on the first report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker & activates shields at full power. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] domain name a name
I don't think that I am really interested in this personally, but you could probably fairly easily write a script that acted as an external test in Declude that would check the special HOLD directory for files older than X number of minutes, move the D* files back into the spool and call Declude with the location of the Q* file. You would probably want to limit the number of reprocessed E-mails for each attempt to a small number so that you don't overwhelm your server. You could also just simply dump them into an overflow directory and have Declude take care of the reprocessing priority itself. I'm guessing that this could be done in less than 100 lines of VBScript and it would be rather straightforward to code. Matt Colbeck, Andrew wrote: Pete I agree with you. Graylisting or greylisting would be a great add on to Declude. I've hoped for this in an MTA, but it doesn't look like CPHZ will go that way, and since Ipswitch only adopts antispam measures that Declude already has , it won't be coming from them. SmarterMail may well be more receptive to suggestions. The current Declude architecture could do it however, as evidenced by the nifty logic which implements the Overflow folder. Instead of the MTA rejecting the message with a 5xx error, Declude would tuck away the new message Q*.SMD and D*.SMD in a folder, and re-scan the messages in that folder that have aged sufficiently and take the usual actions. This could also be a relatively easy 3rd party add-on, and is made a little easier now that Declude 2.0 supports a HOLD with a specified folder name. For those who want to learn more about greylisting, I suggest this: http://projects.puremagic.com/greylisting/ Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 11, 2005 6:49 AM To: Darin Cox Subject: Re[4]: [Declude.JunkMail] domain name a name On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC> Hi Pete, DC> Right... but the first few typically slip through before they're DC> added to your filters (like they would for anyone)...so we add them DC> on the first report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker & activates shields at full power. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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: Re[4]: [Declude.JunkMail] domain name a name
Pete I agree with you. Graylisting or greylisting would be a great add on to Declude. I've hoped for this in an MTA, but it doesn't look like CPHZ will go that way, and since Ipswitch only adopts antispam measures that Declude already has , it won't be coming from them. SmarterMail may well be more receptive to suggestions. The current Declude architecture could do it however, as evidenced by the nifty logic which implements the Overflow folder. Instead of the MTA rejecting the message with a 5xx error, Declude would tuck away the new message Q*.SMD and D*.SMD in a folder, and re-scan the messages in that folder that have aged sufficiently and take the usual actions. This could also be a relatively easy 3rd party add-on, and is made a little easier now that Declude 2.0 supports a HOLD with a specified folder name. For those who want to learn more about greylisting, I suggest this: http://projects.puremagic.com/greylisting/ Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 11, 2005 6:49 AM To: Darin Cox Subject: Re[4]: [Declude.JunkMail] domain name a name On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC> Hi Pete, DC> Right... but the first few typically slip through before they're DC> added to your filters (like they would for anyone)...so we add them DC> on the first report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker & activates shields at full power. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0 -> crash
Andy, just for kicks, can you exclude any scanning of smd, _md, ~md files and such. John Tolmachoff Engineer/Consultant/Owner eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Andy Schmidt > Sent: Friday, February 11, 2005 6:23 AM > To: Declude.JunkMail@declude.com > Subject: RE: [Declude.JunkMail] Declude 2.0 -> crash > > Hi, > > Nope, this is 2.0.4 - just checked my root, this was not the only > occurrence. They contacted me, so I'm in the process to collect logs and > configs to send it off. > > My Declude.GP1 states: > > (Error 5 at 414c99 v2.0.4) > (attempt to read at 0) > (00414C99 0012FF80 (0002 007A0AB0) D:\IMAIL\Declude.exe) > (0042D781 0012FFC0 ( 00135F6C) D:\IMAIL\Declude.exe) > (7C59893D 0012FFF0 (0042D6CD ) D:\WINNT\system32\KERNEL32.dll) > Qb23f0f4c05a2 Couldn't open headers datafile (are you running an > on-access virus scanner?) > > Yes - I've always had an 'on-access scanner' - but I have the Imail\Spool > tree excluded. > > Best Regards > Andy Schmidt > > Phone: +1 201 934-3414 x20 (Business) > Fax:+1 201 934-9206 > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Franco Celli > Sent: Friday, February 11, 2005 08:28 AM > To: Declude.JunkMail@declude.com > Subject: Re: [Declude.JunkMail] Declude 2.0 > > > I had the same problem with version 2.0.? (declude executable date = feb. > 1st). > > While no apparent problem with 2.0.4 so far. > > --- > Franco Celli > > > > - Original Message - > From: "Andy Schmidt" <[EMAIL PROTECTED]> > To: > Sent: Friday, February 11, 2005 5:28 AM > Subject: [Declude.JunkMail] Declude 2.0 > > > > Well - I tried... > > > > Minutes after install my mail server became unresponsive - after a few > > minutes, I saw Dr. Watson in the task list - and then found these in > > the root. > > > > Best Regards > > Andy Schmidt > > > > Phone: +1 201 934-3414 x20 (Business) > > Fax:+1 201 934-9206 > > > > > > > > --- > [Quipo ISP - Questa E-mail e' stata controllata dal programma Declude Virus] > [Quipo ISP - This E-mail was scanned for viruses by Declude Virus] > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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[4]: [Declude.JunkMail] domain name a name
On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC> Hi Pete, DC> Right... but the first few typically slip through before they're added to DC> your filters (like they would for anyone)...so we add them on the first DC> report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker & activates shields at full power. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] domain name a name
On 11 Feb 2005 at 8:51, Darin Cox wrote: Hi Darin - > Most of what slips through our filters is exactly this. Unfortunately > I know of no way to block this short of reacting to the first one seen > and adding a body filter for the URL Same here and that is exactly what I do. Mike had a good idea by using a registration date as a penalty, another idea was something along the lines some sort on non-english test for domain names contained in the body - however I have no idea how to do that - -Nick > > - Original Message - > From: "Nick" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, February 09, 2005 12:25 PM > Subject: Re: [Declude.JunkMail] domain name a name > > > I am seeing more and more I guess one would call throw-away domains > like: > > .hdcnsowp.com > .hcnmvkofut.com > .eisopfkcnjt.com > .edhcbxgsyi.com > > These are generally in the body of an email; is there a way to > determine if a domain is in readable format? I would not fail an > email over this but it would be nice to punish the email at least to > some degree - > > -Nick > > > > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.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 was scanned for viruses by Declude Virus > (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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: Re[2]: [Declude.JunkMail] domain name a name
Hi Pete, Right... but the first few typically slip through before they're added to your filters (like they would for anyone)...so we add them on the first report to us as well. Darin. - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Darin Cox" Sent: Friday, February 11, 2005 9:12 AM Subject: Re[2]: [Declude.JunkMail] domain name a name On Friday, February 11, 2005, 8:51:46 AM, Darin wrote: DC> Most of what slips through our filters is exactly this. Unfortunately I DC> know of no way to block this short of reacting to the first one seen and DC> adding a body filter for the URL...the same thing Message Sniffer or any DC> SURBL list would do. DC> I'm add maybe 1-4 of these per day. DC> Sometimes there's enough other text for additional body filters, which can DC> cut down on the number of edits. This is an area we concentrate on... usually these kinds of campaigns have some kind of script running behind them. If we can reverse engineer the scripting (by reviewing many copies) then we can create a compound rule that matches enough static components to avoid legit messages and block all (or most) of the variants of the spam campaign. _M --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0 -> crash
Hi, Nope, this is 2.0.4 - just checked my root, this was not the only occurrence. They contacted me, so I'm in the process to collect logs and configs to send it off. My Declude.GP1 states: (Error 5 at 414c99 v2.0.4) (attempt to read at 0) (00414C99 0012FF80 (0002 007A0AB0) D:\IMAIL\Declude.exe) (0042D781 0012FFC0 ( 00135F6C) D:\IMAIL\Declude.exe) (7C59893D 0012FFF0 (0042D6CD ) D:\WINNT\system32\KERNEL32.dll) Qb23f0f4c05a2 Couldn't open headers datafile (are you running an on-access virus scanner?) Yes - I've always had an 'on-access scanner' - but I have the Imail\Spool tree excluded. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Franco Celli Sent: Friday, February 11, 2005 08:28 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Declude 2.0 I had the same problem with version 2.0.? (declude executable date = feb. 1st). While no apparent problem with 2.0.4 so far. --- Franco Celli - Original Message - From: "Andy Schmidt" <[EMAIL PROTECTED]> To: Sent: Friday, February 11, 2005 5:28 AM Subject: [Declude.JunkMail] Declude 2.0 > Well - I tried... > > Minutes after install my mail server became unresponsive - after a few > minutes, I saw Dr. Watson in the task list - and then found these in > the root. > > Best Regards > Andy Schmidt > > Phone: +1 201 934-3414 x20 (Business) > Fax:+1 201 934-9206 > > > --- [Quipo ISP - Questa E-mail e' stata controllata dal programma Declude Virus] [Quipo ISP - This E-mail was scanned for viruses by Declude Virus] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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.
[Declude.JunkMail] Multiple Duplicate Recipients
Hello, All, A type of "obvious" spam that we receive has the same recipient listed multiple times in the X-Note: Recipient(s): field, e.g. X-Note: Recipient(s): [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] When I see this in the headers I know immediatelty that is spam. It would be great if Declude could have a test built into it in which you could punish e-mail if it had x number of multiple duplicate recipients. If this functionality does not exist I would like to put in a development request for it. Thanks In Advance, Dan Geiser [EMAIL PROTECTED] --- E-mail scanned for viruses by Nexus (http://www.ntgrp.com/mailscan) --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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[2]: [Declude.JunkMail] domain name a name
On Friday, February 11, 2005, 8:51:46 AM, Darin wrote: DC> Most of what slips through our filters is exactly this. Unfortunately I DC> know of no way to block this short of reacting to the first one seen and DC> adding a body filter for the URL...the same thing Message Sniffer or any DC> SURBL list would do. DC> I'm add maybe 1-4 of these per day. DC> Sometimes there's enough other text for additional body filters, which can DC> cut down on the number of edits. This is an area we concentrate on... usually these kinds of campaigns have some kind of script running behind them. If we can reverse engineer the scripting (by reviewing many copies) then we can create a compound rule that matches enough static components to avoid legit messages and block all (or most) of the variants of the spam campaign. _M --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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[2]: [Declude.JunkMail] Spam tests by months
On Wednesday, February 9, 2005, 5:55:48 AM, Markus wrote: MG> Hi Scott, MG> MG> great stat's ! MG> MG> A question about SNIFFER MG> It seems you have a much longer list of different SNIFFER return codes then I MG> Is there somewhere a complete list? MG> MG> Markus Is this what you are looking for? http://www.sortmonster.com/MessageSniffer/Help/ResultCodesHelp.html _M --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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.
[Declude.JunkMail] Having list issues
I'm sorry if you are getting posts from multiple addresses from me. I am just having list issues.
[Declude.JunkMail] not getting any list e-mails -
I am getting nothing from Declude (JM or V) or Imail and I checked the archive and there are many messages I haven't received. I don't think I changed anything. Could I just be off the lists somehow??? Anyone else having issues? If someone can contact me with some suggestions off list I'd appreciate it. Thanks - Marc Catuogno --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] domain name a name
Perhaps a test that looks at the date of registration so new domains could be weighted higher. Mike - Original Message - From: "Nick" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 09, 2005 12:25 Subject: Re: [Declude.JunkMail] domain name a name I am seeing more and more I guess one would call throw-away domains like: .hdcnsowp.com .hcnmvkofut.com .eisopfkcnjt.com .edhcbxgsyi.com These are generally in the body of an email; is there a way to determine if a domain is in readable format? I would not fail an email over this but it would be nice to punish the email at least to some degree - -Nick --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] search for spam
Baretail and BareGrep from MetalSoft are good for a quicker find and dealing with large log files. Or there's always command line Grep and Find. Darin. - Original Message - From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: "Kevin Rogers" Sent: Wednesday, February 09, 2005 8:33 AM Subject: Re: [Declude.JunkMail] search for spam Hi, You should be able to find the domain by opening the log file with a text editor and using the search/find function. I just use notepad. Thanks, Andrew Baldwin [EMAIL PROTECTED] http://www.thumpernet.com 315-282-0020 Tuesday, February 8, 2005, 2:50:03 PM, you wrote: > We have some users that are reporting that emails being sent from a > certain domain are not getting through to them. I would like to find > those messages in my spam folder to check to see if they are being > caught and why. Is there a way to quickly find messages in my spam > folder from a specific domain? Or do I have to just look through each > log file? > --- > [This E-mail was scanned for viruses.] > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] domain name a name
Most of what slips through our filters is exactly this. Unfortunately I know of no way to block this short of reacting to the first one seen and adding a body filter for the URL...the same thing Message Sniffer or any SURBL list would do. I'm add maybe 1-4 of these per day. Sometimes there's enough other text for additional body filters, which can cut down on the number of edits. Anyone else have any ideas? I've thought about checking WHOIS record creation date, but the spammer could just hold onto it for a while before using it... thereby passing any age limit on the domain before passing the test. Darin. - Original Message - From: "Nick" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 09, 2005 12:25 PM Subject: Re: [Declude.JunkMail] domain name a name I am seeing more and more I guess one would call throw-away domains like: .hdcnsowp.com .hcnmvkofut.com .eisopfkcnjt.com .edhcbxgsyi.com These are generally in the body of an email; is there a way to determine if a domain is in readable format? I would not fail an email over this but it would be nice to punish the email at least to some degree - -Nick --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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 was scanned for viruses by Declude Virus (http://www.declude.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] Declude 2.0
I had the same problem with version 2.0.? (declude executable date = feb. 1st). While no apparent problem with 2.0.4 so far. --- Franco Celli - Original Message - From: "Andy Schmidt" <[EMAIL PROTECTED]> To: Sent: Friday, February 11, 2005 5:28 AM Subject: [Declude.JunkMail] Declude 2.0 > Well - I tried... > > Minutes after install my mail server became unresponsive - after a few > minutes, I saw Dr. Watson in the task list - and then found these in the > root. > > Best Regards > Andy Schmidt > > Phone: +1 201 934-3414 x20 (Business) > Fax:+1 201 934-9206 > > > --- [Quipo ISP - Questa E-mail e' stata controllata dal programma Declude Virus] [Quipo ISP - This E-mail was scanned for viruses by Declude Virus] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] Spam tests by months
I've send this message over 46 hours ago. It's only me to receive it on the list so late? I fear if this happens repeatedly an effective discussion is not more possible. Back to snail-mail? Our mailserver received millions of E-mails over the past few days. Once we detected the problem yesterday morning, we were able to block the E-mails and make sure that backed up E-mail got delivered. Just about all of the backed up E-mail has gone out. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] Base 64 Encoded messages
The headers say base64 Declude JunkMail will attempt to decode base64-encoded attachments (unless you have a DECODE OFF line in your global.cfg file, but that means you don't want Declude JunkMail to do such decoding). If you're running an older version of Declude (before around 1.75 I believe), it might not have this ability. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] OT: Switch to control bandwidth
> It > might even be nice to do this on a per-IP basis instead of a > per-port basis, though that's not absolutely necessary. > Since this is a Web hosting segment and our bandwidth is > naturally limited going out, and very little intra-DMZ > traffic exists, something that is 10/100 is all that is necessary. Maybe give a look to a Fortinet 50 or 60-series Firewall. You can manage guaranted & max traffic and also priorize certain protocols. The price shouldn't be higher then a manageable switch with traffic shapping capabilities. If you want to monitor each switch port with SNMP unfortunately the cheap Syslink Switch has no SNMP support. At the moment I look for different solutions. Certain Cisco Catalyst switches looks promising but also the good old HP ProCurve 2512/2524. Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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] Spam tests by months
WOW! I've send this message over 46 hours ago. It's only me to receive it on the list so late? Received: from declude.com [63.246.13.90] by mail.zcom.it with ESMTP (SMTPD32-8.13) id A0E9C6600B6; Fri, 11 Feb 2005 09:46:33 +0100Received: from mail.zcom.it [217.199.0.33] by mail.declude.com with ESMTP (SMTPD32-8.05) id ABE4656800A2; Wed, 09 Feb 2005 05:54:28 -0500Received: from NB [127.0.0.1] by mail.zcom.it with ESMTP (SMTPD32-8.13) id AC35211008C; Wed, 09 Feb 2005 11:55:49 +0100 I fear if this happens repeatedly an effective discussion is not more possible. Back to snail-mail? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus GuflerSent: Wednesday, February 09, 2005 11:56 AMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] Spam tests by months Hi Scott, great stat's ! A question about SNIFFER It seems you have a much longer list of different SNIFFER return codes then I Is there somewhere a complete list? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott FisherSent: Monday, February 07, 2005 10:14 PMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Spam tests by months I've compiled my spam test results over the last year to look at test effectiveness trends. If anyone is interested I've posted them on my website. I've never really seen test effectiveness trended over a year period anywhere else. All tests spam vs. ham based on all emails. http://it.farmprogress.com/declude/Testsbymonth.html Spam tests based on all spam emails. http://it.farmprogress.com/declude/spamtestbymonth.html Ham tests based on all ham emails. http://it.farmprogress.com/declude/hamtestsbymonth.html Warning these are large HTML files. Some examples: Spamcop triggered on 83% of my Feb 2004 spam emails and has downward trended to 57% of my January 2005 spam emails. Message Sniffer has stayed at 95-96% detection of all spam emails from June 2004 to Jan 2005.
RE: [Declude.JunkMail] Spam tests by months
Hi Scott, great stat's ! A question about SNIFFER It seems you have a much longer list of different SNIFFER return codes then I Is there somewhere a complete list? Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott FisherSent: Monday, February 07, 2005 10:14 PMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Spam tests by months I've compiled my spam test results over the last year to look at test effectiveness trends. If anyone is interested I've posted them on my website. I've never really seen test effectiveness trended over a year period anywhere else. All tests spam vs. ham based on all emails. http://it.farmprogress.com/declude/Testsbymonth.html Spam tests based on all spam emails. http://it.farmprogress.com/declude/spamtestbymonth.html Ham tests based on all ham emails. http://it.farmprogress.com/declude/hamtestsbymonth.html Warning these are large HTML files. Some examples: Spamcop triggered on 83% of my Feb 2004 spam emails and has downward trended to 57% of my January 2005 spam emails. Message Sniffer has stayed at 95-96% detection of all spam emails from June 2004 to Jan 2005.
Re: [Declude.JunkMail] domain name a name
I am seeing more and more I guess one would call throw-away domains like: .hdcnsowp.com .hcnmvkofut.com .eisopfkcnjt.com .edhcbxgsyi.com These are generally in the body of an email; is there a way to determine if a domain is in readable format? I would not fail an email over this but it would be nice to punish the email at least to some degree - -Nick --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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.
