Re: [Declude.JunkMail] Declude 4.9.39 Interim Release Notes

Thu, 05 Nov 2009 13:26:18 -0800 

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 <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 <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.






















					Reply via email to