Weblog entry #2 for Dimon
See all weblog entries made by Dimon.
#2
Postfix to rewrite (or masquerade) Received header
Posted by Dimon on Tue 15 May 2007 at 09:16
I'm using postfix (2.3.7 on debian sarge) as my smtp server with tls
encryption and plain authentication.
However, the mail sent to some domains is returned with the
"Considered UNSOLICITED BULK EMAIL" message. It seems to happen
because my original IP that is recorder into the first Received header
hasn't corresponding dns record.
Return-Path: <user@domain.com>
Received: from domain.com (domain.com [xxx.xxx.xxx.xxx])
by mail.somesite.ru (Postfix) with ESMTP id 056107E82B
for <user@somesite.ru>; Tue, 15 May 2007 12:35:38 +0700 (OMSST)
Received: from localhost (localhost [127.0.0.1])
by domain.com (Postfix) with ESMTP id 1E7F011201DA
for <user@somesite.ru>; Tue, 15 May 2007 12:35:56 +0700 (NOVST)
X-Virus-Scanned: Debian amavisd-new at domain.com
Received: from domain.com ([127.0.0.1])
by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1GYG1hdCuSdR for <user@somesite.ru>;
Tue, 15 May 2007 12:35:53 +0700 (NOVST)
Received: from user (unknown [xx.xx.xx.xx])
by domain.com (Postfix) with ESMTP id E0F4911201A6
for <user@somesite.ru>; Tue, 15 May 2007 12:35:52 +0700 (NOVST)
(I replaced my hostname with domain.com, it's ip with xxx.xxx.xxx.xxx;
my email with user@domain.com, my original ip with xx.xx.xx.xx and
recipient email with user@somesite.com)
So as it's written in the bounced email:
First upstream SMTP client IP address: [xxx.xxx.xxx.xxx] domain.com
According to a 'Received:' trace, the message originated at: [xx.xx.xx.xx],
user (unknown [xx.xx.xx.xx])
The question is: is there any way to skip adding first Received: header;
the best will be if it will be looking like I'm sending emails
directly from the domain.com server? I found something that seems to
be related to this configuration but couldn't point out right way to
do this this.
encryption and plain authentication.
However, the mail sent to some domains is returned with the
"Considered UNSOLICITED BULK EMAIL" message. It seems to happen
because my original IP that is recorder into the first Received header
hasn't corresponding dns record.
Return-Path: <user@domain.com>
Received: from domain.com (domain.com [xxx.xxx.xxx.xxx])
by mail.somesite.ru (Postfix) with ESMTP id 056107E82B
for <user@somesite.ru>; Tue, 15 May 2007 12:35:38 +0700 (OMSST)
Received: from localhost (localhost [127.0.0.1])
by domain.com (Postfix) with ESMTP id 1E7F011201DA
for <user@somesite.ru>; Tue, 15 May 2007 12:35:56 +0700 (NOVST)
X-Virus-Scanned: Debian amavisd-new at domain.com
Received: from domain.com ([127.0.0.1])
by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1GYG1hdCuSdR for <user@somesite.ru>;
Tue, 15 May 2007 12:35:53 +0700 (NOVST)
Received: from user (unknown [xx.xx.xx.xx])
by domain.com (Postfix) with ESMTP id E0F4911201A6
for <user@somesite.ru>; Tue, 15 May 2007 12:35:52 +0700 (NOVST)
(I replaced my hostname with domain.com, it's ip with xxx.xxx.xxx.xxx;
my email with user@domain.com, my original ip with xx.xx.xx.xx and
recipient email with user@somesite.com)
So as it's written in the bounced email:
First upstream SMTP client IP address: [xxx.xxx.xxx.xxx] domain.com
According to a 'Received:' trace, the message originated at: [xx.xx.xx.xx],
user (unknown [xx.xx.xx.xx])
The question is: is there any way to skip adding first Received: header;
the best will be if it will be looking like I'm sending emails
directly from the domain.com server? I found something that seems to
be related to this configuration but couldn't point out right way to
do this this.
Comments on this Entry
ok, so here seems to be a solution:
I had to install postfix-pcre package and then add the following configurations:
add the line
header_checks = pcre:/etc/postfix/headers.pcre
into main.cf
and something like
/^Received:.*\(unknown/ IGNORE
into the headers.pcre file to strip 'problem' headers from the mail
<br/>
--
<br/>
<a href="http://www.softaria.com"; rel="nofollow">SoftAria: Prime grade software development</a>
I had to install postfix-pcre package and then add the following configurations:
add the line
header_checks = pcre:/etc/postfix/headers.pcre
into main.cf
and something like
/^Received:.*\(unknown/ IGNORE
into the headers.pcre file to strip 'problem' headers from the mail
<br/>
--
<br/>
<a href="http://www.softaria.com"; rel="nofollow">SoftAria: Prime grade software development</a>
[ Parent | Reply to this comment ]
I was going to suggest header_checks.
Note it does affect both inbound and outbound.
However are you sure the spam check is triggered because of this record? Some people add some pretty strange things to their spam checks, sometimes it is better just to tell them the test is daft, rather than fiddle with your email configuration.
Note it does affect both inbound and outbound.
However are you sure the spam check is triggered because of this record? Some people add some pretty strange things to their spam checks, sometimes it is better just to tell them the test is daft, rather than fiddle with your email configuration.
[ Parent | Reply to this comment ]
Yeah, you may be right; but tracking Received headers is common practice for UBE filters that are quite common in their turn :), so I think it's worth to remove sucj headers, besides it will help to hide some information that isn't supposed to be public like 192.168.xx ip addresses etc.
--
SoftAria: Prime grade software development
--
SoftAria: Prime grade software development
[ Parent | Reply to this comment ]
We are looking at adding some Received header tests, but we'd only reject on it if the address was clearly blacklists as a known source of spam. Which is what I'm getting at -- what is it about these Received headers they don't like.
Fiddling with headers like this is RFC infringing, any inconsistent or incomplete Received headers I'd accept as reasonable grounds for a spam rejection.
Are you sure it isn't just the clients IP address is on a blacklist somewhere?
Fiddling with headers like this is RFC infringing, any inconsistent or incomplete Received headers I'd accept as reasonable grounds for a spam rejection.
Are you sure it isn't just the clients IP address is on a blacklist somewhere?
[ Parent | Reply to this comment ]
yes, I'm quite sure about this, because after I added header_check and removed the last header (with "unknown" word), first received header was the one added by amavisd and next email returned with the error message claiming about it (so I turned off adding header information in amavis).
Anyway, I don't think that stripping local delivery information from email will be the kind of RFC infringing; for the outside world it looks like my system is sending emails directly, and it's a kind of behavior I need.
Here is some quote from internet about it: Traceability of email passing through the system
Tracing the source of email requires that all systems comply with the email standards and add a "Received" header line as the email passes through them. This serves to identify the machine that is adding the header and the machine from which the email arrived. In principle, the oldest such line indicates the source of the email. In practice, this is sometimes forged, and to trace the true sender it is necessary to work through the Received lines in time order until a discontinuity is found.
The senders of email will sometimes try to obscure the true origin of email by forging the name of the source machine in the "HELO" protocol command. This type of forgery is made easy to detect by ensuring that the Received line contains not only the name, but also the IP address of the sending system, since the latter cannot be disguised. Requirements
ISPs MUST ensure that a standards-compliant "Received" line is added to all email that passes through their systems.
ISPs MUST ensure that the identity of the machine passing them the email is correctly recorded. The HELO announcement MUST NOT be treated as being valid and an IP address SHOULD be recorded.
--
SoftAria: Prime grade software development
Anyway, I don't think that stripping local delivery information from email will be the kind of RFC infringing; for the outside world it looks like my system is sending emails directly, and it's a kind of behavior I need.
Here is some quote from internet about it: Traceability of email passing through the system
Tracing the source of email requires that all systems comply with the email standards and add a "Received" header line as the email passes through them. This serves to identify the machine that is adding the header and the machine from which the email arrived. In principle, the oldest such line indicates the source of the email. In practice, this is sometimes forged, and to trace the true sender it is necessary to work through the Received lines in time order until a discontinuity is found.
The senders of email will sometimes try to obscure the true origin of email by forging the name of the source machine in the "HELO" protocol command. This type of forgery is made easy to detect by ensuring that the Received line contains not only the name, but also the IP address of the sending system, since the latter cannot be disguised. Requirements
ISPs MUST ensure that a standards-compliant "Received" line is added to all email that passes through their systems.
ISPs MUST ensure that the identity of the machine passing them the email is correctly recorded. The HELO announcement MUST NOT be treated as being valid and an IP address SHOULD be recorded.
--
SoftAria: Prime grade software development
[ Parent | Reply to this comment ]