|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
virtual_alias_maps, catchalls, X-Original-To, and null results (second try)
djonas
vitalwerks.com
Date: Mon Oct 02 2006 - 14:20:46 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello,
----
Let me apologize for my previous post. I assume my cold reception was
due to accidentally hijacking a thread. No good excuses, I just made
a mistake. I apologize. I've also updated the original post below
with cut-and-paste information directly from the files. Thanks for
your time.
----
I've implemented forwarding and aliases for my users using the
virtual_alias_maps. This worked exceedingly well, except for a couple
side effects.
First, catchalls are implemented as below:
outside
splitretina.com
david.jonas
gmail.com,splitretina
aim.com
splitretina.com welcome
splitretina.com
There are also entries in transport_maps such as this:
# sa is a pipe transport to a simple perl script for local delivery
djonas
splitretina.com sa:splitretina.com
welcome
splitretina.com sa:splitretina.com
This worked just fine with mysql maps because I could specify a null
return if djonas
splitretina.com was found in the virtual_alias
table, thus never invoking the catchall. I've since moved to hash
files for better performance (and less maintenance overhead). My
solution to the null lookup problem came to me like an angel and
seemed to work quite nicely. Basically, add a redundant entry to
virtual_alias_maps. Postfix notices the loop and stops looking
(cleanup_map1n.c, lines: ~109,~131). My new virtual_alias_maps looks
like this:
outside
splitretina.com
david.jonas
gmail.com,splitretina
aim.com
djonas
splitretina.com djonas
splitretina.com
welcome
splitretina.com welcome
splitretina.com
splitretina.com welcome
splitretina.com
This works, but when sending to djonas
splitretina.com I get
... Delivered: status=success, orig=<djonas
splitretina.com>,
to=<djonas
splitretina.com>, ...
in my logs and an X-Original-To line in the headers. The extra
logging and header lines don't bother me, but it means the X-Original-
To line will be rewritten in the case of a second pass (as described
in the second problem below).
So the first question is, Is there a value or procedure for an entry
in the virtual_alias_maps that can make cleanup think that it found
no entry in the map?
The second problem is the impetus for the post:
Incoming mail is fed through a a content_filter. Before that happens
cleanup has written an X-Original-To header line. When the
content_filter injects that message back into Postfix and cleanup
processes the virtual_alias_maps as above it rewrites the X-Original-
To line with the redundant entry (http://www.postfix.org/postconf.
5.html#enable_original_recipient)! Of course this is no fault of
postfix/cleanup's and is in fact an aptly named system. But what to do!
Solving the first problem solves the second, though I'll take any
hack to make my users happy. The frustration for them lies in not
being able to filter their aliases to different boxes on the X-
Original-To header line.
Any help or advice would be greatly appreciated.
Regards,
David
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]