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

Re: error daemon dsn code

Expand Messages
  • 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 1 of 16 , Oct 1, 2012
    • 0 Attachment
      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 2 of 16 , Oct 1, 2012
      • 0 Attachment
        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 3 of 16 , Oct 1, 2012
        • 0 Attachment
          --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 4 of 16 , Oct 1, 2012
          • 0 Attachment
            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 5 of 16 , Oct 1, 2012
            • 0 Attachment
              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 6 of 16 , Oct 1, 2012
              • 0 Attachment
                --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 7 of 16 , Oct 1, 2012
                • 0 Attachment
                  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 8 of 16 , Oct 1, 2012
                  • 0 Attachment
                    --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 9 of 16 , Oct 1, 2012
                    • 0 Attachment
                      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 10 of 16 , Oct 2, 2012
                      • 0 Attachment
                        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 11 of 16 , Oct 2, 2012
                        • 0 Attachment
                          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 12 of 16 , Oct 2, 2012
                          • 0 Attachment
                            --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 13 of 16 , Oct 2, 2012
                            • 0 Attachment
                              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 14 of 16 , Oct 2, 2012
                              • 0 Attachment
                                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 15 of 16 , Oct 2, 2012
                                • 0 Attachment
                                  --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.