On 7/17/2012 11:16 AM, LittleCho wrote: > Yes, please refer to the sample header shown below: > > Received: from 1.175.147.22 (gate.tcssh.tc.edu.tw [203.71.212.252]) > by mail.localdomain (Postfix) with ESMTP id 3903777002 > for <[email protected]>; Tue, 17 Jul 2012 22:38:54 +0800 (CST) > > We can see the ip after from is "1.175.147.22" but the original > source "203.71.212.252". I am going to ask when the case is > encountered, we could find that those two column is mismatch, > however, why not just let postfix put the client IP after the from > column but using the hello name?
The helo command is always placed in that position. That's how you (and more importantly, software that parses the headers) know it's a helo and not a real IP. Any software that treats that as a real IP is broken. Also, that's an invalid helo command and can be used to reject the mail or mark it as spam. When an IP literal is used in the helo, it MUST be enclosed in "[ ]" brackets. So including it in the header is useful information, since it can be used to easily detect some spam. You can reject such non-compliant mail with a postfix check_helo_access regexp something like /^[0-9.]+$/ REJECT invalid HELO hostname > I know some anti-spam product will > do bottom up parsing and may get the wrong source IP when trying to > locate the sender IP. Any anti-spam product that uses a helo IP for whitelisting is badly broken and should not be used. Any anti-spam product that does RBL lookups on a helo IP literal is badly broken and should not be used. > we just want to let our policy be not strict, the client may have > the possibility to cheat our post-filtering program. Thanks for your > reply. :) Fake helo names are mostly for confusing humans that look at Received: headers. Let the software handle it. -- Noel Jones
