Sturgis, Grant a écrit : > On Wed, 2008-11-26 at 11:44 -0700, Duane Hill wrote: >> On Wed, 26 Nov 2008, Sturgis, Grant wrote: >> >>> On Tue, 2008-11-25 at 11:53 -0700, Wietse Venema wrote: >>>> Sturgis, Grant: >>>>> I'm trying to hide our internal mail servers from the message >>>> headers of >>>>> outbound email. I've done some reading about this and have found >>>> two >>>>> solutions: >>>> ... >>>>> 2. Use header_checks like this >>>>> >> http://www.nabble.com/Hide-internal-address-(Postfix)-td2300995.html >>>> Wietse Venema: >>>> This removes ALL Received: headers. That is a bit drastic. You >>>> could use a REPLACE action to sanitize IP address and hostname >>>> information. >>>> >>>> See: http://www.google.com/search?q=postfix+replace+received >>> I am having some problems getting this header_checks match. The >> header >>> I am working with is this: >>> >>> Received: from blackfoot.internal.com (blackfoot.arraybiopharma.com >>> [10.65.35.185]) >>> >>> So I've added this to my header_checks file for testing: >>> >>> /^Received: from blackfoot\.internal\.com \(blackfoot >> \.arraybiopharma >>> \.com \[10\.65\.35\.185\]\) / HOLD >>> >>> >>> Can someone point out what I've done wrong? >> The space between the last ')' and '/' characters. There won't be any >> space on the end. Besides, you only have to match up to the ending >> parenthesis. >> >> > Thanks, that was it. I've got it matching and so now I've changed it to > REPLACE in order to obfuscate our internal mail servers. I've noticed > that some of the public mail servers are finding this suspicious and are > deferring my mail (yahoo.com in particular). >
I doubt yahoo defers your mail because of that. they defer before they get the message. if you don't send much mail to yahoo, just live with that. if you send a lot of mail, get whitelisted. > Is this a bad idea? Are there some "do's" and "don'ts" that I should be > aware of when modifying the Received: header? Or should I not even > bother? > unfortunately, the imagination of anti-spam filters/rules writers is unlimited. you can minimise damage by using a "plausible" replacement header (obviously, you shouldn't replace your internal infos with *.gmail or so). but what should be important for you is not filters, but the ability to trace problems back to their origin. for this reason, it is better to use one-to-one mappings when you replace information.
