Need help with canonical maps
I'm having difficulty getting the canonical_maps function to work as needed to repair some incorrect addresses from a legacy client. Here's the situation and what I've tried so far: Legacy client (oldhost.legacy.org) does not append its domain (legacy.org) to addresses in the envelope or the message when sending them via SMTP. So, if the user on oldhost types an address such as "user@oldhost", it goes out with SMTP as "user@oldhost" instead of "u...@oldhost.legacy.org". A machine with postfix (newhost.standard.org) has a different domain (standard.org) from the legacy machine. It acts as MX and relay for the oldhost.legacy.org domain. Relaying in both directions works fine. Only the address rewriting function which I'm trying to add is not working properly. When messages from the legacy client arrive at the postfix machine with addresses such as "user@oldhost" (missing .legacy.org), I'd like to rewrite those to read "u...@oldhost.legacy.org". It's my understanding that the canonical_maps function is intended for this purpose. In /etc/postfix/canonical.pcre I have: /^(.*@oldhost)$/$1.legacy.org If I test with: postmap -q "user@oldhost" pcre:/etc/postfix/canonical.pcre the answer is: u...@oldhost.legacy.org. Perfect. In /etc/postfix/main.cf I have canonical_maps = pcre:/etc/postfix/canonical.pcre Then, on the legacy host, I send a message such as: To: user@someotherhost.domain Cc: user@oldhost The message arrives at the postfix machine, but the CC line is not rewritten. The documentation for canonical_maps says that in order for the headers to be rewritten, the client needs to either match the local_header_rewrite_clients or else the remote_header_rewrite_domain must be non-null. I tried both but neither produces the output that I need. Here's what I found: If I set local_header_rewrite_clients = static:all or permit_mynetworks or some other option that would cause a match of the legacy client, then the append_dot_domain option takes over and appends the domain of the postfix host, rewriting the address as u...@oldhost.standard.org. The canonical table is apparently ignored. If I instead leave local_header_rewrite_clients at its default (which does not match the legacy client) and turn on remote_header_rewrite_domain = invalid.domain, then the address is rewritten as user@oldhost.invalid.domain and, once again, the canonical table is apparently ignored. So the documentation for the canonical table is correct, in that rewriting only occurs if the local_header_rewrite_clients matches the client or if remote_header_rewrite_domain is set. And the rewrites are indeed occurring. But the rewriting that takes place completely ignores the canonical table. This seems like a catch-22 situation. I don't want to turn off append_dot_domain or append_at_myorigin because I need that for the local linux machine where postfix is running. If the canonical table rewrites were applied first, then the append_... functions would not apply. So how do I get postfix to apply the canonical table first (or at all)? Michael
Re: Need help with canonical maps
Michael Fox: > If I set local_header_rewrite_clients = static:all or permit_mynetworks or > some other option that would cause a match of the legacy client, then the > append_dot_domain option takes over and appends the domain of the postfix > host, rewriting the address as u...@oldhost.standard.org. The canonical > table is apparently ignored. As documented in ADDRESS_REWRITING_README, canonical mapping happens after append_dot_mydomain. Thus, either turn off append_dot_mydomain (which may also change the handling of other email addresses, which may break something), or change canonical_maps to rewrite the address that results from append_dot_mydomain, i.e. u...@oldhost.standard.org Wietse
RE: Need help with canonical maps
Thanks much, Wietse. A couple of follow-ups: > As documented in ADDRESS_REWRITING_README, canonical mapping happens > after append_dot_mydomain. O.K. I read that document but did not see that statement. I just went back and read it again and I still don't see that. Perhaps the order of processing can be more explicitly stated? > Thus, either turn off append_dot_mydomain (which may also change > the handling of other email addresses, which may break something), > or change canonical_maps to rewrite the address that results from > append_dot_mydomain, i.e. u...@oldhost.standard.org I presume there is a reason for the current processing order. But it seems it causes the need to rewrite a rewrite. In other words, as you described, I either have to turn off a feature (append_dot_mydomain) and then fix the problem that that creates in canonical_maps, or else use canonical to rewrite an address that has already been rewritten. The reverse order seems more intuitive and useful (at least to me). If canonical was processed first, one would have the opportunity to fix the error as it is coming in, before it is further manipulated and, perhaps, becomes harder to distinguish from other addresses. Then, anything left over could be handled by append_dot_mydomain or the remote_header_rewrite_domain, wherever they apply. For backward compatibility, perhaps a switch could be provided to control the order. Just a thought. Once again, thanks for the quick reply. Michael
Re: Need help with canonical maps
Michael Fox: > Thanks much, Wietse. > > A couple of follow-ups: > > > As documented in ADDRESS_REWRITING_README, canonical mapping happens > > after append_dot_mydomain. > > O.K. I read that document but did not see that statement. I just went back > and read it again and I still don't see that. Perhaps the order of > processing can be more explicitly stated? Hmm. ADDRESS_REWRITING_README describes the address manipulations in the order as executed. Presenting these descriptions in a different order would be misleading. > For backward compatibility, perhaps a switch could be provided to control > the order. Just a thought. That would require not a switch, but a mechanism to specify the order of all five cleanup server's address manipulations. Wietse
RE: Need help with canonical maps
Thanks again Wietse. > Hmm. ADDRESS_REWRITING_README describes the address manipulations > in the order as executed. Presenting these descriptions in a different > order would be misleading. Yes. And it's very well written. But assuming or inferring information that is not in a technical document is usually not a wise move. Currently, the processing order is implied by the order mentioned in the document. But I didn't want to assume that. I would respectfully suggest an explicit statement in the document so the reader doesn't need to infer the processing order. > That would require not a switch, but a mechanism to specify the > order of all five cleanup server's address manipulations. Yes, good point. Perhaps that's too complex to address what may be a shrinking problem today (cleaning up legacy client addresses). Best regards, and thanks again for the quick help! Michael
