On 02/14/2011 02:41 PM, Noel Jones wrote:
> 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
Agreed. Its a better idea. From what I have read, some spam filters will
tick more boxes for email missing headers. Hence the desire to falsify
rather than remove the header.
