To enable delivery to the hashed directory structure, use the users/assign
mechanism to divert it to a specific user, which we'll call hashuser (you
can also use the alias user for this purpose). Thus create the file
users/assign (this example assumes alias is the hash user; I've assumed
this user has a UID and GID of 191),
     +:alias:191:191:/var/qmail/alias:H::
     .
(note the dot on the 2nd line). See "man qmail-users" for details of
the format of this file. /var/qmail/alias is assumed to be the home
of the hash user in this example (adjust for your system). Use the
   qmail-newu
command to build the corresponding cdb file (users/cdb).
See the LIMITATIONS file for more details of users/assign, esp. regarding
extension addresses.


Temporary and Permanent Delivery Errors:
This system is designed with shared storage in mind (but it's not mandatory).
It assumes that the maildirs_basedir (hash_core.h) is the mount point on
each front end, and that the hashed directory is on the shared storage. A
user doesn't exist if there's no hashed directory for them. However, I
have a small proviso to that. Suppose joe@somedomain.com hashes to

    /maildirs/14/107/3/joe@somedomain.com

but that when delivering a message, /maildirs/14 can't be reached. In
a shared storage environment, it is possible that the front end where
the message has arrived has lost its mount of the shared storage. For
this reason, if not even the first level of hash (14 in this example)
can be reached, a temporary error is returned, causing the message
to be re-queued (i.e. delivery will be attempted later, hopefully when
the shared storage is mounted).

In the general case, however, all first level hashes exist, meaning
that if the full hashed directory (/maildirs/14/107/3/joe@somedomain.com
in the above example) doesn't exist, the user doesn't exist, and the
[hashing version of] qmail-local) exits with a permanent error, causing
a bounce.

Also see USAGE.NOTES on this point.