On 2/14/2011 7:29 AM, J4K wrote:
On 02/14/2011 02:23 PM, Noel Jones wrote:
On 2/14/2011 4:16 AM, J4K wrote:
Good Monday morning to you all,
I have a regex question for header_checks, that I cannot
get to
work. Possible caused by line wrapping.
I want to replace this line:
Received: from [127.0.0.1] (unknown [62.11.11.11]) (using
TLSv1 with
cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate
requested) by klunky.co.uk (Postfix) with ESMTPSA id
D34A4806B4 for
<test.t...@klunky.co.uk>; Mon, 14 Feb 2011 10:11:43 +0100
(CET)
with this line:
Received: from [127.0.0.1] (localhost [127.0.0.1]) by
localhost
I have the regex in header_checks, and its enabled in main.cf
header_checks = regexp:/etc/postfix/header_checks
# cat /etc/postfix/header_checks
/^Received: from \[[0-9.]+\]
\([^) ]+ \[[0-9.]+\]\)
\(using TLSv1 with cipher DHE-RSA-AES256-SHA \(256\/256
bits\)\)
\(No client certificate requested\)
by klunky.co.uk \(Postfix\)/ REPLACE /^Received: from
[127.0.0.1]
(localhost [127.0.0.1]) by localhost/
Don't try to match line feeds literally; match them with a
dot "." or a [[:space:]] class. Don't enclose the REPLACE
text in /^.../, use the text only.
/bar/ REPLACE foo
But why replace it anyway? Why does the client HELO with
[127.0.0.1] when the connection comes from 62.11.11.11?
Looks like broken routing from a content filter. You should
cure the disease, not put a band-aid on the symptom.
-- Noel Jones
Hi Noel,
Nothing broken here.
62.11.11.11 is correct, as the client is an SMTP-AUTH from a
mobile user. Yet there is other than they are using the email
for work. The same goes for exposing the internal LAN to the
world e.g 10.20.20.45. We'd rather replace this with something
generic like 127.0.0.1.
In that case, better to remove the header with IGNORE rather
than falsifying the evidence.
-- Noel Jones
