Loading ...
Sorry, an error occurred while loading the content.

288621Re: error daemon dsn code

Expand Messages
  • Quanah Gibson-Mount
    Oct 2, 2012
      --On Tuesday, October 02, 2012 8:11 PM +0000 Viktor Dukhovni
      <postfix-users@...> wrote:

      > On Tue, Oct 02, 2012 at 03:34:38PM -0400, Wietse Venema wrote:
      >> 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
      >> local_transport.
      > 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".

      Thanks again! I will see if I can figure out what the intent was to begin
      with, and rework this into a more reasonable configuration.



      Quanah Gibson-Mount
      Sr. Member of Technical Staff
      Zimbra, Inc
      A Division of VMware, Inc.
      Zimbra :: the leader in open source messaging and collaboration
    • Show all 16 messages in this topic