RE: Re: [Declude.JunkMail] observation to share...
Hi: >> "ORDB hatte für den Open-Relay-Check zwei GMX-Adressen verwendet, die nicht auf SMTP-Auth konfiguriert waren." In der eigenen Open-Relay-Definition beschreibe ORDB ein solches System aber als einen Mail-Server, der Nachrichten weiterleite, "bei denen weder der Sender noch der Empfänger ein lokaler Nutzer ist". In den von ORDB dokumentierten Fällen habe es sich aber eindeutig um "local user" gehandelt. << May be there IS more to the story, but, it is expected and normal, that anyone who gets listed as an "open relay" will claim that they really were not and that the process was flawed. In reality, ORDB will send a test message to its own server and watch if it gets delivered. If the "round-trip" was successful, then the result is a pretty convincing case of an open relay. Bottom line, if ORDB found a way/trick to relay a message - then a spammer will too. Unless they can show an actual flaw on ORDB's testing method, I go by the assumption that as long as GMX's server allowed for that way/trick they rightfully would have been listed. It is interesting to note that they eventually resubmitted the server (presumingly after closing that hole) and they were de-listed. I do agree, that the lack of a "real-time" operations center of some of the databases (some don't even offer contact forms) does make them somewhat risky to use - but when viewed against the daily benefits, it's a risk worth taking. Best Regards Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Gufler Sent: Wednesday, May 28, 2003 02:14 AM To: [EMAIL PROTECTED] Subject: RE: Re: [Declude.JunkMail] observation to share... > I agree completly with scott ,and would like to add that > deleting mail only with rbl test does not mean anything. Today I've read an article on a german website (c't computer magazine) http://www.heise.de/newsticker/data/hob-27.05.03-000/ In short there's the information that the big freemailer GMX whas listed from Sunday evening to Monday in the ORDB blacklist. GMX some months ago has announced antispam actions since they have the same problem like msn, aol and co. Last Sunday ORDB has tested a GMX mailserver positive as an open relay (even if the method of testing is controversial) GMX was not very happy that ORDB was not reachable over a "fast way" and GMX-Admin's has had to fill out the standard form on the ORDB website asking to be removed as fast as possible. The result: On Monday a lot of mails was not deliverable because other mailservers blocked any connection from GMX (based on the ORDB blacklist) Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] observation to share...
Hi Chuck: "are you running the DNS cache in IMail 8?" Yes and per your request I disabled it and will let you know how it goes. But also per Scott's recent comment: - we are running the dns locally and they are part of the same active directory. So it may not matter much. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Frolick Sent: Wednesday, May 28, 2003 11:15 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] observation to share... Scott, Have you thought about using Declude Console as a short term dns cache for Declude? I think the results Kami is seeing is because Ipswitch included a DNS cache in the new Queue Manager, and their ip4r test may be using it instead of the DNS. Declude could definitely benefit from it since spammers usually send in bursts and from the same server, so all messages from that host will have the same results. Right now Declude requeries the DNS for each separate message, even if they are received simultaneously, am I correct? Just a thought. Kami, are you running the DNS cache in Imail 8? Could you test the performance difference without it? I know I saw a post on the Imail list about someone having to disable it to get rid of certain problems they were having, so if the cache is the boost, they won't benefit. Thanks, Chuck Frolick ArgoNet, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kami Razvan Sent: Wednesday, May 28, 2003 5:24 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] observation to share... Scott: Thank you for your response. Since we started doing this (almost a week) I have noticed several "real-life" behavior from our server. What we used to see: - When a list was hitting our server I was seeing many Declude.exe processes at the same time - one after another taking 100% of CPU and disappearing. As stated a while back, in one case, the server was almost down for 2-3 hours. By down I mean it could not do anything else but process what was being sent to it. We could not check email, outlook was timing out, and web messaging would return error. Once the processing ended the server was back to normal. Of course part of the problem is the way we do things (isn't it always?). We have a lot of filter files and were checking a lot of ip4r tests. Actions we took: - we commented a lot of ip4r tests in Declude and that helped a lot with times when a lot of email was hitting the server at the same time (lists) but still we were getting time outs in Outlook and web messaging was very slow when the emails were arriving. In essence we stopped using so much of the ip4r tests and only used about 8 or so, rather than all that was listed in the Declude site. - with IMail 8 I thought of moving all the ip4r tests to IMail so I can test a few things. Now the results are interesting. We no longer have that problem. The Outlook does not time out and looking at the Declude processes they appear and disappear fast and even if they hit 100% CPU it is for a very short time. We have not changed our filter files and actually have added two more. So the processing for Declude has not changed at all but it is not doing any ip4r tests. We now simply do all the ip4r tests in IMail, add the header and have a X-Header filter file. After reviewing the log files we will eventually get rid of some of the ip4r tests that we find are not effective but for now we are looking at majority of what you have listed in the Declude site. The header weights ranges from 1 - 8. Myth? Fact? Or just my imagination... May be our mail ends up in our backup mail server while IMail is busy checking ip4r's and since all email is not arriving at the same time Declude can manage it without assuming control of the server for a long time. So in essence we are managing delivery of email in a pipeline .. Of course the users may not mind waiting a minute before the mail arrives but they get frustrated when their mail client times out. Our problem is solved for now. - IMail do ip4r tests - Declude do the filters This was just a report from the field... Regards, Kami --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.Ju
RE: [Declude.JunkMail] observation to share...
Have you thought about using Declude Console as a short term dns cache for Declude? This is something that we have been thinking about doing for some time. However, if the DNS server is on the local network, there would be little benefit from doing this (as the local DNS server will cache the information and respond immediately). A bit less network traffic would be used, and processing would be just slightly faster. Right now Declude requeries the DNS for each separate message, even if they are received simultaneously, am I correct? There will be one query for each separate E-mail. Spammers will typically send one E-mail to multiple recipients, in which case only one query would need to be made. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] observation to share...
Scott, Have you thought about using Declude Console as a short term dns cache for Declude? I think the results Kami is seeing is because Ipswitch included a DNS cache in the new Queue Manager, and their ip4r test may be using it instead of the DNS. Declude could definitely benefit from it since spammers usually send in bursts and from the same server, so all messages from that host will have the same results. Right now Declude requeries the DNS for each separate message, even if they are received simultaneously, am I correct? Just a thought. Kami, are you running the DNS cache in Imail 8? Could you test the performance difference without it? I know I saw a post on the Imail list about someone having to disable it to get rid of certain problems they were having, so if the cache is the boost, they won't benefit. Thanks, Chuck Frolick ArgoNet, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kami Razvan Sent: Wednesday, May 28, 2003 5:24 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] observation to share... Scott: Thank you for your response. Since we started doing this (almost a week) I have noticed several "real-life" behavior from our server. What we used to see: - When a list was hitting our server I was seeing many Declude.exe processes at the same time - one after another taking 100% of CPU and disappearing. As stated a while back, in one case, the server was almost down for 2-3 hours. By down I mean it could not do anything else but process what was being sent to it. We could not check email, outlook was timing out, and web messaging would return error. Once the processing ended the server was back to normal. Of course part of the problem is the way we do things (isn't it always?). We have a lot of filter files and were checking a lot of ip4r tests. Actions we took: - we commented a lot of ip4r tests in Declude and that helped a lot with times when a lot of email was hitting the server at the same time (lists) but still we were getting time outs in Outlook and web messaging was very slow when the emails were arriving. In essence we stopped using so much of the ip4r tests and only used about 8 or so, rather than all that was listed in the Declude site. - with IMail 8 I thought of moving all the ip4r tests to IMail so I can test a few things. Now the results are interesting. We no longer have that problem. The Outlook does not time out and looking at the Declude processes they appear and disappear fast and even if they hit 100% CPU it is for a very short time. We have not changed our filter files and actually have added two more. So the processing for Declude has not changed at all but it is not doing any ip4r tests. We now simply do all the ip4r tests in IMail, add the header and have a X-Header filter file. After reviewing the log files we will eventually get rid of some of the ip4r tests that we find are not effective but for now we are looking at majority of what you have listed in the Declude site. The header weights ranges from 1 - 8. Myth? Fact? Or just my imagination... May be our mail ends up in our backup mail server while IMail is busy checking ip4r's and since all email is not arriving at the same time Declude can manage it without assuming control of the server for a long time. So in essence we are managing delivery of email in a pipeline .. Of course the users may not mind waiting a minute before the mail arrives but they get frustrated when their mail client times out. Our problem is solved for now. - IMail do ip4r tests - Declude do the filters This was just a report from the field... Regards, Kami --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: Re: [Declude.JunkMail] observation to share...
> I agree completly with scott ,and would like to add that > deleting mail only with rbl test does not mean anything. Today I've read an article on a german website (c't computer magazine) http://www.heise.de/newsticker/data/hob-27.05.03-000/ In short there's the information that the big freemailer GMX whas listed from Sunday evening to Monday in the ORDB blacklist. GMX some months ago has announced antispam actions since they have the same problem like msn, aol and co. Last Sunday ORDB has tested a GMX mailserver positive as an open relay (even if the method of testing is controversial) GMX was not very happy that ORDB was not reachable over a "fast way" and GMX-Admin's has had to fill out the standard form on the ORDB website asking to be removed as fast as possible. The result: On Monday a lot of mails was not deliverable because other mailservers blocked any connection from GMX (based on the ORDB blacklist) Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] observation to share...
Scott, does IMail do it's ip4r checking after the whole message is received and the connection terminated or does check on the HELO/EHLO and send an error code back to the remote server? IMail v8 runs the spam tests after the whole E-mail is received. Each ip4r test is run one after another (Declude instead runs the ip4r tests in parallel, sending all the queries at the same time, then awaiting the results). If it does that latter, the remote timeout settings may be a concern. I have been tracking the tarpitting features of our gateway and found that a lot of servers time out at 30 seconds, and more at 60. FWIW, the original teergrubing concept was designed for ultra-long (hours to days) delays that all mailservers should be able to handle. Rather than simply waiting X seconds, it would use multi-line responses, waiting X seconds between each one. For example: > RCPT TO: <[EMAIL PROTECTED]> < 220-OK, you can send to [EMAIL PROTECTED] But you will have to [25 second delay] < 220-wait and [25 second delay] < 220-wait and ... < 220 wait for a very long time! Glad that's over! > DATA ... This allows you to keep the connection open for days if needed (and it has been done for days). The 30- or 60-second timeout is very short, though, and against RFC2821 (which specifies 2-5 minutes as the "SHOULD" minimum for the various commands). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] observation to share...
Scott, does IMail do it's ip4r checking after the whole message is received and the connection terminated or does check on the HELO/EHLO and send an error code back to the remote server? If it does that latter, the remote timeout settings may be a concern. I have been tracking the tarpitting features of our gateway and found that a lot of servers time out at 30 seconds, and more at 60. If it is a spammer then no big deal, but if it is a legitimate mail server, and you are performing a lot of ip4r tests, some messages may be delayed a long time until redelivery is attempted, or maybe never received at all. I have seen some tests take as long as 10 seconds, but these instances were generally due to very heavy traffic on our end, or some other transient network condition. If IMail is checking on HELO, then using Declude for these tests would eliminate this risk. Brian On 05/27/03 7:13pm you wrote... >However, the main disadvantage here is that it will slow down delivery of >the E-mail by having IMail process it. If you have 60 ip4r tests running >in IMail, and they take an average of 1 second each to get the DNS results >back, that's a full minute that the E-mail delivery will be delayed for >valid E-mail (assuming that your local DNS server doesn't have a cached >answer). Also, if IMail's SMTPD process has a limit to the number of >E-mails it can handle at the same time, this limit would get hit much more >quickly with lots of ip4r tests running (I don't know if there is a limit, >however). > >-Scott >--- >Declude JunkMail: The advanced anti-spam solution for IMail mailservers. >Declude Virus: Catches known viruses and is the leader in mailserver >vulnerability detection. > >--- >[This E-mail was scanned for viruses by Declude Virus >(http://www.declude.com)] > >--- >This E-mail came from the Declude.JunkMail mailing list. To >unsubscribe, just send an E-mail to [EMAIL PROTECTED], and >type "unsubscribe Declude.JunkMail". The archives can be found >at http://www.mail-archive.com. > --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] observation to share...
We have been moving our IP4R tests from Declude to IMail (version 8) and are finding it more and more effective. This has the added benefit to delete emails before they reach Declude. we have added over 60 of the IP4R tests to IMail and checked the options for REVDNS, Verify email, and the HELO verification. Then made it delete if 10 tests fail But to me it seems like this is more CPU effective. I'm just going to add a few of my own comments to this thread. :) The one main advantage to having IMail delete the E-mail is that the Declude.exe process doesn't need to start, which saves CPU time. This would be very useful if you process lots of E-mail (100,000s a day), and/or have extensive processing in Declude JunkMail (such as lots of filters). However, the main disadvantage here is that it will slow down delivery of the E-mail by having IMail process it. If you have 60 ip4r tests running in IMail, and they take an average of 1 second each to get the DNS results back, that's a full minute that the E-mail delivery will be delayed for valid E-mail (assuming that your local DNS server doesn't have a cached answer). Also, if IMail's SMTPD process has a limit to the number of E-mails it can handle at the same time, this limit would get hit much more quickly with lots of ip4r tests running (I don't know if there is a limit, however). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
