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

error daemon dsn code

Expand Messages
  • Quanah Gibson-Mount
    I got a complaint from a client that postfix is returning a 5.0.0 DSN when emails are sent to an unknown user. I believe this is to prevent backscatter. In
    Message 1 of 16 , Oct 1, 2012
      I got a complaint from a client that postfix is returning a "5.0.0" DSN
      when emails are sent to an unknown user. I believe this is to prevent
      backscatter. In any case, it appears this 5.0.0 DSN response is hard coded
      into the error daemon?

      >From my logs I see:

      Oct 1 13:11:07 zre-ldap002 postfix/smtp[8257]: 000501E37BC:
      to=<baduser@...>, relay=127.0.0.1[127.0.0.1]:10026,
      delay=0.22, delays=0.03/0/0/0.19, dsn=2.0.0, status=sent (250 2.0.0 from
      MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2D0711E37BE)
      Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 000501E37BC: removed
      Oct 1 13:11:07 zre-ldap002 postfix/error[8324]: 2D0711E37BE:
      to=<baduser@...>, relay=none, delay=0.06,
      delays=0.03/0/0/0.02, dsn=5.0.0, status=bounced (zre-ldap002.eng.vmware.com)

      And in the source I see:

      if (strcmp(service, MAIL_SERVICE_ERROR) == 0)
      status = deliver_message(request, "5.0.0", bounce_append);

      The client would rather have 5.1.1 returned, so they can integrate it with
      a Sophos Email Appliance, which is apparently expecting the 5.1.1 response.

      I assume there is an easy way to change this behavior I'm just missing. ;)
      I checked the postconf reject codes, and I don't see 500 set anywhere. I
      have:

      unknown_local_recipient_reject_code = 550
      unknown_relay_recipient_reject_code = 550

      Thanks for any pointers. :)

      --Quanah


      --

      Quanah Gibson-Mount
      Sr. Member of Technical Staff
      Zimbra, Inc
      A Division of VMware, Inc.
      --------------------
      Zimbra :: the leader in open source messaging and collaboration
    • Wietse Venema
      ... The error daemon uses 5.0.0 as the **default** status code, when whoever decided to route mail to the error daemon did not provide a valid status code.
      Message 2 of 16 , Oct 1, 2012
        Quanah Gibson-Mount:
        > I got a complaint from a client that postfix is returning a "5.0.0" DSN
        > when emails are sent to an unknown user. I believe this is to prevent
        > backscatter. In any case, it appears this 5.0.0 DSN response is hard coded
        > into the error daemon?
        >
        > >From my logs I see:
        >
        > Oct 1 13:11:07 zre-ldap002 postfix/smtp[8257]: 000501E37BC:
        > to=<baduser@...>, relay=127.0.0.1[127.0.0.1]:10026,
        > delay=0.22, delays=0.03/0/0/0.19, dsn=2.0.0, status=sent (250 2.0.0 from
        > MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2D0711E37BE)
        > Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 000501E37BC: removed
        > Oct 1 13:11:07 zre-ldap002 postfix/error[8324]: 2D0711E37BE:
        > to=<baduser@...>, relay=none, delay=0.06,
        > delays=0.03/0/0/0.02, dsn=5.0.0, status=bounced (zre-ldap002.eng.vmware.com)
        >
        > And in the source I see:
        >
        > if (strcmp(service, MAIL_SERVICE_ERROR) == 0)
        > status = deliver_message(request, "5.0.0", bounce_append);

        The error daemon uses "5.0.0" as the **default** status code, when
        whoever decided to route mail to the error daemon did not provide
        a valid status code.

        There are tons of ways that mail can resolve to the error mailer;
        some may even be specified in access maps or transport maps.

        How does the mail end up with the error mailer in your case? If the
        error daemon is specified in a transport or access map, then the
        5.1.1 code should be specified there.

        Wietse


        > The client would rather have 5.1.1 returned, so they can integrate it with
        > a Sophos Email Appliance, which is apparently expecting the 5.1.1 response.
        >
        > I assume there is an easy way to change this behavior I'm just missing. ;)
        > I checked the postconf reject codes, and I don't see 500 set anywhere. I
        > have:
        >
        > unknown_local_recipient_reject_code = 550
        > unknown_relay_recipient_reject_code = 550
        >
        > Thanks for any pointers. :)
        >
        > --Quanah
        >
        >
        > --
        >
        > Quanah Gibson-Mount
        > Sr. Member of Technical Staff
        > Zimbra, Inc
        > A Division of VMware, Inc.
        > --------------------
        > Zimbra :: the leader in open source messaging and collaboration
        >
      • Wietse Venema
        ... If the error is User unknown in virtual alias table , then the fix is in trivial-rewrite/resolve.c:
        Message 3 of 16 , Oct 1, 2012
          Wietse Venema:
          > Quanah Gibson-Mount:
          > > I got a complaint from a client that postfix is returning a "5.0.0" DSN
          > > when emails are sent to an unknown user. I believe this is to prevent
          > > backscatter. In any case, it appears this 5.0.0 DSN response is hard coded
          > > into the error daemon?
          > >
          > > >From my logs I see:
          > >
          > > Oct 1 13:11:07 zre-ldap002 postfix/smtp[8257]: 000501E37BC:
          > > to=<baduser@...>, relay=127.0.0.1[127.0.0.1]:10026,
          > > delay=0.22, delays=0.03/0/0/0.19, dsn=2.0.0, status=sent (250 2.0.0 from
          > > MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2D0711E37BE)
          > > Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 000501E37BC: removed
          > > Oct 1 13:11:07 zre-ldap002 postfix/error[8324]: 2D0711E37BE:
          > > to=<baduser@...>, relay=none, delay=0.06,
          > > delays=0.03/0/0/0.02, dsn=5.0.0, status=bounced (zre-ldap002.eng.vmware.com)
          > >
          > > And in the source I see:
          > >
          > > if (strcmp(service, MAIL_SERVICE_ERROR) == 0)
          > > status = deliver_message(request, "5.0.0", bounce_append);
          >
          > The error daemon uses "5.0.0" as the **default** status code, when
          > whoever decided to route mail to the error daemon did not provide
          > a valid status code.
          >
          > There are tons of ways that mail can resolve to the error mailer;
          > some may even be specified in access maps or transport maps.

          If the error is "User unknown in virtual alias table", then the fix
          is in trivial-rewrite/resolve.c:

          < vstring_sprintf(nexthop, "User unknown%s",
          ---
          > vstring_sprintf(nexthop, "5.1.1 User unknown%s",

          It the error is different, then I'll have to wait for more specific
          information.

          Wietse
        • Quanah Gibson-Mount
          --On Monday, October 01, 2012 5:28 PM -0400 Wietse Venema ... Thanks Wietse, We do use LDAP for our transport map for delivery: zimbra@zre-ldap002:~/conf$ cat
          Message 4 of 16 , Oct 1, 2012
            --On Monday, October 01, 2012 5:28 PM -0400 Wietse Venema
            <wietse@...> wrote:

            > Wietse Venema:
            >> Quanah Gibson-Mount:
            >> > I got a complaint from a client that postfix is returning a "5.0.0"
            >> > DSN when emails are sent to an unknown user. I believe this is to
            >> > prevent backscatter. In any case, it appears this 5.0.0 DSN response
            >> > is hard coded into the error daemon?
            >> >
            >> > > From my logs I see:
            >> >
            >> > Oct 1 13:11:07 zre-ldap002 postfix/smtp[8257]: 000501E37BC:
            >> > to=<baduser@...>,
            >> > relay=127.0.0.1[127.0.0.1]:10026, delay=0.22, delays=0.03/0/0/0.19,
            >> > dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025):
            >> > 250 2.0.0 Ok: queued as 2D0711E37BE) Oct 1 13:11:07 zre-ldap002
            >> > postfix/qmgr[23910]: 000501E37BC: removed Oct 1 13:11:07 zre-ldap002
            >> > postfix/error[8324]: 2D0711E37BE:
            >> > to=<baduser@...>, relay=none, delay=0.06,
            >> > delays=0.03/0/0/0.02, dsn=5.0.0, status=bounced
            >> > (zre-ldap002.eng.vmware.com)
            >> >
            >> > And in the source I see:
            >> >
            >> > if (strcmp(service, MAIL_SERVICE_ERROR) == 0)
            >> > status = deliver_message(request, "5.0.0", bounce_append);
            >>
            >> The error daemon uses "5.0.0" as the **default** status code, when
            >> whoever decided to route mail to the error daemon did not provide
            >> a valid status code.
            >>
            >> There are tons of ways that mail can resolve to the error mailer;
            >> some may even be specified in access maps or transport maps.
            >
            > If the error is "User unknown in virtual alias table", then the fix
            > is in trivial-rewrite/resolve.c:
            >
            > < vstring_sprintf(nexthop, "User unknown%s",
            > ---
            >> vstring_sprintf(nexthop, "5.1.1 User unknown%s",
            >
            > It the error is different, then I'll have to wait for more specific
            > information.

            Thanks Wietse,

            We do use LDAP for our transport map for delivery:

            zimbra@zre-ldap002:~/conf$ cat ldap-transport.cf
            server_host = ldap://zre-ldap002.eng.vmware.com:389
            server_port = 389
            search_base =
            query_filter =
            (&(|(zimbraMailDeliveryAddress=%s)(zimbraDomainName=%s))(zimbraMailStatus=enabled))
            result_attribute = zimbraMailTransport
            version = 3
            start_tls = yes
            tls_ca_cert_dir = /opt/zimbra/conf/ca
            bind = yes
            bind_dn = uid=zmpostfix,cn=appaccts,cn=zimbra
            bind_pw = xxxxxxxxx
            timeout = 30

            I read the page on transport maps, but I don't see a bit in there for
            setting the recipient unknown dsn code.

            --Quanah

            --

            Quanah Gibson-Mount
            Sr. Member of Technical Staff
            Zimbra, Inc
            A Division of VMware, Inc.
            --------------------
            Zimbra :: the leader in open source messaging and collaboration
          • Viktor Dukhovni
            ... The nexthop syntax is naturally transport dependent, the specification for the error(8) transport is in the error(8) manpage. -- Viktor.
            Message 5 of 16 , Oct 1, 2012
              On Mon, Oct 01, 2012 at 03:31:12PM -0700, Quanah Gibson-Mount wrote:


              > I read the page on transport maps, but I don't see a bit in there
              > for setting the recipient unknown dsn code.

              The nexthop syntax is naturally transport dependent, the specification
              for the error(8) transport is in the error(8) manpage.

              --
              Viktor.
            • Wietse Venema
              ... What is the error if it is not User unknown in virtual alias table ? Wietse
              Message 6 of 16 , Oct 1, 2012
                Quanah Gibson-Mount:
                > >> There are tons of ways that mail can resolve to the error mailer;
                > >> some may even be specified in access maps or transport maps.
                > >
                > > If the error is "User unknown in virtual alias table", then the fix
                > > is in trivial-rewrite/resolve.c:
                > >
                > > < vstring_sprintf(nexthop, "User unknown%s",
                > > ---
                > >> vstring_sprintf(nexthop, "5.1.1 User unknown%s",
                > >
                > > It the error is different, then I'll have to wait for more specific
                > > information.
                >
                > Thanks Wietse,
                >
                > We do use LDAP for our transport map for delivery:

                What is the error if it is not "User unknown in virtual alias table"?

                Wietse
              • Quanah Gibson-Mount
                --On Monday, October 01, 2012 7:32 PM -0400 Wietse Venema ... Hi Wieste, I m not sure where the error is you are expecting me to find? This is the full log of
                Message 7 of 16 , Oct 1, 2012
                  --On Monday, October 01, 2012 7:32 PM -0400 Wietse Venema
                  <wietse@...> wrote:

                  > Quanah Gibson-Mount:
                  >> >> There are tons of ways that mail can resolve to the error mailer;
                  >> >> some may even be specified in access maps or transport maps.
                  >> >
                  >> > If the error is "User unknown in virtual alias table", then the fix
                  >> > is in trivial-rewrite/resolve.c:
                  >> >
                  >> > < vstring_sprintf(nexthop, "User unknown%s",
                  >> > ---
                  >> >> vstring_sprintf(nexthop, "5.1.1 User unknown%s",
                  >> >
                  >> > It the error is different, then I'll have to wait for more specific
                  >> > information.
                  >>
                  >> Thanks Wietse,
                  >>
                  >> We do use LDAP for our transport map for delivery:
                  >
                  > What is the error if it is not "User unknown in virtual alias table"?

                  Hi Wieste,

                  I'm not sure where the error is you are expecting me to find? This is the
                  full log of the connection, including the message being bounced back:

                  Oct 1 13:11:06 zre-ldap002 postfix/smtpd[8938]: connect from
                  zre-ldap002.eng.vmware.com[10.137.242.52]
                  Oct 1 13:11:06 zre-ldap002 postfix/smtpd[8938]: NOQUEUE: filter: RCPT from
                  zre-ldap002.eng.vmware.com[10.137.242.52]:
                  <testuser001@...>: Sender address triggers FILTER
                  smtp-amavis:[127.0.0.1]:10026;
                  from=<testuser001@...>
                  to=<baduser@...> proto=ESMTP
                  helo=<zre-ldap002.eng.vmware.com>
                  Oct 1 13:11:07 zre-ldap002 postfix/smtpd[8938]: 000501E37BC:
                  client=zre-ldap002.eng.vmware.com[10.137.242.52]
                  Oct 1 13:11:07 zre-ldap002 postfix/cleanup[8234]: 000501E37BC:
                  message-id=<1387711364.9.1349122266928.JavaMail.root@...>
                  Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 000501E37BC:
                  from=<testuser001@...>, size=765, nrcpt=1 (queue
                  active)
                  Oct 1 13:11:07 zre-ldap002 postfix/smtpd[8938]: disconnect from
                  zre-ldap002.eng.vmware.com[10.137.242.52]
                  Oct 1 13:11:07 zre-ldap002 amavis[789]: (00789-04) ESMTP:[127.0.0.1]:10026
                  /opt/zimbra/data/amavisd/tmp/amavis-20121001T073001-00789-bnitXfGD:
                  <testuser001@...> ->
                  <baduser@...> Received: from
                  zre-ldap002.eng.vmware.com ([127.0.0.1]) by localhost
                  (zre-ldap002.eng.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with
                  ESMTP for <baduser@...>; Mon, 1 Oct 2012 13:11:07
                  -0700 (PDT)
                  Oct 1 13:11:07 zre-ldap002 amavis[789]: (00789-04) Checking: WsQIZc5ms0X9
                  ORIGINATING/MYNETS [10.137.242.52] <testuser001@...>
                  -> <baduser@...>
                  Oct 1 13:11:07 zre-ldap002 postfix/smtpd[8296]: connect from
                  localhost[127.0.0.1]
                  Oct 1 13:11:07 zre-ldap002 postfix/smtpd[8296]: 2D0711E37BE:
                  client=localhost[127.0.0.1]
                  Oct 1 13:11:07 zre-ldap002 postfix/cleanup[8234]: 2D0711E37BE:
                  message-id=<1387711364.9.1349122266928.JavaMail.root@...>
                  Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 2D0711E37BE:
                  from=<testuser001@...>, size=1614, nrcpt=1 (queue
                  active)
                  Oct 1 13:11:07 zre-ldap002 postfix/smtpd[8296]: disconnect from
                  localhost[127.0.0.1]
                  Oct 1 13:11:07 zre-ldap002 amavis[789]: (00789-04) FWD from
                  <testuser001@...> ->
                  <baduser@...>,BODY=7BIT 250 2.0.0 from
                  MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2D0711E37BE
                  Oct 1 13:11:07 zre-ldap002 amavis[789]: (00789-04) Passed CLEAN
                  {RelayedInternal}, ORIGINATING/MYNETS LOCAL [10.137.242.52]:40266
                  [10.137.242.52] <testuser001@...> ->
                  <baduser@...>, Queue-ID: 000501E37BC, Message-ID:
                  <1387711364.9.1349122266928.JavaMail.root@...>,
                  mail_id: WsQIZc5ms0X9, Hits: -2.087, size: 765, queued_as: 2D0711E37BE, 191
                  ms
                  Oct 1 13:11:07 zre-ldap002 postfix/smtp[8257]: 000501E37BC:
                  to=<baduser@...>, relay=127.0.0.1[127.0.0.1]:10026,
                  delay=0.22, delays=0.03/0/0/0.19, dsn=2.0.0, status=sent (250 2.0.0 from
                  MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2D0711E37BE)
                  Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 000501E37BC: removed
                  Oct 1 13:11:07 zre-ldap002 postfix/error[8324]: 2D0711E37BE:
                  to=<baduser@...>, relay=none, delay=0.06,
                  delays=0.03/0/0/0.02, dsn=5.0.0, status=bounced (zre-ldap002.eng.vmware.com)
                  Oct 1 13:11:07 zre-ldap002 postfix/cleanup[8234]: 3A75C1E37BC:
                  message-id=<20121001201107.3A75C1E37BC@...>
                  Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 3A75C1E37BC: from=<>,
                  size=3670, nrcpt=1 (queue active)
                  Oct 1 13:11:07 zre-ldap002 postfix/bounce[8328]: 2D0711E37BE: sender
                  non-delivery notification: 3A75C1E37BC
                  Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 2D0711E37BE: removed
                  Oct 1 13:11:07 zre-ldap002 postfix/lmtp[8941]: 3A75C1E37BC:
                  to=<testuser001@...>,
                  relay=zre-ldap002.eng.vmware.com[10.137.242.52]:7025, delay=0.14,
                  delays=0.03/0.01/0/0.1, dsn=2.1.5, status=sent (250 2.1.5 Delivery OK)
                  Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 3A75C1E37BC: removed


                  The email I get back says:

                  Received: from zre-ldap002.eng.vmware.com (LHLO zre-ldap002.eng.vmware.com)
                  (10.137.242.52) by zre-ldap002.eng.vmware.com with LMTP; Mon, 1 Oct 2012
                  13:11:07 -0700 (PDT)
                  Received: by zre-ldap002.eng.vmware.com (Postfix)
                  id 3A75C1E37BC; Mon, 1 Oct 2012 13:11:07 -0700 (PDT)
                  Date: Mon, 1 Oct 2012 13:11:07 -0700 (PDT)
                  From: MAILER-DAEMON@... (Mail Delivery System)
                  Subject: Undelivered Mail Returned to Sender
                  To: testuser001@...
                  Auto-Submitted: auto-replied
                  MIME-Version: 1.0
                  Content-Type: multipart/report; report-type=delivery-status;
                  boundary="2D0711E37BE.1349122267/zre-ldap002.eng.vmware.com"
                  Content-Transfer-Encoding: 7bit
                  Message-Id: <20121001201107.3A75C1E37BC@...>

                  This is a MIME-encapsulated message.

                  --2D0711E37BE.1349122267/zre-ldap002.eng.vmware.com
                  Content-Description: Notification
                  Content-Type: text/plain; charset=us-ascii

                  This is the mail system at host zre-ldap002.eng.vmware.com.

                  I'm sorry to have to inform you that your message could not
                  be delivered to one or more recipients. It's attached below.

                  For further assistance, please send mail to postmaster.

                  If you do so, please include this problem report. You can
                  delete your own text from the attached returned message.

                  The mail system

                  <baduser@...>: zre-ldap002.eng.vmware.com

                  --2D0711E37BE.1349122267/zre-ldap002.eng.vmware.com
                  Content-Description: Delivery report
                  Content-Type: message/delivery-status

                  Reporting-MTA: dns; zre-ldap002.eng.vmware.com
                  X-Postfix-Queue-ID: 2D0711E37BE
                  X-Postfix-Sender: rfc822; testuser001@...
                  Arrival-Date: Mon, 1 Oct 2012 13:11:07 -0700 (PDT)

                  Final-Recipient: rfc822; baduser@...
                  Original-Recipient: rfc822;baduser@...
                  Action: failed
                  Status: 5.0.0
                  Diagnostic-Code: X-Postfix; zre-ldap002.eng.vmware.com

                  --2D0711E37BE.1349122267/zre-ldap002.eng.vmware.com
                  Content-Description: Undelivered Message
                  Content-Type: message/rfc822
                  Content-Transfer-Encoding: 7bit

                  Return-Path: <testuser001@...>
                  Received: from localhost (localhost [127.0.0.1])
                  by zre-ldap002.eng.vmware.com (Postfix) with ESMTP id 2D0711E37BE
                  for <baduser@...>; Mon, 1 Oct 2012 13:11:07 -0700
                  (PDT)
                  X-Virus-Scanned: amavisd-new at zre-ldap002.eng.vmware.com
                  X-Spam-Flag: NO
                  X-Spam-Score: -2.087
                  X-Spam-Level:
                  X-Spam-Status: No, score=-2.087 tagged_above=-10 required=6.6
                  tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, RDNS_NONE=0.793,
                  T_HELO_NO_DOMAIN=0.01, T_LONG_HEADER_LINE_80=0.01,
                  T_NOT_A_PERSON=-0.01, T_RP_MATCHES_RCVD=-0.01,
                  T_THREAD_INDEX_BAD=0.01, T_UNKNOWN_ORIGIN=0.01] autolearn=no
                  Received: from zre-ldap002.eng.vmware.com ([127.0.0.1])
                  by localhost (zre-ldap002.eng.vmware.com [127.0.0.1]) (amavisd-new, port
                  10026)
                  with ESMTP id WsQIZc5ms0X9 for <baduser@...>;
                  Mon, 1 Oct 2012 13:11:07 -0700 (PDT)
                  Received: from zre-ldap002.eng.vmware.com (zre-ldap002.eng.vmware.com
                  [10.137.242.52])
                  by zre-ldap002.eng.vmware.com (Postfix) with ESMTP id 000501E37BC
                  for <baduser@...>; Mon, 1 Oct 2012 13:11:06 -0700
                  (PDT)
                  Date: Mon, 1 Oct 2012 13:11:06 -0700 (PDT)
                  From: testuser001@...
                  To: baduser@...
                  Message-ID:
                  <1387711364.9.1349122266928.JavaMail.root@...>
                  Subject: bad email test
                  MIME-Version: 1.0
                  Content-Type: text/plain; charset=utf-8
                  Content-Transfer-Encoding: 7bit
                  X-Originating-IP: [10.114.53.3]
                  X-Mailer: Zimbra 8.0.1_GA_5490 (ZimbraWebClient - FF15 (Win)/8.0.1_GA_5490)
                  Thread-Topic: bad email test
                  Thread-Index: qzz+ZTrwa8skbJC/pu2Tsw1a7WrJiA==

                  test

                  --2D0711E37BE.1349122267/zre-ldap002.eng.vmware.com--



                  Thanks!

                  --Quanah

                  --

                  Quanah Gibson-Mount
                  Sr. Member of Technical Staff
                  Zimbra, Inc
                  A Division of VMware, Inc.
                  --------------------
                  Zimbra :: the leader in open source messaging and collaboration
                • Wietse Venema
                  ... I have two questions. Please answer both, if may save us 50% of the time. What is postconf -n output? Does zre-ldap002.eng.vmware.com match
                  Message 8 of 16 , Oct 1, 2012
                    Quanah Gibson-Mount:
                    > If you do so, please include this problem report. You can
                    > delete your own text from the attached returned message.
                    >
                    > The mail system
                    >
                    > <baduser@...>: zre-ldap002.eng.vmware.com

                    I have two questions. Please answer both, if may save us 50%
                    of the time.

                    What is "postconf -n" output?

                    Does zre-ldap002.eng.vmware.com match $virtual_alias_domains?

                    Wietse
                  • Quanah Gibson-Mount
                    --On Monday, October 01, 2012 8:04 PM -0400 Wietse Venema ... alias_maps = hash:/etc/aliases always_add_missing_headers = yes bounce_notice_recipient =
                    Message 9 of 16 , Oct 1, 2012
                      --On Monday, October 01, 2012 8:04 PM -0400 Wietse Venema
                      <wietse@...> wrote:

                      > Quanah Gibson-Mount:
                      >> If you do so, please include this problem report. You can
                      >> delete your own text from the attached returned message.
                      >>
                      >> The mail system
                      >>
                      >> <baduser@...>: zre-ldap002.eng.vmware.com
                      >
                      > I have two questions. Please answer both, if may save us 50%
                      > of the time.
                      >
                      > What is "postconf -n" output?

                      alias_maps = hash:/etc/aliases
                      always_add_missing_headers = yes
                      bounce_notice_recipient = postmaster
                      bounce_queue_lifetime = 5d
                      broken_sasl_auth_clients = yes
                      command_directory = /opt/zimbra/postfix/sbin
                      config_directory = /opt/zimbra/postfix-2.10-20120422.2z/conf
                      content_filter = smtp-amavis:[127.0.0.1]:10024
                      daemon_directory = /opt/zimbra/postfix/libexec
                      delay_warning_time = 0h
                      disable_dns_lookups = no
                      header_checks =
                      in_flow_delay = 1s
                      inet_protocols = ipv4
                      lmtp_connection_cache_destinations =
                      lmtp_connection_cache_time_limit = 4s
                      lmtp_host_lookup = dns
                      local_header_rewrite_clients = permit_mynetworks,permit_sasl_authenticated
                      mail_owner = postfix
                      mailbox_size_limit = 0
                      mailq_path = /opt/zimbra/postfix/sbin/mailq
                      manpage_directory = /opt/zimbra/postfix/man
                      maximal_backoff_time = 4000s
                      message_size_limit = 10240000
                      minimal_backoff_time = 300s
                      mydestination = localhost
                      myhostname = zre-ldap002.eng.vmware.com
                      mynetworks = 127.0.0.0/8 10.137.242.0/24
                      newaliases_path = /opt/zimbra/postfix/sbin/newaliases
                      non_smtpd_milters =
                      notify_classes = resource,software
                      propagate_unmatched_extensions = canonical
                      queue_directory = /opt/zimbra/data/postfix/spool
                      queue_run_delay = 300s
                      recipient_delimiter =
                      relayhost =
                      sender_canonical_maps = proxy:ldap:/opt/zimbra/conf/ldap-scm.cf
                      sendmail_path = /opt/zimbra/postfix/sbin/sendmail
                      setgid_group = postdrop
                      smtp_cname_overrides_servername = no
                      smtp_sasl_auth_enable = no
                      smtp_sasl_mechanism_filter =
                      smtp_sasl_password_maps =
                      smtp_sasl_security_options = noplaintext,noanonymous
                      smtp_tls_security_level =
                      smtpd_client_restrictions = reject_unauth_pipelining
                      smtpd_data_restrictions = reject_unauth_pipelining
                      smtpd_end_of_data_restrictions =
                      smtpd_helo_required = yes
                      smtpd_milters =
                      smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                      permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination,
                      reject_unlisted_recipient, reject_invalid_helo_hostname,
                      reject_non_fqdn_sender, permit
                      smtpd_reject_unlisted_recipient = no
                      smtpd_sasl_auth_enable = yes
                      smtpd_sasl_authenticated_header = no
                      smtpd_sasl_security_options = noanonymous
                      smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
                      smtpd_sender_restrictions = check_sender_access
                      regexp:/opt/zimbra/postfix/conf/tag_as_originating.re, permit_mynetworks,
                      permit_sasl_authenticated, permit_tls_clientcerts, check_sender_access
                      regexp:/opt/zimbra/postfix/conf/tag_as_foreign.re
                      smtpd_tls_auth_only = yes
                      smtpd_tls_cert_file = /opt/zimbra/conf/smtpd.crt
                      smtpd_tls_key_file = /opt/zimbra/conf/smtpd.key
                      smtpd_tls_loglevel = 1
                      smtpd_tls_security_level = may
                      transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
                      virtual_alias_domains = proxy:ldap:/opt/zimbra/conf/ldap-vad.cf
                      virtual_alias_expansion_limit = 10000
                      virtual_alias_maps = proxy:ldap:/opt/zimbra/conf/ldap-vam.cf
                      virtual_mailbox_domains = proxy:ldap:/opt/zimbra/conf/ldap-vmd.cf
                      virtual_mailbox_maps = proxy:ldap:/opt/zimbra/conf/ldap-vmm.cf
                      virtual_transport = error


                      > Does zre-ldap002.eng.vmware.com match $virtual_alias_domains?

                      zimbra@zre-ldap002:~/conf$ cat ldap-vad.cf
                      server_host = ldap://zre-ldap002.eng.vmware.com:389
                      server_port = 389
                      search_base =
                      query_filter =
                      (&(zimbraDomainName=%s)(zimbraDomainType=alias)(zimbraMailStatus=enabled))
                      result_attribute = zimbraDomainName
                      version = 3
                      start_tls = yes
                      tls_ca_cert_dir = /opt/zimbra/conf/ca
                      bind = yes
                      bind_dn = uid=zmpostfix,cn=appaccts,cn=zimbra
                      bind_pw = ajJgnGcCbY
                      timeout = 30


                      This filter returns no result, because this is the actual domain, not an
                      alias:

                      zimbra@zre-ldap002:~/data/ldap/config/cn=config$ ldapsearch -x -LLL -b ""
                      -H ldap://zre-ldap002.eng.vmware.com:389 -D
                      uid=zmpostfix,cn=appaccts,cn=zimbra -w ajJgnGcCbY
                      "(&(zimbraDomainName=zre-ldap002.eng.vmware.com)(zimbraMailStatus=enabled)(zimbraDomainType=alias))"
                      zimbraDomainName
                      zimbra@zre-ldap002:~/data/ldap/config/cn=config$

                      --Quanah

                      --

                      Quanah Gibson-Mount
                      Sr. Member of Technical Staff
                      Zimbra, Inc
                      A Division of VMware, Inc.
                      --------------------
                      Zimbra :: the leader in open source messaging and collaboration
                    • Viktor Dukhovni
                      ... Wietse is working on the assumption that the message is routed to the error transport by internal Postfix logic (such as virtual alias domain recipient
                      Message 10 of 16 , Oct 1, 2012
                        On Mon, Oct 01, 2012 at 04:51:15PM -0700, Quanah Gibson-Mount wrote:

                        > >>We do use LDAP for our transport map for delivery:
                        > >
                        > >What is the error if it is not "User unknown in virtual alias table"?
                        >
                        > Hi Wieste,
                        >
                        > I'm not sure where the error is you are expecting me to find? This
                        > is the full log of the connection, including the message being
                        > bounced back:

                        Wietse is working on the assumption that the message is routed to
                        the "error" transport by internal Postfix logic (such as virtual
                        alias domain recipient that fails to be rewritted, ...).

                        My impression is that Quanah's routing table explicitly returns
                        the "error" transport for this user, but fails to specify a nexthop
                        (thus the recipient domain is the error message).

                        A correct configuration of the error(8) transport is (if I remember
                        my 5.1.x codes correctly):

                        user@... error:5.1.1 Mailbox unavailable
                        example.com error:5.1.2 Destination domain unreachable

                        So all Quanah has to do is use the error(8) transport properly. Examples
                        can be found (IIRC):

                        http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall

                        --
                        Viktor.
                      • Wietse Venema
                        ... For background, you may want to read up about address classes: http://www.postfix.org/ADDRESS_CLASS_README.html Which address class does
                        Message 11 of 16 , Oct 2, 2012
                          Quanah Gibson-Mount:
                          > mydestination = localhost
                          > transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
                          > virtual_alias_domains = proxy:ldap:/opt/zimbra/conf/ldap-vad.cf
                          > virtual_alias_expansion_limit = 10000
                          > virtual_alias_maps = proxy:ldap:/opt/zimbra/conf/ldap-vam.cf
                          > virtual_mailbox_domains = proxy:ldap:/opt/zimbra/conf/ldap-vmd.cf
                          > virtual_mailbox_maps = proxy:ldap:/opt/zimbra/conf/ldap-vmm.cf
                          > virtual_transport = error

                          For background, you may want to read up about address classes:
                          http://www.postfix.org/ADDRESS_CLASS_README.html

                          Which address class does zre-ldap002.eng.vmware.com match?

                          - virtual_alias_domains?

                          If this is the address class, valid recipients in this domain
                          must be aliased to a different domain. The remaining recipients
                          are hard-coded to resolve to:

                          transport=error
                          nexthop=User unknown in virtual alias table
                          recipient=localpart@...

                          Yesterday's trivial-rewrite patch changes that into "5.1.1 User
                          unknown...".

                          - virtual_mailbox_domains?

                          If this is the address class, then all known and unknown
                          recipients in this domain will resolve to:

                          transport=error
                          nexthop=zre-ldap002.eng.vmware.com
                          recipient=localpart@...

                          The resolver's result may be mutated further by transport_maps
                          lookups, before the error mailer submits a non-delivery notification.

                          As documented,

                          - The error mailer reports the value of the nexhop attribute as the
                          reason for non-delivery.

                          - If you specify a transport name without nexthop attribute, then
                          the nexthop attribute becomes the recipient's domain.

                          I could speculate that your "virtual_transport = error" causes the
                          nexthop to become the recipient domain (zre-ldap002.eng.vmware.com)
                          which then is reported as the reason for non-delivery, but I don't
                          speculate because I have no idea what your LDAP results are.

                          To find out what really happens you need to answer the questions
                          above and walk through the LDAP lookups.

                          Wietse
                        • Viktor Dukhovni
                          ... I am willing to speculate more boldly, this setting is clearly problematic. The error transport should not be used without an explicit nexthop. A better
                          Message 12 of 16 , Oct 2, 2012
                            On Tue, Oct 02, 2012 at 08:21:54AM -0400, Wietse Venema wrote:

                            > Quanah Gibson-Mount:
                            > >
                            > > virtual_transport = error
                            >
                            > [...]
                            >
                            > I could speculate that your "virtual_transport = error" causes the
                            > nexthop to become the recipient domain (zre-ldap002.eng.vmware.com)
                            > which then is reported as the reason for non-delivery, but I don't
                            > speculate because I have no idea what your LDAP results are.

                            I am willing to speculate more boldly, this setting is clearly
                            problematic. The error transport should not be used without
                            an explicit nexthop.

                            A better example is:

                            http://www.postfix.org/MULTI_INSTANCE_README.html#quick

                            ...
                            local_transport = error:5.1.1 Mailbox unavailable

                            or in some cases:

                            local_transport = error:5.1.2 Destination domain unreachable

                            and so on.

                            --
                            Viktor.
                          • Quanah Gibson-Mount
                            --On Tuesday, October 02, 2012 3:47 PM +0000 Viktor Dukhovni ... Hi Viktor and Wieste, First, thanks for the time in helping me with this. The setting for
                            Message 13 of 16 , Oct 2, 2012
                              --On Tuesday, October 02, 2012 3:47 PM +0000 Viktor Dukhovni
                              <postfix-users@...> wrote:

                              > On Tue, Oct 02, 2012 at 08:21:54AM -0400, Wietse Venema wrote:
                              >
                              >> Quanah Gibson-Mount:
                              >> >
                              >> > virtual_transport = error
                              >>
                              >> [...]
                              >>
                              >> I could speculate that your "virtual_transport = error" causes the
                              >> nexthop to become the recipient domain (zre-ldap002.eng.vmware.com)
                              >> which then is reported as the reason for non-delivery, but I don't
                              >> speculate because I have no idea what your LDAP results are.
                              >
                              > I am willing to speculate more boldly, this setting is clearly
                              > problematic. The error transport should not be used without
                              > an explicit nexthop.

                              Hi Viktor and Wieste,

                              First, thanks for the time in helping me with this.

                              The setting for virtual_transport apparently was introduced prior to 2006
                              for reasons I have not yet been able to find. I will note that the
                              documentation for virtual_transport does say that nexthop is optional. ;)
                              It sounds like at least in the case of "error" it is not.

                              I changed the value for virtual_transport to be:

                              error: 5.1.1 Mailbox unavailable

                              And now I see:

                              Oct 2 11:54:21 zre-ldap002 postfix/error[331]: 897561E37C6:
                              to=<zimbra@...>, relay=none, delay=0.06,
                              delays=0.03/0/0/0.02, dsn=5.1.1, status=bounced (Mailbox unavail
                              able)
                              Oct 2 11:54:21 zre-ldap002 postfix/qmgr[327]: 897561E37C6: removed


                              So, does that look more correct to you as the way to correctly handle this?


                              As far as the LDAP searches executed goes, we have:

                              Virtual Alias Domains: no result
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=61 SRCH base=""
                              scope=2 deref=0
                              filter="(&(zimbraDomainName=zre-ldap002.eng.vmware.com)(zimbraDomainType=alias)(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=61 SRCH
                              attr=zimbraDomainName
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=61 SEARCH RESULT
                              tag=101 err=0 nentries=0 text=

                              Virtual Mailbox Domains: 1 result

                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=62 SRCH base=""
                              scope=2 deref=0
                              filter="(&(zimbraDomainName=zre-ldap002.eng.vmware.com)(zimbraDomainType=local)(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=62 SRCH
                              attr=zimbraDomainName
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=62 SEARCH RESULT
                              tag=101 err=0 nentries=1 text=

                              Transport Maps: no result

                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=63 SRCH base=""
                              scope=2 deref=0
                              filter="(&(|(zimbraMailDeliveryAddress=baduser@...)(zimbraDomainName=baduser@...))(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=63 SRCH
                              attr=zimbraMailTransport
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=63 SEARCH RESULT
                              tag=101 err=0 nentries=0 text=
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=64 SRCH base=""
                              scope=2 deref=0
                              filter="(&(|(zimbraMailDeliveryAddress=zre-ldap002.eng.vmware.com)(zimbraDomainName=zre-ldap002.eng.vmware.com))(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=64 SRCH
                              attr=zimbraMailTransport
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=64 SEARCH RESULT
                              tag=101 err=0 nentries=1 text=
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=65 SRCH base=""
                              scope=2 deref=0
                              filter="(&(|(zimbraMailDeliveryAddress=.eng.vmware.com)(zimbraDomainName=.eng.vmware.com))(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=65 SRCH
                              attr=zimbraMailTransport
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=65 SEARCH RESULT
                              tag=101 err=0 nentries=0 text=
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=66 SRCH base=""
                              scope=2 deref=0
                              filter="(&(|(zimbraMailDeliveryAddress=.vmware.com)(zimbraDomainName=.vmware.com))(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=66 SRCH
                              attr=zimbraMailTransport
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=66 SEARCH RESULT
                              tag=101 err=0 nentries=0 text=
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=67 SRCH base=""
                              scope=2 deref=0
                              filter="(&(|(zimbraMailDeliveryAddress=.com)(zimbraDomainName=.com))(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=67 SRCH
                              attr=zimbraMailTransport
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=67 SEARCH RESULT
                              tag=101 err=0 nentries=0 text=
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=68 SRCH base=""
                              scope=2 deref=0
                              filter="(&(|(zimbraMailDeliveryAddress=\2A)(zimbraDomainName=\2A))(zimbraMailStatus=enabled))"
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=68 SRCH
                              attr=zimbraMailTransport
                              Oct 2 10:26:19 zre-ldap002 slapd[9023]: conn=28855 op=68 SEARCH RESULT
                              tag=101 err=0 nentries=0 text=


                              Thanks again for your help!

                              --Quanah

                              --

                              Quanah Gibson-Mount
                              Sr. Member of Technical Staff
                              Zimbra, Inc
                              A Division of VMware, Inc.
                              --------------------
                              Zimbra :: the leader in open source messaging and collaboration
                            • Wietse Venema
                              ... 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
                              Message 14 of 16 , Oct 2, 2012
                                Quanah Gibson-Mount:
                                > I changed the value for virtual_transport to be:
                                >
                                > error: 5.1.1 Mailbox unavailable
                                >
                                > And now I see:
                                >
                                > Oct 2 11:54:21 zre-ldap002 postfix/error[331]: 897561E37C6:
                                > to=<zimbra@...>, relay=none, delay=0.06,
                                > delays=0.03/0/0/0.02, dsn=5.1.1, status=bounced (Mailbox unavail
                                > able)
                                > Oct 2 11:54:21 zre-ldap002 postfix/qmgr[327]: 897561E37C6: removed
                                >
                                > So, does that look more correct to you as the way to correctly handle this?

                                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.

                                This would be a good time to study ADDRESS_CLASS_README. I have
                                mentioned this document before.

                                Wietse
                              • Viktor Dukhovni
                                ... 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
                                Message 15 of 16 , Oct 2, 2012
                                  On Tue, Oct 02, 2012 at 03:34:38PM -0400, Wietse Venema wrote:

                                  > > So, does that look more correct to you as the way to correctly handle this?
                                  >
                                  > 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".

                                  --
                                  Viktor.
                                • Quanah Gibson-Mount
                                  --On Tuesday, October 02, 2012 8:11 PM +0000 Viktor Dukhovni ... Thanks again! I will see if I can figure out what the intent was to begin with, and rework
                                  Message 16 of 16 , 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

                                    --

                                    Quanah Gibson-Mount
                                    Sr. Member of Technical Staff
                                    Zimbra, Inc
                                    A Division of VMware, Inc.
                                    --------------------
                                    Zimbra :: the leader in open source messaging and collaboration
                                  Your message has been successfully submitted and would be delivered to recipients shortly.