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: Declude.JunkMail@declude.com 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] 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: Declude.JunkMail@declude.com 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[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: 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 Declude.JunkMail@declude.com 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] 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: Declude.JunkMail@declude.com 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[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: 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 heh, 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] 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 heh, 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
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 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 heh, 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
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: Declude.JunkMail@declude.com 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: 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 Declude.JunkMail@declude.com 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: [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: Declude.JunkMail@declude.com 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: Declude.JunkMail@declude.com 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
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 Declude.JunkMail@declude.com 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. --- [This E-mail
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.
