On Thu, Apr 23, 2009 at 06:47:53PM +1000, Steve Head wrote:
> I've managed to reproduce the problem with an alias include file with
> just two recipients (bypassing majordomo altogether).
>
> It appears to happen when an address included from a file is an alias to
> a mailbox which is over quota. When it is not an alias, delivery
> continues as I would have expected.
>
> =============
> Success mode:
> /etc/postfix/aliases:
> smh-test: :include:/home/majordomo/lists/smh-test
> # lmtp responds 452 Over quota for mailbox aaasmh
>
> /home/majordomo/lists/smh-test: (identical for both)
> [email protected]
> [email protected]
>
> =============
> Failure mode:
> /etc/postfix/aliases:
> # Add aaasmh alias to over quota user.
> # lmtp responds 452 Over quota, for mailbox shead2
> smh-test: :include:/home/majordomo/lists/smh-test
> aaasmh: shead2
>
Yes, aliases are expanded from :include: files:
src/local/recipient.c:
/*
* \user is special: it means don't do any alias or forward expansion.
* ...
*/
...
/*
* Otherwise, alias expansion has highest precedence. First look up the
* full localpart, then the bare user. Obey the address extension
* propagation policy.
*/
...
/*
* Special case for mail locally forwarded or aliased to a different
* local address. Resubmit the message via the cleanup service, so that
* each recipient gets a separate delivery queue file status record in
* the new queue file. The downside of this approach is that mutually
* recursive .forward files cause a mail forwarding loop. Fortunately,
* the loop can be broken by the use of the Delivered-To: message header.
*
* ...
*/
...
/*
* Always forward recipients in :include: files.
*/
...
and "forget" that the address came from a ":include:" file. While
local users encountered directly in the :include: file are delivered
indirectly to a new queue file, aliases encountered in the :include:
file are delivered in the same was as "top-level" aliases.
src/local/alias.c:
/*
* DELIVERY POLICY
*
* Update the expansion type attribute, so we can decide if
* deliveries to |command and /file/name are allowed at all.
*/
state.msg_attr.exp_type = EXPAND_TYPE_ALIAS;
I am not sure whether this is intentional, the Sendmail compatibility
constraints in local(8) are rather complex. Perhaps delaying alias
expansion in :include: files would cause compatibility issues.
I avoid the problem by making all domains (including $myorigin) non-local,
local(8) delivery happens only after virtual(5) alias expansion results
in a name listed in $mydestination, addresses used and seen by users are
never local (have domains in $mydestination). With this, delivery to user
addresses is always "indirect".
Even giving the parent list an "owner-parent" alias will not work,
because when the child-list has no "owner-child" alias, the parent
"owner" property is cleared.
src/local/alias.c:
/*
* WHERE TO REPORT DELIVERY PROBLEMS.
*
* Use the owner- alias if one is specified, otherwise reset the
* owner attribute and use the include file ownership if we can.
* Save the dict_lookup() result before something clobbers it.
*
* Don't match aliases that are based on regexps.
*/
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[email protected]?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
