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

Re: error daemon dsn code

Expand Messages
  • Wietse Venema
    ... If the error is User unknown in virtual alias table , then the fix is in trivial-rewrite/resolve.c:
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.