OSEC

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)

djonasvitalwerks.com
Date: Mon Oct 02 2006 - 14:20:46 CDT


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:

outsidesplitretina.com
david.jonasgmail.com,splitretinaaim.com
splitretina.com welcomesplitretina.com

There are also entries in transport_maps such as this:

# sa is a pipe transport to a simple perl script for local delivery
djonassplitretina.com sa:splitretina.com
welcomesplitretina.com sa:splitretina.com

This worked just fine with mysql maps because I could specify a null
return if djonassplitretina.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:

outsidesplitretina.com
david.jonasgmail.com,splitretinaaim.com
djonassplitretina.com djonassplitretina.com
welcomesplitretina.com welcomesplitretina.com
splitretina.com welcomesplitretina.com

This works, but when sending to djonassplitretina.com I get

... Delivered: status=success, orig=<djonassplitretina.com>,
to=<djonassplitretina.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