Re: [Declude.JunkMail] Double RDNS
I don't know of a way to do this with Declude currently, however, this is a test that I do run on my Postfix gateways. Here is a description of the Postfix test: reject_unknown_client Reject the request when the client IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record Although the Postfix test is a bit more stringent (rejecting if no PTR exists - equivalent to the Declude JunkMail REVDNS test), I think testing for matching forward and reverse records in a weighting system would be a very good test. I would suggest that it probably be best to just match the domain part: xyx.com, rather then looking to match the full hostname: mx1.xyz.com (which will cause fewer false-positives). And since the necessary info for this test is already gathered by Declude JM, it should not be a difficult test to implement. Scott, what are your thoughts on implementing a JM test like this? Bill - Original Message - From: Mike Kruidhof [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 10:38 PM Subject: [Declude.JunkMail] Double RDNS We just purchased and implemented Declude Junkmail here. I am attempting to understand what should be changed to catch more messages. We are using the default values. Many messages are getting through with low values. One thing came to me tonight, I turned on the XINHEADER option to show the RDNS value. Is there a test that can do a DNS lookup with the hostname that is returned from the RDNS? The IP address returned should match the IP address originally used for the RDNS. I would like to see how often this is not the case on the messages that are getting through. Thanks, Mike K --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re[4]: [Declude.JunkMail] Test on Imail X-header
All so much hokum. Not hokum to a commercial developer. Let's see: you've already (1) greatly enhanced interoperability with third-party applications in your new version and (2) greatly enhanced the performance of the underlying platform, thus making the combination of your new version+third-party software much more appealing. So do you then (3a) develop and test another new system service, make sure to parameterize everything under the sun, and slow processing; or (3b) get the d**n thing out the door before your competitors eat away your market share with their integrated anti-spam? On a specific technical level, if you're suggesting that separate services be used for content scanning and delivery, right away you're talking about doubling the disk I/O load even without Declude, since the file would then have to be read and written by two different processes, as well as IPC overhead. That's not something any sane developer would embark on under deadline: Hey, boss, give us a couple of weeks to make it slower. Yep, there are elegant solutions that could work around the extra resource usage when Declude wasn't installed, but at the expense of more development time basically sunk into somebody else's product, with only break-even performance for yourself. a hard-coded split in the spam processing There's no hard-coded split if you use IMail alone, which is the by-design deployment method for IMail anti-spam. IMail's anti-spam implementation depends on IMail's rules engine for postprocessing, and as such has no reason to be more open to third parties. What you suggest would be nice, sure, but Ipswitch is under no ethical or licensing obligation to let third parties use their anti-spam logic, especially not if it costs them development and QA time. In either case, with all the complaints people have had about the insufficiency of the IMail anti-spam implementation (no envelope rejection, etc.), don't you think it would make a bit more sense for them to start by making *their own* part of the equation optimal, instead of spending time opening their insufficient existing code? First things first: the major problem with IMail anti-spam isn't the process flow for content scanning, it's the process flow for envelope scanning. After *that's* fixed, worry about where the SendName comes into the overall process flow. :) -Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] --- [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] Attachments JM
Title: Message Scott: Are there plans for excluding attachments from being scanned by JM? It is real difficult not to have FP's if attachments are in the body of email. It seems like attachments are scanned and naturally the types like Word, PDF, Excel all will show characters that can randomly match the text filters we have. SPAM hardly comes with PDF attachments or Word or even less likely with Excel. Perhaps one easy way to combat this is to figure out the attachment (don't know how) may be we can assign a negative weight to emails with such attachments. Just some early morning thoughts... Regards, Kami
Re: [Declude.JunkMail] Double RDNS
Although the Postfix test is a bit more stringent (rejecting if no PTR exists - equivalent to the Declude JunkMail REVDNS test), I think testing for matching forward and reverse records in a weighting system would be a very good test. I would suggest that it probably be best to just match the domain part: xyx.com, rather then looking to match the full hostname: mx1.xyz.com (which will cause fewer false-positives). And since the necessary info for this test is already gathered by Declude JM, it should not be a difficult test to implement. Scott, what are your thoughts on implementing a JM test like this? The problem here is with false positives -- while about 90% of legitimate mailservers now have reverse DNS entries (up from about 80% a year or two ago), lots of them don't have A records that point back to the mailserver (mostly due to poor DNS, but many people have been told All you need is a reverse DNS entry, it doesn't matter what it is...). It's something that we are still considering, though. -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 have been missing: Ask for a 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] Fail two tests, get extra points
We run Sniffer, and we're testing Alligate (soon to be buying). I'd like to set up a test that adds points if BOTH tests fail. An Accelerator test, I guess. Unfortunately, there isn't any way of doing that currently. -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 have been missing: Ask for a 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] Attachments JM
Are there plans for excluding attachments from being scanned by JM? This question comes fairly often (usually in other forms, though). The answer is Yes, we do plan on adding full MIME support to an upcoming release. It is real difficult not to have FP's if attachments are in the body of email. It seems like attachments are scanned and naturally the types like Word, PDF, Excel all will show characters that can randomly match the text filters we have. SPAM hardly comes with PDF attachments or Word or even less likely with Excel. Perhaps one easy way to combat this is to figure out the attachment (don't know how) may be we can assign a negative weight to emails with such attachments. We have thought about having some sort of attachment detection that would allow for negative weights for various attachment types, which would help legitimate E-mail. -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 have been missing: Ask for a 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] Attachments JM
In looking at the email with PDF attachment I saw the following: Content-Type: application/pdf; Is this typically the case? It depends. If the mailer knows that a .PDF file should be of the MIME type application/pdf, you will probably see a Content-Type: application/pdf; header. But, it's also possible for it to be sent as an octet-stream, which is used for unknown data. -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 have been missing: Ask for a 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] Any ideas about Dartmail.net?
Title: Message Hi; We receive a lot of newsletters using Dartmail.net. Does anyone know of SPAM sent from this company? We are thinking of the wild idea of whitelisting their REVDNS. X-Note: Sent from Reverse DNS: mta2.primary.ddc.dartmail.net ([146.82.220.230]). So far we have ran a filter and every incident of their REVDNS has been legitimate newsletters. Thoughts? Regards, Kami
Re: Re[4]: [Declude.JunkMail] Test on Imail X-header
How are queue management and statistical content filtering even remotely related to each other? Name some other mail servers that you know combine these processes. How is it that you can speak so authoritatively about this subject? Unless you tell me that you consulted with IPSwitch on this product, or that you were a design engineer for them, your response is again all so much hokum and mere unsubstantiated mumbo jumbo. Bill - Original Message - From: Sanford Whiteman [EMAIL PROTECTED] To: Bill Landry [EMAIL PROTECTED] Sent: Friday, June 27, 2003 12:30 AM Subject: Re[4]: [Declude.JunkMail] Test on Imail X-header All so much hokum. Not hokum to a commercial developer. Let's see: you've already (1) greatly enhanced interoperability with third-party applications in your new version and (2) greatly enhanced the performance of the underlying platform, thus making the combination of your new version+third-party software much more appealing. So do you then (3a) develop and test another new system service, make sure to parameterize everything under the sun, and slow processing; or (3b) get the d**n thing out the door before your competitors eat away your market share with their integrated anti-spam? On a specific technical level, if you're suggesting that separate services be used for content scanning and delivery, right away you're talking about doubling the disk I/O load even without Declude, since the file would then have to be read and written by two different processes, as well as IPC overhead. That's not something any sane developer would embark on under deadline: Hey, boss, give us a couple of weeks to make it slower. Yep, there are elegant solutions that could work around the extra resource usage when Declude wasn't installed, but at the expense of more development time basically sunk into somebody else's product, with only break-even performance for yourself. a hard-coded split in the spam processing There's no hard-coded split if you use IMail alone, which is the by-design deployment method for IMail anti-spam. IMail's anti-spam implementation depends on IMail's rules engine for postprocessing, and as such has no reason to be more open to third parties. What you suggest would be nice, sure, but Ipswitch is under no ethical or licensing obligation to let third parties use their anti-spam logic, especially not if it costs them development and QA time. In either case, with all the complaints people have had about the insufficiency of the IMail anti-spam implementation (no envelope rejection, etc.), don't you think it would make a bit more sense for them to start by making *their own* part of the equation optimal, instead of spending time opening their insufficient existing code? First things first: the major problem with IMail anti-spam isn't the process flow for content scanning, it's the process flow for envelope scanning. After *that's* fixed, worry about where the SendName comes into the overall process flow. :) -Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] --- [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] Nolegit test
I would like to begin using the NOLEGITCONTENT test, but the mail archives are down :(. Can someone send me the lines I need in the configs to get this going? Thanks Jason
[Declude.JunkMail] BODY filter problems again
I posted a few weeks back regarding a problem with FP's in scanning attachments using a text filter we have setup; thanks to Scott's help, that problem seemed to be isolated to a high-end character in one of the BODY CONTAINS tests we had - that resolved just fine... Now again, all of a sudden, I am seeing the same thing - any JPG, PDF or DOC attachment is failing on a single line of our filter-porn.txt - BODY 20 CONTAINS c0ck I deleted that line in testing and messages with these types of attachments immediately began failing another line - BODY 20 CONTAINS full nudity No recent additions have been made to this file To make matters more confusing - we also run a regular filter.txt test with general words/phrases etc and are having no problems with this .txt test... Any ideas as to what could be causing this? IMAIL 7.07 hf3 Declude pro 1.70 beta Sincerely, Randy Armbrecht Global Web Solutions, Inc. 804-346-5300 x112 877-800-GLOBAL (4562) x112 http://globalweb.net --- [This msg Virus Scanned by GlobalWeb.net] --- [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] Nolegit test
I would like to begin using the NOLEGITCONTENT test, but the mail archives are down :(. Can someone send me the lines I need in the configs to get this going? You can use: NOLEGITCONTENT nolegitcontent x x 0 -8 this would go in the global.cfg file (you don't need any other lines for this test). -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 have been missing: Ask for a 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] Nolegit test
Thanks Scott (and Bill) We are holding on 20 right now (with very few FPs), so without divulging the details of the test, is -8 too much or too little a weight? Or should I just test test test to see what types of mail are failing/passing the test? Thanks Gents! Jason - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 27, 2003 12:16 PM Subject: Re: [Declude.JunkMail] Nolegit test I would like to begin using the NOLEGITCONTENT test, but the mail archives are down :(. Can someone send me the lines I need in the configs to get this going? You can use: NOLEGITCONTENT nolegitcontent x x 0 -8 this would go in the global.cfg file (you don't need any other lines for this test). -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 have been missing: Ask for a 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] OT: Political Spam
For some reason the political spam coming across our server is mostly radical right. I've seen exactly one liberal message, and that was a subscription that accidentally got caught in our spam traps. Keith Purtell, Web/Network Administrator VantageMed Operations (Kansas City) Email: [EMAIL PROTECTED] CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dan Patnode Sent: Friday, June 27, 2003 12:36 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] OT: Political Spam I preface this by saying that my techniques are based on studying and understanding spammers and the way they behave. More Sun Ztu than Zen: I've been noticing an increasing number of politically oriented spam, starting after the war with Iraq. The most wanted playing card spam turned into getting those who opposed the war. Since, I've seen anti Bush, pro Bush, and now anti Hillary and pro Hillary. This begs the question, are spammers (as a group) more Republican or Democrat? Maybe the 2010 US Census will have Spammer as an occupation... Dan --- [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] Nolegit test
In Global.cfg add a line like: NOLEGITCONTENTnolegitcontentxx0-5 Then adjust the weight to your liking. Remember, this test operates like the IPNOTINMX test in that it is meant to reward (by deducting weight) messages that meet the test requirements rather that penalize them like most of the other tests. Bill - Original Message - From: Jason Newland To: [EMAIL PROTECTED] Sent: Friday, June 27, 2003 9:53 AM Subject: [Declude.JunkMail] Nolegit test I would like to begin using the NOLEGITCONTENT test, but the mail archives are down :(. Can someone send me the lines I need in the configs to get this going? Thanks Jason
Re[6]: [Declude.JunkMail] Test on Imail X-header
How are queue management and statistical content filtering even remotely related to each other? Message filtering and delivery have ALWAYS been paired within the IMail process flow. I don't think you've been polite enough to deserve an explanation of the similarities in implementation across versions, but if you do your due diligence in this area perhaps you'll understand it better. Name some other mail servers that you know combine these processes. This isn't about other mail servers. It's about the evolution of a product from version to version while preserving central paradigms in order to avoid needless ground-up rewrites. In terms of other mail servers, unless you're doing streaming content filtering during the SMTP conversation (which would be resource suicide), you've signed on to doing post-submission filtering, then delivery. Whether or not other mail servers have separate filtering and delivery stages, IMail has historically only had the submission stage and the filtering/delivery stage, and that it is why it comes as absolutely no surprise that QM is an high-performance implementation of the same paired functions. How is it that you can speak so authoritatively about this subject? It is so because I know how IMail's process flow has worked in the past and how it has evolved. I have no professional alignment with Ipswitch, although I have been part of the requirements gathering process as a beta tester for several versions. -Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] --- [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] BODY filter problems again
I deleted that line in testing and messages with these types of attachments immediately began failing another line - BODY 20 CONTAINS full nudity Have you checked the lines just before and just after that one? There is a slight chance that the line numbering could be off for some reason. The BODY 20 CONTAINS full nudity should definitely not get triggered on an E-mail with a .jpg or .pdf file (unless, of course, the E-mail body contains full nudity). -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 have been missing: Ask for a 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] Way OT: IMail Host Aliases on Exchange 2000
Hello, All, We are in the process of moving the users, aliases and host aliases of our in-house domains from IMail over to Exchange 2000. We are still going to be passing our incoming mail through our IMail server to take advantage of Spam and Virus Filtering. I've been able to recreate almost everything that I had setup in IMail over on the Exchange Server. The one thing I haven't been able to recreate is the host aliases. Our primary mail site is defined in IMail as nexustechgroup.com. We also have 2 host aliases nexustechltd.com and nexustechnologygroup.com which allow any mail sent to any of those other domains to be accepted as if it were the primary domain. I was wondering if any of you kind IMail users knew how to setup the equivalent of IMail host aliases in Exchange 2000? Thanks, Much! Dan Geiser [EMAIL PROTECTED] This E-mail is scanned and free from viruses. www.nexustechgroup.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] AOL
Bill is correct. DISABLE fixup to ENABLE ESMTP and SMTP Auth. From the PIX manual: fixup protocol smtp [port[-port]] The fixup protocol smtp command enables the Mail Guard feature. This restricts mail servers to receiving the seven minimal commands defined in RFC 821, section 4.5.1 (HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT). All other commands are rejected. Microsoft Exchange server does not strictly comply with RFC 821 section 4.5.1, using extended SMTP commands such as EHLO. PIX Firewall will convert any such commands into NOOP commands, which as specified by the RFC, forces SMTP servers to fall back to using minimal SMTP commands only. This may cause Microsoft Outlook clients and Exchange servers to function unpredictably when their connection passes through PIX Firewall. Use the port option to change the default port assignments from 25. Use the -port option to apply SMTP application inspection to a range of port numbers. As of Version 5.1 and higher, the fixup protocol smtp command changes the characters in the server SMTP banner to asterisks except for the 2, 0, 0 characters. Carriage return (CR) and linefeed (LF) characters are ignored. PIX Firewall Version 4.4 converts all characters in the SMTP banner to asterisks. Regards, Dan Horne, CCNA Systems Administrator TAIS Web Wilcox World Travel Tours [EMAIL PROTECTED] CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Landry Sent: Thursday, June 26, 2003 7:21 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] AOL I afraid you have got it backwards. The fixup protocol disables ESMTP, which would include SMTP Auth, because fixup or permits SMTP attributes, but none of the extended atributes. Disabling the fixup protocol allow for ESMTP to pass through the PIX, including SMTP Auth. Bill - Original Message - From: Rick Davidson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 3:04 PM Subject: Re: [Declude.JunkMail] AOL Correct. It will disable SMTP AUTH as well The fixup was added to IOS to allow ESMTP its quite a pickle Rick Davidson Buckeye Internet Inc www.buckeyeweb.com 440-953-1900 ext: 222 - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 2:14 PM Subject: Re: [Declude.JunkMail] AOL Disabling the SMTP Fixup Protocol at the firewall disables ESMTP and allows only SMTP Anyone using Imail peering will not be able to disable ESMTP Does that mean that Cisco firewalls can't be set up not to interfere with SMTP transactions? If enabling the fixup protocol breaks RFC-compliance and doesn't do all that it is supposed to, and disabling it disables SMTP AUTH, those firewalls need to be thrown out. -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 have been missing: Ask for a 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. --- [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 body instead of anywhere?
Does Whitelist BODY the secret code is 1234 work or does it have to be anywhere? TIA - Marc --- [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 body instead of anywhere?
Does Whitelist BODY the secret code is 1234 work or does it have to be anywhere? No, you would need to use WHITELIST ANYWHERE The secret code is 1234. -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 have been missing: Ask for a 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: Re[6]: [Declude.JunkMail] Test on Imail X-header
Scott has mentioned on this list many times in the past the process order between IMail and Declude: Here is the order (from Scott): [1] IMail's Control Access file [2] IMail's Kill List [3] Declude Virus [4] Declude Junkmail [5] IMail rules Looks like all global filter processing by IMail has historically been done before messages were passed to Declude. Only individual IMail rules were processed after Declude passed the messages back to IMail for delivery (which certainly makes sense to me). So, since statistical content filtering is completely new in IMail v.8, how do you possibly come up with the conclusion that this type of filtering has always been done as part of queue management (which, by the way, is also new in IMail v.8, and even runs as a separate service, in case you hadn't noticed). So once again, I just feel that IPSwitch should have been consistent in their global spam processing and done it all before passing onto third-party plug-ins. Why hold out on just one of these global spam processing filters and none of the others--how much sense does that make? Wouldn't it make much more sense that if you were going to delete messages that fail statistical content filtering, that you would do that instead of passing the messages onto third-party plug-ins? Why unnecessarily waste the added resources of passing these messages onto third-party apps for additional processing when they are going to get deleted anyway after being sent back to IMail and failing the statistical content filtering--again, how much sense does that make? I know we are getting way OT here, but I just don't see the logic or rationale for your claims. Bill - Original Message - From: Sanford Whiteman [EMAIL PROTECTED] To: Bill Landry [EMAIL PROTECTED] Sent: Friday, June 27, 2003 10:22 AM Subject: Re[6]: [Declude.JunkMail] Test on Imail X-header How are queue management and statistical content filtering even remotely related to each other? Message filtering and delivery have ALWAYS been paired within the IMail process flow. I don't think you've been polite enough to deserve an explanation of the similarities in implementation across versions, but if you do your due diligence in this area perhaps you'll understand it better. Name some other mail servers that you know combine these processes. This isn't about other mail servers. It's about the evolution of a product from version to version while preserving central paradigms in order to avoid needless ground-up rewrites. In terms of other mail servers, unless you're doing streaming content filtering during the SMTP conversation (which would be resource suicide), you've signed on to doing post-submission filtering, then delivery. Whether or not other mail servers have separate filtering and delivery stages, IMail has historically only had the submission stage and the filtering/delivery stage, and that it is why it comes as absolutely no surprise that QM is an high-performance implementation of the same paired functions. How is it that you can speak so authoritatively about this subject? It is so because I know how IMail's process flow has worked in the past and how it has evolved. I have no professional alignment with Ipswitch, although I have been part of the requirements gathering process as a beta tester for several versions. -Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] --- [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] Way OT: IMail Host Aliases on Exchange 2000
That would be setup (after creating the base domain naming convention in Exchange- the default email address domain name). It is configured in Exchange system manager, Go to Recipients, Recipient Policies, edit the default policy, go to the second tab marked: Email Addresses Policy. Add the alternate domain names, and when done verify that the properties of a random user has all the appropriate domain names listed, and the appropriate default domain name. K? Stan Lyzak, BSEE, CISSP, MCSE², CCNA, Security+, A+ Network Security Engineer ASysTech, Inc. -Original Message- From: Dan Geiser [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 2:19 PM To: Declude JunkMail Subject: [Declude.JunkMail] Way OT: IMail Host Aliases on Exchange 2000 Hello, All, We are in the process of moving the users, aliases and host aliases of our in-house domains from IMail over to Exchange 2000. We are still going to be passing our incoming mail through our IMail server to take advantage of Spam and Virus Filtering. I've been able to recreate almost everything that I had setup in IMail over on the Exchange Server. The one thing I haven't been able to recreate is the host aliases. Our primary mail site is defined in IMail as nexustechgroup.com. We also have 2 host aliases nexustechltd.com and nexustechnologygroup.com which allow any mail sent to any of those other domains to be accepted as if it were the primary domain. I was wondering if any of you kind IMail users knew how to setup the equivalent of IMail host aliases in Exchange 2000? Thanks, Much! Dan Geiser [EMAIL PROTECTED] This E-mail is scanned and free from viruses. www.nexustechgroup.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[6]: [Declude.JunkMail] Test on Imail X-header
How are queue management and statistical content filtering even remotely related to each other? Message filtering and delivery have ALWAYS been paired within the IMail process flow. I don't think you've been polite enough to deserve an explanation of the similarities in implementation across versions, but if you do your due diligence in this area perhaps you'll understand it better. Name some other mail servers that you know combine these processes. This isn't about other mail servers. It's about the evolution of a product from version to version while preserving central paradigms in order to avoid needless ground-up rewrites. In terms of other mail servers, unless you're doing streaming content filtering during the SMTP conversation (which would be resource suicide), you've signed on to doing post-submission filtering, then delivery. Whether or not other mail servers have separate filtering and delivery stages, IMail has historically only had the submission stage and the filtering/delivery stage, and that it is why it comes as absolutely no surprise that QM is an high-performance implementation of the same paired functions. How is it that you can speak so authoritatively about this subject? It is so because I know how IMail's process flow has worked in the past and how it has evolved. I have no professional alignment with Ipswitch, although I have been part of the requirements gathering process as a beta tester for several versions. -Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] --- [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] Way OT: IMail Host Aliases on Exchange 2000
Rolling Eyes See my reply on Imail list. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.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 body instead of anywhere?
Crud... But the WHITELIST only does a complete match, right? so if I had slug as the whitelist word, the word sluggish in the headers or body wouldn't count. Right? Marc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry Sent: Friday, June 27, 2003 02:24 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Whitelist body instead of anywhere? Does Whitelist BODY the secret code is 1234 work or does it have to be anywhere? No, you would need to use WHITELIST ANYWHERE The secret code is 1234. -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 have been missing: Ask for a 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] --- [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: Re[6]: [Declude.JunkMail] Test on Imail X-header
Gee, Sandy, are you throwing in the towel already? That's certainly not like you, to be giving up so quickly and easily! ;-) Ok, I know I wasn't all that polite (as you pointed out), but I thought we were having a good spar anyway. Oh well, my bad... Bill - Original Message - From: Sanford Whiteman [EMAIL PROTECTED] To: Bill Landry [EMAIL PROTECTED] Sent: Friday, June 27, 2003 10:57 AM Subject: Re[6]: [Declude.JunkMail] Test on Imail X-header How are queue management and statistical content filtering even remotely related to each other? Message filtering and delivery have ALWAYS been paired within the IMail process flow. I don't think you've been polite enough to deserve an explanation of the similarities in implementation across versions, but if you do your due diligence in this area perhaps you'll understand it better. Name some other mail servers that you know combine these processes. This isn't about other mail servers. It's about the evolution of a product from version to version while preserving central paradigms in order to avoid needless ground-up rewrites. In terms of other mail servers, unless you're doing streaming content filtering during the SMTP conversation (which would be resource suicide), you've signed on to doing post-submission filtering, then delivery. Whether or not other mail servers have separate filtering and delivery stages, IMail has historically only had the submission stage and the filtering/delivery stage, and that it is why it comes as absolutely no surprise that QM is an high-performance implementation of the same paired functions. How is it that you can speak so authoritatively about this subject? It is so because I know how IMail's process flow has worked in the past and how it has evolved. I have no professional alignment with Ipswitch, although I have been part of the requirements gathering process as a beta tester for several versions. -Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] --- [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[8]: [Declude.JunkMail] Test on Imail X-header
Scott has mentioned on this list many times in the past the process order between IMail and Declude... Yes, and you're not interpreting the order correctly. IMail has always performed all content-based filtering after submission, during the filtering/delivery stage once represented by SMTP32 and now succeeded by QM (your quip in case you haven't noticed unfortunately shows that you didn't even read one of my posts in which I described the performance pitfalls of adding YET ANOTHER system service, splitting queue management and content scanning into two services instead of the one unified executable that has been offered--once a process, now a service). I think the fundamental thing you're missing is that the SMTP daemon does not do content filtering, and never has. Envelope filtering powered by the KILL.LST is not content filtering, by definition. The content filtering, which used to be limited to the basic IMail rules engine but now has been beefed up to include a seeded list of spam phrases and patterns and statistical averaging as well, has always been done by the delivery process: again, the basic content filtering used to be done by SMTP32, now the enhanced content filtering is done by QM. This is, again, unsurprising. Your projections about the wisdom of putting content filtering into the SMTP daemon do not agree with best practices for Win32 system programming (nor do I know of *nix milters that operate at such a level). They may make sense to you, but they don't make sense on a system that could be easily socket- and process-starved by such a decision...if you'd worked on an enterprise WinSock application, you'd understand. And the resources that you're suggesting are wasted by spooling a file, then triggering another process to read and scan the file are only IPC resources, and the disk and CPU resources have been appropriately moved away from the primary, non-multi-threaded daemon to be managed by a self-scheduling secondary daemon. As I tried to explain two posts ago, to further expand this into a secondary content scanning daemon and a tertiary delivery daemon would mean that files *not* selected for deletion after content scanning would need to be spooled by SMTPD, read by CS, written by CS, read by QM, and written again by QM--suboptimal design that, if not mandated by third-party interoperability concerns (as clearly it was not), should be avoided. -Sandy -- Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. mailto:[EMAIL PROTECTED] -- --- [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 body instead of anywhere?
But the WHITELIST only does a complete match, right? Correct. But: so if I had slug as the whitelist word, the word sluggish in the headers or body wouldn't count. Right? If you had WHITELIST BODY slug, then an E-mail with the word sluggish would get caught. No Declude functions attempt to parse an E-mail into words, so nothing in Declude (or IMail) will distinguish Look at that slug! from He was acting sluggish. -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 have been missing: Ask for a 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] interesting idea from a bulk marketer
Since yesterday I have been in contact with a very helpful mail admin. It seems one of my users has an outside email address at bigfoot and was forwarding all his email to our server from there. One opt-in list he is on was getting bounced. In the process of finding out that email sent directly to us was fine and so on, this guy asked if ISP's would be interested in a blacklist at HIS end. This idea intrigued me a lot. He is willing to have a web page setup so a domain can be entered and no email at all will go to any address on that domain. I can see abuse against him though. Nice to work with a helpful bulk mailer for a change!!! Sheldon Sheldon Koehler, Owner/Partnerhttp://www.tenforward.com Ten Forward Communications 360-457-9023 Nationwide access, neighborhood support! Whenever you find yourself on the side of the majority, it's time to pause and reflect. Mark Twain --- [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] OT: National Do Not Call Registry
Stops the telemarketers (with some exceptions), debuted this morning: http://donotcall.gov/ More junk stopping info: http://www.obviously.com/junkmail/ --- [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] Weight problem ?
I had a customer send me the headers of an email that did not get caught held ) that should have.. At least I think it should have... snip X-MSMail-priority: Normal X-RBL-Warning: BADHEADERS: This E-mail was sent from a broken mail client [801f]. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 211.243.11.104 with no reverse DNS entry. X-RBL-Warning: WEIGHT10: Weight of 13 reaches or exceeds the limit of 10. X-Declude-Sender: [EMAIL PROTECTED] [211.243.11.104] X-Declude-Spoolname: D18a2a9cf007cfa90.SMD I have declude set up to hold at 10 delete at 20. Any thoughts ? David Barrett Maine Connect, Inc. I'd rather be a failure at something I enjoy than be a success at something I hate -- George Burns --- [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] Way OT: IMail Host Aliases on Exchange 2000
Thanks, Stanley! That's exactly the sort of advice that I was looking for! It worked like a charm. Take Care, Dan - Original Message - From: Stanley Lyzak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 27, 2003 2:52 PM Subject: RE: [Declude.JunkMail] Way OT: IMail Host Aliases on Exchange 2000 That would be setup (after creating the base domain naming convention in Exchange- the default email address domain name). It is configured in Exchange system manager, Go to Recipients, Recipient Policies, edit the default policy, go to the second tab marked: Email Addresses Policy. Add the alternate domain names, and when done verify that the properties of a random user has all the appropriate domain names listed, and the appropriate default domain name. K? Stan Lyzak, BSEE, CISSP, MCSE², CCNA, Security+, A+ Network Security Engineer ASysTech, Inc. -Original Message- From: Dan Geiser [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 2:19 PM To: Declude JunkMail Subject: [Declude.JunkMail] Way OT: IMail Host Aliases on Exchange 2000 Hello, All, We are in the process of moving the users, aliases and host aliases of our in-house domains from IMail over to Exchange 2000. We are still going to be passing our incoming mail through our IMail server to take advantage of Spam and Virus Filtering. I've been able to recreate almost everything that I had setup in IMail over on the Exchange Server. The one thing I haven't been able to recreate is the host aliases. Our primary mail site is defined in IMail as nexustechgroup.com. We also have 2 host aliases nexustechltd.com and nexustechnologygroup.com which allow any mail sent to any of those other domains to be accepted as if it were the primary domain. I was wondering if any of you kind IMail users knew how to setup the equivalent of IMail host aliases in Exchange 2000? Thanks, Much! Dan Geiser [EMAIL PROTECTED] This E-mail is scanned and free from viruses. www.nexustechgroup.com --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. === This E-mail is scanned and free from viruses. www.nexustechgroup.com This E-mail is scanned and free from viruses. www.nexustechgroup.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] OT: National Do Not Call Registry
There is some helpful info here as well... http://www.ftc.gov/bcp/conline/edcams/donotcall/index.html - Original Message - From: Dan Patnode [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 27, 2003 3:49 PM Subject: [Declude.JunkMail] OT: National Do Not Call Registry Stops the telemarketers (with some exceptions), debuted this morning: http://donotcall.gov/ More junk stopping info: http://www.obviously.com/junkmail/ --- [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 is scanned and free from viruses. www.nexustechgroup.com This E-mail is scanned and free from viruses. www.nexustechgroup.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] interesting idea from a bulk marketer
Or is it a ploy to harvest more addresses? John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Sheldon Koehler Sent: Friday, June 27, 2003 1:25 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] interesting idea from a bulk marketer Since yesterday I have been in contact with a very helpful mail admin. It seems one of my users has an outside email address at bigfoot and was forwarding all his email to our server from there. One opt-in list he is on was getting bounced. In the process of finding out that email sent directly to us was fine and so on, this guy asked if ISP's would be interested in a blacklist at HIS end. This idea intrigued me a lot. He is willing to have a web page setup so a domain can be entered and no email at all will go to any address on that domain. I can see abuse against him though. Nice to work with a helpful bulk mailer for a change!!! Sheldon Sheldon Koehler, Owner/Partnerhttp://www.tenforward.com Ten Forward Communications 360-457-9023 Nationwide access, neighborhood support! Whenever you find yourself on the side of the majority, it's time to pause and reflect. Mark Twain --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: Re[8]: [Declude.JunkMail] Test on Imail X-header
You seem to be talking all around the real issue, and that is that all global (not individual) content filtering should be done prior to invoking any other third-party apps, which is where it is most appropriately done. Individual content filtering is user specific, and so it make sense that this filtering be done after messages are returned to IMail, and just prior to delivery. Of all of the different mail servers we manage at our data centers, including Postfix and Sendmail, I can't imagine not doing all of the processing you can do before delivering to a third-part app for additional processing. It just would not make sense to do part of the message spam processing, send it to some other app for processing, and then receive it back to do more spam processing. What a waste of time and resources. If at any point in the process you can reach final disposition before invoking other processes, then you should do so. When we setup Amavis-New as a Postfix content filter, we first do all spam processing we want to do with Postfix, and if the message has not been disposed of there, then inject it into Amavis, were we invoke SpamAssassin, Razor, and DCC, and if the message is not disposed somewhere along this process, then send it back to Postfix for final delivery--not for more spam processing. Now that's not to say that more individual content filtering is not done after Postfix receives the message back. Users can setup additional content filtering with Procmail, if they like. But again, this is individual content filtering, not global content filtering, and should be done as the last test prior to delivery. Although I don't directly manage any of the Sendmail servers, I will check to see how they handle their content filtering, as well. But from the looks of the headers, it appears to be very similar to how we run our Postfix servers on Linux. Okay, so let's just agree to admit that it's a major design flaw in IMail v.8, and leave it at that--and hope that IPSwitch will fix it in a future update... ;-) Bill - Original Message - From: Sanford Whiteman [EMAIL PROTECTED] To: Bill Landry [EMAIL PROTECTED] Sent: Friday, June 27, 2003 12:46 PM Subject: Re[8]: [Declude.JunkMail] Test on Imail X-header Scott has mentioned on this list many times in the past the process order between IMail and Declude... Yes, and you're not interpreting the order correctly. IMail has always performed all content-based filtering after submission, during the filtering/delivery stage once represented by SMTP32 and now succeeded by QM (your quip in case you haven't noticed unfortunately shows that you didn't even read one of my posts in which I described the performance pitfalls of adding YET ANOTHER system service, splitting queue management and content scanning into two services instead of the one unified executable that has been offered--once a process, now a service). I think the fundamental thing you're missing is that the SMTP daemon does not do content filtering, and never has. Envelope filtering powered by the KILL.LST is not content filtering, by definition. The content filtering, which used to be limited to the basic IMail rules engine but now has been beefed up to include a seeded list of spam phrases and patterns and statistical averaging as well, has always been done by the delivery process: again, the basic content filtering used to be done by SMTP32, now the enhanced content filtering is done by QM. This is, again, unsurprising. Your projections about the wisdom of putting content filtering into the SMTP daemon do not agree with best practices for Win32 system programming (nor do I know of *nix milters that operate at such a level). They may make sense to you, but they don't make sense on a system that could be easily socket- and process-starved by such a decision...if you'd worked on an enterprise WinSock application, you'd understand. And the resources that you're suggesting are wasted by spooling a file, then triggering another process to read and scan the file are only IPC resources, and the disk and CPU resources have been appropriately moved away from the primary, non-multi-threaded daemon to be managed by a self-scheduling secondary daemon. As I tried to explain two posts ago, to further expand this into a secondary content scanning daemon and a tertiary delivery daemon would mean that files *not* selected for deletion after content scanning would need to be spooled by SMTPD, read by CS, written by CS, read by QM, and written again by QM--suboptimal design that, if not mandated by third-party interoperability concerns (as clearly it was not), should be avoided. -Sandy -- Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. mailto:[EMAIL PROTECTED] -- --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
[Declude.JunkMail] Mail Client with Redirect Command
Can anyone out there recommend a Windows based email client that supports the redirect command ?? Thank you. Jeff
RE: [Declude.JunkMail] BODY filter problems again
Checked 3 lines and 3 lines below - I failed to mentioned - and this will blow more minds - the 1st failure line was line 120 , after I deleted that, the failure line immediately became line 136. I have removed all BODY filter tags out for now until I time to go back and add a block 5 at a time again... As I mentioned before - we have a regular filter test also running at same time that does not cause these issues Sincerely, Randy Armbrecht Global Web Solutions, Inc. 804-346-5300 x112 877-800-GLOBAL (4562) x112 http://globalweb.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Friday, June 27, 2003 1:22 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] BODY filter problems again I deleted that line in testing and messages with these types of attachments immediately began failing another line - BODY 20 CONTAINS full nudity Have you checked the lines just before and just after that one? There is a slight chance that the line numbering could be off for some reason. The BODY 20 CONTAINS full nudity should definitely not get triggered on an E-mail with a .jpg or .pdf file (unless, of course, the E-mail body contains full nudity). -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 have been missing: Ask for a 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 msg Virus Scanned by GlobalWeb.net] --- [This msg Virus Scanned by GlobalWeb.net] --- [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] Mail Client with Redirect Command
Friday, June 27, 2003 you wrote: JP Can anyone out there recommend a Windows based email client JP that supports the redirect command ?? the Bat! http://www.ritlabs.com/the_bat/index.html Terry Fritts --- [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] time-dependently hold weight
Title: Nachricht Hi spam-fighters, What do you think about a time-dependently hold weight? Maybe this can be helpfull on certain systems (where all users work in the same time zone) to reduce FP's. For further explanation please see the PDF-file located at www.zcom.it/decludeupdater/returncodes.pdf (280 kB). -The red dots are single messages over 24 hours (x) and their weight (y). -The blue line is the average value of all weights in this time range -The yellow line is our current hold weight of 100 points.(consider it 100% if you hold on the default weight of 20 points) Now my suggestion/question: As you can see, our server processes most legit messages between 8:00 AM and 8:00 PM So why not increase the hold weight slightly in this time range and decrease it a little bit on the resting time? (green line) Counting our FP's from the last 20 days and increasing the hold weight during business time from 100 to 110 this will avoid 65% of them. Naturally the increased hold value let pass some more spam messages, but with 225 more delivered spam (that has recieved a weight between 100 and 110 points)from over 14000 hold spam in the last 20 days this is very few. Theoretically we all can create two identical configuration files with 2 different hold weights and switch between this two with a scheduled task. No additional ressources are needed. ...or am I missing something? Markus
RE: [Declude.JunkMail] time-dependently hold weight
Title: Nachricht Go to sleep Markus. It has been too long of a week to think. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Gufler Sent: Friday, June 27, 2003 5:13 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] time-dependently hold weight Hi spam-fighters, What do you think about a time-dependently hold weight? Maybe this can be helpfull on certain systems (where all users work in the same time zone) to reduce FP's. For further explanation please see the PDF-file located at www.zcom.it/decludeupdater/returncodes.pdf (280 kB). -The red dots are single messages over 24 hours (x) and their weight (y). -The blue line is the average value of all weights in this time range -The yellow line is our current hold weight of 100 points. (consider it 100% if you hold on the default weight of 20 points) Now my suggestion/question: As you can see, our server processes most legit messages between 8:00 AM and 8:00 PM So why not increase the hold weight slightly in this time range and decrease it a little bit on the resting time? (green line) Counting our FP's from the last 20 days and increasing the hold weight during business time from 100 to 110 this will avoid 65% of them. Naturally the increased hold value let pass some more spam messages, but with 225 more delivered spam (that has recieved a weight between 100 and 110 points)from over 14000 hold spam in the last 20 days this is very few. Theoretically we all can create two identical configuration files with 2 different hold weights and switch between this two with a scheduled task. No additional ressources are needed. ...or am I missing something? Markus
Re: [Declude.JunkMail] OT: National Do Not Call Registry
More info and stats: http://www.bankrate.com/brm/news/advice/20030627a1.asp The Federal Trade Commission says more than 1,000 people per second are trying to register either online or by phone. In an ironic twist, a technology consulting firm discovered that spam filters, specifically Yahoo's and perhaps others, are blocking many of the confirmation e-mails consumers are supposed to receive to complete their online registration. On Friday, June 27, 2003 12:49, Dan Patnode [EMAIL PROTECTED] wrote: Stops the telemarketers (with some exceptions), debuted this morning: http://donotcall.gov/ More junk stopping info: http://www.obviously.com/junkmail/ --- [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] time-dependently hold weight
Its been a horrible week, but I need the distraction... I've considered this a few times, every time I prepare to suggest it I remember what happened with my idea to test for long subjects, there just isn't enough uniformity. My concern isn't so much uniformity of technical things like tracking time zones and the like, but rather the way the world spins. A system that penalizes (or rewards) based on when (even if cross referenced when it arrived) would still have to deal with localization. Can a system reliably know a message was sent during daylight/working hours from where it was sent? The only reliable way I can see is if Scott found a way (assuming the recieving server's clock was set correctly) to cross reference the geo code of the senders IP address with the arrival time of the message. BTW, the graph is amazing, how is it made? Dan On Friday, June 27, 2003 17:12, Markus Gufler [EMAIL PROTECTED] wrote: Nachricht Hi spam-fighters, What do you think about a time-dependently hold weight? Maybe this can be helpfull on certain systems (where all users work in the same time zone) to reduce FP's. For further explanation please see the PDF-file located at www.zcom.it/decludeupdater/returncodes.pdf (280 kB). -The red dots are single messages over 24 hours (x) and their weight (y). -The blue line is the average value of all weights in this time range -The yellow line is our current hold weight of 100 points. (consider it 100% if you hold on the default weight of 20 points) Now my suggestion/question: As you can see, our server processes most legit messages between 8:00 AM and 8:00 PM So why not increase the hold weight slightly in this time range and decrease it a little bit on the resting time? (green line) Counting our FP's from the last 20 days and increasing the hold weight during business time from 100 to 110 this will avoid 65% of them. Naturally the increased hold value let pass some more spam messages, but with 225 more delivered spam (that has recieved a weight between 100 and 110 points) from over 14000 hold spam in the last 20 days this is very few. Theoretically we all can create two identical configuration files with 2 different hold weights and switch between this two with a scheduled task. No additional ressources are needed. ...or am I missing something? Markus --- [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] OT: National Do Not Call Registry
When will the government listen to the will of the people and just outlaw spam and tele-marketing (with severe enough penalties to deter)? Ooops. I'm sorry. I had brain fart. I wasn't thinking that the lobbyists for keeping spam and tele-marketing around have deeper pockets than the poor users. Combined with the golden rule of capitalism: He who has the gold makes the rules., results in what we have today. I think that the do not call list will result in a new call list worth $$MM. Todd Holt Xidix Technologies, Inc Las Vegas, NV USA www.xidix.com -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Dan Patnode Sent: Friday, June 27, 2003 6:37 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] OT: National Do Not Call Registry More info and stats: http://www.bankrate.com/brm/news/advice/20030627a1.asp The Federal Trade Commission says more than 1,000 people per second are trying to register either online or by phone. In an ironic twist, a technology consulting firm discovered that spam filters, specifically Yahoo's and perhaps others, are blocking many of the confirmation e-mails consumers are supposed to receive to complete their online registration. On Friday, June 27, 2003 12:49, Dan Patnode [EMAIL PROTECTED] wrote: Stops the telemarketers (with some exceptions), debuted this morning: http://donotcall.gov/ More junk stopping info: http://www.obviously.com/junkmail/ --- [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 scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.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] Attachments JM
Scott: Thanks for your comment... May be you can answer this question before we can figure out through iterations. In looking at the email with PDF attachment I saw the following: Content-Type: application/pdf; Is this typically the case? If so I think we can assign negative weight to this as a filter in the body. If this is true and consistent then we can do the same with DOC, XLS, etc. Thoughts? Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Friday, June 27, 2003 7:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Attachments JM Are there plans for excluding attachments from being scanned by JM? This question comes fairly often (usually in other forms, though). The answer is Yes, we do plan on adding full MIME support to an upcoming release. It is real difficult not to have FP's if attachments are in the body of email. It seems like attachments are scanned and naturally the types like Word, PDF, Excel all will show characters that can randomly match the text filters we have. SPAM hardly comes with PDF attachments or Word or even less likely with Excel. Perhaps one easy way to combat this is to figure out the attachment (don't know how) may be we can assign a negative weight to emails with such attachments. We have thought about having some sort of attachment detection that would allow for negative weights for various attachment types, which would help legitimate E-mail. -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 have been missing: Ask for a 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 Ready to Activate SPAMDOMAINS
Hi, Again, Would anyone care to comment on my original posting? If my questions are too simple or complex or some place in between or my message is too long or the questions themselves just don't have an answer then please let me know and I'll try and proceed with my current knowledge base. Thanks, Much! Dan Geiser [EMAIL PROTECTED] - Original Message - From: Dan Geiser [EMAIL PROTECTED] To: Declude JunkMail [EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 5:02 PM Subject: [Declude.JunkMail] Getting Ready to Activate SPAMDOMAINS Hello, All, I'm getting ready to put SPAMDOMAINS in place on my installation of Declude JunkMail Pro. Before I flip the switch I had a few questions which I was hoping that those who are currently using SPAMDOMAINS could answer... 1) Increase message weight or HOLD? I realize that there are 2 ways, possibly more, that I can actually do something to a message when it's recognized by SPAMDOMAINS. One is to increase the weight by a certain amount, e.g. 20 points, until I'm pretty sure it will fall over my hold weight. Another way to do it would just to HOLD on failure of the SPAMDOMAINS out right. My tendency is to want to just increase the weight somewhat to fall in line with the standard way of doing things, i.e. not HOLDing on any one test, but because I've read on this list that Kami is currently HOLDing I thought maybe that was viable as well. Perhaps I can start out with a weight increase and then move to HOLD later on? Regardless, for those of you who currently have SPAMDOMAINS implemented I'm looking for some feedback as to which way you feel it is best to go. If you fall in the camp who thinks just increasing the weight should be sufficient could you recommend a good point value to increase it by? I'm still using all of the default point values that come with GLOBAL.CFG if that helps. 2) Start out with one entry in SPAMDOMAINS Since I've seen lots of domains bandied about which fit the SPAMDOMAINS bill I was thinking of maybe just starting out with one domain, Hotmail.com, to ease in to how all of this works. Can someone provide me with the entries for spamdomains.txt given the current wisdom on Hotmail.com? 3) What triggers additional entries to spamdomains.txt? For those who are currently running SPAMDOMAINS, what occurence in your spam tuning process triggers the addition of a new entry to spamdomains.txt? Is it just seeing the headers of an obvious spam which makes it through the current filters or are you actively seeking out new potential SPAMDOMAINS all of the time, by searching the HELD queue, etc? 4) Maintaining One Master SPAMDOMAINS List I've seen discussion on here about someone perhaps maintaing one master list of all of the SPAMDOMAINS. Is that currently happening? If so, where can I obtain the official list? If not, is that plan still in the works? 5) Actual Entries to Enable SPAMDOMAINS Just for review I want to make sure I'm planning on implementing it properly. 5a) Add an entry to GLOBAL.CFG which looks something like the following... SPAMDOMAINS spamdomains D:\iMail\declude\JunkMail.SpamDomains.txt x 0 0 If I want to increase the points which SPAMDOMAINS adds to the total weight then I would increase the number in the 5th column (2nd to last column). 5b) Create a file called JunkMail.SpamDomains.txt (without the quotes) and add the entry... hotmail.com If I want I can also add aliases for servers that the Hotmail.com domain might pass through like MSN.COM, etc. 5c) Add an entry in the $default$.junkmail file which looks something like... SPAMDOMAINSWARN or if I want to actually block for all mail which fails the SPAMDOMAINS test I can put... SPAMDOMAINSHOLD Thanks In Advance For Any and All Feedback! Take Care, Dan [EMAIL PROTECTED] This E-mail is scanned and free from viruses. www.nexustechgroup.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 is scanned and free from viruses. www.nexustechgroup.com This E-mail is scanned and free from viruses. www.nexustechgroup.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.
