RE: [Declude.JunkMail] OT - iMail 7.x and Windows 2003
Actually, we have tried both but have not found the culprit(s) yet. Although my partner believes he saw a spike in traffic coming in as a Telenet session from an unexpected origin - rrcs-74-39-200-122.nys.biz.rr.com which on searching with google appears not too uncommon - that is hacks, spam and spyware from users of biz.rr.com. This has us planning to try to isolate which IP address(es) attacks may be coming in on and shut them down. Regarding telnet - apparently there is a problem with windows 2003 and iMail. If my source is correct one can telnet into a Windows 2003 system running iMail (pick a version) on port 25 and get by the authentication. Again, my source told me that neither Micosoft nor Ipswitch has come up with a way to stop this. It appears only to be a problem on Windows 2003, not Windows 2000. At 04:05 PM 9/7/2005, Kevin Bilbee wrote: Start with TCPView From sysinternals to view open ports on the server find the ports and programs that should not be running and kill then remove them from the system. Also use Process Explorer from sysinternals and look at all the running processes. If you find one that does not belong then kill and remove it. Kevin Bilbee --- 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] SPFPass - good or bad?
I use SPFFail to add weight to test to a message, but like you I have also seen spammers creating SPF records, which in turn allows them to get lower score with SPFPass. As a result, we no long find that SPFPass is a useful in detecting spam. David Kornitz / Cornerstone Computer Solutions, Inc, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Dodell Sent: Thursday, September 08, 2005 12:28 AM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPFPass - good or bad? I've noticed a bunch of spam with SPFPass grades that have negated the spam databases (I have SPFPass at -5) ... is anyone finding that SPFPass is working with spammers using legitimate ISP's? david - Internet Dental Forum www.internetdentalforum.org Dentalcast Podcast www.dentalcast.net --- 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 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] SPFPass - good or bad?
Hi David - I like the spfpass test - coupled with filters it does help aginst false positives. [I prepend all my tests with the test type - thanks Kami! - it makes these filters easier to write -] Here is my spfgood filter - I score it with a -12: SKIPIFWEIGHT26 TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS TESTSFAILEDENDCONTAINSIP4R. TESTSFAILEDENDCONTAINSDNSBL. TESTSFAILEDENDCONTAINSRHSBL. TESTSFAILEDENDCONTAINSSNIFFER.. TESTSFAILEDENDCONTAINSEXTERNAL. TESTSFAILEDENDCONTAINSIPFILE.HOSTS TESTSFAILEDENDCONTAINSIPFILE.NETWORK TESTSFAILEDENDCONTAINSIPFILE.SUSPICIOUS #if it gets to here it is is clean REMOTEIP0CONTAINS. Here is my spfmaybe combo filter which I score with a -3: SKIPIFWEIGHT26 TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS TESTSFAILEDENDCONTAINS.SBL TESTSFAILEDENDCONTAINS.XBL TESTSFAILEDENDCONTAINS.CBL TESTSFAILEDENDCONTAINS.MPL #if it gets to here it is not listed in dnsbl's I trust TESTSFAILED0CONTAINSIP4RW. [whitelist ip4r tests] TESTSFAILED0CONTAINSDNSBLW. [whitelist dnsbl tests] -Nick David Dodell wrote: I've noticed a bunch of spam with SPFPass grades that have negated the spam databases (I have SPFPass at -5) ... is anyone finding that SPFPass is working with spammers using legitimate ISP's? david - Internet Dental Forum www.internetdentalforum.org Dentalcast Podcast www.dentalcast.net --- 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 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 - iMail 7.x and Windows 2003
Orin Wells wrote on Thursday, September 08, 2005 1:15 AM: Regarding telnet - apparently there is a problem with windows 2003 and iMail. If my source is correct one can telnet into a Windows 2003 system running iMail (pick a version) on port 25 and get by the authentication. Again, my source told me that neither Micosoft nor Ipswitch has come up with a way to stop this. It appears only to be a problem on Windows 2003, not Windows 2000. This is FUD and is patently false. Telnetting on port 25 is not true telnet which runs on port 23. When you connect on port 25 you are connecting to an SMTP session just like any other SMTP server. It is not possible to bypass Authentication in this manner. If your source is trying to do this from your network, and you have your network in the relay mail for addresses list, then no authentication is necessary. The proper way to test this would be to make the attempt from an outside network. If you have your relay settings set to anything other than No mail relay or relay for addresses, then no authentication is necessary from any network and you ARE an open relay. Your source has his facts wrong. The OS (windows 2003/2000) has nothing to do with Imail's SMTP service and whether it requires auth. Dan Horne --- 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] SPFPass - good or bad?
David, Since the start of SPF I have seen a steady adoption of SPF by spammers. Their really is nothing that stops them from using it. My suggestion is not applying negative weight for SPFPASS. Darrell --- invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default configuration. Download a copy today - http://www.invariantsystems.com - Original Message - From: David Dodell [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Thursday, September 08, 2005 1:28 AM Subject: [Declude.JunkMail] SPFPass - good or bad? I've noticed a bunch of spam with SPFPass grades that have negated the spam databases (I have SPFPass at -5) ... is anyone finding that SPFPass is working with spammers using legitimate ISP's? david - Internet Dental Forum www.internetdentalforum.org Dentalcast Podcast www.dentalcast.net --- 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 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] SPFPass - good or bad?
Be careful of using spfpass. Spammers can use SPF, too! We do not give any credit for passing SPF, only a penalty for failing which too many email admins set up but allow their networks to send email from machines not listed in their SPF record :(. Darin. - Original Message - From: Nick Hayer [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 8:40 AM Subject: Re: [Declude.JunkMail] SPFPass - good or bad? Hi David - I like the spfpass test - coupled with filters it does help aginst false positives. [I prepend all my tests with the test type - thanks Kami! - it makes these filters easier to write -] Here is my spfgood filter - I score it with a -12: SKIPIFWEIGHT26 TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS TESTSFAILEDENDCONTAINSIP4R. TESTSFAILEDENDCONTAINSDNSBL. TESTSFAILEDENDCONTAINSRHSBL. TESTSFAILEDENDCONTAINSSNIFFER.. TESTSFAILEDENDCONTAINSEXTERNAL. TESTSFAILEDENDCONTAINSIPFILE.HOSTS TESTSFAILEDENDCONTAINSIPFILE.NETWORK TESTSFAILEDENDCONTAINSIPFILE.SUSPICIOUS #if it gets to here it is is clean REMOTEIP0CONTAINS. Here is my spfmaybe combo filter which I score with a -3: SKIPIFWEIGHT26 TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS TESTSFAILEDENDCONTAINS.SBL TESTSFAILEDENDCONTAINS.XBL TESTSFAILEDENDCONTAINS.CBL TESTSFAILEDENDCONTAINS.MPL #if it gets to here it is not listed in dnsbl's I trust TESTSFAILED0CONTAINSIP4RW. [whitelist ip4r tests] TESTSFAILED0CONTAINSDNSBLW. [whitelist dnsbl tests] -Nick David Dodell wrote: I've noticed a bunch of spam with SPFPass grades that have negated the spam databases (I have SPFPass at -5) ... is anyone finding that SPFPass is working with spammers using legitimate ISP's? david - Internet Dental Forum www.internetdentalforum.org Dentalcast Podcast www.dentalcast.net --- 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 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 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] SPFPass - good or bad?
Looking at the last 80.000 messages on our Mailserver SPFPASS has had a positive result on 11% Following the final weight after all spam tests 7 from this 11% was right. The other 4% was a wrong result. SPFFAIL will only catch around 1% of all processed messages. Nearly all of the catched right as spam. Only 0.12% has had a wrong result. Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Dodell Sent: Thursday, September 08, 2005 7:28 AM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPFPass - good or bad? I've noticed a bunch of spam with SPFPass grades that have negated the spam databases (I have SPFPass at -5) ... is anyone finding that SPFPass is working with spammers using legitimate ISP's? david - Internet Dental Forum www.internetdentalforum.org Dentalcast Podcast www.dentalcast.net --- 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 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 - iMail 7.x and Windows 2003
One other thing to add to this. Ipswitch in their brilliance, decided to make a default password of "password" for any newly created account including root. One must take great care to change these otherwise they can become susceptible to AUTH hacking with a great deal of ease, and you then become essentially an open relay even though you are configured not to be. Matt Dan Horne wrote: Orin Wells wrote on Thursday, September 08, 2005 1:15 AM: Regarding telnet - apparently there is a problem with windows 2003 and iMail. If my source is correct one can telnet into a Windows 2003 system running iMail (pick a version) on port 25 and get by the authentication. Again, my source told me that neither Micosoft nor Ipswitch has come up with a way to stop this. It appears only to be a problem on Windows 2003, not Windows 2000. This is FUD and is patently false. Telnetting on port 25 is not true "telnet" which runs on port 23. When you connect on port 25 you are connecting to an SMTP session just like any other SMTP server. It is not possible to bypass Authentication in this manner. If your source is trying to do this from your network, and you have your network in the "relay mail for addresses" list, then no authentication is necessary. The proper way to test this would be to make the attempt from an outside network. If you have your relay settings set to anything other than "No mail relay" or "relay for addresses", then no authentication is necessary from any network and you ARE an open relay. Your source has his facts wrong. The OS (windows 2003/2000) has nothing to do with Imail's SMTP service and whether it requires auth. Dan Horne --- 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 - iMail 7.x and Windows 2003
Orin Wells wrote: OK, I see it. The question is how do you KILL the stuff that has gotten into the server? We shut down the IMAP yesterday primarily because we really don't have anyone we are aware of who does not use POP3. But the problem persists and seems to avoid every attempt to find it. I see a lot of code on the examples of how they are using the exploit. I am afraid it does not mean a lot to me and my brain is too tired to try to make any sense of this and figure out how to catch it. Surely someone has found a solution. They *have* to connect to a network port. If you can't find the port that shouldn't be open using something like Foundstone's Vision (http://www.foundstone.com/index.htm?subnav=resources/navigation.htmsubcontent=/resources/proddesc/vision.htm) ... watch wrap .. Then the only option you have is to setup a packet capture like ethereal (http://www.ethereal.com/) and looking at the raw data. My guess is they have been able to plant something they are now using against us. According to the tech if he disconnects the server from the network, the problem stops. It is only when the cable is hooked up that it starts in again. They've definitely installed a root kit. Windows root kit's are become obscenely popular. Your only option is to capture the raw data with ethereal if it's a good root kit. I suppose if it is coming in on a specific IP address we could disconnect them all and then add them back one at a time until we find the one they are coming in on, but that sounds like a LOT of work. Is there some other way to find this? Right now we have a lot of unhappy clients. If you block their IP, they will just come in on another IP. You must find the program and get rid of it, or rebuild... If I can be of any more assistance, let me know. Thanks, Russ --- [This E-mail scanned for viruses by Declude Virus] --- 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 - iMail 7.x and Windows 2003
I have seen some root kits be able to hide from tools like F-Port and such. As you have suggested using a packet capture tool usually always helps identify which port they are exploiting. However, with that said the one thing that I keep as a golden rule is once a box has been comprimised is that its going to be scratched. You just never know what else the left on the machine. Darrell --- DLAnalyzer - Comprehensive reporting on Declude Junkmail and Virus. Download it today - http://www.invariantsystems.com - Original Message - From: Russ Lists [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 9:24 AM Subject: Re: [Declude.JunkMail] OT - iMail 7.x and Windows 2003 Orin Wells wrote: OK, I see it. The question is how do you KILL the stuff that has gotten into the server? We shut down the IMAP yesterday primarily because we really don't have anyone we are aware of who does not use POP3. But the problem persists and seems to avoid every attempt to find it. I see a lot of code on the examples of how they are using the exploit. I am afraid it does not mean a lot to me and my brain is too tired to try to make any sense of this and figure out how to catch it. Surely someone has found a solution. They *have* to connect to a network port. If you can't find the port that shouldn't be open using something like Foundstone's Vision (http://www.foundstone.com/index.htm?subnav=resources/navigation.htmsubcontent=/resources/proddesc/vision.htm) ... watch wrap .. Then the only option you have is to setup a packet capture like ethereal (http://www.ethereal.com/) and looking at the raw data. My guess is they have been able to plant something they are now using against us. According to the tech if he disconnects the server from the network, the problem stops. It is only when the cable is hooked up that it starts in again. They've definitely installed a root kit. Windows root kit's are become obscenely popular. Your only option is to capture the raw data with ethereal if it's a good root kit. I suppose if it is coming in on a specific IP address we could disconnect them all and then add them back one at a time until we find the one they are coming in on, but that sounds like a LOT of work. Is there some other way to find this? Right now we have a lot of unhappy clients. If you block their IP, they will just come in on another IP. You must find the program and get rid of it, or rebuild... If I can be of any more assistance, let me know. Thanks, Russ --- [This E-mail scanned for viruses by Declude Virus] --- 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 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] SPFPass - good or bad?
On 09:01 AM 9/8/2005 -0400, it would appear that Darin Cox wrote: Be careful of using spfpass. Spammers can use SPF, too! We do not give any credit for passing SPF, only a penalty for failing which too many email admins set up but allow their networks to send email from machines not listed in their SPF record :(. Darin. Personally, I find SPF to be worthless in all cases. To begin with, the only SPAM it could halt (in a perfect setup) is SPAM sent through unauthorized servers. As already noted, SPAM can be sent legitimately from a server using SPF. Also, current best practices break SPF. The current wisdom is to block outgoing port 25 and force the clients to only send mail through the local mail server. That sounds good on the surface but such a practice and SPF cannot live together. Example: Employer QRS.com has a beautiful SPF record, clean SPAM record and encourages their employees to telecommute. John, a QRS.com employee, is working from home today and needs to send some updated information to one of QRS.com's customer. John's ISP (ISPXYZ) blocks outbound 25 and forces its clients to send all email through the ISPXYZ mail server. John, not wanting to confuse his customers by sending the information via his ISPXYZ account, uses SMTP Auth and sends his email using his @QRS.com address via the IXPXYZ server. That message, which is completely legitimate AND which follows all current best practices, will fail any SPF test. True, John could request that ISPXYZ be added to the QRS.com SPF record but do you really want to keep track of every mail server that your employees may have legitimate cause to use in sending mail from your domain? I know I don't and we have only a small number of employees and would only have to deal with this while employees are out of town attending conferences or training. The only way SPF could be used reliably is if A) port 25 were thrown wide open again and B) mail servers were reconfigured to ONLY send mail for their own domain. Then in the above scenario, John sends his QRS.com mail from home via the QRS.com mail server and both QRS.com's and ISPXYZ's mail servers would refuse to send mail for any domain but their own. Then all QRS.com's mail would pass SPF and all the mail that ISPXYZ's server sends would also pass SPF. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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] SPFPass - good or bad?
John, not wanting to confuse his customers by sending the information via his ISPXYZ account, uses SMTP Auth and sends his email using his @QRS.com address via the IXPXYZ server. That would not be wise. Instead, he'll use SMTP AUTH on port 587 to send his mail using the @QRS.com address via the QRS.com mail server. Declude WHITELIST AUTH takes priority over SPF and Imail 8.2x is capable of answering on more than one port (e.g., 587). I've been an early adopter of SPF, running it for quick a long time and don't have any problem with my own customers failing SPF. SPFPASS has to be used with care, I agree. If spammers use SPFPASS then their SPF record makes it easy for us to block all their permitted IP addresses, since they are committing themselves to those. I think it's a good idea to first check the IP blacklists and NOT give credit for SPFPASS unless the IP blacklists come back clean. In essence, you are giving SPFPASS credit only to counteract some other tests (such as content and header checking). (One could even go a step further and check multiple trusted blacklist sources - if an IP is listed in several, the SPFPASS could be used to ADD weight - but that's just a theory.) Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tyran Ormond Sent: Thursday, September 08, 2005 09:59 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPFPass - good or bad? On 09:01 AM 9/8/2005 -0400, it would appear that Darin Cox wrote: Be careful of using spfpass. Spammers can use SPF, too! We do not give any credit for passing SPF, only a penalty for failing which too many email admins set up but allow their networks to send email from machines not listed in their SPF record :(. Darin. Personally, I find SPF to be worthless in all cases. To begin with, the only SPAM it could halt (in a perfect setup) is SPAM sent through unauthorized servers. As already noted, SPAM can be sent legitimately from a server using SPF. Also, current best practices break SPF. The current wisdom is to block outgoing port 25 and force the clients to only send mail through the local mail server. That sounds good on the surface but such a practice and SPF cannot live together. Example: Employer QRS.com has a beautiful SPF record, clean SPAM record and encourages their employees to telecommute. John, a QRS.com employee, is working from home today and needs to send some updated information to one of QRS.com's customer. John's ISP (ISPXYZ) blocks outbound 25 and forces its clients to send all email through the ISPXYZ mail server. John, not wanting to confuse his customers by sending the information via his ISPXYZ account, uses SMTP Auth and sends his email using his @QRS.com address via the IXPXYZ server. That message, which is completely legitimate AND which follows all current best practices, will fail any SPF test. True, John could request that ISPXYZ be added to the QRS.com SPF record but do you really want to keep track of every mail server that your employees may have legitimate cause to use in sending mail from your domain? I know I don't and we have only a small number of employees and would only have to deal with this while employees are out of town attending conferences or training. The only way SPF could be used reliably is if A) port 25 were thrown wide open again and B) mail servers were reconfigured to ONLY send mail for their own domain. Then in the above scenario, John sends his QRS.com mail from home via the QRS.com mail server and both QRS.com's and ISPXYZ's mail servers would refuse to send mail for any domain but their own. Then all QRS.com's mail would pass SPF and all the mail that ISPXYZ's server sends would also pass SPF. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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 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] SPFPass - good or bad?
Not true. We find SPF to be extremely useful in stopping spoofing from domains we host, and there really is no reason for anyone to fail SPF... when it happens it's the result of poor management on the part of the mail admins. Regarding the situation you outlined, SPF can be easily configured to specify the server that mail is forced through as the sending server. SPF records can also be designed to inherit other SPF records, so if an ISP has SPF defined, then customers who manage their own SPF records can specify to inherit the ISPs SPF record, thus avoiding having to know and specify all of the ISPs sending servers. So, the example you gave is incomplete and can easily be handled by SPF. Darin. - Original Message - From: Tyran Ormond [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 9:58 AM Subject: Re: [Declude.JunkMail] SPFPass - good or bad? On 09:01 AM 9/8/2005 -0400, it would appear that Darin Cox wrote: Be careful of using spfpass. Spammers can use SPF, too! We do not give any credit for passing SPF, only a penalty for failing which too many email admins set up but allow their networks to send email from machines not listed in their SPF record :(. Darin. Personally, I find SPF to be worthless in all cases. To begin with, the only SPAM it could halt (in a perfect setup) is SPAM sent through unauthorized servers. As already noted, SPAM can be sent legitimately from a server using SPF. Also, current best practices break SPF. The current wisdom is to block outgoing port 25 and force the clients to only send mail through the local mail server. That sounds good on the surface but such a practice and SPF cannot live together. Example: Employer QRS.com has a beautiful SPF record, clean SPAM record and encourages their employees to telecommute. John, a QRS.com employee, is working from home today and needs to send some updated information to one of QRS.com's customer. John's ISP (ISPXYZ) blocks outbound 25 and forces its clients to send all email through the ISPXYZ mail server. John, not wanting to confuse his customers by sending the information via his ISPXYZ account, uses SMTP Auth and sends his email using his @QRS.com address via the IXPXYZ server. That message, which is completely legitimate AND which follows all current best practices, will fail any SPF test. True, John could request that ISPXYZ be added to the QRS.com SPF record but do you really want to keep track of every mail server that your employees may have legitimate cause to use in sending mail from your domain? I know I don't and we have only a small number of employees and would only have to deal with this while employees are out of town attending conferences or training. The only way SPF could be used reliably is if A) port 25 were thrown wide open again and B) mail servers were reconfigured to ONLY send mail for their own domain. Then in the above scenario, John sends his QRS.com mail from home via the QRS.com mail server and both QRS.com's and ISPXYZ's mail servers would refuse to send mail for any domain but their own. Then all QRS.com's mail would pass SPF and all the mail that ISPXYZ's server sends would also pass SPF. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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 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] SPFPass - good or bad?
On 10:32 AM 9/8/2005 -0400, it would appear that Darin Cox wrote: Regarding the situation you outlined, SPF can be easily configured to specify the server that mail is forced through as the sending server. SPF records can also be designed to inherit other SPF records, so if an ISP has SPF defined, then customers who manage their own SPF records can specify to inherit the ISPs SPF record, thus avoiding having to know and specify all of the ISPs sending servers. That still means that I have to setup includes for each of the possible sending domains, still unacceptable and reason enough for me to discard SPF completely. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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] Is there any hope running Declude with imail8.21???
Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude. Thanks -- Original Message -- From: R. Scott Perry [EMAIL PROTECTED] Reply-To: Declude.JunkMail@declude.com Date: Wed, 07 Sep 2005 19:28:41 -0400 I gave up and downgraded to 8.15 now I'm getting: 09:07 15:08 SMTPD(CP) error 3 executing c:\imail\Declude.exe D:\IMAIL\spool\Q3ab90041008c0e76.SMD It looks like you set up Declude to run in C:\IMail, but you run IMail on D:\IMail. :) -Scott --- 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. __ __ __ __ Sent via the CMS Internet Webmail system at mail1.cmsinter.net --- 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] SPFPass - good or bad?
You have to set up an SPF record for each of the domains anyway, since the SPF record resides in the DNS of the sending domain, so I don't see that it's a big deal. Bottom line: It's a useful tool. Not as useful as originally intended, but still useful. Use it or don't at your discretion. Darin. - Original Message - From: Tyran Ormond [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:09 AM Subject: Re: [Declude.JunkMail] SPFPass - good or bad? On 10:32 AM 9/8/2005 -0400, it would appear that Darin Cox wrote: Regarding the situation you outlined, SPF can be easily configured to specify the server that mail is forced through as the sending server. SPF records can also be designed to inherit other SPF records, so if an ISP has SPF defined, then customers who manage their own SPF records can specify to inherit the ISPs SPF record, thus avoiding having to know and specify all of the ISPs sending servers. That still means that I have to setup includes for each of the possible sending domains, still unacceptable and reason enough for me to discard SPF completely. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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 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] How to credit a domain
Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail). - Received: from mx.dstsystems.com [204.167.177.68] by mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A records [0301]. X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68] X-Note: Reverse DNS: Sent from dstsys-cp.dstsystems.com ([204.167.177.68]). X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0], SIZE-S [0] - So this mail came from domain dstsystems.com on the IP 204.167.177.68 but it is from domain ifdsgroup.com. Now my preferred method of dealing with this type of problem is to credit based on REVDNS. Again in this case there is a good REVDNS but it is not from the same domain as the MAILFROM (if it was then I would have no problem in crediting the REVDNS). So is there a way to figure out if dstsystems.com is a e-mail hosting company and then I would not want to credit the REVDNS as I do not know what other domains they host. If I cannot figure out the link then I would not credit REVDNS and would move to step 2. Credit HELO. HELOs can be spoofed but in this case the HELO is basically the same as the REVDNS. Next step is crediting MAILFROM. This I can do with the ifdsgroup.com and lower the score for e-mail from this domain. Again it can be spoofed but ... I would prefer to credit REVDNS as that cannot be spoofed but I am leery of crediting an unknown domain when it does not relate to the MAILFROM address. Any thoughts on how (if possible) to connect the two domains? Or do I simply drop down to option 3 and credit MAILFROM? I suppose that I could try and figure out the admin responsible for dstsystems.com and tell them to fix the HELOBOGUS error in which case my problems would (mostly) go away. Any thoughts and comments are appreciated. Thanks Goran Jovanovic The LAN Shoppe --- 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 - Missing the Point
still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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 - Missing the Point
That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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 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] How to credit a domain
Goran, I have consistently found that providers that handle mail for other companies are reliable enough that I can merely counterweight their IP. I hardly ever trust their reverse DNS, and even less often the HELO. I have a last resort test where I have a mixed bag of counterweights. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, September 08, 2005 8:33 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] How to credit a domain Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail). -- -- - Received: from mx.dstsystems.com [204.167.177.68] by mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A records [0301]. X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68] X-Note: Reverse DNS: Sent from dstsys-cp.dstsystems.com ([204.167.177.68]). X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0], SIZE-S [0] -- -- - So this mail came from domain dstsystems.com on the IP 204.167.177.68 but it is from domain ifdsgroup.com. Now my preferred method of dealing with this type of problem is to credit based on REVDNS. Again in this case there is a good REVDNS but it is not from the same domain as the MAILFROM (if it was then I would have no problem in crediting the REVDNS). So is there a way to figure out if dstsystems.com is a e-mail hosting company and then I would not want to credit the REVDNS as I do not know what other domains they host. If I cannot figure out the link then I would not credit REVDNS and would move to step 2. Credit HELO. HELOs can be spoofed but in this case the HELO is basically the same as the REVDNS. Next step is crediting MAILFROM. This I can do with the ifdsgroup.com and lower the score for e-mail from this domain. Again it can be spoofed but ... I would prefer to credit REVDNS as that cannot be spoofed but I am leery of crediting an unknown domain when it does not relate to the MAILFROM address. Any thoughts on how (if possible) to connect the two domains? Or do I simply drop down to option 3 and credit MAILFROM? I suppose that I could try and figure out the admin responsible for dstsystems.com and tell them to fix the HELOBOGUS error in which case my problems would (mostly) go away. Any thoughts and comments are appreciated. Thanks Goran Jovanovic The LAN Shoppe --- 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 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] Server Running at 100%
I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Richard Farris To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet"
Re: [Declude.JunkMail] Server Running at 100%
It goes in the virus.cfg file and the option is "AVAFTERJM ON". Is your CPU running at 100% due to high load of incoming mail? Anything else you can tell us what is going on? Any patterns in the logs? Darrell ---Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: Richard Farris To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:55 AM Subject: [Declude.JunkMail] Server Running at 100% I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Richard Farris To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet"
RE: [Declude.JunkMail] Server Running at 100%
In your virus.cfg file: AVAFTERJM ON Also ensure that you have the directive: PRESCANON David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris Sent: Thursday, September 08, 2005 11:56 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Server Running at 100% Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: Richard Farris mailto:[EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet --- 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] Is there any hope running Declude with imail8.21???
So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude. The beta seems decent, but their are some issues with multiprocessor machines right now. Essentially it would go to sleep at the wrong times and due to sleeping so much it could never really keep up with my volume. However, in terms of stability it worked very well no issues with major functionality. Darrell--- Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Thanks -- Original Message -- From: R. Scott Perry [EMAIL PROTECTED] Reply-To: Declude.JunkMail@declude.com Date: Wed, 07 Sep 2005 19:28:41 -0400 I gave up and downgraded to 8.15 now I'm getting: 09:07 15:08 SMTPD(CP) error 3 executing c:\imail\Declude.exe D:\IMAIL\spool\Q3ab90041008c0e76.SMD It looks like you set up Declude to run in C:\IMail, but you run IMail on D:\IMail. :) -Scott --- 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. __ __ __ __ Sent via the CMS Internet Webmail system at mail1.cmsinter.net --- 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 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] Server Running at 100%
Put: AVAFTERJM ON with a blank line after it in your virus.cfg this has pros and cons that have been discussed over and over again on this list and the virus list, so the archives will be a rich vein to mine, no need to go over it all again. However, Richard, I don't think you've answered WHAT process is taking your cpu time to 100%. Is it multiple instances of declude.exe, is it your antivirus program, or what? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard FarrisSent: Thursday, September 08, 2005 8:56 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server Running at 100%Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Richard Farris To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet"
Re: [Declude.JunkMail] Server Running at 100%
PRESCAN is not in the virus.cfg file...just put it in there? Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: David Barker [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:00 AM Subject: RE: [Declude.JunkMail] Server Running at 100% In your virus.cfg file: AVAFTERJM ON Also ensure that you have the directive: PRESCANON David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris Sent: Thursday, September 08, 2005 11:56 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Server Running at 100% Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: Richard Farris mailto:[EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet --- 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 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] Server Running at 100%
Yes - but with the option ON. PRESCAN ON Darrell --- Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: Richard Farris [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 12:08 PM Subject: Re: [Declude.JunkMail] Server Running at 100% PRESCAN is not in the virus.cfg file...just put it in there? Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: David Barker [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:00 AM Subject: RE: [Declude.JunkMail] Server Running at 100% In your virus.cfg file: AVAFTERJM ON Also ensure that you have the directive: PRESCANON David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris Sent: Thursday, September 08, 2005 11:56 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Server Running at 100% Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: Richard Farris mailto:[EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet --- 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 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 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 - iMail 7.x and Windows 2003
I don't see that as a big issue. They can't Auth when 'Account Access Disabled' is checked in the user gui. If the user has a POP box, uncheck 'Account Access Disabled' and use their unique password. If the user is for forwarding, then make sure that 'Account Access Disabled' is checked. They can't Auth, so they can't send. Thursday, September 8, 2005, 8:15:20 AM, Matt [EMAIL PROTECTED] wrote: M M One other thing to add to this. Ipswitch in their brilliance, M decided to make a default password of password for any newly M created account including root. One must take great care to change M these otherwise they can become susceptible to AUTH hacking with a M great deal of ease, and you then become essentially an open relay M even though you are configured not to be. M M Matt M M M M Dan Horne wrote: M M Orin Wells wrote on Thursday, September 08, 2005 1:15 AM: M M M Regarding telnet - apparently there is a problem with windows 2003 M and iMail. If my source is correct one can telnet into a Windows M 2003 system running iMail (pick a version) on port 25 and get by the M authentication. Again, my source told me that neither Micosoft nor M Ipswitch has come up with a way to stop this. It appears only to be M a problem on Windows 2003, not Windows 2000. M M M This is FUD and is patently false. Telnetting on port 25 is not true M telnet which runs on port 23. When you connect on port 25 you are M connecting to an SMTP session just like any other SMTP server. It is M not possible to bypass Authentication in this manner. If your source is M trying to do this from your network, and you have your network in the M relay mail for addresses list, then no authentication is necessary. M The proper way to test this would be to make the attempt from an outside M network. If you have your relay settings set to anything other than No M mail relay or relay for addresses, then no authentication is M necessary from any network and you ARE an open relay. Your source has M his facts wrong. The OS (windows 2003/2000) has nothing to do with M Imail's SMTP service and whether it requires auth. M Dan Horne M --- M This E-mail came from the Declude.JunkMail mailing list. To M unsubscribe, just send an E-mail to [EMAIL PROTECTED], and M type unsubscribe Declude.JunkMail. The archives can be found M at http://www.mail-archive.com. M M M Don Brown - Dallas, Texas USA Internet Concepts, Inc. [EMAIL PROTECTED] http://www.inetconcepts.net (972) 788-2364Fax: (972) 788-5049 --- 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] Server Running at 100%
It looks like sniffer and fprot...when I turn off sniffer things look normal but thena lot of spam comes thru too...so I can not afford to do thatI think it is just the shear volume of spam hitting my server constantly and the server can't keep caught up.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Colbeck, Andrew To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:03 AM Subject: RE: [Declude.JunkMail] Server Running at 100% Put: AVAFTERJM ON with a blank line after it in your virus.cfg this has pros and cons that have been discussed over and over again on this list and the virus list, so the archives will be a rich vein to mine, no need to go over it all again. However, Richard, I don't think you've answered WHAT process is taking your cpu time to 100%. Is it multiple instances of declude.exe, is it your antivirus program, or what? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard FarrisSent: Thursday, September 08, 2005 8:56 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server Running at 100%Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Richard Farris To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet"
Re: [Declude.JunkMail] How to credit a domain
I've struggled also what I call the technical tests (helobogus, badheaders, cmdspace, spamheaders). They indicate to me that something is technically wrong with an email, but really don't indicate that the email's content is spam. More likely to be spam yes. Solidly spam, no. The bad news for me is they seem to tend to fire together in groups on poorly configured mail servers dragging tho weight of those emails up. Over time, I've adjusted the scores of these tests downward. helobogus: I weight 10 on a subject tag at 100. It is positive on 11% of my total email. It is a false positive on 6% of my total email. Wrong 6% of the time! badheaders: I weight at 30 on a subject tag scale at 100. It is positive on 14% of my total email. It is a false positive on 1% of my total email. spamheaders: I weight at 40 on a subject tag scale at 100. It is positive on 18% of my total email. It is a false positive on 2% of my total email. cmdspace: I weight at 40 on a subject tag scale at 100. It is positive on 28% of my total email. It is a false positive on 1% of my total email. This test is effective and I use this in combo with sniffer and uribl tests to drag middle weighted spam to a higher weight. I've contemplated putting these together in a technical test filter where I could apply a maxweight. - Original Message - From: Goran Jovanovic [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 10:32 AM Subject: [Declude.JunkMail] How to credit a domain Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail). - Received: from mx.dstsystems.com [204.167.177.68] by mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A records [0301]. X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68] X-Note: Reverse DNS: Sent from dstsys-cp.dstsystems.com ([204.167.177.68]). X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0], SIZE-S [0] - So this mail came from domain dstsystems.com on the IP 204.167.177.68 but it is from domain ifdsgroup.com. Now my preferred method of dealing with this type of problem is to credit based on REVDNS. Again in this case there is a good REVDNS but it is not from the same domain as the MAILFROM (if it was then I would have no problem in crediting the REVDNS). So is there a way to figure out if dstsystems.com is a e-mail hosting company and then I would not want to credit the REVDNS as I do not know what other domains they host. If I cannot figure out the link then I would not credit REVDNS and would move to step 2. Credit HELO. HELOs can be spoofed but in this case the HELO is basically the same as the REVDNS. Next step is crediting MAILFROM. This I can do with the ifdsgroup.com and lower the score for e-mail from this domain. Again it can be spoofed but ... I would prefer to credit REVDNS as that cannot be spoofed but I am leery of crediting an unknown domain when it does not relate to the MAILFROM address. Any thoughts on how (if possible) to connect the two domains? Or do I simply drop down to option 3 and credit MAILFROM? I suppose that I could try and figure out the admin responsible for dstsystems.com and tell them to fix the HELOBOGUS error in which case my problems would (mostly) go away. Any thoughts and comments are appreciated. Thanks Goran Jovanovic The LAN Shoppe --- 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 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] Is there any hope running Declude with imail8.21???
IMail 8.20+ is only compatible with Declude 3+, but that software is still in early beta and I wouldn't recommend it. This combination can work, but it appears that the higher the volume you have, the more likely you are to experience serious issues with E-mail backing up. I have been using IMail 8.15 HF2 for many months without any new issues, and it works very well with Declude 2.0.6.16 (the most recent interim release) which also doesn't have any new issues. The newer Declude 3.0 that is in beta is basically the same in terms of functionality, but it is changed to act as a service in order to resolve issues with the changes in IMail 8.20+ and also increase performance slightly. This is a big change for Declude, and building a service to handle E-mail reliably isn't a small feat so I would suggest being patient in the mean time. Matt Timothy Bohen wrote: Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude. Thanks -- Original Message -- From: "R. Scott Perry" [EMAIL PROTECTED] Reply-To: Declude.JunkMail@declude.com Date: Wed, 07 Sep 2005 19:28:41 -0400 I gave up and downgraded to 8.15 now I'm getting: 09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" "D:\IMAIL\spool\Q3ab90041008c0e76.SMD" It looks like you set up Declude to run in C:\IMail, but you run IMail on D:\IMail. :) -Scott --- 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. __ __ __ __ Sent via the CMS Internet Webmail system at mail1.cmsinter.net --- 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] Server Running at 100%
Yes, just put it in there. I also think that it requires the PRO version to work ? Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris Sent: Thursday, September 08, 2005 10:08 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Server Running at 100% PRESCAN is not in the virus.cfg file...just put it in there? Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: David Barker [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:00 AM Subject: RE: [Declude.JunkMail] Server Running at 100% In your virus.cfg file: AVAFTERJM ON Also ensure that you have the directive: PRESCANON David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris Sent: Thursday, September 08, 2005 11:56 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Server Running at 100% Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: Richard Farris mailto:[EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet --- 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 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 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 - Missing the Point
Excellent point, Andy. Not just detecting spoofing, but changing behavior to avoid future spoofing. Darin. - Original Message - From: Andy Schmidt [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:47 AM Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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 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] Server Running at 100%
After doing this my server looks more normal...up and down instead of constant 100% then drop for a couple seconds then back to 100%..I will check the archives and monitor to see if I am screwing up here.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Colbeck, Andrew To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:03 AM Subject: RE: [Declude.JunkMail] Server Running at 100% Put: AVAFTERJM ON with a blank line after it in your virus.cfg this has pros and cons that have been discussed over and over again on this list and the virus list, so the archives will be a rich vein to mine, no need to go over it all again. However, Richard, I don't think you've answered WHAT process is taking your cpu time to 100%. Is it multiple instances of declude.exe, is it your antivirus program, or what? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard FarrisSent: Thursday, September 08, 2005 8:56 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server Running at 100%Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Richard Farris To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet"
RE: [Declude.JunkMail] How to credit a domain
Andrew, Why would you counterweight their IP and not the REVDNS? It seems that it is basically the same thing? Goran Jovanovic The LAN Shoppe -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, September 08, 2005 11:52 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] How to credit a domain Goran, I have consistently found that providers that handle mail for other companies are reliable enough that I can merely counterweight their IP. I hardly ever trust their reverse DNS, and even less often the HELO. I have a last resort test where I have a mixed bag of counterweights. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, September 08, 2005 8:33 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] How to credit a domain Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail). -- -- - Received: from mx.dstsystems.com [204.167.177.68] by mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A records [0301]. X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68] X-Note: Reverse DNS: Sent from dstsys-cp.dstsystems.com ([204.167.177.68]). X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0], SIZE-S [0] -- -- - So this mail came from domain dstsystems.com on the IP 204.167.177.68 but it is from domain ifdsgroup.com. Now my preferred method of dealing with this type of problem is to credit based on REVDNS. Again in this case there is a good REVDNS but it is not from the same domain as the MAILFROM (if it was then I would have no problem in crediting the REVDNS). So is there a way to figure out if dstsystems.com is a e-mail hosting company and then I would not want to credit the REVDNS as I do not know what other domains they host. If I cannot figure out the link then I would not credit REVDNS and would move to step 2. Credit HELO. HELOs can be spoofed but in this case the HELO is basically the same as the REVDNS. Next step is crediting MAILFROM. This I can do with the ifdsgroup.com and lower the score for e-mail from this domain. Again it can be spoofed but ... I would prefer to credit REVDNS as that cannot be spoofed but I am leery of crediting an unknown domain when it does not relate to the MAILFROM address. Any thoughts on how (if possible) to connect the two domains? Or do I simply drop down to option 3 and credit MAILFROM? I suppose that I could try and figure out the admin responsible for dstsystems.com and tell them to fix the HELOBOGUS error in which case my problems would (mostly) go away. Any thoughts and comments are appreciated. Thanks Goran Jovanovic The LAN Shoppe --- 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 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 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] Server Running at 100%
Did you get my reply in the Message Sniffer support list about rotating your log file? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard FarrisSent: Thursday, September 08, 2005 9:15 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Server Running at 100% It looks like sniffer and fprot...when I turn off sniffer things look normal but thena lot of spam comes thru too...so I can not afford to do thatI think it is just the shear volume of spam hitting my server constantly and the server can't keep caught up.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Colbeck, Andrew To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:03 AM Subject: RE: [Declude.JunkMail] Server Running at 100% Put: AVAFTERJM ON with a blank line after it in your virus.cfg this has pros and cons that have been discussed over and over again on this list and the virus list, so the archives will be a rich vein to mine, no need to go over it all again. However, Richard, I don't think you've answered WHAT process is taking your cpu time to 100%. Is it multiple instances of declude.exe, is it your antivirus program, or what? Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard FarrisSent: Thursday, September 08, 2005 8:56 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server Running at 100%Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: Richard Farris To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet"
Re: [Declude.JunkMail] How to credit a domain
We maintain a filter file for many of the major tests, including REVDNS so we can credit domains or addresses that fail a specific test. This is a much narrower way to credit than a whitelist, as it only credits if the message failed the test to begin with. Darin. - Original Message - From: Goran Jovanovic [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 11:32 AM Subject: [Declude.JunkMail] How to credit a domain Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail). - Received: from mx.dstsystems.com [204.167.177.68] by mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A records [0301]. X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68] X-Note: Reverse DNS: Sent from dstsys-cp.dstsystems.com ([204.167.177.68]). X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0], SIZE-S [0] - So this mail came from domain dstsystems.com on the IP 204.167.177.68 but it is from domain ifdsgroup.com. Now my preferred method of dealing with this type of problem is to credit based on REVDNS. Again in this case there is a good REVDNS but it is not from the same domain as the MAILFROM (if it was then I would have no problem in crediting the REVDNS). So is there a way to figure out if dstsystems.com is a e-mail hosting company and then I would not want to credit the REVDNS as I do not know what other domains they host. If I cannot figure out the link then I would not credit REVDNS and would move to step 2. Credit HELO. HELOs can be spoofed but in this case the HELO is basically the same as the REVDNS. Next step is crediting MAILFROM. This I can do with the ifdsgroup.com and lower the score for e-mail from this domain. Again it can be spoofed but ... I would prefer to credit REVDNS as that cannot be spoofed but I am leery of crediting an unknown domain when it does not relate to the MAILFROM address. Any thoughts on how (if possible) to connect the two domains? Or do I simply drop down to option 3 and credit MAILFROM? I suppose that I could try and figure out the admin responsible for dstsystems.com and tell them to fix the HELOBOGUS error in which case my problems would (mostly) go away. Any thoughts and comments are appreciated. Thanks Goran Jovanovic The LAN Shoppe --- 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 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] SPFPass - good or bad?
Tyran Ormond wrote: That still means that I have to setup includes for each of the possible sending domains, still unacceptable and reason enough for me to discard SPF completely. Well be advised not all your mail will get delivered. I have some insurance agencies whose mail will bounce if I did not have valid spf recs for their domains. I know this because its happened. :) [The setup is kake; some dns programs can even synthesize spf recs for local domains. SimpleDns for one will ] -Nick Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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 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] How to credit a domain
One would suspect if they have PTR's setup for all their customer's IP's like other providers. Example: customer1-xx-xx-xx-xx.dtsystems.com This way you may not get killed by a customer IP infected with a trojan since you are only reverse weighting the mail server IP. Darrell --- Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From: Goran Jovanovic [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 12:21 PM Subject: RE: [Declude.JunkMail] How to credit a domain Andrew, Why would you counterweight their IP and not the REVDNS? It seems that it is basically the same thing? Goran Jovanovic The LAN Shoppe -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, September 08, 2005 11:52 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] How to credit a domain Goran, I have consistently found that providers that handle mail for other companies are reliable enough that I can merely counterweight their IP. I hardly ever trust their reverse DNS, and even less often the HELO. I have a last resort test where I have a mixed bag of counterweights. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, September 08, 2005 8:33 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] How to credit a domain Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail). -- -- - Received: from mx.dstsystems.com [204.167.177.68] by mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A records [0301]. X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68] X-Note: Reverse DNS: Sent from dstsys-cp.dstsystems.com ([204.167.177.68]). X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0], SIZE-S [0] -- -- - So this mail came from domain dstsystems.com on the IP 204.167.177.68 but it is from domain ifdsgroup.com. Now my preferred method of dealing with this type of problem is to credit based on REVDNS. Again in this case there is a good REVDNS but it is not from the same domain as the MAILFROM (if it was then I would have no problem in crediting the REVDNS). So is there a way to figure out if dstsystems.com is a e-mail hosting company and then I would not want to credit the REVDNS as I do not know what other domains they host. If I cannot figure out the link then I would not credit REVDNS and would move to step 2. Credit HELO. HELOs can be spoofed but in this case the HELO is basically the same as the REVDNS. Next step is crediting MAILFROM. This I can do with the ifdsgroup.com and lower the score for e-mail from this domain. Again it can be spoofed but ... I would prefer to credit REVDNS as that cannot be spoofed but I am leery of crediting an unknown domain when it does not relate to the MAILFROM address. Any thoughts on how (if possible) to connect the two domains? Or do I simply drop down to option 3 and credit MAILFROM? I suppose that I could try and figure out the admin responsible for dstsystems.com and tell them to fix the HELOBOGUS error in which case my problems would (mostly) go away. Any thoughts and comments are appreciated. Thanks Goran Jovanovic The LAN Shoppe --- 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 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 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 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] How to credit a domain
Hi, Goran. I like to counterweight based on their IP for a couple of reasons. The first is that if their administration is not up to par (so that I have to counterweight them), the odds are good that their revdns is flawed or that their DNS is subject to timeouts. I also find that, as a practical matter, a company is as likely to change their IP as their revdns so neither is more stable than the other. Third, a lot of the companies with this kind of problem also fail REVDNS anyway! Last, larger companies can sometimes easily be spotted in SenderBase.org as having all of their mailhosts on a small subnet and I can use a REMOTEIP CIDR mask. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, September 08, 2005 9:22 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] How to credit a domain Andrew, Why would you counterweight their IP and not the REVDNS? It seems that it is basically the same thing? Goran Jovanovic The LAN Shoppe -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, September 08, 2005 11:52 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] How to credit a domain Goran, I have consistently found that providers that handle mail for other companies are reliable enough that I can merely counterweight their IP. I hardly ever trust their reverse DNS, and even less often the HELO. I have a last resort test where I have a mixed bag of counterweights. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, September 08, 2005 8:33 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] How to credit a domain Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail). -- -- - Received: from mx.dstsystems.com [204.167.177.68] by mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A records [0301]. X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68] X-Note: Reverse DNS: Sent from dstsys-cp.dstsystems.com ([204.167.177.68]). X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0], SIZE-S [0] -- -- - So this mail came from domain dstsystems.com on the IP 204.167.177.68 but it is from domain ifdsgroup.com. Now my preferred method of dealing with this type of problem is to credit based on REVDNS. Again in this case there is a good REVDNS but it is not from the same domain as the MAILFROM (if it was then I would have no problem in crediting the REVDNS). So is there a way to figure out if dstsystems.com is a e-mail hosting company and then I would not want to credit the REVDNS as I do not know what other domains they host. If I cannot figure out the link then I would not credit REVDNS and would move to step 2. Credit HELO. HELOs can be spoofed but in this case the HELO is basically the same as the REVDNS. Next step is crediting MAILFROM. This I can do with the ifdsgroup.com and lower the score for e-mail from this domain. Again it can be spoofed but ... I would prefer to credit REVDNS as that cannot be spoofed but I am leery of crediting an unknown domain when it does not relate to the MAILFROM address. Any thoughts on how (if possible) to connect the two domains? Or do I simply drop down to option 3 and credit MAILFROM? I suppose that I could try and figure out the admin responsible for dstsystems.com and tell them to fix the HELOBOGUS error in which case my problems would (mostly) go away. Any thoughts and comments are appreciated. Thanks Goran Jovanovic The LAN Shoppe --- 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 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 came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives
RE: [Declude.JunkMail] SPF - Missing the Point
On 11:47 AM 9/8/2005 -0400, it would appear that Andy Schmidt wrote: still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude.. [snip] If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name. No, the effect is that if I define SPF (which I don't and won't as I'll explain) then I am forced to either write includes for Netzero, Xmission, Connect2 and every other ISP that my users (employees) use at home where they also write emails that legitimately use @cvwrf.org. If I use SPF and *don't* write those includes then I am forcing a FAIL when those users send mail through their home ISP using @cvwrf.org. If, however, I don't have any SPF record (which I don't) then at worst an SPF test is required to return a NONE/NEUTRAL. Some ISPs do reject on FAIL but I have yet to find one that rejects on a NONE/NEUTRAL because the RFC specifies that NONE/NEUTRAL should not be rejected out of hand. For example, SPFFAIL is *not* triggered if a domain has no SPF record. From the Junkmail manual: Note that it will not be triggered for E-mail that has other problems (no SPF record, unknown results from the SPF record, etc.). So any E-mail failing the SPFFAIL test is E-mail that is not authorized per the administrator of the domain the E-mail is being sent from. In short, I better ensure my that my users can send mail regardless of their location by not having any SPF record. That also means that I do no SPF checks on incoming mail, in my view it is simply too unreliable. Besides, my other Declude tests are already catching 97% of the SPAM we receive with only 0.03% of those messages caught being false positives. As to using port 587 as you suggested early Andy, we may do that eventually but currently 587 usage is still not widespread enough on the client side. Sure, I can *make* 587 work for nearly any client out there but that will break port 25 usage on many of those clients. Example: Any Eudora client older than 17 June 2005 can use *either* port 25 or port 587 for sending. Besides, I *really* don't want to make 73 house calls to get my users over to port 587. ;) Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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 - Missing the Point
Well, it's entirely up to you: Tell your users to send out through your server instead of their ISP(over port 587 if the ISP is blocking 25) or use the SPF neutral response instead of pass or fail. Yes, it requires a little work, but for us it has proven useful. I don't think anyone is saying it's perfect, but it can be implemented in a useful fashion. Darin. - Original Message - From: Tyran Ormond [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 12:39 PM Subject: RE: [Declude.JunkMail] SPF - Missing the Point On 11:47 AM 9/8/2005 -0400, it would appear that Andy Schmidt wrote: still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude.. [snip] If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name. No, the effect is that if I define SPF (which I don't and won't as I'll explain) then I am forced to either write includes for Netzero, Xmission, Connect2 and every other ISP that my users (employees) use at home where they also write emails that legitimately use @cvwrf.org. If I use SPF and *don't* write those includes then I am forcing a FAIL when those users send mail through their home ISP using @cvwrf.org. If, however, I don't have any SPF record (which I don't) then at worst an SPF test is required to return a NONE/NEUTRAL. Some ISPs do reject on FAIL but I have yet to find one that rejects on a NONE/NEUTRAL because the RFC specifies that NONE/NEUTRAL should not be rejected out of hand. For example, SPFFAIL is *not* triggered if a domain has no SPF record. From the Junkmail manual: Note that it will not be triggered for E-mail that has other problems (no SPF record, unknown results from the SPF record, etc.). So any E-mail failing the SPFFAIL test is E-mail that is not authorized per the administrator of the domain the E-mail is being sent from. In short, I better ensure my that my users can send mail regardless of their location by not having any SPF record. That also means that I do no SPF checks on incoming mail, in my view it is simply too unreliable. Besides, my other Declude tests are already catching 97% of the SPAM we receive with only 0.03% of those messages caught being false positives. As to using port 587 as you suggested early Andy, we may do that eventually but currently 587 usage is still not widespread enough on the client side. Sure, I can *make* 587 work for nearly any client out there but that will break port 25 usage on many of those clients. Example: Any Eudora client older than 17 June 2005 can use *either* port 25 or port 587 for sending. Besides, I *really* don't want to make 73 house calls to get my users over to port 587. ;) Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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 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] How to credit a domain
Good point. I wasn't thinking about the domain in question, only the practice, and didn't go so far as to mention that for ISP domains like this, we prefer to counterweight by MAILFROM on the exact email address rather than REVDNS. It's all about being as narrow as possible where there's room for abuse... Darin. - Original Message - From: Colbeck, Andrew [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 12:58 PM Subject: RE: [Declude.JunkMail] How to credit a domain Danger, Will Robinson! Danger! Darin, thank you pointing out that qualifying a domain name with a prepended period is a solid best practice, and I'll add that it is mandatory to get the expected results when one uses a SPAMDOMAINS test. However, this ComCast example is NOT a recommended action, as it will still have the flaw I cited earlier, i.e. that you would be counterweighting their mailhosts all right, but also all of the zombies on their highly infested cable subscriber network. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox Sent: Thursday, September 08, 2005 9:46 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] How to credit a domain Might want to make it REVDNS -100 ENDSWITH .ComCast.net instead of REVDNS -100 ENDSWITH ComCast.net (note the period before comcast.net) That way spamcomcast.net won't match when you don't want it to. Darin. - Original Message - From: Colbeck, Andrew [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 12:37 PM Subject: RE: [Declude.JunkMail] How to credit a domain Oop, there was one other thing. I try to avoid the temptation of counterweighting a fragment of their reverse DNS. For example, if there were a ComCast.net mailhost problem that I wanted to counterweight, it would be tempting to add: REVDNS -100 ENDSWITH ComCast.net Which would accomplish the goal, but that the same time as letting in a tidal wave of spam from zombies on their cable subscriber network! That all being said, I also have a very few Declude PRO filter text files that accomplish counterweighting for problematic domains that need help to get their mail through my setup, but whose complexity to keep the spam out preclude it from going in my mixed bag of counterweights. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, September 08, 2005 9:31 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] How to credit a domain Hi, Goran. I like to counterweight based on their IP for a couple of reasons. The first is that if their administration is not up to par (so that I have to counterweight them), the odds are good that their revdns is flawed or that their DNS is subject to timeouts. I also find that, as a practical matter, a company is as likely to change their IP as their revdns so neither is more stable than the other. Third, a lot of the companies with this kind of problem also fail REVDNS anyway! Last, larger companies can sometimes easily be spotted in SenderBase.org as having all of their mailhosts on a small subnet and I can use a REMOTEIP CIDR mask. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, September 08, 2005 9:22 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] How to credit a domain Andrew, Why would you counterweight their IP and not the REVDNS? It seems that it is basically the same thing? Goran Jovanovic The LAN Shoppe -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, September 08, 2005 11:52 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] How to credit a domain Goran, I have consistently found that providers that handle mail for other companies are reliable enough that I can merely counterweight their IP. I hardly ever trust their reverse DNS, and even less often the HELO. I have a last resort test where I have a mixed bag of counterweights. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, September 08, 2005 8:33 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] How to credit a domain Hi all, I get messages like this all the time and I am always in a dilemma on what to do about them. This is a legit mail that scored 10 (where I start tagging mail).
Re: [Declude.JunkMail] SPF - Missing the Point
But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately? I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic. I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me. Matt Colbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Thus, without question, SPF should be in place for all domains you control. Specially for alias/vanity/web-only domains that never send any email. Ideally, in addition, set up SMTP AUTH for your clients so that you can use SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 --- 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 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] Is there any hope running Declude with imail8.21???
Yes, we justtoday reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that our problems would not be related to the multi-processor sleep problems. It just doesn't seem able to handle the load that 1.82 does. And yes, we have increased our THREADS to 25. Also, they claim to have fixed a problem with leftover files, but after swapping out the Declude executable with 1.82 and leaving the Decludeproc service running, 24 files are still stranded in the "spool\proc\work" directory and there are 9 *.vir directories still in there (they are truly stranded, even the 24 files comprise 12 paired q and d files they are not being delivered for several hours with the Decludeproc service still running. I am going to have to move them back into the spool directory manually). The Decludeproc service has NOT stopped running at all in theseveral days it has been running, so I don't know why the files are stranded. I just tried restarting it to see if I could "wake it up", but it didn't give me any love. Looking at the dates, I see one q/d pair from Sep 2, several from Sep 7 and the2 pairfrom today. Each one of these represents a "lost" email. I opened afew and didn't find any of them to be spam. The one thing I can't abide is "lost" email, so I had to stop our beta test. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Thursday, September 08, 2005 12:11 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? IMail 8.20+ is only compatible with Declude 3+, but that software is still in early beta and I wouldn't recommend it. This combination can work, but it appears that the higher the volume you have, the more likely you are to experience serious issues with E-mail backing up. I have been using IMail 8.15 HF2 for many months without any new issues, and it works very well with Declude 2.0.6.16 (the most recent interim release) which also doesn't have any new issues. The newer Declude 3.0 that is in beta is basically the same in terms of functionality, but it is changed to act as a service in order to resolve issues with the changes in IMail 8.20+ and also increase performance slightly. This is a big change for Declude, and building a service to handle E-mail reliably isn't a small feat so I would suggest being patient in the mean time.MattTimothy Bohen wrote: Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude. Thanks -- Original Message -- From: "R. Scott Perry" [EMAIL PROTECTED] Reply-To: Declude.JunkMail@declude.com Date: Wed, 07 Sep 2005 19:28:41 -0400 I gave up and downgraded to 8.15 now I'm getting: 09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" "D:\IMAIL\spool\Q3ab90041008c0e76.SMD" It looks like you set up Declude to run in C:\IMail, but you run IMail on D:\IMail. :) -Scott --- 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. __ __ __ __ Sent via the CMS Internet Webmail system at mail1.cmsinter.net --- 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] Is there any hope running Declude with imail8.21???
Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan HorneSent: Thursday, September 08, 2005 1:58 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yes, we justtoday reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that our problems would not be related to the multi-processor sleep problems. It just doesn't seem able to handle the load that 1.82 does. And yes, we have increased our THREADS to 25. Also, they claim to have fixed a problem with leftover files, but after swapping out the Declude executable with 1.82 and leaving the Decludeproc service running, 24 files are still stranded in the "spool\proc\work" directory and there are 9 *.vir directories still in there (they are truly stranded, even the 24 files comprise 12 paired q and d files they are not being delivered for several hours with the Decludeproc service still running. I am going to have to move them back into the spool directory manually). The Decludeproc service has NOT stopped running at all in theseveral days it has been running, so I don't know why the files are stranded. I just tried restarting it to see if I could "wake it up", but it didn't give me any love. Looking at the dates, I see one q/d pair from Sep 2, several from Sep 7 and the2 pairfrom today. Each one of these represents a "lost" email. I opened afew and didn't find any of them to be spam. The one thing I can't abide is "lost" email, so I had to stop our beta test. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Thursday, September 08, 2005 12:11 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? IMail 8.20+ is only compatible with Declude 3+, but that software is still in early beta and I wouldn't recommend it. This combination can work, but it appears that the higher the volume you have, the more likely you are to experience serious issues with E-mail backing up. I have been using IMail 8.15 HF2 for many months without any new issues, and it works very well with Declude 2.0.6.16 (the most recent interim release) which also doesn't have any new issues. The newer Declude 3.0 that is in beta is basically the same in terms of functionality, but it is changed to act as a service in order to resolve issues with the changes in IMail 8.20+ and also increase performance slightly. This is a big change for Declude, and building a service to handle E-mail reliably isn't a small feat so I would suggest being patient in the mean time.MattTimothy Bohen wrote: Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude. Thanks -- Original Message -- From: "R. Scott Perry" [EMAIL PROTECTED] Reply-To: Declude.JunkMail@declude.com Date: Wed, 07 Sep 2005 19:28:41 -0400 I gave up and downgraded to 8.15 now I'm getting: 09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" "D:\IMAIL\spool\Q3ab90041008c0e76.SMD" It looks like you set up Declude to run in C:\IMail, but you run IMail on D:\IMail. :) -Scott --- 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. __ __ __ __ Sent via the CMS Internet Webmail system at mail1.cmsinter.net --- 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 - Missing the Point
Hi Matt: I read your posting (because you are always insightful), but I'm not sure that your message actually applies to what I had said(and to which Andrew had commented on) or if youmay beanswering to a different part of the conversation. Certainly nothing Utopian in what I wrote? a) It isplain fact that the largest providers do check SPF, which in turn means that Joe-Jobs have a drastically lower impact on the spoofed domain's owner. b) It is also a fact, that spammers are very SPF aware (to the point that they create SPF records.) c) Based on my personal, admittedly anecdotal, experience (supported bycommon sense) it further appears to me that SPF protected domainswould beless likely to get picked for Joe-Jobs than unprotected domains. Here is what I had written: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names?If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place.The effect of having SPF defined is, that FEWER spammers even bother trying to abuse YOUR domain name, because they know that a lot of their spam would never reach anyone. Instead, they now use their own domain names and even set up SPF for those. To me - that ripple effect alone justifies SPF! Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Thursday, September 08, 2005 01:55 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF - Missing the Point But isn't this utopian? The majority of situations have exceptions as they apply to SPF, and in a world where there are open relays on every corner, many servers without proper reverse DNS records, etc., would you really want to trust others to maintain SPF records accurately?I use a custom filter for tagging local domains in incoming E-mail. Since all of my customers' servers are whitelisted, and hosted clients are also whitelisted through AUTH, I can add a couple of points for anything with a Mail From that matches something that I handle. This does have false positives, many in fact due to mailers that forge such as greeting cards or feedback forms, devices that send out notifications with their own SMTP engine, people that are port 25 blocked or proxied, configured to use their own ISP's SMTP server, Web applications, etc. SPF isn't required to do this. I don't trust how well some random admin manages their own SPF records, and if I had my own SPF records, I wouldn't trust how some random admin treated a failure among my own customers. At least they aren't going to be tagged for sending E-mail from someplace that they didn't know not to send from, and is otherwise perfectly acceptable. I am obviously not going to give any credit to anyone for passing SPF either. Passing SPF is a better indication of spam than of legitimate E-mail these days for incoming traffic.I have never been a big fan of SPF because of what I saw as an impractical and unreliable implementation in the real world. It really isn't any better than Habeas once you get down to it, but people ate that up for a while as well. We have many tools available to us these days that are quite effective and much more accurate. Forging spam almost never leaks through my system, and it's not something that I care to focus on at all these days. It's things like Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me.MattColbeck, Andrew wrote: That's right on the money, Andy. I agree 100%. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt Sent: Thursday, September 08, 2005 8:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] SPF - Missing the Point still unacceptable and reason enough for me to discard SPF completely. I think the discusson is missing the key point of SPF. Sure, this list is focused on INCOMING spam, and thus we restricting our discussions to SPFFAIL/SPFPASS and how to use it in Declude. However, that ignores what SPF is designed to do: How many times have we received angry emails or hundreds of bounce messages from other ISPs because some Spammer was sending mail with a fake email sender - using OUR domain names? If you define SPF for your own (and client) domain names, then the largest ISPs won't accept the spam that has your email address faked, thus you and your clients will no longer be bombarded with responses/complaints/bounces to messages you never sent in the first place. The effect of having SPF defined
RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???
3.0.3. Mail has backed up repeatedly since installing this version. We originally installed 3.0 when it was released, but quickly backed off that when the service stopped on its own, leaving multiple files in the proc directory. After waiting a while, we got an email about 3.0.3 being released which seemed to specifically target the problems we had, so we again immediately installed that version (on Sep 2). The results were OK until the weekend when mail piled up for an unknown reason. We just waited that one out, and the next one which occurred Monday afternoon. The one from yesterday though caused an hour-long delay in email delivery. Today the decision was made to cease the beta test and revert back to 1.82. The change was made this morning at around 9:00 AM EST, and the files I noted are still in thework directorynow, 5 hours later. I just want to note that the same server never backs up running 1.82. I notice that there is now a version 3.0.3.4, but we of course haven't tried that version. FWIW, we are using all three Declude products including Hijack. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David BarkerSent: Thursday, September 08, 2005 2:04 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan HorneSent: Thursday, September 08, 2005 1:58 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yes, we justtoday reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that our problems would not be related to the multi-processor sleep problems. It just doesn't seem able to handle the load that 1.82 does. And yes, we have increased our THREADS to 25. Also, they claim to have fixed a problem with leftover files, but after swapping out the Declude executable with 1.82 and leaving the Decludeproc service running, 24 files are still stranded in the "spool\proc\work" directory and there are 9 *.vir directories still in there (they are truly stranded, even the 24 files comprise 12 paired q and d files they are not being delivered for several hours with the Decludeproc service still running. I am going to have to move them back into the spool directory manually). The Decludeproc service has NOT stopped running at all in theseveral days it has been running, so I don't know why the files are stranded. I just tried restarting it to see if I could "wake it up", but it didn't give me any love. Looking at the dates, I see one q/d pair from Sep 2, several from Sep 7 and the2 pairfrom today. Each one of these represents a "lost" email. I opened afew and didn't find any of them to be spam. The one thing I can't abide is "lost" email, so I had to stop our beta test. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Thursday, September 08, 2005 12:11 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? IMail 8.20+ is only compatible with Declude 3+, but that software is still in early beta and I wouldn't recommend it. This combination can work, but it appears that the higher the volume you have, the more likely you are to experience serious issues with E-mail backing up. I have been using IMail 8.15 HF2 for many months without any new issues, and it works very well with Declude 2.0.6.16 (the most recent interim release) which also doesn't have any new issues. The newer Declude 3.0 that is in beta is basically the same in terms of functionality, but it is changed to act as a service in order to resolve issues with the changes in IMail 8.20+ and also increase performance slightly. This is a big change for Declude, and building a service to handle E-mail reliably isn't a small feat so I would suggest being patient in the mean time.MattTimothy Bohen wrote: Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude. Thanks -- Original Message -- From: "R. Scott Perry" [EMAIL PROTECTED] Reply-To: Declude.JunkMail@declude.com Date: Wed, 07 Sep 2005 19:28:41 -0400 I gave up and downgraded to 8.15 now I'm getting: 09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" "D:\IMAIL\spool\Q3ab90041008c0e76.SMD" It looks like you set up Declude to run in C:\IMail, but
RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???
Dan, 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. 2. We have never seen an long delay in the processing of email and no one else has reported this. 3. As mentioned on the Beta page there are still issues with orphan files due to Hijack, but this is because the hijack is moving the email to the HOLD2 folder and leaving files behind, these email should not be legitimate. 4. The only other reasons we are aware of for orphan files is - if the files already exist in the location (eg Spam folder) then the files cannot be moved from the \work directory to that location. 5. In order to find the cause please send us your log files / copy of an orphaned email / config files for us to look at the situation ? 6. In addition to the lists, in future it would be a good idea to email us at [EMAIL PROTECTED] with issues you are experiencing so we can deal with them promptly. Thanks David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 2:26 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? 3.0.3. Mail has backed up repeatedly since installing this version. We originally installed 3.0 when it was released, but quickly backed off that when the service stopped on its own, leaving multiple files in the proc directory. After waiting a while, we got an email about 3.0.3 being released which seemed to specifically target the problems we had, so we again immediately installed that version (on Sep 2). The results were OK until the weekend when mail piled up for an unknown reason. We just waited that one out, and the next one which occurred Monday afternoon. The one from yesterday though caused an hour-long delay in email delivery. Today the decision was made to cease the beta test and revert back to 1.82. The change was made this morning at around 9:00 AM EST, and the files I noted are still in the work directory now, 5 hours later. I just want to note that the same server never backs up running 1.82. I notice that there is now a version 3.0.3.4, but we of course haven't tried that version. FWIW, we are using all three Declude products including Hijack. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 2:04 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 1:58 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yes, we just today reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that our problems would not be related to the multi-processor sleep problems. It just doesn't seem able to handle the load that 1.82 does. And yes, we have increased our THREADS to 25. Also, they claim to have fixed a problem with leftover files, but after swapping out the Declude executable with 1.82 and leaving the Decludeproc service running, 24 files are still stranded in the spool\proc\work directory and there are 9 *.vir directories still in there (they are truly stranded, even the 24 files comprise 12 paired q and d files they are not being delivered for several hours with the Decludeproc service still running. I am going to have to move them back into the spool directory manually). The Decludeproc service has NOT stopped running at all in the several days it has been running, so I don't know why the files are stranded. I just tried restarting it to see if I could wake it up, but it didn't give me any love. Looking at the dates, I see one q/d pair from Sep 2, several from Sep 7 and the 2 pair from today. Each one of these represents a lost email. I opened a few and didn't find any of them to be spam. The one thing I can't abide is lost email, so I had to stop our beta test. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Thursday, September 08, 2005 12:11 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? IMail 8.20+ is only compatible with Declude 3+, but that software is still in early beta and I wouldn't recommend it. This combination can work, but it appears that the higher the volume you have, the more likely you are to experience serious issues with E-mail backing up. I have been using IMail
RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???
DB 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. Dave, at the top of my suggested list for new code in declude.exe has been to do robust MIME decoding so that Declude PRO text filters no longer grind the raw layer of attachments for spammy text. That alone would make Declude orders of magnitude faster, more accurate, and lighter on RAM. Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a great stopgap for me. If anybody out there is wondering what the heck I'm talking about, check the archive for my posting of my SKIPATTACH test. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 11:54 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. 2. We have never seen an long delay in the processing of email and no one else has reported this. 3. As mentioned on the Beta page there are still issues with orphan files due to Hijack, but this is because the hijack is moving the email to the HOLD2 folder and leaving files behind, these email should not be legitimate. 4. The only other reasons we are aware of for orphan files is - if the files already exist in the location (eg Spam folder) then the files cannot be moved from the \work directory to that location. 5. In order to find the cause please send us your log files / copy of an orphaned email / config files for us to look at the situation ? 6. In addition to the lists, in future it would be a good idea to email us at [EMAIL PROTECTED] with issues you are experiencing so we can deal with them promptly. Thanks David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 2:26 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? 3.0.3. Mail has backed up repeatedly since installing this version. We originally installed 3.0 when it was released, but quickly backed off that when the service stopped on its own, leaving multiple files in the proc directory. After waiting a while, we got an email about 3.0.3 being released which seemed to specifically target the problems we had, so we again immediately installed that version (on Sep 2). The results were OK until the weekend when mail piled up for an unknown reason. We just waited that one out, and the next one which occurred Monday afternoon. The one from yesterday though caused an hour-long delay in email delivery. Today the decision was made to cease the beta test and revert back to 1.82. The change was made this morning at around 9:00 AM EST, and the files I noted are still in the work directory now, 5 hours later. I just want to note that the same server never backs up running 1.82. I notice that there is now a version 3.0.3.4, but we of course haven't tried that version. FWIW, we are using all three Declude products including Hijack. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 2:04 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 1:58 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yes, we just today reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that our problems would not be related to the multi-processor sleep problems. It just doesn't seem able to handle the load that 1.82 does. And yes, we have increased our THREADS to 25. Also, they claim to have fixed a problem with leftover files, but after swapping out the Declude executable with 1.82 and leaving the Decludeproc service running, 24 files are still stranded in the spool\proc\work directory and there are 9 *.vir directories still in there (they are truly stranded, even the 24 files comprise 12 paired q and d files they are not being delivered for several hours with the Decludeproc service still running. I am going to have to move them back into the spool directory manually). The Decludeproc service has
RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???
Andrew, Thanks for the suggestion. I have passed it on to our developers to look into. David B www.declude.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Thursday, September 08, 2005 3:03 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? DB 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. Dave, at the top of my suggested list for new code in declude.exe has been to do robust MIME decoding so that Declude PRO text filters no longer grind the raw layer of attachments for spammy text. That alone would make Declude orders of magnitude faster, more accurate, and lighter on RAM. Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a great stopgap for me. If anybody out there is wondering what the heck I'm talking about, check the archive for my posting of my SKIPATTACH test. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 11:54 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. 2. We have never seen an long delay in the processing of email and no one else has reported this. 3. As mentioned on the Beta page there are still issues with orphan files due to Hijack, but this is because the hijack is moving the email to the HOLD2 folder and leaving files behind, these email should not be legitimate. 4. The only other reasons we are aware of for orphan files is - if the files already exist in the location (eg Spam folder) then the files cannot be moved from the \work directory to that location. 5. In order to find the cause please send us your log files / copy of an orphaned email / config files for us to look at the situation ? 6. In addition to the lists, in future it would be a good idea to email us at [EMAIL PROTECTED] with issues you are experiencing so we can deal with them promptly. Thanks David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 2:26 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? 3.0.3. Mail has backed up repeatedly since installing this version. We originally installed 3.0 when it was released, but quickly backed off that when the service stopped on its own, leaving multiple files in the proc directory. After waiting a while, we got an email about 3.0.3 being released which seemed to specifically target the problems we had, so we again immediately installed that version (on Sep 2). The results were OK until the weekend when mail piled up for an unknown reason. We just waited that one out, and the next one which occurred Monday afternoon. The one from yesterday though caused an hour-long delay in email delivery. Today the decision was made to cease the beta test and revert back to 1.82. The change was made this morning at around 9:00 AM EST, and the files I noted are still in the work directory now, 5 hours later. I just want to note that the same server never backs up running 1.82. I notice that there is now a version 3.0.3.4, but we of course haven't tried that version. FWIW, we are using all three Declude products including Hijack. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 2:04 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 1:58 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yes, we just today reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that our problems would not be related to the multi-processor sleep problems. It just doesn't seem able to handle the load that 1.82 does. And yes, we have increased our THREADS to 25. Also, they claim to have fixed a problem with leftover files, but after swapping out the Declude executable with 1.82 and leaving the Decludeproc service running, 24 files are still
Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21???
Yeah, throw us Pro users a couple of bones! - Original Message - From: Colbeck, Andrew [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 2:02 PM Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? DB 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. Dave, at the top of my suggested list for new code in declude.exe has been to do robust MIME decoding so that Declude PRO text filters no longer grind the raw layer of attachments for spammy text. That alone would make Declude orders of magnitude faster, more accurate, and lighter on RAM. Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a great stopgap for me. If anybody out there is wondering what the heck I'm talking about, check the archive for my posting of my SKIPATTACH test. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 11:54 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. 2. We have never seen an long delay in the processing of email and no one else has reported this. 3. As mentioned on the Beta page there are still issues with orphan files due to Hijack, but this is because the hijack is moving the email to the HOLD2 folder and leaving files behind, these email should not be legitimate. 4. The only other reasons we are aware of for orphan files is - if the files already exist in the location (eg Spam folder) then the files cannot be moved from the \work directory to that location. 5. In order to find the cause please send us your log files / copy of an orphaned email / config files for us to look at the situation ? 6. In addition to the lists, in future it would be a good idea to email us at [EMAIL PROTECTED] with issues you are experiencing so we can deal with them promptly. Thanks David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 2:26 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? 3.0.3. Mail has backed up repeatedly since installing this version. We originally installed 3.0 when it was released, but quickly backed off that when the service stopped on its own, leaving multiple files in the proc directory. After waiting a while, we got an email about 3.0.3 being released which seemed to specifically target the problems we had, so we again immediately installed that version (on Sep 2). The results were OK until the weekend when mail piled up for an unknown reason. We just waited that one out, and the next one which occurred Monday afternoon. The one from yesterday though caused an hour-long delay in email delivery. Today the decision was made to cease the beta test and revert back to 1.82. The change was made this morning at around 9:00 AM EST, and the files I noted are still in the work directory now, 5 hours later. I just want to note that the same server never backs up running 1.82. I notice that there is now a version 3.0.3.4, but we of course haven't tried that version. FWIW, we are using all three Declude products including Hijack. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 2:04 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 1:58 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yes, we just today reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that our problems would not be related to the multi-processor sleep problems. It just doesn't seem able to handle the load that 1.82 does. And yes, we have increased our THREADS to 25. Also, they claim to have fixed a problem with leftover files, but after swapping out the Declude executable with 1.82 and leaving the Decludeproc service running, 24 files are still stranded in the spool\proc\work directory and there are 9 *.vir directories still in there (they are truly stranded, even the 24 files comprise 12 paired q and d files they are not being delivered for several hours with the Decludeproc service still
RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???
Scott, We are very happy with the suggestions Declude users have made regarding tests and improvements of Declude, as soon as we are done with the Declude 3.0 release the focus will be on these additions wrt to functionality. David B www.declude.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Fisher Sent: Thursday, September 08, 2005 3:20 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yeah, throw us Pro users a couple of bones! - Original Message - From: Colbeck, Andrew [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 2:02 PM Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? DB 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. Dave, at the top of my suggested list for new code in declude.exe has been to do robust MIME decoding so that Declude PRO text filters no longer grind the raw layer of attachments for spammy text. That alone would make Declude orders of magnitude faster, more accurate, and lighter on RAM. Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a great stopgap for me. If anybody out there is wondering what the heck I'm talking about, check the archive for my posting of my SKIPATTACH test. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 11:54 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. 2. We have never seen an long delay in the processing of email and no one else has reported this. 3. As mentioned on the Beta page there are still issues with orphan files due to Hijack, but this is because the hijack is moving the email to the HOLD2 folder and leaving files behind, these email should not be legitimate. 4. The only other reasons we are aware of for orphan files is - if the files already exist in the location (eg Spam folder) then the files cannot be moved from the \work directory to that location. 5. In order to find the cause please send us your log files / copy of an orphaned email / config files for us to look at the situation ? 6. In addition to the lists, in future it would be a good idea to email us at [EMAIL PROTECTED] with issues you are experiencing so we can deal with them promptly. Thanks David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 2:26 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? 3.0.3. Mail has backed up repeatedly since installing this version. We originally installed 3.0 when it was released, but quickly backed off that when the service stopped on its own, leaving multiple files in the proc directory. After waiting a while, we got an email about 3.0.3 being released which seemed to specifically target the problems we had, so we again immediately installed that version (on Sep 2). The results were OK until the weekend when mail piled up for an unknown reason. We just waited that one out, and the next one which occurred Monday afternoon. The one from yesterday though caused an hour-long delay in email delivery. Today the decision was made to cease the beta test and revert back to 1.82. The change was made this morning at around 9:00 AM EST, and the files I noted are still in the work directory now, 5 hours later. I just want to note that the same server never backs up running 1.82. I notice that there is now a version 3.0.3.4, but we of course haven't tried that version. FWIW, we are using all three Declude products including Hijack. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 2:04 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 1:58 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yes, we just today reverted back to 1.82 because our single-processor machine backed up. At the worst there was an hour delay in delivery. I specifically denoted it was a single-processor machine just to indicate that
Re: [Declude.JunkMail] SPF - Missing the Point
Andy, Thanks for the kind words. My answer was more so an indirect response instead of a direct one. As far as your points go, please allow me to piece them out. a) It isplain fact that the largest providers do check SPF, which in turn means that Joe-Jobs have a drastically lower impact on the spoofed domain's owner. It depends on the joe-job. Most of them target random domains and not necessarily the largest providers. If providers are rejecting on SPF-FAIL alone, then that is actually even more reason for me to not implement SPF on my own domains and advise customers to skip this as well. There are just too many legitimate exceptions to this that would cause an SPF-FAIL on a strictly defined record. If I was to define the records less specifically, it doesn't have much practical use since this would be like saying it can come from anywhere...and in fact it can. The worst joe-job bounce issues that I see are where the open relay itself is what is bouncing the majority of messages. Open relays are not likely to support SPF. Other servers that bounce the joe-jobs are ones that accept all E-mail without authenticating, which is a huge mistake in this day and age, and I wouldn't expect for them to use SPF either since they can't seem to figure out how to validate addresses which is 100 times more important. b) It is also a fact, that spammers are very SPF aware (to the point that they create SPF records.) Static spammers (where they spam from their own servers) are aware of SPF and abuse it. Zombie spammers can't make use of it and they are a whole different class in terms of what they do. Forging is almost exclusive to zombie spammers. They can be very sophisticated, but they don't cleanse their databases of things like SPF, they just generally rotate through either fake or known addresses as they attack servers with millions of addresses that mostly don't exist in the first place. I have also found that many of these guys cache the IP addresses corresponding to MX records and they don't refresh this data for very long periods of time if ever. I have changed MX records for domains that are still being spammed on the original IP over a year and a half later. This is why we always attempt to lock down our gateway customer's servers, or at least try to get them to change IP's if that isn't practical. c) Based on my personal, admittedly anecdotal, experience (supported bycommon sense) it further appears to me that SPF protected domainswould beless likely to get picked for Joe-Jobs than unprotected domains. This kind of points to my reply to a). I don't think that the zombie spammers care. They will attempt 1 million addresses on a domain with a single valid user, they don't care if every attempt is accepted or rejected, and they aren't even trying to capture the rejected addresses so save themselves processing on future attacks. They aren't really even dictionary attacks by definition, they are just brute-force spam runs. While you might have experienced some anecdotal proof of them caring about SPF, it doesn't make sense to me that they would ignore bigger issues such as repeatedly hitting invalid addresses and not bothering to update their IP cache of MX records. These guys are social misfits, many of them with tens of thousands of zombies in their bot networks, and they don't care to micro-manage things. Success to them is not just spamming a particular site, but also causing a bounce, overwhelming a server, or even just pissing you off. I think that you might have the perception that these guys care. I don't think they do. SPF just isn't anywhere near accurate enough for me to want to use on my system for catching spam, and it would create some double-hit problems with SPAMDOMAINS. I can control SPAMDOMAINS, but I can't control what someone does for their own SPF records. Many domains, especially the larger and more actively used ones, have many examples of fully legitimate use that will fail SPF, and while I might be smart enough to not block on that alone, there are others around here that will most definitely at least hold a message if it hits SPF-FAIL, and again I have no control over that except to either configure SPF records for every address, or not configure it at all. Since SPF has come out, forging spam has dramatically increased, and dictionary attacks have become much more common and fierce. I tag this stuff with much more reliable tests such as Sniffer, enhanced URIBL functionality, DUL lists enhanced by my own data, technical heuristics that find zombie spamware patterns, blacklists, and custom combo filters that know that a combinations like a DUL hit, a Sniffer hit and an XBL hit together is stronger than the three alone. It works incredibly well on my system and I don't feel that I need any more tools to block such things, though tweaking them can help of course. My opinion remains that SPF, while well intentioned, lacks the ability to be accurate enough to be used
RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???
I'm feeling the love. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 12:34 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Scott, We are very happy with the suggestions Declude users have made regarding tests and improvements of Declude, as soon as we are done with the Declude 3.0 release the focus will be on these additions wrt to functionality. David B www.declude.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Fisher Sent: Thursday, September 08, 2005 3:20 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Yeah, throw us Pro users a couple of bones! - Original Message - From: Colbeck, Andrew [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, September 08, 2005 2:02 PM Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? DB 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. Dave, at the top of my suggested list for new code in declude.exe has been to do robust MIME decoding so that Declude PRO text filters no longer grind the raw layer of attachments for spammy text. That alone would make Declude orders of magnitude faster, more accurate, and lighter on RAM. Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a great stopgap for me. If anybody out there is wondering what the heck I'm talking about, check the archive for my posting of my SKIPATTACH test. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 11:54 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, 1. 3.0.3 in our testing has been considerably quicker than that of earlier versions of Declude. 2. We have never seen an long delay in the processing of email and no one else has reported this. 3. As mentioned on the Beta page there are still issues with orphan files due to Hijack, but this is because the hijack is moving the email to the HOLD2 folder and leaving files behind, these email should not be legitimate. 4. The only other reasons we are aware of for orphan files is - if the files already exist in the location (eg Spam folder) then the files cannot be moved from the \work directory to that location. 5. In order to find the cause please send us your log files / copy of an orphaned email / config files for us to look at the situation ? 6. In addition to the lists, in future it would be a good idea to email us at [EMAIL PROTECTED] with issues you are experiencing so we can deal with them promptly. Thanks David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne Sent: Thursday, September 08, 2005 2:26 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? 3.0.3. Mail has backed up repeatedly since installing this version. We originally installed 3.0 when it was released, but quickly backed off that when the service stopped on its own, leaving multiple files in the proc directory. After waiting a while, we got an email about 3.0.3 being released which seemed to specifically target the problems we had, so we again immediately installed that version (on Sep 2). The results were OK until the weekend when mail piled up for an unknown reason. We just waited that one out, and the next one which occurred Monday afternoon. The one from yesterday though caused an hour-long delay in email delivery. Today the decision was made to cease the beta test and revert back to 1.82. The change was made this morning at around 9:00 AM EST, and the files I noted are still in the work directory now, 5 hours later. I just want to note that the same server never backs up running 1.82. I notice that there is now a version 3.0.3.4, but we of course haven't tried that version. FWIW, we are using all three Declude products including Hijack. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, September 08, 2005 2:04 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21??? Dan, What version for Declude Beta were you running? As we have not seen the behavior you are referring to. David B www.declude.com
RE: [Declude.JunkMail] What Header does Whitelist file use?
Title: What Header does Whitelist file use? I finally figured out the problem.stupid, stupid, stupid.I had fat-fingered the path to the whitelist fileNow everything works as expected! From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin CoxSent: Friday, September 02, 2005 12:30 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] What Header does Whitelist file use? Hi Corby, The best way to determine explicitly what it's using is to add custom header to the email. There are several you may find useful, but the one I'm referring to can be added by adding a line like XINHEADERX-Note: FROM: %MAILFROM% to your Global.cfg file. We add several headers for diagnostic purposes... XINHEADERX-Note: Total spam weight of this E-mail is %WEIGHT%.XINHEADERX-Note: Spam Tests Failed: %TESTSFAILEDWITHWEIGHTS%XINHEADERX-Note: REMOTEIP: %REMOTEIP%XINHEADERX-Note: REVDNS: %REVDNS%XINHEADERX-Note: FROM: %MAILFROM%XINHEADERX-Note: TO: %RECIPHOST% TheFROM address that will be reported there is exactly what Declude woulduse when checking against your whitelists. REVDNS is almost always a different domain than the sending address, since most email domains are hosted on common servers. While you may have reason to block or whitelist on REVDNS, which would be a different test completely, the FROM whitelist would only need the two entries you specify. BTW, though we've been calling it whitelisting, it is generally recommended to use the "whitelists" as negative weights instead of true whitelists. That way if something is really bad (i.e. bad enough that your negative weight doesn't keep it from being tagged, held, or deleted), then it is still detected. True whitelisting would let it through no matter how bad it was. We hold on a weight of 100 and delete on 300, and have three FROM "whitelists" defined like FROMWHITELIST_LOWfromfileC:\IMail\Declude\fromwhitelist_low.txtx-1000FROMWHITELIST_MEDfromfileC:\IMail\Declude\fromwhitelist_med.txtx-2000FROMWHITELIST_HIGHfromfileC:\IMail\Declude\fromwhitelist_high.txtx-5000 We also have FROM blacklists, IP white and black lists, content-based white and black lists, and test-specific counterweights thatmatch againstMAILFROM and/or REVDNS. We favor adding to the counterweight tests first, then FROM whitelists, and finally IP whitelists, though you could argue the order of the last two. Just another list member..been using IMail for 5 years or so, and Declude for about 3.5 years now. Thanks, man. Darin. - Original Message - From: Agid, Corby To: Declude.JunkMail@declude.com Sent: Friday, September 02, 2005 3:03 PM Subject: RE: [Declude.JunkMail] What Header does Whitelist file use? Darin, I'm still confused on what part of the message converstation would be compared to the whitelist entry. A message often has a different values for the From Header and the envelope (not sure if I'm using the correct terms). The Reverse DNS is also different from the other two. Using the format of .sub.domain.com and @sub.domain.com, I would have to make six entries to cover all the bases, when probably the correct two would take care of it. Suggestions? BTW, are you with Declude or a helpful bystander? Thanks again for your help and hope you are feeling better. Corby From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin CoxSent: Thursday, September 01, 2005 7:49 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] What Header does Whitelist file use? Sorry, you're right... Sometimes when I'm under the weather I switch things around... Have you checked the other suggestion... making sure the last line has a carriage return afterwards? Darin. - Original Message - From: Agid, Corby To: Declude.JunkMail@declude.com Sent: Thursday, September 01, 2005 6:26 PM Subject: RE: [Declude.JunkMail] What Header does Whitelist file use? Hi Darin, I just checked the manual regarding theSWITCHRECIP ON. The description sounds like it affects who the message is addressed to rather than where it comes from. Am I missing something? Corby From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin CoxSent: Thursday, September 01, 2005 1:02 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] What Header does Whitelist file use? This may be an issue where the FROM listed in the email is different from the MAILFROM address found in the envelope. If so, putting SWITCHRECIP ONin your Declude Global.cfg should fix it. You can
RE: [Declude.JunkMail] Server Running at 100%
I'm confused. The page in the Knowledge Base http://support.declude.com/Customer/KBArticle.aspx?articleid=11 says to put it in the global.cfg file. It also says nothing about adding the ON switch. I even exchanged emails with Declude support back on Aug. 2 stating that I was putting AVAFTERJM in my global.cfg file, and support never mentioned that I should have put it in the virus.cfg file, nor was anything said about PRESCAN. Original Message From: David Barker [EMAIL PROTECTED] Sent: Thursday, September 08, 2005 12:01 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Server Running at 100% In your virus.cfg file: AVAFTERJM ON Also ensure that you have the directive: PRESCANON David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris Sent: Thursday, September 08, 2005 11:56 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Server Running at 100% Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: Richard Farris mailto:[EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet --- [This E-mail scanned for viruses by Declude Virus] --- 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] Server Running at 100%
I'm confused. The page in the Knowledge Base http://support.declude.com/Customer/KBArticle.aspx?articleid=11 Now I am too - I had no idea there was a knowledge base now :) says to put it in the global.cfg file. It also says nothing about adding the ON switch. I even exchanged emails with Declude support back on Aug. 2 stating that I was putting AVAFTERJM in my global.cfg file, and support never mentioned that I should have put it in the virus.cfg file, nor was anything said about PRESCAN. Placing it in your global.cfg is wrong. It needs to be in your virus.cfg. Prescan is a seperate feature that if it basically detects no attachments or harmful code it will skip scanning the message period. Darrell --- Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Original Message From: David Barker [EMAIL PROTECTED] Sent: Thursday, September 08, 2005 12:01 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Server Running at 100% In your virus.cfg file: AVAFTERJM ON Also ensure that you have the directive: PRESCANON David B www.declude.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris Sent: Thursday, September 08, 2005 11:56 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Server Running at 100% Importance: High I was told to see if using AVAFTERJM would help on resources on my server...right now I almost dead in the water..my server is cralling to send mailhow do I use this command...exactly how does it go into the config.. Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet - Original Message - From: Richard Farris mailto:[EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 11:21 AM Subject: [Declude.JunkMail] Spam box Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet --- [This E-mail scanned for viruses by Declude Virus] --- 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 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] FBI: Hurricane relief Internet scams proliferate
It isn't a surprise to see that phishers are targeting donations for hurricane relief, but I found it promising that the FBI was apparently paying close attention to the scams. I figure that the phishers are the same ones that target the banks and PayPal on a daily basis, but doing that they seem to have attracted little action by the Feds. Maybe things will change now. I don't see why these people can't be tracked down and jailed. FBI: Hurricane relief Internet scams proliferate http://www.cnn.com/2005/US/09/08/katrina.web.scams.ap/index.html --- 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.