[Declude.JunkMail] Hold Mails?
Hello, is it possible to redirect the directory for held spam to somewhere else then spool\spam? Like Spamdir x:\imail\spool\spam? (an the Imail Spooldir ist y:\Imail\spool?) Alex --- [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] Whitelist as a filter
Scott: With the new features you have added, namely SKIP, END, MaxWeight - it seems like adding a whitelist filter type should be real easy. :) (as a programmer I love it when people say that..) A Whitelist filter type could actually serve as an extension to END in some ways.. I was thinking: Whitelist BODYCONTAINSDeclude whitelist SUBJECT STARTSWITH Hello just examples.. If this condition is satisfied the filter could exit and no other filter will execute- Declude will exit. This could set a condition that acts as MAXWEIGHT for all filters to follow. If this is added we can take all of our whitelist entries out of Global.cfg file and will ease updating and maintaining different files - as well as sharing the files with others. Simply for us to not execute any filters we can put all of our WHITELIST filter files at the top of global file. Just a thought.. Kami
Re: [Declude.JunkMail] Hold Mails?
is it possible to redirect the directory for held spam to somewhere else then spool\spam? No, but this is something that we are planning to change. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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.
[Declude.JunkMail] Setting Bias weight
Another crazy idea... but worth considering :) Right now we have an all or nothing environment with Declude. If a user does not want whitelist they can add [EMAIL PROTECTED] and no spam filtering will happen. What if we can set a bias weight so they can fine tune their desires. for example: [EMAIL PROTECTED] or [EMAIL PROTECTED] (so for example the extreme spam is only taken out) that means take5 or 30points off the email weight before making the decision. This way if someone does not like the tight control they can loosen it by adding their total weight bias just for themselves. Just a thought.. Kami
Re: [Declude.JunkMail] Whitelist as a filter
I was thinking: WhitelistBODY CONTAINSDeclude whitelistSUBJECT STARTSWITH Hello just examples.. If this condition is satisfied the filter could exit and no other filter will execute- Declude will exit. This is an excellent idea -- not just for saving processing time on filters, but also to enhance the flexibility of whitelisting. This will be done for the next release. :) It will actually be *slightly* different, with Whitelist replacing the weight in the filters, so it would look like: BODYWHITELIST CONTAINSDeclude SUBJECT WHITELIST STARTSWITH Hello If there is a match, the filter will end, and the E-mail will be whitelisted (with no further filters being run). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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.
[Declude.JunkMail] WHITELIST AUTH
Question, when using this in the Global.cfg and Imail 8.x, do the tests still run and no action, or does it cause tests not to run? 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.
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
Hi Darin, For the sake or arguement, I'm assuming one keeps one's server and up-to-date, patched, and takes prudent efforts to secure these devices. Most people probably don't secure workstations well enough. The server side of the equation is too complex. I don't think you (as an individual) can prevent spam from being sent. You can only control the email that you send and the actions you take in response to spam. You as an administator can prevent Spam from being sent outbound, but beyond securing the server and taking prudent measures your users are going to have to put up with false positives. Businesses run on email, and I'm not sure most companies would be willing to take such risks. Burzin At 09:12 PM 12/12/2003, you wrote: Everyone keep the ideas flowing... maybe we can come up with ideas as to how to keep spam from being sent to begin with. -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [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] WHITELIST AUTH
Question, when using this in the Global.cfg and Imail 8.x, do the tests still run and no action, or does it cause tests not to run? With PREWHITELIST ON, the tests will not be run (for WHITELIST AUTH). Otherwise, they will be run. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] Setting Bias weight
What if we can set a bias weight so they can fine tune their desires. for example: mailto:[EMAIL PROTECTED][EMAIL PROTECTED] or mailto:[EMAIL PROTECTED][EMAIL PROTECTED] (so for example the extreme spam is only taken out) that means take 5 or 30 points off the email weight before making the decision. This does sound like a good idea -- it has been added to the suggestion database. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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.
[Declude.JunkMail] Getting exec time on less than DEBUG mode?
I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. Just a thought. Happy Monday, Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com - - - - - - - - - - - - - - Site Design and ColdFusion Developer Tools --- [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] WHITELIST AUTH
So in Global if I have PREWHITELIST ON WHITELIST IP XXX.XXX.XXX.XXX/XXX where XXX.XXX.XXX.XXX/XXX is an ip in our local range it will bypass all spam tests? (using 8.04 1.77) - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 10:25 AM Subject: Re: [Declude.JunkMail] WHITELIST AUTH Question, when using this in the Global.cfg and Imail 8.x, do the tests still run and no action, or does it cause tests not to run? With PREWHITELIST ON, the tests will not be run (for WHITELIST AUTH). Otherwise, they will be run. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] WHITELIST AUTH
Thanks. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Monday, December 15, 2003 8:25 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] WHITELIST AUTH Question, when using this in the Global.cfg and Imail 8.x, do the tests still run and no action, or does it cause tests not to run? With PREWHITELIST ON, the tests will not be run (for WHITELIST AUTH). Otherwise, they will be run. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] WHITELIST AUTH
Question, when using this in the Global.cfg and Imail 8.x, do the tests still run and no action, or does it cause tests not to run? With PREWHITELIST ON, the tests will not be run (for WHITELIST AUTH). Otherwise, they will be run Ok, question on behalf of those using AutoWhite for Declude: Would it be possible to add a configuration so that certain tests will still run with PREWHITELIST ON in the Global.cfg? Something like PREWHITELISTRUNTEST listouttestbyexactname The reason I ask is because if using PREWHITELIST ON and say WHITELIST AUTH, the processing of outbound messages so as to add to the list of e-mails in the AutoWhite for Declude files will not be done, defeating the test. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Monday, December 15, 2003 8:25 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] WHITELIST AUTH clude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] WHITELIST AUTH
Ok, question on behalf of those using AutoWhite for Declude: Would it be possible to add a configuration so that certain tests will still run with PREWHITELIST ON in the Global.cfg? That is very unlikely. The whole point of PREWHITELIST ON is to save CPU time, by not running any tests when E-mails are whitelisted. Running tests in this case ends up using some of that CPU time that should be saved, and adds extra complexity (to the program itself, the manual, support, etc.). The reason I ask is because if using PREWHITELIST ON and say WHITELIST AUTH, the processing of outbound messages so as to add to the list of e-mails in the AutoWhite for Declude files will not be done, defeating the test. In this case, I would recommend not using PREWHITELIST ON. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] Getting exec time on less than DEBUG mode?
I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. If others think this may be useful, it could get changed. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] Getting exec time on less than DEBUG mode?
I think it would be very useful. Thanks, Bill - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 9:38 AM Subject: Re: [Declude.JunkMail] Getting exec time on less than DEBUG mode? I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. If others think this may be useful, it could get changed. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] Getting exec time on less than DEBUG mode?
I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. If others think this may be useful, it could get changed. That would be useful Scott, however, maybe make it a logging ON/OFF switch? So if you need that to be logged, just have exectime ON or something in Global.cfg. Paul --- [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] Getting exec time on less than DEBUG mode?
HAND RAISED IN AGREEMENT John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Bill Landry Sent: Monday, December 15, 2003 9:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Getting exec time on less than DEBUG mode? I think it would be very useful. Thanks, Bill - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 9:38 AM Subject: Re: [Declude.JunkMail] Getting exec time on less than DEBUG mode? I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. If others think this may be useful, it could get changed. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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. --- [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] Getting exec time on less than DEBUG mode?
I like Paul's idea, choice is always better. (my logs, even on low run in the 140 to 160mb range) Steve paul wrote: I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. If others think this may be useful, it could get changed. That would be useful Scott, however, maybe make it a logging ON/OFF switch? So if you need that to be logged, just have exectime ON or something in Global.cfg. Paul --- [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. --- [This E-mail was scanned for viruses as a service to Keeling Inc. Customers]
[Declude.JunkMail] undeliverable email
Hi, When my customers send email that is undeliverable, a lot of the returned undeliverable messages are being caught as spam. Any suggestions for changes that will allow it will go through? failing SPAMHEADERS and BADHEADERS, IPNOTINMX, WEIGHT10 (action HOLD) Thanks, Andy --- [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] Legit or Scam
This looks legit but my hair is raised: (The FORM action has me concerned.) The key here is this line: FORM action=http://www.response-o-matic.com/cgi-bin/rom.pl ... That ain't eBay. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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.
[Declude.JunkMail] Legit or Scam
This looks legit but my hair is raised: (The FORM action has
me concerned.)
DIVWe regret to inform you that your eBay account
couldBRbe suspended if you don't resolve your problems. To
BRresolve this problems please click here and login BRto your
account in order to resolve your accountBRproblems. If your problems
could not be resolved BRyour account will be suspended for a period of
BR3-4 days, after that it will be again
operational.BRBRPer the User Agreement, Section 9, we may
immediatelyBRissue a warning, temporarily suspend, indefinitely
BRsuspend or terminate your membership and refuse BRto provide
our services to you if we believe that BRyour actions may cause
financial loss or legal BRliability for you, our users or us. We may
also BRtake these actions if we are unable to verify
orBRauthenticate any information you provide to
us.BRBRDue to the suspension of this account, please
beBRadvised you are prohibited from using eBay in BRany way.
This includes the registering of a new BRaccount.BRBRPlease
note that this suspension does not relieve youBRof your agreed-upon
obligation to pay any fees BRyou may owe to ebay.BRBRRegards,BRBRSafeharbor
DepartmentBReBay, Inc.BRBRBRBR16 Nov
2003BReBayBRBR
TABLE border=0 cellPadding=4 cellSpacing=0
width=100%
TBODY
TR class=heada
TD/TD/TR/TBODY/TABLE
TABLE border=0 cellPadding=0 cellSpacing=0 width=600
TBODY
TR
TDA href=""
target=_blankIMG alt=eBay logo border=0 height=40 hspace=0
src=""
width=387/A/TD/TR/TBODY/TABLE
TABLE border=0 cellPadding=0 cellSpacing=0 width=600
TBODY
TR
TD colSpan=2IMG alt=spacer height=10 src=""
width=1/TD/TR
TR
TD bgColor=#ffcc00 colSpan=2IMG alt=spacer
height=2 src=""
width=1/TD/TR
TR bgColor=#ffe580
TD width=25IMG align=middle alt=
height=3 src=""
width=16/TD
TD vAlign=center width=575
TABLE border=0 cellPadding=1 cellSpacing=0
width=100%
TBODY
TR
TD noWrap vAlign=centerFONT face=Verdana,
Helvetica, Arial, sans-serif size=3BSign
In/B/FONT /TD
TD align=right noWrap vAlign=centerA href=""
target=_blank openHelpWindow(this.href);IMG
border=0 height=14
src=""
width=14/AIMG alt=spacer height=1 src=""
width=4FONT color=#003399 face=Arial, Helvetica, sans-serif
size=2A href=""
target=_blank openHelpWindow(this.href);Need
Help?/A/FONTFONT color=#003399IMG alt=spacer
height=1 src=""
width=2/FONT/TD/TR/TBODY/TABLE/TD/TR
TR
TD bgColor=#ffcc00 colSpan=2FONT
color=#003399IMG alt=spacer height=2 src=""
width=1/FONT/TD/TR/TBODY/TABLE
TABLE border=0 cellPadding=0 cellSpacing=0 width=600
TBODY
TR bgColor=#cc
TD height=23 width=15FONT
color=#003399IMG alt=spacer height=1 src=""
width=15/FONT/TD
TD height=23 noWrap width=180FONT
face=Arial, Helvetica, sans-serif size=2BNew to
eBay?/B/FONT/TD
TD align=middle colSpan=3 height=23 vAlign=bottomIMG
border=0 height=23 hspace=0 src=""
width=60/TD
TD height=23 noWrap width=310FONT
face=Arial, Helvetica, sans-serif size=2BAlready an
eBay user?/B/FONT/TD/TR
TR
TD width=15IMG alt=spacer height=1 src=""
width=15/TD
TD vAlign=top width=180
FORM
action="" method=post name=passwordform
target=_blank confirm('Alert! You are about to send
information to someone other than Yahoo! If you do not want anyone outside of
Yahoo! to have this information, press quot;Cancelquot; now.
Remember: Yahoo! will NEVER ask you for your password in an unsolicited phone
call or an unsolicited email.') AUTOCOMPLETE=OFFINPUT
name=your_email_address type=hidden INPUT name=your_name type=hidden
[EMAIL PROTECTED] INPUT name=email_subject_line type=hidden
value=eBay INPUT name=required_fields type=hidden INPUT name=thank_you_title
type=hidden value=cursivelocation.href =
'';/script
INPUT name=return_link_url type=hidden value=http://www.ebay.com
INPUT name=return_link_name type=hidden value=eBay INPUT name=MfcISAPICommand
type=hidden value=RegisterEnterInfoINPUT name=co_partnerId type=hidden
value=2INPUT name=siteid type=hidden value=0INPUT name=ru
type=hiddenINPUT name=bin type=hidden value=-1
TABLE border=0 cellPadding=0 cellSpacing=0
width=100%
TBODY
TR
TDIMG alt=spacer height=10 src=""
width=1/TD/TR
TR
TD vAlign=topFONT face=Arial, Helvetica,
sans-serifFONT size=2If you want to sign in, you'll need to
register first. /FONT
PFONT size=2Registration is fast and
Bfree/B./FONT/PINPUT type=submit
value=Register /FONTFONT face=Times New
Roman size=2
/FONT/TD/TR/TBODY/TABLE/FORM/TD
TDFONT face=Times New Roman
size=2IMG border=0 height=1 src=""
width=30/FONT/TD
TD align=middle bgColor=#cc vAlign=top width=1FONT
face=Times New Roman size=2IMG border=0 height=1 src=""
width=1/FONT/TD
TDFONT face=Times New Roman
size=2IMG border=0 height=1 src=""
width=29/FONT/TD
TD
FORM
action="" method=post name=passwordform
target=_blank confirm('Alert! You are about to send
information to someone other than Yahoo! If you do not want anyone outside of Yahoo!
to have this information, press quot;Cancelquot; now. Remember:
Yahoo! will NEVER ask you for your password in an#13;#10; unsolicited
phone
RE: [Declude.JunkMail] Legit or Scam
That's what I thought, however I am not well versed in HTML code and did not want to make an assumption again like before. ;) John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Monday, December 15, 2003 10:34 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Legit or Scam This looks legit but my hair is raised: (The FORM action has me concerned.) The key here is this line: FORM action=http://www.response-o-matic.com/cgi-bin/rom.pl ... That ain't eBay. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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.
[Declude.JunkMail] whitelist
What is auth in the commented out whitelist? I'm trying to bypass spam testing for internal emails on the local network, any examples? Right now I have in global PREWHITELISTONWHITELISTHABEASAUTOWHITELIST ON#WHITELISTAUTHWHITELIST IP 192.168.0.0/22WHITELIST IP 10.1.0.0/22WHITELIST IP 10.1.4.0/22WHITELIST IP 10.1.12.0/22WHITELIST IP 10.1.16.0/22WHITELIST IP 10.1.20.0/22(and soforth for all theaddresses within our network) Right track or barking up the wrong tree?
Re: [Declude.JunkMail] whitelist
What is auth in the commented out whitelist? WHITELIST AUTH will automatically whitelist E-mail where IMail lets Declude JunkMail know that the user authenticated (which happens with IMail v8). It is commented out because it is only available in the latest beta, and a warning will appear in the log file for previous versions of Declude JunkMail. I'm trying to bypass spam testing for internal emails on the local network, any examples? If your users authenticate, and you are using IMail v8 and the latest beta of Declude JunkMail, WHITELIST AUTH would be a good idea. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] Legit or Scam
http://www.response-o-matic.com [Free Form Processor] .. I don't think so. John I don't think eBay will use a 3rd party form processor. Regards, Kami From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists)Sent: Monday, December 15, 2003 1:13 PMTo: [EMAIL PROTECTED]Subject: [Declude.JunkMail] Legit or Scam This looks legit but my hair is raised: (The FORM action has me concerned.) DIVWe regret to inform you that your eBay account couldBRbe suspended if you don't resolve your problems. To BRresolve this problems please click here and login BRto your account in order to resolve your accountBRproblems. If your problems could not be resolved BRyour account will be suspended for a period of BR3-4 days, after that it will be again operational.BRBRPer the User Agreement, Section 9, we may immediatelyBRissue a warning, temporarily suspend, indefinitely BRsuspend or terminate your membership and refuse BRto provide our services to you if we believe that BRyour actions may cause financial loss or legal BRliability for you, our users or us. We may also BRtake these actions if we are unable to verify orBRauthenticate any information you provide to us.BRBRDue to the suspension of this account, please beBRadvised you are prohibited from using eBay in BRany way. This includes the registering of a new BRaccount.BRBRPlease note that this suspension does not relieve youBRof your agreed-upon obligation to pay any fees BRyou may owe to ebay.BRBRRegards,BRBRSafeharbor DepartmentBReBay, Inc.BRBRBRBR16 Nov 2003BReBayBRBR TABLE border=0 cellPadding=4 cellSpacing=0 width="100%" TBODY TR class=heada TD/TD/TR/TBODY/TABLE TABLE border=0 cellPadding=0 cellSpacing=0 width=600 TBODY TR TDA href="" target=_blankIMG alt="eBay logo" border=0 height=40 hspace=0 src="" width=387/A/TD/TR/TBODY/TABLE TABLE border=0 cellPadding=0 cellSpacing=0 width=600 TBODY TR TD colSpan=2IMG alt=spacer height=10 src="" width=1/TD/TR TR TD bgColor=#ffcc00 colSpan=2IMG alt=spacer height=2 src="" width=1/TD/TR TR bgColor=#ffe580 TD width=25IMG align=middle alt="" height=3 src="" width=16/TD TD vAlign=center width=575 TABLE border=0 cellPadding=1 cellSpacing=0 width="100%" TBODY TR TD noWrap vAlign=centerFONT face="Verdana, Helvetica, Arial, sans-serif" size=3BSign In/B/FONT /TD TD align=right noWrap vAlign=centerA href="" target=_blank IMG border=0 height=14 src="" width=14/AIMG alt=spacer height=1 src="" width=4FONT color=#003399 face="Arial, Helvetica, sans-serif" size=2A href="" target=_blank Need Help?/A/FONTFONT color=#003399IMG alt=spacer height=1 src="" width=2/FONT/TD/TR/TBODY/TABLE/TD/TR TR TD bgColor=#ffcc00 colSpan=2FONT color=#003399IMG alt=spacer height=2 src="" width=1/FONT/TD/TR/TBODY/TABLE TABLE border=0 cellPadding=0 cellSpacing=0 width=600 TBODY TR bgColor=#cc TD height=23 width=15FONT color=#003399IMG alt=spacer height=1 src="" width=15/FONT/TD TD height=23 noWrap width=180FONT face="Arial, Helvetica, sans-serif" size=2BNew to eBay?/B/FONT/TD TD align=middle colSpan=3 height=23 vAlign=bottomIMG border=0 height=23 hspace=0 src="" width=60/TD TD height=23 noWrap width=310FONT face="Arial, Helvetica, sans-serif" size=2BAlready an eBay user?/B/FONT/TD/TR TR TD width=15IMG alt=spacer height=1 src="" width=15/TD TD vAlign=top width=180 FORM action="" method=post name=passwordform target=_blank AUTOCOMPLETE="OFF"INPUT name=your_email_address type=hidden INPUT name=your_name type=hidden [EMAIL PROTECTED] INPUT name=email_subject_line type=hidden value=eBay INPUT name=required_fields type=hidden INPUT name=thank_you_title type=hidden value="cursivelocation.href = '';/script" INPUT name=return_link_url type=hidden value=http://www.ebay.com INPUT name=return_link_name type=hidden value=eBay INPUT name=MfcISAPICommand type=hidden value=RegisterEnterInfoINPUT name=co_partnerId type=hidden value=2INPUT name=siteid type=hidden value=0INPUT name=ru type=hiddenINPUT name=bin type=hidden value=-1 TABLE border=0 cellPadding=0 cellSpacing=0 width="100%" TBODY TR TDIMG alt=spacer height=10 src="" width=1/TD/TR TR TD vAlign=topFONT face="Arial, Helvetica, sans-serif"FONT size=2If you want to sign in, you'll need to register first. /FONT PFONT size=2Registration is fast and Bfree/B./FONT/PINPUT type=submit value="Register "/FONTFONT face="Times New Roman" size=2 /FONT/TD/TR/TBODY/TABLE/FORM/TD TDFONT face="Times New Roman" size=2IMG border=0 height=1 src="" width=30/FONT/TD TD align=middle bgColor=#cc vAlign=top width=1FONT face="Times New Roman" size=2IMG border=0 height=1 src="" width=1/FONT/TD TDFONT face="Times New Roman" size=2IMG border=0 height=1 src="" width=29/FONT/TD TD FORM action="" method=post name=passwordform target=_blank AUTOCOMPLETE="OFF"INPUT name=your_email_address type=hidden [EMAIL PROTECTED] INPUT name=your_name type=hidden [EMAIL PROTECTED] INPUT name=email_subject_line
Re: [Declude.JunkMail] whitelist
I have the beta in place already, users all have to authenticate (no relay what-so-ever) Any additional settings or reg hacks? - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 1:07 PM Subject: Re: [Declude.JunkMail] whitelist What is auth in the commented out whitelist? WHITELIST AUTH will automatically whitelist E-mail where IMail lets Declude JunkMail know that the user authenticated (which happens with IMail v8). It is commented out because it is only available in the latest beta, and a warning will appear in the log file for previous versions of Declude JunkMail. I'm trying to bypass spam testing for internal emails on the local network, any examples? If your users authenticate, and you are using IMail v8 and the latest beta of Declude JunkMail, WHITELIST AUTH would be a good idea. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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.
[Declude.JunkMail] whitelist / CC
I have Imail/Declude Junkmail/Virus running as a front end for another server which is using Lyris for multiple mailing lists. I had a problem in the past that certain ISP's (ie bellsouth.net) would fail multiple SPAM tests, so users posting to those lists would have their mail rejected. I decided to try and get around it by whitelisting the names of the mailing lists, ie [EMAIL PROTECTED], in the thoughts that Spam would be rejected by Lyris since the spammer was not a subscriber to the list. Works well. However, I'm noticing some spam is getting through by having the mailing list name, with a bunch of other accounts, ie mine, postmaster, etc all as part of the CC line. Since one of the accounts is whitelisted, it appears that Declude is whitelisting the message and letting it also get through to all of the other accounts on that cc line. Any suggestions on how I can deal with this? I thought that I might have to make a user configuration file per mailing list which I could just WHITELIST as the entry, but if I do this, will it still whitelist the email for the others on the cc line? David --- [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] refining the filtering process
We're fairly new at using JunkMail and we want to refine the process beyond the basic tests (typically weight10 or weight20). What strategy or steps would you recommend next? Two obvious ideas are Filtering and the ip4r tests. For filtering, I'm concerned about the system overhead and the effectiveness. I've heard that filtering on message headers is not effective and that filtering on message bodies is hard on the system. For ip4r, I've heard so many horror stories about over-zealous spam databases that I'm not sure which spam databases are worth working with. It would be really cool if someone at Declude wrote an addendum to the manual that talks about how to work with Declude JunkMail, rather than just how to use it. Any guidelines would be much appreciated. Thanks and happy holidays. Ben BC Web --- [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] ROUTETO syntax
I just installed the Pro version after using the trial and am trying to configure the ROUTETO action. My Actions in the $default$.junkmail file are as follows: WEIGHT10 WARN WEIGHT20 HOLD WEIGHT30 HOLD WEIGHT40 ROUTETO [EMAIL PROTECTED] Reveal Codes would display it like this: WEIGHT40tabROUTETOtab[EMAIL PROTECTED] However, the messages with weights greater than 40 are still put into the \spool\spam\hold directory rather than going to the spambox account. I use Spam Review to monitor messages in the \hold directory. While messages are indicated as being destined for the spambox account if they fail the WEIGHT40 test, they never get routed there. What am I doing wrong? Thanks.
Re: [Declude.JunkMail] ROUTETO syntax
I just installed the Pro version after using the trial and am trying to configure the ROUTETO action. My Actions in the $default$.junkmail file are as follows: WEIGHT10 WARN WEIGHT20 HOLD WEIGHT30 HOLD WEIGHT40 ROUTETO [EMAIL PROTECTED] However, the messages with weights greater than 40 are still put into the \spool\spam\hold directory rather than going to the spambox account. That's because you have 3 actions for those E-mails -- WARN, HOLD, and ROUTETO. HOLD and ROUTETO can't logically be combined, so Declude JunkMail assumes you want the stricter action (HOLD). To get around this, you can define the tests (in the global.cfg file) as: WEIGHT10weightrange x x 10 19 WEIGHT20weightrange x x 20 29 WEIGHT30weightrange x x 30 39 WEIGHT40weight x x 40 0 That way, only one of them will fail. So if the weight is 40 or higher, only the WEIGHT40 test will fail, and the ROUTETO action will be used. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] Outbound Port 25, was - Virginia Indicts
Hi Burzin, I wasn't thinking from an individual standpoint, but globally, as in cooperative efforts by all mail system providers to provide traceability and valid sender enforcement. I certainly realize that I individually have no control over others' systems to prevent spam, but with cooperative efforts between all providers we can make a difference. Not sure about the second part of your argument regarding FPs and business risk, and how it relates to this topic. Certainly I've always taken the stance that we have to err on the conservative side to ensure all legitimate business correspondence gets delivered, even if it means some spam gets through. My point is again that I'd like us to all put our heads together to see what measures we can initiate that will prevent spam from being sent in the first place. Outbound port 25 blocking from dynamic addresses is a start, but would only be partially effective as trojans, open relays, and port redirectors allow spammers to get around it. I guess what I was thinking is if we all could come up with a scenario to all but eliminate spam through cooperation by all providers, we could write up our recommendations and publish the results to the major players, lobbyists, and independent and government agencies to try to make it happen. As I mentioned before I'm wary of efforts that encourage spammers to develop viruses and worms to circumvent the blocks we put in place, as that could be a much bloodier battle than the one we're currently in, but here's what I think the initial pieces to this are. There are obvious holes in this list, though, and it doesn't completely solve the problem. 1. All SMTP servers verify the sending IP and add it to the headers for traceability. Some mailservers and ISPs do this, but most do not. Thankfully, this is something that Declude assists us with. 2. Port 25 blocking for all dynamic addresses with all network providers. This could cause some problems as I'm sure there are many legitimate networks that send from internal networks that are only connected via dynamic addresses, but it seems to be a critical piece to this effort. Forcing businesses that run internal mail servers to static addresses might not be a bad thing, though. 3. Globally managed open relay list and blacklist, preferably maintained by some sort of non-profit internet council. This could help close many open relays if an authoritative, complete list was formed and maintained. This organization should be responsive to removal requests, but require the burden of proof on the petitioner. 4. SMTP AUTH required on all SMTP servers, forcing users to properly authenticate in order to send. This might help reduce the virus threat. This is far from foolproof as the virus could use local mail profiles that have been set up with SMTP AUTH instead of embedding it's own SMTP component, but it's a start. I know that this won't be easy, but if we could make it happen, the end result would be extremely satisfying. Any comments, or other ideas to add to this list? Scott, sorry if this is too far off-topic, but I thought this would be a good community to discuss the possibilities. Let me know if you'd rather we take this discussion to another list. Darin. - Original Message - From: Burzin Sumariwalla [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 11:19 AM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Hi Darin, For the sake or arguement, I'm assuming one keeps one's server and up-to-date, patched, and takes prudent efforts to secure these devices. Most people probably don't secure workstations well enough. The server side of the equation is too complex. I don't think you (as an individual) can prevent spam from being sent. You can only control the email that you send and the actions you take in response to spam. You as an administator can prevent Spam from being sent outbound, but beyond securing the server and taking prudent measures your users are going to have to put up with false positives. Businesses run on email, and I'm not sure most companies would be willing to take such risks. Burzin At 09:12 PM 12/12/2003, you wrote: Everyone keep the ideas flowing... maybe we can come up with ideas as to how to keep spam from being sent to begin with. -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [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
Re: [Declude.JunkMail] Getting exec time on less than DEBUG mode?
I'm somewhat with Paul on this. The only thing is though that one doesn't need to constantly get time stats in order to judge such a change, and I don't think that I would personally bother to run this consistently unless I had an issue that was more suitable for debug mode in the first place. Maybe if there were some log analyzer tools that would average this stuff out per day and per hour, it would become a much more useful way to gauge performance over time. Matt paul wrote: I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. If others think this may be useful, it could get changed. That would be useful Scott, however, maybe make it a logging ON/OFF switch? So if you need that to be logged, just have exectime ON or something in Global.cfg. Paul --- [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] whitelist / CC
Dave, Try not to whitelist things over which you have no control over or a relationship with, and when you do, and use the IP whenever possible. When it comes to things like this, you should set up a pseudo-whitelist, which credits some points, but only enough to mitigate the false postives that you are seeing on those sources. This way you will still have the benefit of the custom filters that you are running as well as external tests, or rather you might not want to take away all the false positive points and start the bar a bit higher since this is a known issue. You create a pseudo-whitelist by setting up a custom filter as a negative scoring test. It might be best to score the filter at a fixed amount and then make adjustments to the individual lines when necessary. I have mine set up primarily to help with things might fail SpamCop or MailPolice, so the default credit that I give is about 80% of fail weight. It's also important to look for the least likely to be spoofed identifier. IP's are the best but hard to come by, REVDNS is the next best choice. Things like MAILFROM are consistently spoofed if the claimed source is popular (like an ecommerce site or ISP). A HEADERS filter can also be done in instances where the MAILFROM is dynamic and is a source for multiple content providers (such as third party bulk mailers). It's best to stay away from the BODY when possible and counterbalance in the custom filters that might have issues, though Sniffer may need a BODY filter to counterbalance for an FP there. Matt David Dodell wrote: I have Imail/Declude Junkmail/Virus running as a front end for another server which is using Lyris for multiple mailing lists. I had a problem in the past that certain ISP's (ie bellsouth.net) would fail multiple SPAM tests, so users posting to those lists would have their mail rejected. I decided to try and get around it by whitelisting the names of the mailing lists, ie [EMAIL PROTECTED], in the thoughts that Spam would be rejected by Lyris since the spammer was not a subscriber to the list. Works well. However, I'm noticing some spam is getting through by having the mailing list name, with a bunch of other accounts, ie mine, postmaster, etc all as part of the CC line. Since one of the accounts is whitelisted, it appears that Declude is whitelisting the message and letting it also get through to all of the other accounts on that cc line. Any suggestions on how I can deal with this? I thought that I might have to make a user configuration file per mailing list which I could just WHITELIST as the entry, but if I do this, will it still whitelist the email for the others on the cc line? David --- [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] Whitelist as a filter
R. Scott Perry wrote: This is an excellent idea -- not just for saving processing time on filters, but also to enhance the flexibility of whitelisting. This will be done for the next release. :) It will actually be *slightly* different, with Whitelist replacing the weight in the filters, so it would look like: BODYWHITELIST CONTAINSDeclude SUBJECT WHITELIST STARTSWITH Hello If there is a match, the filter will end, and the E-mail will be whitelisted (with no further filters being run). -Scott Scott, I'm not sure why this would be approached this way. Why not automatically stop Declude from processing all filters, custom, technical, RBL's, whatever, when something is whitelisted? Why would we want to have to start coding this information into our individual filters? Please reconsider. Thanks, Matt --- [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] Whitelist as a filter
BODYWHITELIST CONTAINSDeclude If there is a match, the filter will end, and the E-mail will be whitelisted (with no further filters being run). I'm not sure why this would be approached this way. Why not automatically stop Declude from processing all filters, custom, technical, RBL's, whatever, when something is whitelisted? That's just the way the code exists now. When Declude JunkMail was originally created, there were no whitelists (they were added about 6 months after Declude JunkMail was first released). When they were added, they were rarely used, and the extra processing wasn't much of a consideration, and ensured that there would not be any unwelcome side-effects (for example, reverse DNS lookups would be skipped, preventing the %REVDNS% variable from working). Also, order becomes an issue -- from the beginning, users haven't been able to control the order that tests are run in. That means that if a test is to whitelist an E-mail, other tests may already have been run (so it would not be possible to not run them). Why would we want to have to start coding this information into our individual filters? That's up to you. One reason is that it allows more flexibility -- anything that a filter can filter on can now be used for a whitelist. Another reason is that it helps reduce CPU time by ensuring that other filters will not be run. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] ROUTETO syntax
Aha! That makes perfect sense. Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Monday, December 15, 2003 3:10 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] ROUTETO syntax I just installed the Pro version after using the trial and am trying to configure the ROUTETO action. My Actions in the $default$.junkmail file are as follows: WEIGHT10 WARN WEIGHT20 HOLD WEIGHT30 HOLD WEIGHT40 ROUTETO [EMAIL PROTECTED] However, the messages with weights greater than 40 are still put into the \spool\spam\hold directory rather than going to the spambox account. That's because you have 3 actions for those E-mails -- WARN, HOLD, and ROUTETO. HOLD and ROUTETO can't logically be combined, so Declude JunkMail assumes you want the stricter action (HOLD). To get around this, you can define the tests (in the global.cfg file) as: WEIGHT10weightrange x x 10 19 WEIGHT20weightrange x x 20 29 WEIGHT30weightrange x x 30 39 WEIGHT40weight x x 40 0 That way, only one of them will fail. So if the weight is 40 or higher, only the WEIGHT40 test will fail, and the ROUTETO action will be used. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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 scanned for viruses by Declude Virus on the Orion Medical Management IMail server] --- [This E-mail scanned for viruses by Declude Virus on the Orion Medical Management IMail server] -- This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential and privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of the communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank you, Orion Medical Management Inc., Radiology Associates of Tampa. This message has been scanned for viruses by Declude Virus on the Orion Medical Management Imail Server. --- [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] refining the filtering process
While I'm hoping that Scott or someone will still reply to my earlier message (quoted below), I have a simpler, more mechanical question: how can I place the weight into the subject line of a message that fails one of the weight tests? It would be handy, for example, to see SPAM [6]: blah blah blah. Thanks, Ben - Original Message - From: IMail Admin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 11:41 AM Subject: [Declude.JunkMail] refining the filtering process We're fairly new at using JunkMail and we want to refine the process beyond the basic tests (typically weight10 or weight20). What strategy or steps would you recommend next? Two obvious ideas are Filtering and the ip4r tests. For filtering, I'm concerned about the system overhead and the effectiveness. I've heard that filtering on message headers is not effective and that filtering on message bodies is hard on the system. For ip4r, I've heard so many horror stories about over-zealous spam databases that I'm not sure which spam databases are worth working with. It would be really cool if someone at Declude wrote an addendum to the manual that talks about how to work with Declude JunkMail, rather than just how to use it. Any guidelines would be much appreciated. Thanks and happy holidays. Ben BC Web --- [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] refining the filtering process
While I'm hoping that Scott or someone will still reply to my earlier message (quoted below), I have a simpler, more mechanical question: how can I place the weight into the subject line of a message that fails one of the weight tests? It would be handy, for example, to see SPAM [6]: blah blah blah. You can use TESTNAME SUBJECT SPAM [%WEIGHT%] to do that. As far as refining the filtering process, that's a *huge* topic, and reading this mailing list is the best thing that you can do. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] refining the filtering process
Hi Ben, Hope this helps. I'll send you my configs if you are interested. Burzin At 01:41 PM 12/15/2003, you wrote: We're fairly new at using JunkMail and we want to refine the process beyond the basic tests (typically weight10 or weight20). What strategy or steps would you recommend next? I'd recommend using a using the default global.cfg file for starters. A link appears at http://www.declude.com/junkmail/manual.htm The default file (I believe) has the action set to WARN. Now see what happens. Depending on what version of JM you have, you may be able to setup per user .junkmail files. If so, pick out a spammed account that you are going to pay attention to and setup a per user .junkmail file. Use that file to take appropriate. That way, your users aren't effected by something you fat finger. I've setup my test.junkmail file with 2 actions per test, MAILBOX, and ATTACH. Two obvious ideas are Filtering and the ip4r tests. For filtering, I'm concerned about the system overhead and the effectiveness. I've heard that filtering on message headers is not effective and that filtering on message bodies is hard on the system. For ip4r, I've heard so many horror stories about over-zealous spam databases that I'm not sure which spam databases are worth working with. The IP4r tests that Scott has in the default global.cfg file seem pretty reliable. Look at http://www.declude.com/junkmail/support/ip4r.htm for some details on the particular databases. It would be really cool if someone at Declude wrote an addendum to the manual that talks about how to work with Declude JunkMail, rather than just how to use it. Any guidelines would be much appreciated. Thanks and happy holidays. Ben BC Web --- [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] refining the filtering process
Thanks for the answer on the subject question. Your answer on the other (refining...) question was a bit shorter than I was hoping for. Do you have an archive for your JunkMail list messages? I've been scanning through the archives of IMail, but it's hard to pinpoint the right information. Thanks, Ben - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 1:56 PM Subject: Re: [Declude.JunkMail] refining the filtering process While I'm hoping that Scott or someone will still reply to my earlier message (quoted below), I have a simpler, more mechanical question: how can I place the weight into the subject line of a message that fails one of the weight tests? It would be handy, for example, to see SPAM [6]: blah blah blah. You can use TESTNAME SUBJECT SPAM [%WEIGHT%] to do that. As far as refining the filtering process, that's a *huge* topic, and reading this mailing list is the best thing that you can do. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] Whitelist as a filter
R. Scott Perry wrote: When they were added, they were rarely used, and the extra processing wasn't much of a consideration, and ensured that there would not be any unwelcome side-effects (for example, reverse DNS lookups would be skipped, preventing the %REVDNS% variable from working). FYI, I'm using this to whitelist my customers that are behind a static IP. This will probably save me about 3% to 5% of my Declude processing demands with PREWHITELIST ON (if I understand that correctly). Before such an impact didn't matter, but I've got so many custom filters that every little bit matters. It's true though that most of your customers probably use this improperly. Why would we want to have to start coding this information into our individual filters? That's up to you. One reason is that it allows more flexibility -- anything that a filter can filter on can now be used for a whitelist. Another reason is that it helps reduce CPU time by ensuring that other filters will not be run. OK, I occurs to me that I was misunderstanding the functionality that you and Kami were in agreement on. This does make sense, though it will probably be misused just as often if not more than the Global.cfg whitelist. No reason to punish those that understand how best to use the functionality though. I need to give things a second thought before responding when both you and Kami agree on something and I don't :) Matt --- [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] refining the filtering process
Check the footer of all messages, they contain a link to the list archives. Bill - Original Message - From: IMail Admin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 2:33 PM Subject: Re: [Declude.JunkMail] refining the filtering process Thanks for the answer on the subject question. Your answer on the other (refining...) question was a bit shorter than I was hoping for. Do you have an archive for your JunkMail list messages? I've been scanning through the archives of IMail, but it's hard to pinpoint the right information. Thanks, Ben - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 1:56 PM Subject: Re: [Declude.JunkMail] refining the filtering process While I'm hoping that Scott or someone will still reply to my earlier message (quoted below), I have a simpler, more mechanical question: how can I place the weight into the subject line of a message that fails one of the weight tests? It would be handy, for example, to see SPAM [6]: blah blah blah. You can use TESTNAME SUBJECT SPAM [%WEIGHT%] to do that. As far as refining the filtering process, that's a *huge* topic, and reading this mailing list is the best thing that you can do. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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. --- [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] Whitelist as a filter
I'm not sure why this would be approached this way. Matt: I have always had an issue with Global.cfg being used for filters. I like to think of the global.cfg as a source for instructions. If the Global.cfg is setup correctly then John's issue with AutoWhitelist will also be resolved. Lets imagine.. If Global was like a script file that was just for instuctions we could simply order our commands as we saw fit. We could put the following: AUTOWHITE5 external10 WHITELIST AUTH And this way John's program would run first and then Whitelist would come into effect. Separating filters from commands is just clean programming and it makes sense from an object oriented perspective.. Having Whitelists as their own filter types would also separate the actions from global statement and makes us one more step closer to adding logic. All we need is a sequence command structure before we can start asking for IF Statements :) Regards, Kami --- [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] refining the filtering process
Ben, Maybe everyone assumed that the almighty IMail Admin knew all :) There is a link at the bottom of every message linking to the archive of this list. I would recommend that you take things one step at a time and try to be specific, i.e. don't try to figure out the accuracy of all of the RBL's at the same time, take it one or a couple at a time, do some review, read the manual, search the archives, ask questions when necessary, and make adjustment as needed. Also keep in mind that there are plenty of differing opinions around here, and there are multiple ways of achieving a perfect config. Leave the custom filtering for after the point where you feel comfortable with the built in technical filters and the blocklists. A lot of the questions that you will probably have to start have likely been answered in the manual or in the list archive. I don't mean to discourage you from asking valid questions, Declude is a complex environment, but it's best that you do some footwork once you have identified the sources. There's a wealth of information in the archives, too much in fact, and that alone should keep you busy for some time. Matt IMail Admin wrote: Thanks for the answer on the subject question. Your answer on the other (refining...) question was a bit shorter than I was hoping for. Do you have an archive for your JunkMail list messages? I've been scanning through the archives of IMail, but it's hard to pinpoint the right information. Thanks, Ben - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 1:56 PM Subject: Re: [Declude.JunkMail] refining the filtering process While I'm hoping that Scott or someone will still reply to my earlier message (quoted below), I have a simpler, more mechanical question: how can I place the weight into the subject line of a message that fails one of the weight tests? It would be handy, for example, to see SPAM [6]: blah blah blah. You can use TESTNAME SUBJECT SPAM [%WEIGHT%] to do that. As far as refining the filtering process, that's a *huge* topic, and reading this mailing list is the best thing that you can do. -Scott --- [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] Whitelist as a filter
Kami Razvan wrote: All we need is a sequence command structure before we can start asking for IF Statements :) What about AND, OR and NOT? Regular expressions as well :D Just kidding of course...well, kind of. --- [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] Outbound Port 25, was - Virginia Indicts
Hi Darin, At 02:14 PM 12/15/2003, you wrote: Hi Burzin, I wasn't thinking from an individual standpoint, but globally, as in cooperative efforts by all mail system providers to provide traceability and valid sender enforcement. I certainly realize that I individually have no control over others' systems to prevent spam, but with cooperative efforts between all providers we can make a difference. I think what you are saying (traceability and valid sender) can be summed up as good email server management. RFCs provide a good place to start, but as many people on the list have pointed out, many server admins don't abide by these practices. Sometimes it's out of ignorance, sometimes its out of laziness, and sometimes admin knows what they are doing and has a valid reason for it. This doesn't even address RFC compliance by the software developers on the server or client side. Ultimately some of this may be fixed by a successor to SMTP. This may not be a bad route to pursue, but there's always this thing about backwards compatibility. As an Imail admin., I use the Delcude, Sniffer, and Imail forums/resources to make sure I'm following best practices. There are other flavors out there. Is there better forum, or site that can be used by admins to secure their servers, understand the dos and don'ts, and correctly implemement them? Not sure about the second part of your argument regarding FPs and business risk, and how it relates to this topic. Certainly I've always taken the stance that we have to err on the conservative side to ensure all legitimate business correspondence gets delivered, even if it means some spam gets through. SMTP is a dual edged sword it works very well on a technical and social/business levels. However, its precisely because it works well on these levels that we have to deal with spam. If a large enough ISP or a group of ISPs takes action to prevent spam and if these efforts prevent enough mail from being delivered or make it a hastle for email to be delivered, it dimishes the utility of email. My point is again that I'd like us to all put our heads together to see what measures we can initiate that will prevent spam from being sent in the first place. Outbound port 25 blocking from dynamic addresses is a start, but would only be partially effective as trojans, open relays, and port redirectors allow spammers to get around it. I guess what I was thinking is if we all could come up with a scenario to all but eliminate spam through cooperation by all providers, we could write up our recommendations and publish the results to the major players, lobbyists, and independent and government agencies to try to make it happen. As I mentioned before I'm wary of efforts that encourage spammers to develop viruses and worms to circumvent the blocks we put in place, as that could be a much bloodier battle than the one we're currently in, but here's what I think the initial pieces to this are. There are obvious holes in this list, though, and it doesn't completely solve the problem. I think we are only a step or two (at most) away from spammers developing viruses/worms. 1. All SMTP servers verify the sending IP and add it to the headers for traceability. Some mailservers and ISPs do this, but most do not. Thankfully, this is something that Declude assists us with. I do this myself, but I can imagine organizations where they may not want this information out there for all to see. 2. Port 25 blocking for all dynamic addresses with all network providers. This could cause some problems as I'm sure there are many legitimate networks that send from internal networks that are only connected via dynamic addresses, but it seems to be a critical piece to this effort. Forcing businesses that run internal mail servers to static addresses might not be a bad thing, though. A subject of much discussion and consternation. I weight dynamic addresses. 3. Globally managed open relay list and blacklist, preferably maintained by some sort of non-profit internet council. This could help close many open relays if an authoritative, complete list was formed and maintained. This organization should be responsive to removal requests, but require the burden of proof on the petitioner. I think we have several defacto lists out there already. Some of these are free, but I suspect that the better ones will become non-profits and charge a subscription. 4. SMTP AUTH required on all SMTP servers, forcing users to properly authenticate in order to send. This might help reduce the virus threat. This is far from foolproof as the virus could use local mail profiles that have been set up with SMTP AUTH instead of embedding it's own SMTP component, but it's a start. I do this now, but had to get all my users upgraded to correct clients. I know that this won't be easy, but if we could make it happen, the end result would be extremely satisfying. Any comments, or other ideas to add to
[Declude.JunkMail] SPF support to be added to next beta
We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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.
[Declude.JunkMail] Autowhitelist AND gateways
How does (or doesn't it) AUTOWHITELIST work with a Gateway situation? We use iMail/Junkmail simply as a spam solution to MSFT Exchange 2003. My hunch is that it doesn't work because the users won't have a local login. Then again, I could write an application to extract contacts from a given users mailbox and insert them into the iMail contacts. That would probably cause the gateway to stop functioning because the mailbox would be on the iMail server. --- [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] Autowhitelist AND gateways
Declude AUTOWHITELIST relies upon the users address list residing on the same server. Therefore, it does not work for gateway solutions. However, there is another product that does work if both incoming and outgoing flow through Imail. http://www.eservicesforyou.com/products/autowhite.html ;) John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Mark Smith Sent: Monday, December 15, 2003 4:52 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] Autowhitelist AND gateways How does (or doesn't it) AUTOWHITELIST work with a Gateway situation? We use iMail/Junkmail simply as a spam solution to MSFT Exchange 2003. My hunch is that it doesn't work because the users won't have a local login. Then again, I could write an application to extract contacts from a given users mailbox and insert them into the iMail contacts. That would probably cause the gateway to stop functioning because the mailbox would be on the iMail server. --- [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] Filtering Question...
We have just upgraded to the Declude Junkmail Pro version mostly to take advantage of filtering. I have looked at Kami's filtering setup and I would like to get some input on other filters especially negative filters. 1) Are others using revdns filters for mail from aol, yahoo, excite, etc. with success since many of these domains trip no abuse, no postmaster tests? If so, does anyone have a list they would care to share for this purpose? 2) I notice some are using a MAILFROM counterweight instead of Revdns counterweight. What are the pros and cons of that approach? Chuck Schick Warp 8, Inc. 303-421-5140 www.warp8.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] Filtering Question...
Chuck, There are several different general uses for custom filtering. The Matt's School of Thought would teach as follows: 1) Programmatic filtering. This is more like pattern matching with custom filters. Patterns can be as simple as the country of origin, or more complex like gibberish inserted into spam in order to throw off some products. These filters can be highly effective at targeting crud spammers, even when they find a perfectly clean IP address. These guys often try multiple types of obfuscation in each message, and it's the techniques that give them away instead of the content. You can download a bunch of filters from my site, www.mailpure.com/software/decludefilters/ , and search the archives for versions of OBFUSCATION, DYNAMIC, PEXICOM, FORGEDHELO-IP, FORGEDHELP-FDQN, FORGEDASLOCAL, SPAMDOMAINS, and last week's New fraud exploit. There are other examples as well that appear now and then. 2) Banned words list. These should be scored fairly low, but some words are highly indicative of spam, for instance the various drugs that are advertised, or terms related to sex, printer cartridges, anti-virus products, fraud and scams, etc. You can categorize these in one single file, and score each entry independently. You can also add words to the list as you discover false negatives that get through your system. This need not be a very large list, in fact I make due quite well with maybe 50 such entries, though I could pay a bit more attention to it. Spammers will obfuscate problematic words, which means that the entries themselves may cause more FP's than P's. 3) Pseudo-whitelist. This is a very useful file to have in order to mitigate the effects of false positives from tests. Every system out there makes a subconscious attempt to deem what a normal score is, and it's not necessary to counterbalance every last point that might be scored from every last test...otherwise we would be blocking on every RBL and whitelisting with every filter. I really don't get concerned about false positives on E-mails until they start to score consistently at 70% of my fail weight, and then I take action on them by listing them in this filter. My pseudo-whitelist is much larger than my own blocklist because I add a listing to it every time I encounter a false positive as a result of an RBL or external test. I do differentiate between responsible bulk mailers, direct senders, and those that come from neither. 4) Pseudo-blacklist. This is mostly what Kami has done by building a list of identifiers for what he considers to be spam. In many cases he lists multiple types of information, probably in the off chance that one piece changes, but the others remain trackable. The downside of tracking multiple pieces is that FP's can occur with multiple elements. I personally keep two filters for this use, one is IP based (uses IPFILE functionality) and the other is based on a range of things, it all depends on what I deem as a reliable identifier, but I group them by identifier. If I consider a source to be spam and its not he crud type of spam that comes from open relays or zombied machines (so it can be tracked by way of some identifier where that type will even throw away domains after a few days), then I throw it in that file. I don't add a lot of this stuff because most of the static spammers tend to be well blocked by the RBL's, though I must block something if a customer asks me to. This becomes resource intensive if your file(s) grow too large and can be hard to maintain, i.e. how do you expire listings. Now as far as the pros and cons of using a particular data element for pseudo-whitelisting goes, you want to use the hardest to spoof piece of data that is reliable. The IP is the hardest, but it is rarely tracked due to the difficulty in maintaining this information, REVDNS is the next best, however it is sometimes spoofed with major ISP's and ecommerce sites. Data elements like HELO and MAILFROM are easily and often spoofed, and should be used as a last resort. You might even be forced to use HEADERS to search for an address that appears as the from, but not the MAILFROM, or in the event that you are counterbalancing an external test such as Message Sniffer, you might need to list URL's in a BODY filter since they will often track such things, and while you might get something through originally with a REVDNS counterbalance, a reply or forward of the same content could still trip Sniffer based on the content of the message. A recent issue highlights the decision making process required for pseudo-whitelisting. I had a FP reported to me from a pay site that sends out daily newsletters. This company uses a third-party delivery service which has a big problem with spammers and is even listed on SBL, though they also managed to get listed in Bonded Sender (both of which seem inappropriate). The REMOTEIP, REVDNS, HELO and
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
snip I think what you are saying (traceability and valid sender) can be summed up as good email server management. /snip Yes, I believe most of us on the list do this. The point is bringing more awareness to the global community to encourage all admins to do this. snip but as many people on the list have pointed out, many server admins don't abide by these practices. /snip Ditto from above snip Ultimately some of this may be fixed by a successor to SMTP. This may not be a bad route to pursue, but there's always this thing about backwards compatibility. /snip I've long advocated a successor to SMTP to deal with the authentication and traceability issues snip If a large enough ISP or a group of ISPs takes action to prevent spam and if these efforts prevent enough mail from being delivered or make it a hastle for email to be delivered, it dimishes the utility of email. /snip Yes, obviously we need to make to make every effort to ensure valid email gets delivered. That's why I suggested a global internet council to support tighter standards. Again, the only way we're going to win this battle is through cooperation. snip I think we are only a step or two (at most) away from spammers developing viruses/worms. /snip They already have. I want to avoid encouraging them to be more active in this area. Again, soliciting suggestions for this. snip 1. All SMTP servers verify the sending IP and add it to the headers for traceability. Some mailservers and ISPs do this, but most do not. Thankfully, this is something that Declude assists us with. I do this myself, but I can imagine organizations where they may not want this information out there for all to see. /snip Again, cooperation is needed. snip 2. Port 25 blocking for all dynamic addresses with all network providers. ... A subject of much discussion and consternation. I weight dynamic addresses. /snip With weighting only for dynamic addresses, there is always the possibility that spam can slip through. If we shut down other ways of sending, not blocking dynamic addresses will result in a mich higher percentage of spam getting through. snip I think we have several defacto lists out there already. Some of these are free, but I suspect that the better ones will become non-profits and charge a subscription. /snip None are adequate to the needs. That's why I suggested a global internet council to manage them. snip 4. SMTP AUTH required on all SMTP servers, forcing users to properly ... I do this now, but had to get all my users upgraded to correct clients. snip We switched about three years ago, but it was well received by our customer base. Yes, all of these suggestions will take some effort, but the end result of this, along with other suggestions not as yet raised, will be significant progress in the battle. How about some new suggestions for methods to combat the spammers? - --- [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. _ [This E-mail virus scanned by 4C Web] --- [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] SPF support to be added to next beta
Scott, Great idea! This is the kind of idea I was hoping for. Certainly it can be spoofed until all mailservers utilize this test, but it can at least add to negative weighting in the meantime...except for the trojan issue, of course. Darin. - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 6:54 PM Subject: [Declude.JunkMail] SPF support to be added to next beta We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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 virus scanned by 4C Web] --- [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] Filtering Question...
Matt: Thanks for your insight. I have been trying for two years to get in Front of the Spam curve but have found it to be an ever changing landscape which is hard to stay on top of. We have seen our Spam load increase at least 10 fold in the past two years. The challenge is that we have seen our legitimate email customers increase significantly also in that period of time and I feel the number one objective is to deliver the legitimate mail to them. Every time we add a spam test it also increases the false positives. It has gotten to the point where we need to counterweight some of the known issues. I prefer a counterweight (negative filter value) to out and out whitelisting. I believe whitelisting by email address or domain should be a last resort. I agree with much of what you have stated (the parts I do not fully agree with are simply because I have not fully studied it yet). Programmatic filtering we have been using Spamchk for two months now and have been very happy with the results - it has probably moved us to the high 90% in eliminating spam. One thing I see as that certain test cause more false positives than others. Spamdomains is an example of a test that I am strongly thinking of dropping - it probably causes more false positives than any other tests. Too many times people sending legitimate emails use a reply to address that is not the same domain as they are sending from. So I would like to use more programmatic filtering and counterbalances to get 99% rejection (we are there) and less than .3 % FP - (we are not there). Chuck Schick -- Original Message -- From: Matthew Bramble [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 15 Dec 2003 21:52:57 -0500 Chuck, There are several different general uses for custom filtering. The Matt's School of Thought would teach as follows: 1) Programmatic filtering. This is more like pattern matching with custom filters. Patterns can be as simple as the country of origin, or more complex like gibberish inserted into spam in order to throw off some products. These filters can be highly effective at targeting crud spammers, even when they find a perfectly clean IP address. These guys often try multiple types of obfuscation in each message, and it's the techniques that give them away instead of the content. You can download a bunch of filters from my site, www.mailpure.com/software/decludefilters/ , and search the archives for versions of OBFUSCATION, DYNAMIC, PEXICOM, FORGEDHELO-IP, FORGEDHELP-FDQN, FORGEDASLOCAL, SPAMDOMAINS, and last week's New fraud exploit. There are other examples as well that appear now and then. 2) Banned words list. These should be scored fairly low, but some words are highly indicative of spam, for instance the various drugs that are advertised, or terms related to sex, printer cartridges, anti-virus products, fraud and scams, etc. You can categorize these in one single file, and score each entry independently. You can also add words to the list as you discover false negatives that get through your system. This need not be a very large list, in fact I make due quite well with maybe 50 such entries, though I could pay a bit more attention to it. Spammers will obfuscate problematic words, which means that the entries themselves may cause more FP's than P's. 3) Pseudo-whitelist. This is a very useful file to have in order to mitigate the effects of false positives from tests. Every system out there makes a subconscious attempt to deem what a normal score is, and it's not necessary to counterbalance every last point that might be scored from every last test...otherwise we would be blocking on every RBL and whitelisting with every filter. I really don't get concerned about false positives on E-mails until they start to score consistently at 70% of my fail weight, and then I take action on them by listing them in this filter. My pseudo-whitelist is much larger than my own blocklist because I add a listing to it every time I encounter a false positive as a result of an RBL or external test. I do differentiate between responsible bulk mailers, direct senders, and those that come from neither. 4) Pseudo-blacklist. This is mostly what Kami has done by building a list of identifiers for what he considers to be spam. In many cases he lists multiple types of information, probably in the off chance that one piece changes, but the others remain trackable. The downside of tracking multiple pieces is that FP's can occur with multiple elements. I personally keep two filters for this use, one is IP based (uses IPFILE functionality) and the other is based on a range of things, it all depends on what I deem as a reliable identifier, but I group them by identifier. If I consider a source to be spam and its not he crud type of spam that comes from open relays or zombied machines (so it can be tracked by
