RE: [Declude.JunkMail] HELO Filter not Working?
Remember, Declude JunkMail looks at the HELO/EHLO of the remote mailserver, based on IPBYPASS/HOP Uh - that's the answer. Thanks for clearing this up. So the HELO is not necessarily taken from the HELO, but from the HEADER. Both, actually. Declude JunkMail gets the HELO from the real HELO/EHLO from the SMTP envelope. The method Declude JunkMail uses to obtain the HELO, however, is the headers. Note that if Declude JunkMail used IMail's SMTP envelope as the method of obtained the HELO, Declude JunkMail could get the wrong HELO (as would be the case if there are gateways). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. This outgoing message is guaranteed to be authentic by Message Level users. Guarantee the authenticity of your email @ http://www.messagelevel.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] 1.82 - Last Action no longer logged for IGNORE
Please note the subject: I AM running 1.82 (the SpamHeader fix!) It's only missing if LOG_OK is NONE. 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 R. Scott Perry Sent: Saturday, January 08, 2005 09:48 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 1.82 - Last Action no longer logged for IGNORE Can you remind me, what additional messages/log lines I will see if #LOG_OK NONE is commented out? With v1.82, it will add back the Message OK line(s) and the Tests Failed line(s). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. This outgoing message is guaranteed to be authentic by Message Level users. Guarantee the authenticity of your email @ http://www.messagelevel.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] 1.82 - Last Action no longer logged for IGNORE
Can you remind me, what additional messages/log lines I will see if #LOG_OK NONE is commented out? With v1.82, it will add back the Message OK line(s) and the Tests Failed line(s). Please note the subject: I AM running 1.82 (the SpamHeader fix!) Yes, I am aware of that. It's only missing if LOG_OK is NONE. Correct. You asked what additional lines you will see if you comment out LOG_OK NONE. Commenting it out will add back the Message OK line(s) and the Tests Failed line(s). I made the comment about 1.82 as it was the version you are running, and there were many changes to the logging in 1.75 and earlier. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. This outgoing message is guaranteed to be authentic by Message Level users. Guarantee the authenticity of your email @ http://www.messagelevel.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] HELO Filter not Working?
Both, actually. Declude JunkMail gets the HELO from the real HELO/EHLO from the SMTP envelope. The method Declude JunkMail uses to obtain the HELO, however, is the headers. Ok, this is clear as mudwhich is it, envelope or headers? Or is there a precedence, so in some circumstances it uses one and in others uses the other? Darin. --- [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] DLAnalyzer - upgrading from 1.79i16 to 1.82
Uuuh - okay. Thanks for clearing this up. I was running 1.79i16 before - so the changes occurred between 1.79i16 and 1.82 To be pragmatic, I guess the Log_OK none is no longer really that relevant as it once seemed. Now that at least 80% is spam anyway causing multi-line entries, it really doesn't matter if we add a few single lines for the other 20%. DLAnalyzer customers have to be aware that they MUST NOT run LOG_OK NONE if they upgrade from 1.79i16, which I think is perfectly acceptable. 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 R. Scott Perry Sent: Saturday, January 08, 2005 09:58 AM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] 1.82 - Last Action no longer logged for IGNORE Can you remind me, what additional messages/log lines I will see if #LOG_OK NONE is commented out? With v1.82, it will add back the Message OK line(s) and the Tests Failed line(s). Please note the subject: I AM running 1.82 (the SpamHeader fix!) Yes, I am aware of that. It's only missing if LOG_OK is NONE. Correct. You asked what additional lines you will see if you comment out LOG_OK NONE. Commenting it out will add back the Message OK line(s) and the Tests Failed line(s). I made the comment about 1.82 as it was the version you are running, and there were many changes to the logging in 1.75 and earlier. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. This outgoing message is guaranteed to be authentic by Message Level users. Guarantee the authenticity of your email @ http://www.messagelevel.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] HELO Filter not Working?
The short/direct answer is: Declude gets it from the header. It doesn't watch the SMTP conversation. That information is inserted by Imail (or a server you trust by specifying IPBYPASS) by copying it from the HELO string. It only makes sense once I thought about it. 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 R. Scott Perry Sent: Saturday, January 08, 2005 11:05 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] HELO Filter not Working? Both, actually. Declude JunkMail gets the HELO from the real HELO/EHLO from the SMTP envelope. The method Declude JunkMail uses to obtain the HELO, however, is the headers. Ok, this is clear as mudwhich is it, envelope or headers? The SMTP envelope contains information about the E-mail that may or may not appear in the headers. The most common information is the true sender (MAIL FROM) and the actual recipients (as they may be Bcc:s). There are several SMTP envelopes as the E-mail passes from computer to computer, but you can only access the true SMTP envelope on the current server. However, some of the information from the SMTP envelope does go into the headers. The HELO/EHLO will appear in the Received: header. So it *is* as clear as mud. :) The information is obtained from the headers, and is added to the headers from information that comes from the SMTP envelope. So the information Declude JunkMail gets is the same as the information in the SMTP envelope, but Declude JunkMail gets it from somewhere else. It's kind of like asking Did you get Joe's number from the phone company? -- it kind of a silly question, the answer to which would not be obvious (no, you got the number from Joe, but he got it from the phone company). Or is there a precedence, so in some circumstances it uses one and in others uses the other? It's a moot point, really, except for scholars. Declude JunkMail will get the same information from the SMTP envelope as it gets from the headers, unless a trusted mailserver lies (in which case you have bigger problems), or if an error occurs on the mailserver creating the headers (in which case you also have bigger problems). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. This outgoing message is guaranteed to be authentic by Message Level users. Guarantee the authenticity of your email @ http://www.messagelevel.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] HELOBOGUS for Email from Postfix Gateway
Title: Message Hi Scott, I'm colocating a Postfix gateway for a client - and "external" mail is being routed fine. However, I'm having a problem with Declude triggering on reporting emails that are generated directly ON the gateway itself: -I have IPBYPASS set for 67.132.45.18 (which is how it should be). -Declude parses IP Address 0.0.0.0 -Declude parses HELO string of "userid" Here is what Declude parsed from the RECEIVED header (2nd and even 3rd hop) Mail Server: %REMOTEIP% for %RHSBL% [%SENDERHOST%] DNS Pointer: %REVDNS% Host Name: %HELO% Mail Server: 0.0.0.0 for mail.dollardays.com [mail.dollardays.com] DNS Pointer: (Private IP) Host Name: userid Here is the headers that Postfix generates for email that originates from that machine: Received: from mail.dollardays.com [67.132.45.18] by mail.webhost.hm-software.com with ESMTP (SMTPD32-8.14) id A4F0800114; Sat, 08 Jan 2005 04:16:32 -0500 Received: by mail.dollardays.com (Postfix) id BD39835A9D2; Sat, 8 Jan 2005 04:16:24 -0500 (EST) Received: by mail.dollardays.com (Postfix, from userid 0) id A8FC335A9CE; Sat, 8 Jan 2005 04:16:24 -0500 (EST) As you can see, it a) has no FROM field in the received header - that's what's causing the "0.0.0.0" being reported as the IP address b) it picking up "userid" form inside an SMTP header comment - the string is included inside paranthesis, thus should NOT be interpreted by Declude. I think item b)is truly a malfunction by Declude. At "worst" it should detect the HELO string as null. However, ideally, I wonder whether Declude should only "hop" to the next Receive line, if the receive line actuallyDOES havea "FROM" field. If there is no other Received/From line, then it should use the information from the LASTVALID Receivedtimestamp (which in this case would be the header inserted by Imail) - which would then yield correct results. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206
[Declude.JunkMail] Sniffer vs. SURBL
Title: Message Hi, Today I finally took the time (I didn't have) and ran both Sniffer and SURBL Tests (using http://www.invariantsystems.com/invURIBL/). Result: 1,860 tagged by invURIBL only - gain over Sniffer= 21% 8,926 tagged by BOTH invURIBLAND Sniffer 962 tagged by Sniffer only - gain over invURIBL = 11% In other words: If I ran ONLY Sniffer, I would have missed 21% of additional messages that were detected by checking against SURBL. If I tested SURBL only, I would have missed 11% of messages (that only Sniffer found) I have configured Declude, so that the two tests are complimentary (no extra weightBOTH testsvs. ONE test fails.) My conclusion: Both Sniffer and invURIBL are worth their money... PS: here the "raw" numbers: DLAnalyzer(4.0.5 - 12/21/2004) Report Generated At 1/9/2005 12:48:14 AM For Argos.net Breakdown Of Messages That Failed: INV-URIBLMessages That Matched: 10,786 TEST # FAILED PercentageIPNOTINMX..10,372...96.16%SNIFFER.8,926...82.76%NOLEGITCONTENT..8,673...80.41%SPAMCOP.4,983...46.20%SORBS...4,521...41.92%XBL-DYNA4,470...41.44% Breakdown Of Messages That Failed: SNIFFERMessages That Matched: 9,888 TEST # FAILED PercentageIPNOTINMX...9,611...97.20%INV-URIBL...8,926...90.27%NOLEGITCONTENT..8,788...88.88%SPAMCOP.5,208...52.67%XBL-DYNA4,672...47.25%SORBS...4,664...47.17% Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206
