Awesome Scott! Does this feature work with PREWHITELIST ON so that we can conserve
some resources for Auth'd users?
Thanks,
Bill
-Original Message-
From: R. Scott Perry
Sent: Tue, 16 Sep 2003 20:05:40 -0400
Subject: Re: [Declude.JunkMail] Next release
Scott could you give us an
Scott,
Do you need to have anything turned on in IMAIL 8.0 to make this work.
WHITELIST AUTH
Fred
- Original Message -
From: R. Scott Perry [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 16, 2003 8:05 PM
Subject: Re: [Declude.JunkMail] Next release
Scott could you
Hello All.
Thanks for help in creating a kill list. The below is a spam message
being received. I noticed in these headers that is says:
X-RBL-Warning: EASYNET-DNSBL: Blacklisted by easynet.nl DNSBL -
http://blackholes.easynet.nl/errors.html
X-RBL-Warning: SBL:
Is the ImageFX file still being updated? When I check their code next to
an entry, looks like the last time anything was added was 8/25.
N. Mathews
At 09:29 AM 9/16/2003, you wrote:
Not to feed the spammers again by asking this, but is there a repository
of blacklists out there somewhere?
Awesome Scott! Does this feature work with PREWHITELIST ON so that we
can conserve some resources for Auth'd users?
No, but it will in the next interim release. :)
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail
Do you need to have anything turned on in IMAIL 8.0 to make this work.
WHITELIST AUTH
No. Declude JunkMail checks the Q*.SMD file for an A line, which is
automatically added by IMail v8 (and I believe 7.1x as well, but I'm not sure).
-Scott
Thanks for help in creating a kill list. The below is a spam message
being received. I noticed in these headers that is says:
X-RBL-Warning: EASYNET-DNSBL: Blacklisted by easynet.nl DNSBL -
http://blackholes.easynet.nl/errors.html
X-RBL-Warning: SBL:
Sending this again.
Any ideas?
Is there any way to filter based on character set, code page, etc?
I'm getting swamped with tons of Cyrillic spam lately and it's
passing my RBL's recently.
I can't filter by code word or phrase and the MAILFROM field
is random.
Any thoughts?
Here's a
Scott,
What happens if you have PREWHITELIST ON and WHITELIST AUTH
Fred
- Original Message -
From: R. Scott Perry [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 17, 2003 8:57 AM
Subject: Re: [Declude.JunkMail] Next release
Do you need to have anything turned
I'm new to JunkMail, but your post did get flagged as spam by my Declude
installation, using the default settings. So there's something there.
One or two list postings per day gets marked as spam by Declude.
- Original Message -
From: mark_smith [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sending this again.
Any ideas?
One option would be to use the NONENGLISH test, which is designed to detect
character sets other than English that are common in spam. Of course, you
shouldn't use this test to block E-mail or even in the weighting system
unless you only receive E-mail in
Mark:
I get a fair amout of this also. Mine seems to come mostly from broadband
lines (rr, verizon, charter, comcast, attbi) so I ip block at the /24 level
(class c). Of course it's after the fact. But should block some future spam.
I also have a subject filter to add weight for non western char
What happens if you have PREWHITELIST ON and WHITELIST AUTH
There will be no problem. However, the AUTH whitelisting will be done
after the tests are run. When the next version is ready, that behavior
will change so that the AUTH whitelisting will prevent the tests from being
run.
Will NONENGLISH block Spanish characters?
How does the test determine what is English and what isn't?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of R.
Scott Perry
Sent: Wednesday, September 17, 2003 10:22 AM
To: [EMAIL PROTECTED]
Subject:
Will NONENGLISH block Spanish characters?
It depends on a number of factors:
How does the test determine what is English and what isn't?
It looks for non-English subject encoding that is common to spam, and the
presence of high-bit characters in the subject.
Would Spanish subject lines be detected at a higher rate?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of R.
Scott Perry
Sent: Wednesday, September 17, 2003 11:03 AM
To: [EMAIL PROTECTED]
Subject: RE: [Declude.JunkMail] Character set/unicode
Scott,
Will adding 64.94.110.0/24 to the ipfile block these?
BLACKLISTIP ipfile D:\IMail\Declude\ipfile.txt x 20
Sheldon
Sheldon Koehler, Owner/Partnerhttp://www.tenforward.com
Ten Forward Communications 360-457-9023
Nationwide access, neighborhood support!
Whenever you
Will adding 64.94.110.0/24 to the ipfile block these?
BLACKLISTIP ipfile D:\IMail\Declude\ipfile.txt x 20
No. The problem is that the E-mail isn't *coming* from 64.94.110.11, the
problem is that a response to the E-mail would be sent to 64.94.110.11.
There was a posting about other tld's returning a default IP for free
domain names:
Quoting Len:
Reserach lifted from another mailing list:
dnsqr a *.nu
answer: \052.nu 86375 A 64.55.105.9
answer: \052.nu 86375 A 212.181.91.6
dnsqr a *.com
answer: \052.com 167 A 64.94.110.11
dnsqr a *.net
Hmmm. So WHITELIST AUTH does not work with
IMail 7.x? Why is it enabled by default in the latest global.cfg and
thereare no comments indicating that it works only with IMail 8? I
just upgraded from 1.69 to 1.75 yesterday, and incorporated the changes in the
defaultglobal.cfg and
Would this mean we can/should add additional test like veriscam to our
configuration?
For example:
VERISCAM rhsbl . 64.94.110.1110 0
FREEDOM_ac rhsbl . 194.205.62.122 10 0
FREEDOM_cc rhsbl . 206.253.214.102 10 0
FREEDOM_cx rhsbl . 219.88.106.80 10 0
FREEDOM_tm rhsbl . 194.205.62.42 10
Hmmm. So WHITELIST AUTH does not work with IMail 7.x?
You would have to check with Ipswitch to be sure. My understanding is that
they started including the information in the Q*.SMD file with v7.10, but
haven't confirmed it. It is definitely there for v8.x.
Why is it enabled by default in
Here's this morning's biggest loser: we HOLD on 20, and this spammer
achieved a whopping:
DSBL:6 SPAMCOP:10 BADHEADERS:6 HELOBOGUS:6 REVDNS:4 ROUTING:8 IPNOTINMX:2
NOLEGITCONTENT:2 COUNTRY:10 COMMENTS:153 SNIFFER:7 FIVETENSRC:5
EASYNET-DNSBL:7 EASYNET-DYNA:6 EASYNET-PROXIES:5 BH-CNKR:10
I'm using IMail 7.13 at the moment and this is what I get for a message
that I AUTHed:
QC:\IMail\spool\D94de0163018e1cda.SMD
Higaia.com
We:\mail.igaia.com
E0,
S[EMAIL PROTECTED]
NRCPT TO:hidden
Rhidden
Doesn't look to be in there. Maybe I should upgrade my version and try
again? I see
That is funny - it goes to show that the more they try to hide,
the more obvious they become. Most of the spam that makes it
through my filters are perfectly legitimate looking e-mail, which
I have to manually add to the kill list.
Congrats - I think this is the highest score I've ever seen.
Title: Message
Received: from 66.38.133.97 [200.252.69.131] by mail.bentall.com
(SMTPD32-8.02) id A3E5113000F4; Wed, 17 Sep 2003 10:03:33 -0700Received:
from [73.250.175.174]
by 66.38.133.97 with
SMTP for snip; Wed, 17 Sep
2003 06:00:29 +Message-ID:
[EMAIL PROTECTED]From: "Sheldon
You would have to check with Ipswitch to be sure. My
understanding is that
they started including the information in the Q*.SMD file
with v7.10, but
haven't confirmed it. It is definitely there for v8.x.
This is the content of an v7.15 queue file sent from an authenticated
user:
DSBL:6 SPAMCOP:10 BADHEADERS:6 HELOBOGUS:6 REVDNS:4 ROUTING:8 IPNOTINMX:2
NOLEGITCONTENT:2 COUNTRY:10 COMMENTS:153 SNIFFER:7 FIVETENSRC:5
EASYNET-DNSBL:7 EASYNET-DYNA:6 EASYNET-PROXIES:5 BH-CNKR:10 SORBS-HTTP:7
PSBL:5 CBL:5 GIBBERISHBODY:3 VERISCAM:7 BENTALLIPBL:7 BENTALLSPAMHINT:22
This looks a lot like the millions that were sent through one of my clients'
WAP. If this is the case, it's nonroutable because they are sitting behind
a corporate firewall.
-Original Message-
From: Colbeck, Andrew [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2003 11:25 AM
DSBL:6 SPAMCOP:10 BADHEADERS:6 HELOBOGUS:6 REVDNS:4 ROUTING:8 IPNOTINMX:2
NOLEGITCONTENT:2 COUNTRY:10 COMMENTS:153 SNIFFER:7 FIVETENSRC:5
EASYNET-DNSBL:7 EASYNET-DYNA:6 EASYNET-PROXIES:5 BH-CNKR:10 SORBS-HTTP:7
PSBL:5 CBL:5 GIBBERISHBODY:3 VERISCAM:7 BENTALLIPBL:7 BENTALLSPAMHINT:22
On Sep 17, 2003, at 12:17 PM, Sheldon Koehler wrote:
Scott,
Will adding 64.94.110.0/24 to the ipfile block these?
BLACKLISTIP ipfile D:\IMail\Declude\ipfile.txt x 20
Bill posted this in response to my posting about being able to use
this...
Below is the right hand side test you can use
False positives will come from users that misspell their domain name in
their mail client. I have had that happen. There are also lots of
forms being used on Web sites that take the user's input and construct a
message using their address as the From in order to facilitate replies,
and I can
Paul, those last 3 tests are our in-house tests that may or may not be
suitable for anyone else.
The first of the three is an IPFILE test that contains our banned IPs. We
put them here instead of IMail because we like the logging of the
mail-handling decisions to all be in Declude's log.
Hi Paul:
The URL files are in the same place that I referenced earlier..
We have a large number of filters.
1- URL in the body
2- Phone in the body
3- IP's in the body
4- Free emails
5- Free emails with subject= e.g. @hotmail.com?subject=
6- Free emails with remove e.g. @hotmail with remove
On Sep 17, 2003, at 2:59 PM, Matthew Bramble wrote:
False positives will come from users that misspell their domain name
in their mail client. I have had that happen. There are also lots of
forms being used on Web sites that take the user's input and construct
a message using their address
Since the address is bad, the bounce won't ever get to the sender. It's
pretty unfortunate.
I just had a client call the other week when I upgraded to a newer
version of Declude which I think started catching the misspelling in
MAILFROM where as it didn't before (if I recall the problem
Ok, I've been testing this one for about a week with very positive
results. It's still a work in progress as far as exclusions go
(candidates welcome), but I have been using it with a good deal of
success as is for the past week. The filter is called DYNAMIC and it
can be downloaded at the
Is the ImageFX file still being updated? When I check their
code next to an entry, looks like the last time anything was added was
8/25.
It's still being updated, just not as often. Because our spam has been way
down and under control we have not needed to do daily updates. So we now
New versions of GIBBERISH and ANTIGIBBERISH have been posted after
someone pointed out a false positive coming from the Outlook mail
client for read receipts that have a marker filled with gibberish-ish
text.
The new filter files can be downloaded at the following locations:
GIBBERISH and
I hate to open up old wounds, butgoing
back to the AOL filtering issue
I would agree that the few (very few)
number of legitimate mail servers connecting with cable modem or consumer DSL
are acceptable false positives when filtered out as SPAM sources.
But one must consider that
On Sep 17, 2003, at 7:31 PM, Todd Holt wrote:
1. x-tad-biggerCan this filter distinguish between ADSL and SDSL? If not, is this acceptable?/x-tad-bigger
2. x-tad-biggerIs the filter doing this?/x-tad-bigger
3. x-tad-biggerAre there any unique instructions for doing this/x-tad-bigger
One thing that I'm looking into right now is the Declude server which is
at cpe-24-107-232-14.ma.charter.com. I'm thinking that cpe is for
customer premise equipment, and if that is exclusive to charter business
customers, it could be excluded. All we need are some Charter residential
Todd,
1) Possibly. Still yes IMO.
2) Not presently.
3) Definitely, just help me make a list.
It is a little stickly, but my results showed it to not be
problematic. I am scoring this as only 30% of my fail weight, and DUL
lists can have similar false positive rates (only 2% in my test of
I'm seeing some false positives for mail from .comcast.net hosts that are
falling into various ip4r lists. It's very sporadic. It seems like quite a
few are being tested as mail relay hosts, but aren't.
Other providers provide a sensible naming convention to make it
straightforward to identify
It was purposeful because I wanted to protect from false positives. If
there are enough of those, we could of course add tests or maybe even
mark the domain in some cases. It's helpful to also know their policy
on outbound SMTP and mail server hosting if available.
I think that the following
Thanks for the pointer on Charter. If I wasn't whitelisting you for
this listserv, you would still only score a -1 for most any message
because of negative weighting on your mx and legit content after failing
DYNAMIC.
Matt
R. Scott Perry wrote:
One thing that I'm looking into right now is
On Sep 17, 2003, at 8:21 PM, Matthew Bramble wrote:
I think that the following is a candidate for exclusion:
rrcs-nys-###-###-###-###.biz.rr.com
Matthew,
In the case of Road Runner I would put ENSWITH rr.com in the DYNAMIC and in the AntiDYNAMIC I would put ENDSWITH biz.rr.com because
I'm hoping that an anti-filter won't be necessary for this to work, but
it might be beneficial if there are some harder to detect strings like
the one you pointed out (if folks feel it is necessary).
The entry for counterbalancing Road Runner Business customers would be
as follows:
MAILFROM
It would probably be safe to negative score on the following:
REVDNS-10ENDSWITH1.comcast.net
REVDNS-10ENDSWITH2.comcast.net
REVDNS-10ENDSWITH3.comcast.net
REVDNS-10ENDSWITH4.comcast.net
REVDNS-10
Joshua makes a great case for how to
adjust the weighting system.
However, I think the initial test assumptions are flawed.
Case in point:
As Joshua corrected noted, our RDNS is las-DSL224-cust088.mpowercom.net. However, we are on a T-1 line from MPower. Now I
agree that MPower is to
Actually, you don't get scored with this filter. You would need to
have dashes or dots on both sides of a number. Even if you did, you
would have a real tough time scoring anything over 1 coming to my
machine. Your mileage may vary of course.
Also, I can't see why it would be even workable to
Oops, my bad, the 224 is a reference to your class B. That is dumb,
but at least they didn't make it look like a dial-up IP. You still
wouldn't score though :)
Matt
Matthew Bramble wrote:
Actually, you don't get scored with this filter. You would need to
have dashes or dots on both
Matt,
Would you please let me know when you have an
updated Dynamic.txt file.
Thanks.
Fred
- Original Message -
From:
Matthew Bramble
To: [EMAIL PROTECTED]
Sent: Wednesday, September 17, 2003 9:33
PM
Subject: Re: [Declude.JunkMail] DYNAMIC -
09/17/2003 - A
After looking up the code, and then looking at the RFC
http://www.faqs.org/rfcs/rfc2822.html (which I hope is the right place)
I can't figure out what is bogus about the following header. What is
wrong with it? Was it inserted by IMAIL after the fact? If it was how
could I tell? I'd like to work
I believe that Message-ID: header was added by your IMail because the
email didn't have it. It failed the test because it should have had it
prior to IMail getting the email.
-Josh
On Sep 17, 2003, at 11:55 PM, Marc Catuogno wrote:
This E-mail has a bogus Message-ID: header.
Received: from
Nevermind... I see that what I assume was its message ID:
X-Streamsendid: 3+1+135073+10+lists.streamsend.com
Is not unique and doesn't follow the RFC recommendation.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc Catuogno
Sent: Wednesday,
Josh is right. Declude doesn't like seeing IP addresses in Message ID
headers. I see FP's from BADHEADERS for the same. There's another
issue though...SPAMHEADERS get's triggered for exactly the same
reason. I found something buried in the release notes though that
allows you to make this only
57 matches
Mail list logo
