Dear all,
I am not sure if this issue has been discussed.I am going to ask ,
I found Postfix will put the string which is used as hello name in the
received header. That is, if I try to using a fake name or ip as my
hello name during a SMTP conversation, postfix will output a fake
header in the mail and deliver it. Doesn't it make the anti-spam
product being confused when parsing the mail source and doing RBL
checking?
Comments
Re: Received header and fake hello name
By Noel Jones at 07/17/2012 - 12:01On 7/17/2012 10:26 AM, LittleCho wrote:
First, remember that a helo command is basically a comment, and is
always treated as such. The helo is never treated as verified,
reliable information.
Postfix records the helo command as given by the client in a
Received: header.
Although a client can give an IP as the helo name, it is still just
a comment and does not override the actual client IP, which is
impractical to fake. Neither postfix nor any anti-spam system will
ever use a helo IP in routing decisions.
No. Helo information is well-known to be easily faked, and no
anti-spam nor RBL will rely on it for whitelisting.
Sometimes faked helo names can be used for blacklisting, such as if
a client uses "paypal.com" as helo, but the client hostname is
something like 189-68-88-213.dsl.telesp.net.br, it will be pretty
obvious to most anti-spam systems that it's not really paypal.
-- Noel Jones
Re: Received header and fake hello name
By LittleCho at 07/17/2012 - 12:16引述 Noel Jones < ... at megan dot vbhcs.org>:
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 < ... at domain dot tld>; 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? 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.
It may effect the RBL checking result while we are using the IP with
better reputation as our hello name. And that is, some spammer will
try to use the ip address which our MTA is using as the hello name, if
we didn't set the hello check policy or 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. :)
Re: Received header and fake hello name
By Noel Jones at 07/17/2012 - 12:44On 7/17/2012 11:16 AM, LittleCho wrote:
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
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.
Fake helo names are mostly for confusing humans that look at
Received: headers. Let the software handle it.
-- Noel Jones
Re: Received header and fake hello name
By LittleCho at 07/17/2012 - 13:12引述 Noel Jones < ... at megan dot vbhcs.org>:
Yes, I confirmed that in RFC 5321 section 4.4.
Re: Received header and fake hello name
By Bill Cole at 07/18/2012 - 17:59Yes, and there's a good reason for that. The HELO parameter is an
identity that the sending system knows for itself. In cases where
multiple systems are subjected to NAT gateways that put their traffic on
one external IP address, the HELO can be useful in identifying which one
of the systems sharing the NAT handled the transaction.