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
>> <[email protected]>; 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.


Reply via email to