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
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 Declude.JunkMail@declude.com
Sent: Wednesday,
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
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
I'm sorry if you are getting posts from multiple
addresses from me. I am just having list
issues.
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
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
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)
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
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
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
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,
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
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
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
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
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]
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
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
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:
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
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
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
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
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
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: Declude.JunkMail@declude.com
Sent: Friday, February 11, 2005 5:28 AM
Thumbs up for putting the current version number on
the main Declude web page.
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
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
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
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: Declude.JunkMail@declude.com
Sent: Friday, February 11, 2005 7:43 PM
Subject: RE: [Declude.JunkMail]
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
32 matches
Mail list logo
