+<A NAME="SEC132" HREF="FAQ.html#TOC132">Q0438</A>: Some of our users have no home directories; the field in the password
+ file contains <B>/no/home/dir</B>. This causes the error "failed to stat
+ <B>/no/home/dir</B> (No such file or directory)" when Exim tries to look for a
+ <B>.forward</B> file, and the delivery is deferred.
+
+
+<P>
+A0438: With the default configuration, you are asking Exim to check for a
+ <B>.forward</B> file in the user's home directory. It looks up the home
+ directory and tries to stat() it before looking for <B>.forward</B>. This is so
+ that it can will notice a missing NFS home directory, and not treat it
+ as if the <B>.forward</B> file did not exist. This stat() is failing when the
+ home directory doesn't exist. What you should do is pick off these
+ special cases before looking for <B>.forward</B> files for normal users. Place
+ the following director before the userforward director:
+
+</P>
+<PRE>
+ no_home_directory_users:
+ driver = localuser
+ transport = local_delivery
+ match_directory = /no/home/dir
+ current_directory = /</PRE>
+<A NAME="SEC133" HREF="FAQ.html#TOC133">Q0439</A>: How can I disable Exim's de-duplication features? I want it to do two
+ deliveries if two different aliases expand to the same address.
+
+
+<P>
+A0439: This is not possible. Duplication has other ramifications other than
+ just (in)convenience. Consider:
+
+</P>
+<P>
+ . Message is addressed to A and to B.
+
+</P>
+<P>
+ . Both A and B are aliased to C.
+
+</P>
+<P>
+ . Without de-duplication, two deliveries to C are scheduled.
+
+</P>
+<P>
+ . One delivery happens, Exim records that it has delivered the message
+ to C.
+
+</P>
+<P>
+ . The next delivery fails (C's mailbox is over quota, say).
+
+</P>
+<P>
+ Next time round, Exim wants to know if it has already delivered to C or
+ not, before scheduling a new delivery. Has it? Obviously, if duplicate
+ deliveries are supported, it has to remember not only that it has
+ delivered to C but also the "history" of how that delivery happened - in
+ effect an ancestry list back to the original envelope address. This it
+ does not do, and changing it to work in that way would be a lot of work
+ and a big upheaval.
+
+</P>
+<P>
+ The best way to get duplicate deliveries if you want them is not to use
+ <B>aliasfile</B>, but to use <B>smartuser</B> with a transport, e.g.
+
+</P>
+<PRE>
+ alias_with_duplicates:
+ driver = smartuser
+ transport = local_delivery_for_duplicates
+ new_address = ${lookup {$local_part} lsearch ..... etc</PRE>
+<P>
+ This goes straight to the transport without generating a new address
+ that is considered for de-duplication or re-aliasing. In effect, it is
+ just re-writing the address on the way to the transport. You will need
+ to specify the user under which to run the delivery, either on the
+ transport or on the director.
+
+</P>
+<A NAME="SEC134" HREF="FAQ.html#TOC134">Q0440</A>: I set up an <B>aliasfile</B> director using MySQL, but it doesn't use the new
+ addresses. This it my director:
+
+
+<PRE>
+ mysql_system_aliases:
+ driver = aliasfile
+ search_type = mysql
+ query = "select userid from domain_table where \
+ aliasid='$local_part' and domain='$domain'"
+ transport = local_delivery</PRE>
+<P>
+A0440: The setting of "transport" is your problem. Aliasfile operates entirely
+ differently if you give it a transport. It just verifies the incoming
+ address by doing the query, then sends it to the transport. Take away
+ the transport setting, and it will do normal aliasing, that is, turn one
+ address into another which is independently processed.
+
+</P>
+<A NAME="SEC135" HREF="FAQ.html#TOC135">Q0441</A>: I received a message with a Subject: line that contained a non-printing
+ character (a carriage return). This messed up my filter file. Is there a
+ way to get round it?
+
+
+<P>
+A0441: Instead of <B>$h_subject:</B> use <B>${escape:$h_subject:}</B>
+
+</P>
+<A NAME="SEC136" HREF="FAQ.html#TOC136">Q0442</A>: My users' mailboxes are distributed between several servers according to
+ the first letter of the user name. All the servers receive incoming mail
+ at random. I would like to have the same configuration file for all the
+ servers, which does local delivery for the mailboxes it holds, and sends
+ other addresses to the correct other server. Is this possible?
+
+
+<P>
+A0442: It is easiest if you arrange for all the users to have password entries
+ on all the servers. This means that non-existent users can be detected
+ at the first server they reach. Set up a file containing a mapping from
+ the first letter of the user names to the servers where their mailboxes
+ are held. For example:
+
+</P>
+<PRE>
+ a: server1
+ b: server1
+ c: server2
+ ...</PRE>
+<P>
+ Replace the normal localuser director with these two directors:
+
+</P>
+<PRE>
+ localuser:
+ driver = localuser
+ transport = local_delivery
+ condition = ${if eq{$primary_hostname}\
+ {${lookup {${substr_0_1:$local_part}}\
+ lsearch{/etc/mapfile} {$value}}}{yes}{no}}</PRE>
+<PRE>
+ check_remote:
+ driver = localuser
+ transport = send_to_correct_host</PRE>
+<P>
+ The first director succeeds only if the local part is a local user whose
+ mailbox is listed as being on the current host. The second server runs
+ for all other local users, directing the addresses to this transport:
+
+</P>
+<PRE>
+ send_to_correct_host:
+ driver = smtp
+ hosts = ${lookup {${substr_0_1:$local_part}}lsearch{/etc/mapfile}\
+ {$value}}</PRE>
+<P>
+ Local parts that are not the names of local users are declined by both
+ directors, and so they fail.
+
+</P>
+<A NAME="SEC137" HREF="FAQ.html#TOC137">Q0443</A>: I want to search for '$' in the subject line, but I can't seem to get
+ the syntax. The obvious choice, '\$' doesn't work. Any help?
+
+
+<P>
+A0443: Try one of these:
+
+</P>
+<PRE>
+ if $h_subject: contains \$ then ...
+ if $h_subject: contains "\\$" then ...</PRE>
+<A NAME="SEC138" HREF="FAQ.html#TOC138">Q0444</A>: One of the things I want to set up is for <B>anything@onedomain</B> to forward
+ to <B><B>anything@anotherdomain.</B></B> I tried adding <B>$local_part@anotherdomain</B> to
+ my aliases but it did not expand - it sent it to that literal address.
+
+
+<P>
+A0444: If you want to do it that way, you can make it expand by setting
+ the "expand" option on the <B>aliasfile</B> director. Another approach is to
+ use a <B>smartuser</B> director like this:
+
+</P>
+<PRE>
+ forwarddomain:
+ driver = smartuser
+ domains = onedomain
+ new_address = $local_part@anotherdomain</PRE>
+<P>
+ <TT>new_address</TT> can, of course, be more complicated, involving lookups etc.
+ if you have lots of different cases.
+
+</P>
+<A NAME="SEC139" HREF="FAQ.html#TOC139">Q0445</A>: How can I have an address looked up in two different alias files, and
+ delivered to all the addresses that are found?
+
+
+<P>
+A0445: It is tempting to use the "unseen" option for this (see
+ <A HREF="FAQ.html#SEC145">Q0504</A> for an
+ example of the use of "unseen"). You would have two directors, the first
+ of which has "unseen" set, so that the address is always passed on to
+ the next director, even if the first one accepts it.
+
+</P>
+<P>
+ However, there is a problem with this approach. If an address is found
+ in the first director (with unseen set) but not in the second one, it
+ will get delivered but will also (under most normal setups) generate an
+ "unknown user" bounce as well.
+
+</P>
+<P>
+ If you want an incoming address to be "properly" delivered to
+ two different "child" addresses (or lists), "unseen" is not really the
+ right way to do it. You don't really need two different directors. You
+ can use a <B>smartuser</B> director with an option something like this:
+
+</P>
+<PRE>
+ new_address = ${lookup{$local_part}lsearch{/etc/aliases1}\
+ {$value${lookup{$local_part}lsearch{/etc/aliases2}{,$value}}}\
+ {${lookup{$local_part}lsearch{/etc/aliases2}{$value}fail}}}\</PRE>
+<P>
+ If the first lookup succeeds, the result is its data, followed by the
+ data from the second lookup, if any, separated by a comma. If the first
+ lookup fails, the result is the data from the third lookup (which also
+ looks in the second file), but if this also fails, the entire expansion
+ is forced to fail, thereby causing the director to decline.
+
+</P>
+<A NAME="SEC140" HREF="FAQ.html#TOC140">Q0446</A>: I've converted from Sendmail, and I notice that Exim doesn't make use
+ of the "owner-" entries in my alias file to change the sender address in
+ outgoing messages to a mailing list.
+
+
+<P>
+A0446: If you have an alias file with entries like this:
+
+</P>
+<PRE>
+ somelist: a@b, c@d, ...
+ owner-somelist: postmaster</PRE>
+<P>
+ Sendmail assumes that the second entry specifies a new sender address
+ for the first. Exim does not make this assumption. However, you can make
+ it take the same action, by adding
+
+</P>
+<PRE>
+ errors_to = owner-$local_part@whatever.domain</PRE>
+<P>
+ to the configuration for your <B>aliasfile</B> director. This is fail-safe,
+ because Exim verifies a new sender address before using it. Thus, the
+ change of sender address occurs only when the owner entry exists.
+
+</P>
+<BR><H2><A NAME="SEC141" HREF="FAQ.html#TOC141">5. DELIVERY
git://git.exim.org / exim-website.git / commitdiff