Removing headers from SASL-authenticated SMTP hosts
Brandon Kuczenski
SASL.
When an authenticated user sends mail from a remote computer, the mail
retains a Received: header from the remote IP address. In the case that
this is a dynamic address, the message is then blemished in the eyes of
UCE filters, because even though the mail originates from a legitimate
server (mine), it still has what would be an otherwise illegitimate IP
address and reverse-DNS lookup in the headers (the dynamic IP).
Below is an example (with some of the specifics fudged). The first line
is the Received header from my server. The line below it is the one I
want to strip.
....
Received: from 301south.net (ocean.301south.net [74.0.242.82])
by destination.host (8.13.6/8.13.6) with ESMTP id kBT5Sd2f022202
for <reci...@destination.host>; Fri, 29 Dec 2006 00:28:40 -0500
Received: from [192.168.internal.IP] (c-dynamic-ip.wherever.comcast.net
[dyn.amic.ip.addr])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by 301south.net (Postfix) with ESMTP id 4A2D7FD96
for <reci...@destination.host>; Fri, 29 Dec 2006 00:28:40 -0500
(EST)
.......
I tried adding permit_sasl_authenticated to the
local_header_rewrite_clients configuration option. It now looks like
this:
local_header_rewrite_clients = permit_inet_interfaces
permit_sasl_authenticated
but that didn't do the trick. Where should I look next?
Thanks in advance!
-Brandon
Michael Wang
I have a similar situation. I send messages from my local machine at
home over DSL to my server using IMAP which then sends the message to
the recipient. I strip out my DSL specific received header using:
main.cf:
header_checks = pcre:/etc/postfix/header_checks.pcre
header_checks.pcre:
/Received:.*adsl-mydsl-junk.net/
IGNORE
I have no idea if that's an okay thing to do, though.
--
Michael Wang
Noel Jones
>Hello, list. I am running Postfix 2.1.5 with SMTP authentication via SASL.
>
>When an authenticated user sends mail from a remote computer, the
>mail retains a Received: header from the remote IP address. In the
>case that this is a dynamic address, the message is then blemished
>in the eyes of UCE filters, because even though the mail originates
>from a legitimate server (mine), it still has what would be an
>otherwise illegitimate IP address and reverse-DNS lookup in the
>headers (the dynamic IP).
With postfix 2.1 this is a little tricky. I think your best bet is
to enable the submission port for SASL users, and remove the
offending received headers on that port using a second cleanup
service. This means that your SASL users will need to configure
their mail software to submit mail to the submission port.
An alternative to all these master.cf gyrations is to configure a
second instance of postfix that listens only on the submission port.
# master.cf, adjust as needed
submission inet n - n - - smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o cleanup_service_name=sasl_cleanup
sasl_cleanup unix n - n - 0 cleanup
-o header_checks=regexp:/etc/postfix/header_checks_sasl
And then your header_checks_sasl would look something like:
# header_checks_sasl
/^Received: .*by 301south.net \(Post/ IGNORE
--
Noel Jones
Brandon Kuczenski
> At 12:20 AM 12/29/2006, Brandon Kuczenski wrote:
>> Hello, list. I am running Postfix 2.1.5 with SMTP authentication via SASL.
>>
>> When an authenticated user sends mail from a remote computer, the mail
>> retains a Received: header from the remote IP address. In the case that
>> this is a dynamic address, the message is then blemished in the eyes of UCE
>> filters, because even though the mail originates from a legitimate server
>> (mine), it still has what would be an otherwise illegitimate IP address and
>> reverse-DNS lookup in the headers (the dynamic IP).
>
> With postfix 2.1 this is a little tricky. I think your best bet is to enable
> the submission port for SASL users, and remove the offending received headers
> on that port using a second cleanup service. This means that your SASL users
> will need to configure their mail software to submit mail to the submission
> port.
>
Hmm. This is not desirable-- I'd rather stick to the standard port. I
would be quite happy to upgrade (current in my distribution is 2.3.5) if
that would help solve the problem.
-Brandon
Noel Jones
>Hmm. This is not desirable-- I'd rather stick to the standard port. I
>would be quite happy to upgrade (current in my distribution is 2.3.5) if
>that would help solve the problem.
With postfix 2.3, you can use "smtpd_sasl_authenticated_header = yes"
to tag the header that the sender authenticated. I believe recent
SpamAssassin versions will recognize these authenticated headers and
ignore them.
You can also use the tag for a header_checks that will only remove
these headers, something like:
/^Received: .*\(Authenticated sender: .*by 301south.net \(Post/ IGNORE
http://www.postfix.org/postconf.5.html#smtpd_sasl_authenticated_header
--
Noel Jones
mouss
> Hello, list. I am running Postfix 2.1.5 with SMTP authentication via
> SASL.
>
> When an authenticated user sends mail from a remote computer, the mail
> retains a Received: header from the remote IP address. In the case
> that this is a dynamic address, the message is then blemished in the
> eyes of UCE filters, because even though the mail originates from a
> legitimate server (mine), it still has what would be an otherwise
> illegitimate IP address and reverse-DNS lookup in the headers (the
> dynamic IP).
Are you talking about the "last trusted" Received header or of any
Received header.
if your filter tags mail as spam because one of the Received headers
says it passed through a dynmaic IP, then your filter configuration is
broken. A lot of mail goes like that.
But I guess you are talking of the "last trusted" Received header, where
the filter gets the "point of injection" and checks whether it is dynamic.
>
> Below is an example (with some of the specifics fudged). The first
> line is the Received header from my server. The line below it is the
> one I want to strip.
>
> ....
> Received: from 301south.net (ocean.301south.net [74.0.242.82])
> by destination.host (8.13.6/8.13.6) with ESMTP id kBT5Sd2f022202
> for <reci...@destination.host>; Fri, 29 Dec 2006 00:28:40 -0500
> Received: from [192.168.internal.IP] (c-dynamic-ip.wherever.comcast.net
> [dyn.amic.ip.addr])
> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> (No client certificate requested)
> by 301south.net (Postfix) with ESMTP id 4A2D7FD96
> for <reci...@destination.host>; Fri, 29 Dec 2006 00:28:40 -0500
> (EST)
> .......
>
you can use header checks
/^(Received:.*\(using TLSv1 with cypher .* by 301south\.net
\(Postfix\))/ REPLACE X-SOUTH-$1
you can then rewrite the header back after the content filter if you want.
If your postfix doesn't support REPLACE, you can use IGNORE but
- you'll lose information that may be helpful for debugging/audit/...
- other headers will be removed (It's hard to get an expression that
will only match the one you want)
If the filter is spamassassin, an alternative would be to add a rule to
add a negative score when such a header is found. the negative score is
just enough to cancel the positive score of dynamic IP rules. The tricky
part is devising the rule so that spammers can't exploit it...
a yet another alternative is to skip spam filtering for sasl
authenticated users.
smtpd_recipient_restrictions =
...
check_client_access pcre:$dir/filter_trusted
permit_sasl_authenticated
permit_mynetworks
check_client_access pcre:$dir/filter_default
...
filter_trusted:
# filter for trusted originators
/./ FILTER virus-scan:[127.0.0.1]:10586
filter_default:
# filter for others
/./ FILTER scan:[127.0.0.1]:10024
Victor Duchovni
> If your postfix doesn't support REPLACE, you can use IGNORE but
> - you'll lose information that may be helpful for debugging/audit/...
> - other headers will be removed (It's hard to get an expression that
> will only match the one you want)
I recommend against deleting "Received" headers, absense of origin
"Received" headers increases the spam score of mail arriving at the
receiving MTA, and makes problem resolution harder. If you want
to prevent stupid downstream systems from scoring IPs of your
authenticated clients, you can use REPLACE to just hide the IP
and helo name of the sending client:
PCRE:
/^Received: from (\S+) \(\S+ \[[.\d]+\]\)(.*)/ REPLACE
Received: from localhost (localhost [127.0.0.1]){$1}
The true origin is in your logs, and the queue time, timestamp, ...
are still available in the Received header for problem solving.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
mouss
> On Sat, Dec 30, 2006 at 12:27:02PM +0100, mouss wrote:
>
>
>> If your postfix doesn't support REPLACE, you can use IGNORE but
>> - you'll lose information that may be helpful for debugging/audit/...
>> - other headers will be removed (It's hard to get an expression that
>> will only match the one you want)
>>
>
> I recommend against deleting "Received" headers, absense of origin
> "Received" headers increases the spam score of mail arriving at the
> receiving MTA, and makes problem resolution harder.
fully agreed.
> If you want
> to prevent stupid downstream systems from scoring IPs of your
> authenticated clients, you can use REPLACE to just hide the IP
> and helo name of the sending client:
>
> PCRE:
>
> /^Received: from (\S+) \(\S+ \[[.\d]+\]\)(.*)/ REPLACE
> Received: from localhost (localhost [127.0.0.1]){$1}
>
>
or the version that I suggested: replacing Received with X-Received (or
X-something-Received). Then OP can write it back to its original form
after his filter has been made happier.
Brandon Kuczenski
> On Sat, Dec 30, 2006 at 12:27:02PM +0100, mouss wrote:
>
>> If your postfix doesn't support REPLACE, you can use IGNORE but
>> - you'll lose information that may be helpful for debugging/audit/...
>> - other headers will be removed (It's hard to get an expression that
>> will only match the one you want)
>
> I recommend against deleting "Received" headers, absense of origin
> "Received" headers increases the spam score of mail arriving at the
> receiving MTA, and makes problem resolution harder. If you want
> to prevent stupid downstream systems from scoring IPs of your
> authenticated clients, you can use REPLACE to just hide the IP
> and helo name of the sending client:
>
> PCRE:
>
> /^Received: from (\S+) \(\S+ \[[.\d]+\]\)(.*)/ REPLACE
> Received: from localhost (localhost [127.0.0.1]){$1}
>
Thanks for your help. I thought deleting the trusted Received: header
would protect my users' privacy, and anyway, reflect the true entry point
of the mail into 'The Internet'. In any case, I didn't want to try
rewriting it for fear of violating some RFC regarding the Received:
header.
But if you all agree that deleting the header entirely is distasteful,
maybe you can help me construct a regexp that would clean it. I'm afraid
I'm no perl whiz. Can you tell me what the {$1} in your expression above
decodes to? I thought that it would include the first matched
expression.. [192.168.internal.ip] in my example.. is that correct? I
would think that {$2} would be more useful to strip the IP information but
include the remainder of the header.
Thanks again for your help... I love postfix.
-Brandon
Victor Duchovni
Sorry the pattern is a mess, not checked... The correct version is
probably (please test):
/^Received: from \S+ \(\S+ \[[.\d]+\]\)(.*)/ REPLACE
Received: from localhost (localhost [127.0.0.1])${1}
This picks up the rest of the header after hiding the HELO name and IP
address with localhost and 127.0.0.1.
Adam Jacob Muller
I've actually thought about (and would like to -- and probably will)
write something that removes the first "Received" header on my
submission port, saving the results into a database, and replacing it
some kind of unique key, probably will write a milter to do this at
some point.
The reasons for me are simple, if you look at the headers of my mail
it, quite frankly, divulges more information than I would like to
provide about my location. In the sense, that I really don't want
people being able to know if I sent a particular email from the
office (or which office), or from home, or starbucks, or the free
WiFi at the strip club.
At the same time, removing the headers entirely could leave me open
to abuse, so replacing them with some kind of hash and preserving the
information elsewhere seems smart.
Am I the only one who has thought of the privacy implications of this?
-Adam
// Forgive me if the above is incoherent, i am sleep deprived.
Michael Wang
> I've actually thought about (and would like to -- and probably will)
> write something that removes the first "Received" header on my
> submission port, saving the results into a database, and replacing it
> some kind of unique key, probably will write a milter to do this at some
> point.
> The reasons for me are simple, if you look at the headers of my mail it,
> quite frankly, divulges more information than I would like to provide
> about my location. In the sense, that I really don't want people being
> able to know if I sent a particular email from the office (or which
> office), or from home, or starbucks, or the free WiFi at the strip club.
> At the same time, removing the headers entirely could leave me open to
> abuse, so replacing them with some kind of hash and preserving the
> information elsewhere seems smart.
>
> Am I the only one who has thought of the privacy implications of this?
That was the reason why I originally stripped out my Received header
coming from my home machine going to my mail server -- I didn't want
people to know the IP and try to attack it. I'm now using a modified
version of Victor's regexp to rewrite that line rather than removing it
completely.
--
Michael Wang
Victor Duchovni
> At the same time, removing the headers entirely could leave me open
> to abuse, so replacing them with some kind of hash and preserving the
> information elsewhere seems smart.
Best, if you take this route, to sanitize the Received header without
removing it.
> Am I the only one who has thought of the privacy implications of this?
By no means the first, for example, Gmail hides the IP address of webmail
users, while Yahoo and AOL forward (last I checked) the real IP.
Gerard Seibert
> By no means the first, for example, Gmail hides the IP address of webmail
> users, while Yahoo and AOL forward (last I checked) the real IP.
GMail's hiding of the real IP address lead to it's (GMail) being
blacklisted by at least SpamCop and I believe SORBS, although it may
have been another BL service. That decision by Google lead to a rather
lively debate on the GMail forums regarding the importance of hiding the
IP vs the annoyance of having your mail BL'd, especially since there is
no RFC requiring it nor does it by any means appear to be an industrial
recognised procedure.
--
Gerard
"The very powerful and the very stupid have one thing in common. Instead
of altering their views to fit the facts, they alter the facts to fit
their views ... which can be very uncomfortable if you happen to be one
of the facts that needs altering."
Doctor Who