|Main Archive Page > Month Archives > postfix-users archives|
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 [126.96.36.199]) (using
>>> TLSv1 with
>>> cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
>>> requested) by klunky.co.uk (Postfix) with ESMTPSA id
>>> D34A4806B4 for
>>> <firstname.lastname@example.org>; Mon, 14 Feb 2011 10:11:43 +0100
>>> with this line:
>>> Received: from [127.0.0.1] (localhost [127.0.0.1]) by
>>> 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
>>> \(No client certificate requested\)
>>> by klunky.co.uk \(Postfix\)/ REPLACE /^Received: from
>>> (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 188.8.131.52?
>> 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.
> 184.108.40.206 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