RE: [Declude.JunkMail] ip4r & rhsbl tests not catching spam
Bad DNS server will do it every time. Thanks for your insight. Evans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Sunday, June 05, 2005 10:47 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] ip4r & rhsbl tests not catching spam Evan, Is your DNS server responding to these queries? One thing to verify is turn your log level to debug for a few minutes and see what the output of the queries are. Darrell --- invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default configuration. Download a copy today - http://www.invariantsystems.com - Original Message - From: Evans Martin To: Declude.JunkMail@declude.com Sent: Sunday, June 05, 2005 1:42 PM Subject: [Declude.JunkMail] ip4r & rhsbl tests not catching spam None of my ip4r or rhsbl tests are catching any spam since I switched to the latest global.cfg file distributed with v2.0.6 of Declude Junkmail Pro. Can anyone give me any suggestions as to what I can do to test or attempt to correct this? Thanks, Evans Martin #= RBL IP4R TESTS == # 1. Definitions of the tests to use (do not edit unless you know what you are doing). These must come before the actions. # 2. First is the name of the check, then the type of check (ip4r is a DNS lookup using the reverse of the IP address). # 3. For type ip4r, 'matchstring' is the string to look for, or "*" for anything. AHBL ip4r dnsbl.ahbl.org * 6 0 BLITZEDALL ip4r opm.blitzed.org * 7 0 CBL ip4r cbl.abuseat.org 127.0.0.2 6 0 DSBL ip4r list.dsbl.org * 6 0 MXRATE-BLOCK ip4r pub.mxrate.net 127.0.0.2 7 0 MXRATE-SUSPICIOUS ip4r pub.mxrate.net 127.0.0.4 2 0 ORDB ip4r relays.ordb.org * 5 0 SBL ip4r sbl.spamhaus.org * 7 0 SORBS-HTTP ip4r dnsbl.sorbs.net 127.0.0.2 5 0 SORBS-SOCKS ip4r dnsbl.sorbs.net 127.0.0.3 5 0 SORBS-MISC ip4r dnsbl.sorbs.net 127.0.0.4 5 0 SORBS-SMTP ip4r dnsbl.sorbs.net 127.0.0.5 5 0 SORBS-SPAM ip4r dnsbl.sorbs.net 127.0.0.6 4 0 SORBS-WEB ip4r dnsbl.sorbs.net 127.0.0.7 5 0 SORBS-BLOCK ip4r dnsbl.sorbs.net 127.0.0.8 5 0 SORBS-ZOMBIE ip4r dnsbl.sorbs.net 127.0.0.9 5 0 SORBS-DUHL ip4r dnsbl.sorbs.net 127.0.0.10 4 0 SPAMCOP ip4r bl.spamcop.net 127.0.0.2 7 0 BONDEDSENDER ip4r query.bondedsender.org 127.0.0.10 -10 0 MXRATE-ALLOW ip4r pub.mxrate.net 127.0.0.3 -3 0 #=ADDITIONAL USED RBL IP4R TESTS= MTLDB ip4r mtldb.declude.com 127.0.0.2 3 0 INTERSIL ip4r blackholes.intersil.net 127.0.0.2 5 0 CSMA-SBL ip4r sbl.csma.biz 127.0.0.2 5 0 SPAMBAG ip4r blacklist.spambag.org 127.0.0.2 4 0 FIVETENSRC ip4r blackholes.five-ten-sg.com 127.0.0.2 4 0 JAMMDNSBL ip4r dnsbl.jammconsulting.com 127.0.0.2 4 0 #= RHBSL TESTS == DSN rhsbl dsn.rfc-ignorant.org 127.0.0.2 3 0 NOABUSE
Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
You have to trust me that in the headers and logs that you provided, the E-mail was whitelisted when sent, and the only E-mail that was double scanned was the one that was forwarded from the prserv.net server back to [EMAIL PROTECTED]. It might have been sent directly to [EMAIL PROTECTED], but is is also being sent to an attglobal.net account which is likely the culprit here. This is proper to scan the message again when it returns after having left your server. Matt Susan Duncan wrote: [EMAIL PROTECTED] sent a message to a bunch of people including [EMAIL PROTECTED] using his dial-up att global account. I didn’t know there was a limit to the number of addresses in a send list. If our users aren’t using our distribution lists, but instead their own address lists, and send to all the locals, they’ll have at least 51 addresses. [EMAIL PROTECTED] is not coming from att global, the first guy is using att global. I’ve dropped the MXRATE-BLOCK to half its original value. I have seen any more caught mail that should not have been, but I’m still not clear on why I had two messages which should have been whitelisted, get caught. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: June 7, 2005 11:27 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not Just a little follow up about this. The first E-mail appears to be sent from your server in some sort of automated fashion (denoted by the GSC extension on the Q file). These are either postmaster messages, or some message created by calling imail1.exe directly (probably some bulk-mail script in this case, maybe even the listserv). It comes from the address [EMAIL PROTECTED] and was sent to a long list of addresses (too long for IMail not to throw an error). It was whitelisted on the way out. Then, one of the addresses on attglobal.net that it is sent to is apparently forwarding back to [EMAIL PROTECTED]. It is natural that it gets scanned coming back in, creating a second set of headers and a different spool file name. Your logs show the connecting hop as 32.97.166.48 which is in8.prserv.net and is used by AT&T for sending/forwarding E-mail. The E-mail was being blocked because of a combination of primarily two things. First, your DNS setup was initially not allowing your server to resolve your own MX records causing a failure in the MAILFROM test when this came in from the other server with a Mail From domain of ute-sei.org. Secondly, you are using MXRATE-BLOCK which has issues with tagging legitimate servers with high volume that allow forwarding (and some that are just simply high volume). To this blacklist, when spam is received by an AT&T hosted account that is then forwarded to an account on a different provider's machine that is sourced for data to generate MXRATE-BLOCK, it ends up tagging the forwarding server instead of the actual source. I stopped using MXRATE because of their issues with such things, in addition to them tagging a lot of legitimate bulk-mail that many blacklists have issues with and I didn't want to compound such issues further on my system. I don't know what you score MXRATE-BLOCK at, but you might consider dropping the score a bit if you weight it heavily Matt Matt wrote: Susan Duncan wrote: That still doesn’t explain why someone who is whitelisted still has some of their email caught. That's not the issue, they aren't actually both happening at the same time. It's being double scanned, and it is only being whitelisted when it is being sent, but not when it is received (over one minute later according to your logs). The full headers should have showed the complete path that the E-mail took and it would be easier to diagnose if they were shared (the Received lines). I'm thinking that maybe this E-mail was sent from your server to an address on another server that was actually forwarded back to her address on your server. That's the only way that I can think of that would generate two different spool file names, and cause it to be scanned twice by Declude in this way; adding headers each time. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
I reported the false positive (being a good netizin) to MXRATE (Alligate) and their automated reply included the following: "Generally, the most common reason an IP address is falsely listed in the MXRate database is when one of your users forwards all their mail to an account on a server protected by Alligate. Unfortunately, this usually includes all the spam and viruses they receive, and your server may be identified as the sending server." Matt Matt wrote: Just a little follow up about this. The first E-mail appears to be sent from your server in some sort of automated fashion (denoted by the GSC extension on the Q file). These are either postmaster messages, or some message created by calling imail1.exe directly (probably some bulk-mail script in this case, maybe even the listserv). It comes from the address [EMAIL PROTECTED] and was sent to a long list of addresses (too long for IMail not to throw an error). It was whitelisted on the way out. Then, one of the addresses on attglobal.net that it is sent to is apparently forwarding back to [EMAIL PROTECTED]. It is natural that it gets scanned coming back in, creating a second set of headers and a different spool file name. Your logs show the connecting hop as 32.97.166.48 which is in8.prserv.net and is used by AT&T for sending/forwarding E-mail. The E-mail was being blocked because of a combination of primarily two things. First, your DNS setup was initially not allowing your server to resolve your own MX records causing a failure in the MAILFROM test when this came in from the other server with a Mail From domain of ute-sei.org. Secondly, you are using MXRATE-BLOCK which has issues with tagging legitimate servers with high volume that allow forwarding (and some that are just simply high volume). To this blacklist, when spam is received by an AT&T hosted account that is then forwarded to an account on a different provider's machine that is sourced for data to generate MXRATE-BLOCK, it ends up tagging the forwarding server instead of the actual source. I stopped using MXRATE because of their issues with such things, in addition to them tagging a lot of legitimate bulk-mail that many blacklists have issues with and I didn't want to compound such issues further on my system. I don't know what you score MXRATE-BLOCK at, but you might consider dropping the score a bit if you weight it heavily Matt Matt wrote: Susan Duncan wrote: That still doesn’t explain why someone who is whitelisted still has some of their email caught. That's not the issue, they aren't actually both happening at the same time. It's being double scanned, and it is only being whitelisted when it is being sent, but not when it is received (over one minute later according to your logs). The full headers should have showed the complete path that the E-mail took and it would be easier to diagnose if they were shared (the Received lines). I'm thinking that maybe this E-mail was sent from your server to an address on another server that was actually forwarded back to her address on your server. That's the only way that I can think of that would generate two different spool file names, and cause it to be scanned twice by Declude in this way; adding headers each time. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
[EMAIL PROTECTED] sent a message to a bunch of people including [EMAIL PROTECTED] using his dial-up att global account. I didn’t know there was a limit to the number of addresses in a send list. If our users aren’t using our distribution lists, but instead their own address lists, and send to all the locals, they’ll have at least 51 addresses. [EMAIL PROTECTED] is not coming from att global, the first guy is using att global. I’ve dropped the MXRATE-BLOCK to half its original value. I have seen any more caught mail that should not have been, but I’m still not clear on why I had two messages which should have been whitelisted, get caught. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: June 7, 2005 11:27 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not Just a little follow up about this. The first E-mail appears to be sent from your server in some sort of automated fashion (denoted by the GSC extension on the Q file). These are either postmaster messages, or some message created by calling imail1.exe directly (probably some bulk-mail script in this case, maybe even the listserv). It comes from the address [EMAIL PROTECTED] and was sent to a long list of addresses (too long for IMail not to throw an error). It was whitelisted on the way out. Then, one of the addresses on attglobal.net that it is sent to is apparently forwarding back to [EMAIL PROTECTED]. It is natural that it gets scanned coming back in, creating a second set of headers and a different spool file name. Your logs show the connecting hop as 32.97.166.48 which is in8.prserv.net and is used by AT&T for sending/forwarding E-mail. The E-mail was being blocked because of a combination of primarily two things. First, your DNS setup was initially not allowing your server to resolve your own MX records causing a failure in the MAILFROM test when this came in from the other server with a Mail From domain of ute-sei.org. Secondly, you are using MXRATE-BLOCK which has issues with tagging legitimate servers with high volume that allow forwarding (and some that are just simply high volume). To this blacklist, when spam is received by an AT&T hosted account that is then forwarded to an account on a different provider's machine that is sourced for data to generate MXRATE-BLOCK, it ends up tagging the forwarding server instead of the actual source. I stopped using MXRATE because of their issues with such things, in addition to them tagging a lot of legitimate bulk-mail that many blacklists have issues with and I didn't want to compound such issues further on my system. I don't know what you score MXRATE-BLOCK at, but you might consider dropping the score a bit if you weight it heavily Matt Matt wrote: Susan Duncan wrote: That still doesn’t explain why someone who is whitelisted still has some of their email caught. That's not the issue, they aren't actually both happening at the same time. It's being double scanned, and it is only being whitelisted when it is being sent, but not when it is received (over one minute later according to your logs). The full headers should have showed the complete path that the E-mail took and it would be easier to diagnose if they were shared (the Received lines). I'm thinking that maybe this E-mail was sent from your server to an address on another server that was actually forwarded back to her address on your server. That's the only way that I can think of that would generate two different spool file names, and cause it to be scanned twice by Declude in this way; adding headers each time. Matt -- =MailPure custom filters for Declude JunkMail Pro.http://www.mailpure.com/software/= -- =MailPure custom filters for Declude JunkMail Pro.http://www.mailpure.com/software/=
Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
This isn't the same issue. See my last note. Matt Susan Duncan wrote: It seems to be happening when staff are not in the office when they send the mail. When they are out of office they connect to email either through webmail or use outlook same as always but use an outside ISP. In some cases, they have to use some mail proxy server as some of the ISPs are blocking access to port 25 on servers that are not their own. X-Declude-Sender: [EMAIL PROTECTED] [127.0.0.1] X-Declude-Sender: [EMAIL PROTECTED] [32.97.166.48] The first time around it shows the local loop address and the second time around the dial-up ISP (att global) address. Should I still be getting this if I use Whitelist Auth? I’ve even whitelisted specific users and still their messages sometimes get caught. Shouldn’t whitelist take care of incoming and not outgoing? Should I just turn off outgoing tests? I seem to have misplaced the original message, but here are the headers of another message that follows the same rules. It wasn’t scanned twice, but it doesn’t show as whitelisted either. Received: from DTRAYOWCRO001.pngxnet.com [209.87.233.98] by ute-sei.org with ESMTP (SMTPD32-8.15) id A4071060152; Tue, 07 Jun 2005 08:33:11 -0400 Received: from UTENP01 ([10.255.255.142]) by DTRAYOWCRO001.pngxnet.com (8.12.4/8.12.4) with ESMTP id j57CfnGK023801 for <[EMAIL PROTECTED]>; Tue, 7 Jun 2005 08:41:53 -0400 From: "Betty Bannon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: FW: FW: utelocals distribution list Date: Tue, 7 Jun 2005 08:41:36 -0400 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Declude-Sender: [EMAIL PROTECTED] [209.87.233.98] X-Declude-Spoolname: D94070106015219BF.SMD X-Declude-Note: Scanned by Declude 2.0.6 (http://www.declude.com/x-note.htm) for spam. X-Declude-Scan: Score [-5] at 08:33:13 on 07 Jun 2005 X-Declude-Tests: None X-Country-Chain: CANADA->destination X-RCPT-TO: <[EMAIL PROTECTED]> Status: U X-UIDL: 418092265 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: June 7, 2005 10:42 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not Susan Duncan wrote: That still doesn’t explain why someone who is whitelisted still has some of their email caught. That's not the issue, they aren't actually both happening at the same time. It's being double scanned, and it is only being whitelisted when it is being sent, but not when it is received (over one minute later according to your logs). The full headers should have showed the complete path that the E-mail took and it would be easier to diagnose if they were shared (the Received lines). I'm thinking that maybe this E-mail was sent from your server to an address on another server that was actually forwarded back to her address on your server. That's the only way that I can think of that would generate two different spool file names, and cause it to be scanned twice by Declude in this way; adding headers each time. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
Just a little follow up about this. The first E-mail appears to be sent from your server in some sort of automated fashion (denoted by the GSC extension on the Q file). These are either postmaster messages, or some message created by calling imail1.exe directly (probably some bulk-mail script in this case, maybe even the listserv). It comes from the address [EMAIL PROTECTED] and was sent to a long list of addresses (too long for IMail not to throw an error). It was whitelisted on the way out. Then, one of the addresses on attglobal.net that it is sent to is apparently forwarding back to [EMAIL PROTECTED]. It is natural that it gets scanned coming back in, creating a second set of headers and a different spool file name. Your logs show the connecting hop as 32.97.166.48 which is in8.prserv.net and is used by AT&T for sending/forwarding E-mail. The E-mail was being blocked because of a combination of primarily two things. First, your DNS setup was initially not allowing your server to resolve your own MX records causing a failure in the MAILFROM test when this came in from the other server with a Mail From domain of ute-sei.org. Secondly, you are using MXRATE-BLOCK which has issues with tagging legitimate servers with high volume that allow forwarding (and some that are just simply high volume). To this blacklist, when spam is received by an AT&T hosted account that is then forwarded to an account on a different provider's machine that is sourced for data to generate MXRATE-BLOCK, it ends up tagging the forwarding server instead of the actual source. I stopped using MXRATE because of their issues with such things, in addition to them tagging a lot of legitimate bulk-mail that many blacklists have issues with and I didn't want to compound such issues further on my system. I don't know what you score MXRATE-BLOCK at, but you might consider dropping the score a bit if you weight it heavily Matt Matt wrote: Susan Duncan wrote: That still doesn’t explain why someone who is whitelisted still has some of their email caught. That's not the issue, they aren't actually both happening at the same time. It's being double scanned, and it is only being whitelisted when it is being sent, but not when it is received (over one minute later according to your logs). The full headers should have showed the complete path that the E-mail took and it would be easier to diagnose if they were shared (the Received lines). I'm thinking that maybe this E-mail was sent from your server to an address on another server that was actually forwarded back to her address on your server. That's the only way that I can think of that would generate two different spool file names, and cause it to be scanned twice by Declude in this way; adding headers each time. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
It seems to be happening when staff are not in the office when they send the mail. When they are out of office they connect to email either through webmail or use outlook same as always but use an outside ISP. In some cases, they have to use some mail proxy server as some of the ISPs are blocking access to port 25 on servers that are not their own. X-Declude-Sender: [EMAIL PROTECTED] [127.0.0.1] X-Declude-Sender: [EMAIL PROTECTED] [32.97.166.48] The first time around it shows the local loop address and the second time around the dial-up ISP (att global) address. Should I still be getting this if I use Whitelist Auth? I’ve even whitelisted specific users and still their messages sometimes get caught. Shouldn’t whitelist take care of incoming and not outgoing? Should I just turn off outgoing tests? I seem to have misplaced the original message, but here are the headers of another message that follows the same rules. It wasn’t scanned twice, but it doesn’t show as whitelisted either. Received: from DTRAYOWCRO001.pngxnet.com [209.87.233.98] by ute-sei.org with ESMTP (SMTPD32-8.15) id A4071060152; Tue, 07 Jun 2005 08:33:11 -0400 Received: from UTENP01 ([10.255.255.142]) by DTRAYOWCRO001.pngxnet.com (8.12.4/8.12.4) with ESMTP id j57CfnGK023801 for <[EMAIL PROTECTED]>; Tue, 7 Jun 2005 08:41:53 -0400 From: "Betty Bannon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: FW: FW: utelocals distribution list Date: Tue, 7 Jun 2005 08:41:36 -0400 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Declude-Sender: [EMAIL PROTECTED] [209.87.233.98] X-Declude-Spoolname: D94070106015219BF.SMD X-Declude-Note: Scanned by Declude 2.0.6 (http://www.declude.com/x-note.htm) for spam. X-Declude-Scan: Score [-5] at 08:33:13 on 07 Jun 2005 X-Declude-Tests: None X-Country-Chain: CANADA->destination X-RCPT-TO: <[EMAIL PROTECTED]> Status: U X-UIDL: 418092265 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: June 7, 2005 10:42 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not Susan Duncan wrote: That still doesn’t explain why someone who is whitelisted still has some of their email caught. That's not the issue, they aren't actually both happening at the same time. It's being double scanned, and it is only being whitelisted when it is being sent, but not when it is received (over one minute later according to your logs). The full headers should have showed the complete path that the E-mail took and it would be easier to diagnose if they were shared (the Received lines). I'm thinking that maybe this E-mail was sent from your server to an address on another server that was actually forwarded back to her address on your server. That's the only way that I can think of that would generate two different spool file names, and cause it to be scanned twice by Declude in this way; adding headers each time. Matt -- =MailPure custom filters for Declude JunkMail Pro.http://www.mailpure.com/software/=
Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
Susan Duncan wrote: That still doesn’t explain why someone who is whitelisted still has some of their email caught. That's not the issue, they aren't actually both happening at the same time. It's being double scanned, and it is only being whitelisted when it is being sent, but not when it is received (over one minute later according to your logs). The full headers should have showed the complete path that the E-mail took and it would be easier to diagnose if they were shared (the Received lines). I'm thinking that maybe this E-mail was sent from your server to an address on another server that was actually forwarded back to her address on your server. That's the only way that I can think of that would generate two different spool file names, and cause it to be scanned twice by Declude in this way; adding headers each time. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] X-RBL-Warning??
This part of the problem seems to be fixed. I added an MX record to my internal DNS and I’m no longer getting the error. I was confused because I checked the DNS lookups and everything seemed fine but I’d forgotten that it first looks at our internal version. Thanks for the reply. Susan Duncan Web/Communications Officer / Agent des Communications/web Union of Taxation Employees / Syndicat des employées de l'Impôt Tel: 613-235-6704 ext 240 Fax: 613-234-7290 e-mail: [EMAIL PROTECTED] http://www.ute-sei.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Patterson Sent: June 7, 2005 10:00 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] X-RBL-Warning?? It looks like it should have passed, http://www.dnsstuff.com/tools/lookup.ch?name=ute-sei.org&type=MX . I would turn the declude log level to High and send another test, this will give you more information on how it is checking. Thanks, Chris Patterson, CCNA Network Engineer/Support Manager From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Duncan Sent: Monday, June 06, 2005 1:49 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] X-RBL-Warning?? I’m resending this as I didn’t get any replies. Anyone?? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Duncan Sent: May 31, 2005 9:35 AM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] X-RBL-Warning?? Our own domain is getting caught with an X-RBL-Warning: X-RBL-Warning: MAILFROM: Domain ute-sei.org has no MX or A records [0001]. I checked the documentation for this and found: Each line determines the action to take for a specific test; for example, "ORBZ WARN" lets Declude JunkMail know to add a standard "X-RBL-Warning:" header for E-mail that fails the ORBZ test. I can’t find how to check the ORBZ test. Everything I look up tells me that this domain doesn’t exist anymore. Any other checks I make on our domain points to the MX record being defined properly. What should I be checking or changing? Susan Duncan Web/Communications Officer / Agent des Communications/web Union of Taxation Employees / Syndicat des employées de l'Impôt Tel: 613-235-6704 ext 240 Fax: 613-234-7290 e-mail: [EMAIL PROTECTED] http://www.ute-sei.org/
RE: [Declude.JunkMail] X-RBL-Warning??
It looks like it should have passed, http://www.dnsstuff.com/tools/lookup.ch?name=ute-sei.org&type=MX . I would turn the declude log level to High and send another test, this will give you more information on how it is checking. Thanks,Chris Patterson, CCNANetwork Engineer/Support Manager From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan DuncanSent: Monday, June 06, 2005 1:49 PMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] X-RBL-Warning?? Im resending this as I didnt get any replies. Anyone?? -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan DuncanSent: May 31, 2005 9:35 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] X-RBL-Warning?? Our own domain is getting caught with an X-RBL-Warning: X-RBL-Warning: MAILFROM: Domain ute-sei.org has no MX or A records [0001]. I checked the documentation for this and found: Each line determines the action to take for a specific test; for example, "ORBZ WARN" lets Declude JunkMail know to add a standard "X-RBL-Warning:" header for E-mail that fails the ORBZ test. I cant find how to check the ORBZ test. Everything I look up tells me that this domain doesnt exist anymore. Any other checks I make on our domain points to the MX record being defined properly. What should I be checking or changing? Susan Duncan Web/Communications Officer / Agent des Communications/webUnion of Taxation Employees / Syndicat des employées de l'ImpôtTel: 613-235-6704 ext 240Fax: 613-234-7290e-mail: [EMAIL PROTECTED]http://www.ute-sei.org/
RE: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not
Robert, I did that too, but we also had the web server to deal with and some servers within our building that we couldn’t connect to without going through ‘fake’ listings in our own DNS. The long and short is that running my own DNS is an operational requirement unless we change internet providers and completely reconfigure our firewall to do NAT properly. That still doesn’t explain why someone who is whitelisted still has some of their email caught. Susan Duncan Web/Communications Officer / Agent des Communications/web Union of Taxation Employees / Syndicat des employées de l'Impôt Tel: 613-235-6704 ext 240 Fax: 613-234-7290 e-mail: [EMAIL PROTECTED] http://www.ute-sei.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sent: June 6, 2005 5:38 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not we just put our mail server ip in the hosts file. just a mention. robert - Original Message - From: Susan Duncan To: Declude.JunkMail@declude.com Sent: Monday, June 06, 2005 5:12 PM Subject: RE: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not I fixed the DNS already. As I said it was missing the MX record in my internal dns. I need to run a separate DNS as the email server is behind the firewall and with the current configuration the only way for anyone internal to see the web or email server is to run my own mini dns. 06/01/2005 21:19:04 Q5E8705DC5A1F Skipping E-mail from authenticated user [EMAIL PROTECTED]; whitelisted. This is the only line in the declude log file pertaining to the first spool name. 06/01/2005 21:20:52 Q5EF114F40118D5BC L1 Message OK 06/01/2005 21:20:52 Q5EF114F40118D5BC Tests failed [weight=18]: CATCHALLMAILS=IGNORE IPNOTINMX=IGNORE MXRATE-BLOCK=WARN MAILFROM=WARN SUBJECTCHARS=WARN WEIGHT10=SUBJECT WEIGHT14=ROUTETO 06/01/2005 21:20:52 Q5EF114F40118D5BC Action(s) taken for [EMAIL PROTECTED] = IGNORE WARN SUBJECT ROUTETO [LAST ACTION=""> These are the lines pertaining to the second spool name. Susan Duncan Web/Communications Officer / Agent des Communications/web Union of Taxation Employees / Syndicat des employées de l'Impôt Tel: 613-235-6704 ext 240 Fax: 613-234-7290 e-mail: [EMAIL PROTECTED] http://www.ute-sei.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: June 6, 2005 4:53 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] X-RBL-Warning // Whitelisted but not Susan, The double scanning seemed secondary to the problem at hand. You should re-read my message for info about fixing DNS in order to solve the issue. As far as the logs go, you are sending IMail logs and not the Declude JunkMail logs. It would be best to also share your JunkMail log entries corresponding to the headers so one could better figure out what was going on. Your IMail log seems to indicate that there were too many recipients in one message and that caused the Q file to exceed the allowed size. That might have cut off parts of a recipient address or caused other issues. Declude's logs would shed more light on this. Matt ==
