Hi Matt,
Sorry - but some of these are actually headers inserted by my OWN server. So they are NOT forged. Most of them are "spam", but some of them were even false positives. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Matt Sent: Thursday, November 05, 2009 4:14 PM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] Declude 4.9.39 Interim Release Notes Andy, One important thing of note here is that the first 5 examples you gave are in fact forged headers, and the information contained within them is fake and not at all useful. While I don't expect Declude to figure out that these are forged Received headers, one shouldn't worry about how they are parsed as they can be malformed anyway (as was the case in several examples shown). As a good rule of thumb, you def-old the entire Received header and then take the data in between the FROM and the BY/WITH/FOR or the end of the header, whichever appears first, and then take the last braketed IP value. If you can't find a bracketed IP value, you should take the last IP shown (which won't be perfect, but this would not be RFC compliant anyway). I would guess that this would take a programmer maybe an hour to code up and test. Matt Andy Schmidt wrote: Hi Dave, just sent you a zip file - hope it made it past your virus check. It has a few "interesting" cases to see if your new code picks up the CORRECT IP address. Always picking the "first" or the "last" IP address is not at all necessarily reliable. Received: from unknown (HELO 192.168.10.1) (72.167.113.99) by k2smtpout02-01.prod.mesa1.secureserver.net (64.202.189.90) with ESMTP; 04 Nov 2009 08:29:08 -0000 Received: from 58.92.178.208 ([208.178.92.58]) by smtp.webhost.hm-software.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Nov 2009 10:43:37 -0500 Received: from admd.net ([::ffff:187.3.43.120]) (AUTH: LOGIN audito...@vazemaia.com.br) by mail4.task.com.br with esmtp; Wed, 04 Nov 2009 01:53:07 -0200 id 00000000006788A4.000000004AF0FAA3.0000242C Received: from (]) by mx1.businessprocessware.com [66.232.102.164] (8.13.8/8.13.8) STMP id mzqbrzhqqbq; for <mailto:jul...@websterwatch.com> <jul...@websterwatch.com>; Wed, 04 Nov 2009 14:40:40 -0500 Received: from 105.188.233.220.static.exetel.com.au [220.233.188.105] by Mail.Webhost.HM-Software.com with ESMTP (SMTPD-11.0) id 0afd00000fb0197a; Thu, 5 Nov 2009 06:45:55 -0500 Received: from mail.headquarters.qts.local ([192.168.0.103]) by mail.headquarters.qts.local ([70.99.176.211]) with mapi; Thu, 5 Nov 2009 09:40:05 -0600 Received: from [195.248.173.117] (HELO 192.168.1.75) by mail.alkar.net (CommuniGate Pro SMTP 5.2.16) with SMTP id 2124311918 for abus...@ultirisk.com; Tue, 03 Nov 2009 14:58:19 +0200 Best Regards, Andy -----Original Message----- From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of David Barker Sent: Thursday, November 05, 2009 10:57 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Declude 4.9.39 Interim Release Notes Hi Andy, Great suggestion. Can you send some full header examples to me directly so we can review this, if you have the matching pair files even better as we can use them to test specifically. Thanks David Barker VP Operations Declude Your Email security is our business 978.499.2933 office 978.988.1311 fax dbar...@declude.com -----Original Message----- From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Thursday, November 05, 2009 10:50 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Declude 4.9.39 Interim Release Notes Hi Dave, You might want to test this new option very carefully! >> You could be right, the original Declude code may have had an issue parsing the second IP. I do not know if this was by design or just bad code. << I think the explanation/reason was, that Scott was having issues with RECEIVED Headers where the sender's reverse DNS was set up to point to an apparent IP address or where the HELO/EHLO string was using an IP address. He might have encountered RECEIVED headers like this: Received: from 192.168.0.1 [10.1.20.1] (helo=192.168.0.1) by mx-out-manc2.simplymailsolutions.com with esmtp (Exim 4.63) (envelope-from <mailto:fredrik.karlb...@jameslist.com> <fredrik.karlb...@jameslist.com>) id 1N5zih-0005FR-15 for andy_schm...@hm-software.com; Thu, 05 Nov 2009 10:37:35 +0000 And eventually decided to ignore the "first" IP address and go for the last IP address in the first line - or something like that. This parsing problem is rather old and reported occasionally. I even recall this being an issue with "spamrouting" causing false positives if the header had more than one IP address - because it would pick up wrong IP addresses and think the routing was suspicious. If I can make a (VERY important) suggestion. Since this clearly is NOT at all a "Postini" issue and certainly NOT LIMITED to Postini - how about NOT giving that feature/directive a totally misleading/inappropriate name: POSTINIFIX ON Example - out of 10 emails in my current inbox, I instantly found THIS (non-Postini) sample: Received: from sha-exch9.shared.ifeltd.com ([10.1.20.9]) by sha-exch9.shared.ifeltd.com ([10.1.20.9]) with mapi; Thu, 5 Nov 2009 10:36:21 +0000 Calling it "PostiniFix" implies to people who don't use a Postini gateway, that they don't need that option. In reality this is an attempt at (finally) making Declude's Received header parsing RFC-compliant and should be the default way that Declude works all the time so that spamrouting and other features pick up the CORRECT ( "from" clause IP address ) and not get confused by any optional "by" clause IP address. If you want to make it an "option" (that propbably should default to "ON" if ommitted), I would suggest naming it something like: USEFROMCLAUSEIP ON or IGNOREBYCLAUSEIP ON depending on how your new parsing logic is set up (I would look for the 'BY' clause, if any, and then parse the IP addresses prior to the BY clause - possibly starting from the end - so to mimic Scott's original code and avoid reverse DNS confusion. Best Regards, Andy -----Original Message----- From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of David Barker Sent: Thursday, November 05, 2009 9:40 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Declude 4.9.39 Interim Release Notes It looks like this issue goes back to when Scott was around. You could be right, the original Declude code may have had an issue parsing the second IP. I do not know if this was by design or just bad code. http://www.mail-archive.com/declude.junkmail@declude.com/msg20816.html Either way, this is what it comes down too. Declude now identifies the first IP as the actual sender IP and not the second IP on Postini emails. This directive gives you the ability to choose how you would like Declude to parse Postini messages. David Barker VP Operations Declude Your Email security is our business 978.499.2933 office 978.988.1311 fax dbar...@declude.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, 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 imail...@declude.com, 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 imail...@declude.com, 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 imail...@declude.com, 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 imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
