288621Re: error daemon dsn code
- Oct 2, 2012--On Tuesday, October 02, 2012 8:11 PM +0000 Viktor Dukhovni
> On Tue, Oct 02, 2012 at 03:34:38PM -0400, Wietse Venema wrote:Thanks again! I will see if I can figure out what the intent was to begin
>> Alas, it makes no sense to me, and I am the person who designed
>> this mail system.
>> In particular I fail to understand what this is meant to achieve:
>> 1) list the domain in virtual_mailbox_domains.
>> 2) set the delivery agent to "error".
>> I suspect that this is combined with virtual aliases or transport
>> maps to redirect "good" recipients away from the error transport,
>> towards a proper delivery agent.
>> This is working against the system, and therefore I anticipate more
>> trouble down the road.
>> Proper usage of the Postfix virtual mailbox address class is:
>> 1) list the domain(s) in virtual_mailbox_domains.
>> 2) list the valid recipients in virtual_mailbox_maps
>> 3) configure a proper delivery agent with virtual_transport
>> With this, Postfix takes care of non-existent recipients. There
>> is no need for manual "error" delivery agent configuration, or
>> for word-smithing the "user unknown" error message.
>> Similar usage is recommended for the other Postfix address classes:
>> the virtual alias class (which has no delivery agent), the relay
>> class with relay_transport, and the local address class with
> Indeed I was only responding to the question of how to get error(8)
> to generate a sensible DSN status code and error message. Whether
> it is wise to route the mail in question to the error transport
> via "virtual_transport=error:5.1.1 <text>" is a separate issue
> I did not address.
> Indeed it is typically best to not fight the system, and let Postfix
> determine valid recipients in the standard way.
> There be some existing logic in smtpd(8), that rejects all recipients
> that explicitly resolve to the error transport. In which case in
> combination with an LDAP-based per-user transport table, something
> sensible may happen for this domain. If so it is a rather complicated
> design, perhaps it can be made more "natural".
with, and rework this into a more reasonable configuration.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
- << Previous post in topic