I think Todd pretty much hit the nail on the head.
Remember, I proposed that we would put all negative weight filters first,
then anything we considered mandatory (including particular tests and
filters we want to log), then the QUITIFWEIGHT test would start.
I do understand that it is desirable
I need some help with a request I got yesterday from our marketing dept. I
walk into work yesterday to find that marketing, in their infinite wisdom,
have decided to start doing email marketing. Of course they didn't involve
any technical people until I stumbled across the rumor of such
Seems that there is a lot of chatter on the mailing list right now
with tests etc that are not in the manual. I am curious will a new
manual be released, or does anyone have any good explanations of some
of these tests on their sites?
The general rule of thumb is that the manual is updated
Ok let me resume:
1.) it's a non-tecnical person
2.) his task is to sell more
3.) he don't know what means being flooded with marketing mails because
you filter them out all of this trash.
Solution: disable spam filtering for this guy (or bether the entire
marketing dept)
Say nothing to
So here is my dilemma: These people are VERY non-technical and my greatest
worry as the mail admin is that some bright marketing person is going to
sit down with Outlook, plug a bunch of customer names into their address
book and start sending out spam. I know we fight external spammers but how
Scott, for what it's worth, our Declude maintenance is up for renewal,
and one of the questions I got asked was when there would be an
updated printed manual that our less-experienced admins could
understand. Don't worry, the maintenance will definitely get paid, but
now one of my tasks in my
The first thing I would do is check to see if your Internet provider has a
TOS that prohibits spamming (which is very likely). If so, you may want
to
pass that information on to the marketing department. If they know that
their actions could risk the company losing Internet access even
Andy,
Harvesting from business cards dropped in a fish bowl is not a best
practice, even if they feel justified in doing so. Address collection
should be done by a method that follows MAPS standards, and E-mail
campaigns need to follow their same best standards as well. Even if you
do so, you
Why not use Kami's Nigerian Filter? He's done all of the work for
you. Just remember to thank him.
That sounds interesting, how about a pointer to Kami's site/email/etc.?
(Or am I just too far out of it and missed the obvious location
somehwere...?)
Thanks, and in advance, thanks to Kami
Hi Andy-
I get this question for my customers a couple of times a month. Of course,
we prohibit such activity. We usually send them to one of the list houses
that specialize in this kind of thing. Microsoft's B-Central lets you create
a list and mail to it, and there are many others that are
I know this suggestion was kind of tongue-in-cheek, but we did exactly this
for one of our Marketing wonderboys. After 3 days, just three days, he came
into my office waving his white handkerchief and begging for mercy. The
message was sent better than any discussion could have, technical or not.
I have been testing Kami's Nigerian filter and found that in 3 days it
flagged 56 email and only caught out of 5 nigerian scam emails.
I do not see this as a fault of Kami's effort but a fault of filtering. Some
of the line are very common in ligitimate email. I even lowered all the
weights to
Interesting, in my testing it has only produced 3 FP, and those would not
have been held except that they had other problems as well.
As has been said, you mileage may vary.
John Tolmachoff
Engineer/Consultant/Owner
eServices For You
-Original Message-
From: [EMAIL PROTECTED]
Correction:
That should be only caught 2 out of 5
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Kevin Bilbee
Sent: Friday, January 23, 2004 9:38 AM
To: [EMAIL PROTECTED]
Subject: RE: [Declude.JunkMail] Nigerian Filter Creator Helper
I have been
Matt,
this filter won't get run unless an E-mail gets past almost everything
else with a score less than 28 on my system
How are you accomplishing that? Are you uising SKIPIFWEIGHT on
the filter?
-Dave
Kevin,
I also have been using Kami's Nigerian stuff, however I modified it a
great deal and removed some of the lines that I felt were too common, I
reduced scores, and capped the score at 80% of my hold weight. The
result is that it only hit 0.06% of my total mail volume across a 3 day
Hello Kevin,
Friday, January 23, 2004, 12:37:37 PM, you wrote:
KB I have been testing Kami's Nigerian filter and found that in 3 days it
KB flagged 56 email and only caught out of 5 nigerian scam emails.
KB I do not see this as a fault of Kami's effort but a fault of filtering. Some
KB of the
Yes. I also have it very near the bottom of my list because it has a
lot of body searches, and it rarely gets hit. Even so, setting
SKIPIFWEIGHT to 28 while holding at 10 and deleting at 25 means that my
best custom filter tops out at 3% of total mail volume. Even GIBBERISH
only gets hit 1.21%
Basic Mailing List Management Guidelines for Preventing Abuse
http://www.mail-abuse.org/manage.html
Thanks Matt...that was exactly what I was looking for. Would a place like
EmailLabs (http://www.emaillabs.com) be a good place to investigate or does
anyone else have the name of a good (read
I agree that a manual is greatly needed. the value of all the new tests is
greatly diminished if there is not adequate documentation.
Searching through the archives and reading the discussions my be a good
thing to do if you are having trouble understanding the manual but to search
the archives
I agreebetter documentation...please!
- Original Message -
From: Kevin Bilbee [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 23, 2004 11:06 AM
Subject: RE: [Declude.JunkMail] Manual
I agree that a manual is greatly needed. the value of all the new tests is
greatly
Listservs that service small companies are commonly very dirty and have
RBL issues, bCentral for instance is terrible. As far as other
companies go, you need to make sure that they don't also operate under
other identities, or service dirty lists as a practice.
Experian/exactis.com,
I have not renewed my Junkmail SA due to the lack of an updated manual.
If Scott would spend the same amount of time updating the manul as he does
explaining to the list how features work, the manual would be current.
Monitoring and researching list archives is fine for free or diy software
but
I have not renewed my Junkmail SA due to the lack of an updated manual.
If Scott would spend the same amount of time updating the manul as he does
explaining to the list how features work, the manual would be current.
Monitoring and researching list archives is fine for free or diy software
but
Hmmm. I tag the subject on weight 14 to 19, delete on 20+. I've had
Sniffer weighted at 18 for a while. Reduced it to 16 a couple days ago
after adding some additional SORBS tests that are in the lastest global.cfg.
Anyway, I've had several Nigerian-type scam emails come through without
failing
Keep it up guys and you'll be forced to wait for a full release to get some of these new features that add such extreme functionality to this product. If you don't like the way Scott does this, only use the latest full release with features covered in the manual. My $.02.N. Mathews[EMAIL
Scott:
Your abilities as a writer are fine. I have seem many of your explanations
on use of features and for most I think they would suffice. They just need
to be put in the online manual at the same time you post a message to the
list.
I agree that beta features should not be in the main manual
DITTO!
The manual is completely updated right now, unless you have volunteered yourself for
the beta program. :-)
--
---
Matt Robertson, [EMAIL PROTECTED]
MSB Designs, Inc. http://mysecretbase.com
---
--
Does the junkmail fire redirect work for aliased domains. It origionally did
not.
For example I have an alias setup as [EMAIL PROTECTED] and that
points to [EMAIL PROTECTED] and I put
REDIRECT @mail.internal d:\junkmailfiles\strict.junkmail
In the $default$.junkmail file will it use the
At 03:36 PM 1/23/2004, Mike K wrote:
Scott:
Your abilities as a writer are fine. I have seem many of your explanations
on use of features and for most I think they would suffice. They just need
to be put in the online manual at the same time you post a message to the
list.
I agree that beta
I think the beta/interim features debate has been done recently,
however there are two different things that this effects, first, more
info about what these things do, and eventually converging these things
into the manual (they're not all there in final release format).
Second, and more
Does the junkmail fire redirect work for aliased domains. It origionally did
not.
For example I have an alias setup as [EMAIL PROTECTED] and that
points to [EMAIL PROTECTED] and I put
REDIRECT @mail.internal d:\junkmailfiles\strict.junkmail
In the $default$.junkmail file will it use the redirect
Scott,
A better manual would be nice. I grumble when I see you changed it
and cannot find where *BUT* if creating a new one takes away from
your literal instant tech support, advice on OT subjects, I can live
with the system.
From my perspective isn't fair for folks that want new features
Maybe beta's should be by invitation/request only, and distributed only
to that group like a normal beta program? At the same time, bug fixes
can be applied to the last release, as well as the most recent beta, or
only to the beta's if that's all that is affected? It's a bit more
work to
Title: Message
I'm all in favour
of the manual being sync'ed with the releases. That's a
no-brainer.
Beta support
handling is a bone of contention, and I'd rather that support maintenance of
those featuresnot interfere with the stellar support we already get from
Declude.
Therefore, I
Thank you Scott,
and sorry to the list for not changing the subject
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry
Sent: Friday, January 23, 2004 12:50 PM
To: [EMAIL PROTECTED]
Subject: RE: Re[2]: [Declude.JunkMail] Nigerian Filter
I
think this is the best idea. This also give the admin that wants to or needs to
use the new features/bug fixes can and they understand their functionality. This
also gives the admin the ability to decide wether using the beta is worth the
hassle of possible bugs in features they are not
Title: Message
I agree with this approach. It would separate the BETA users from the
curious RELEASE users (who probably should wait for the release).
Todd Holt
Xidix Technologies, Inc
Las Vegas, NV USA
www.xidix.com
702.319.4349
-Original Message-
From:
[EMAIL
Scott-
I'll cast my vote for this approach.
Just a simple beta-only html page on your website. Contents: What's in each
interim release, a one-line explanation, and a .config file and/or .junkmail
file example would be fine with me. Once we know what's in the release, we
can search this list for
Scott,
This is a feature request concerning the new/interim format of Log Level
Low. It would be nice to have the IP logged at this level, and the need
for this would otherwise cause me to have to go to a higher log level
currently, but I much prefer working with the much smaller files
This is a feature request concerning the new/interim format of Log Level
Low. It would be nice to have the IP logged at this level, and the need
for this would otherwise cause me to have to go to a higher log level
currently, but I much prefer working with the much smaller files (almost
I'll give that a try tonight. This might be a very nice happy medium.
Thanks,
Matt
R. Scott Perry wrote:
This is a feature request concerning the new/interim format of Log
Level Low. It would be nice to have the IP logged at this level, and
the need for this would otherwise cause me to
Scott, is there a way to turn off the separate SPF logging that is currently
being written to c:\spf.log and c:\spf.none? If not, when do you plan to
remove this logging from the Declude code?
Bill
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This
Scott, is there a way to turn off the separate SPF logging that is currently
being written to c:\spf.log and c:\spf.none?
Not right now.
If not, when do you plan to
remove this logging from the Declude code?
It should be removed before the next beta.
44 matches
Mail list logo
