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

Re: Trouble configuring backup MX to reject unauth destination

Expand Messages
  • Titanus Eramius
    Fri, 22 Mar 2013 19:12:40 -0400 (EDT) skrev Wietse Venema ... aptget:~# postalias -q cogky.dk mysql:/etc/postfix/mysql_virtual_mailbox_domains.cf cogky.dk ...
    Message 1 of 28 , Mar 25, 2013
    • 0 Attachment
      Fri, 22 Mar 2013 19:12:40 -0400 (EDT) skrev Wietse Venema
      <wietse@...>:

      > Test your lookups:
      >
      > postmap -q cogky.dk the-virtual_mailbox_domains-table
      > This should return a result (the value does not matter).

      aptget:~# postalias -q cogky.dk
      mysql:/etc/postfix/mysql_virtual_mailbox_domains.cf
      cogky.dk

      > postmap -q real-user@... the-virtual_mailbox_maps-table
      > This should return a result (the mailbox file name).

      aptget:~# postalias -q real-user@...
      mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
      cogky.dk/real-user/

      > postmap -q bogus-user@... the-virtual_mailbox_maps-table
      > This should return no result (Postfix treats this as "user unknown
      > in virtual mailbox table").

      And this does not return a result. Bash gives a error-status of 1.


      Sun, 24 Mar 2013 09:36:03 +0100 skrev mouss <mouss@...>:

      > one possible reason is that you configured a wildcard alias:
      > @... ==> @...
      > (that is anything to cogky maps to same address in aptget.dk).

      As far as I can see that should not be the case. All addresses and
      aliases in the database have a left hand side to it. Is there a way to
      test this?


      I'm using Dovecot 2 as LDA for final delivery and IMAP-services, so
      "virtual_transport" is set to "dovecot" in main.cf and the following
      lines are in master.cf:

      dovecot unix - n n - - pipe
      flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d
      ${recipient}


      When looking through the log, it looks like the "user unknown"
      response comes from Dovecot and not Postfix:

      Mar 25 13:43:53 aptget postfix/smtpd[24133]: connect from
      unknown[92.243.255.38]

      Mar 25 13:43:54 aptget postfix/smtpd[24133]:
      Anonymous TLS connection established from unknown[92.243.255.38]: TLSv1
      with cipher DHE-RSA-AES128-SHA (128/128 bits)

      Mar 25 13:43:54 aptget dovecot: auth-worker(24136): mysql(localhost):
      Connected to database postfix

      Mar 25 13:43:54 aptget postfix/smtpd[24133]: BB6AD371DDC4:
      client=unknown[92.243.255.38], sasl_method=LOGIN,
      sasl_username=HIDDEN_USER@...

      Mar 25 13:43:54 aptget postfix-policyd: connection from: 127.0.0.1
      port: 48937 slots: 0 of 4096 used

      Mar 25 13:43:54 aptget postfix-policyd: connecting to mysql database:
      localhost

      Mar 25 13:43:54 aptget postfix-policyd: connected..

      Mar 25 13:43:54 aptget postfix-policyd: rcpt=16, throttle=clear(a),
      host=92.243.255.38, from=titanus@..., to=unknown-user@...,
      size=365/26214400, quota=365/1800000000, count=1/125(10),
      rcpt=1/600(11), threshold=0%|0%|0%, sasl_username=HIDDEN_USER@...

      Mar 25 13:43:54 aptget postfix/cleanup[24138]: BB6AD371DDC4:
      message-id=<20130325134351.5c2e026f@...>

      Mar 25 13:43:54 aptget postfix/qmgr[23982]: BB6AD371DDC4:
      from=<titanus@...>, size=663, nrcpt=1 (queue active)

      Mar 25 13:43:55 aptget postfix/pipe[24140]: BB6AD371DDC4:
      to=<unknown-user@...>, relay=dovecot, delay=0.38,
      delays=0.26/0.03/0/0.09, dsn=5.1.1, status=bounced (user unknown)

      Mar 25 13:43:55 aptget postfix/cleanup[24138]: 16228371DE3E:
      message-id=<20130325124355.16228371DE3E@...>

      Mar 25 13:43:55 aptget postfix/bounce[24142]: BB6AD371DDC4: sender
      non-delivery notification: 16228371DE3E

      Mar 25 13:43:55 aptget postfix/qmgr[23982]: 16228371DE3E: from=<>,
      size=2673, nrcpt=1 (queue active)

      Mar 25 13:43:55 aptget postfix/qmgr[23982]: BB6AD371DDC4: removed

      Mar 25 13:43:55 aptget postfix/smtpd[24133]: disconnect from
      unknown[92.243.255.38]


      Thank you again for helping
      Titanus


      postconf -n
      alias_maps = hash:/etc/aliases

      bounce_template_file = /etc/postfix/bounce.cf

      broken_sasl_auth_clients = yes

      config_directory = /etc/postfix

      delay_warning_time = 4

      disable_vrfy_command = yes

      dovecot_destination_recipient_limit = 1

      inet_interfaces = 46.21.105.38

      local_recipient_maps = $virtual_mailbox_maps

      mailman_destination_recipient_limit = 1

      maximal_queue_lifetime = 15

      message_size_limit = 26214400

      mydestination = localhost

      mydomain = aptget.dk

      myhostname = aptget.aptget.dk

      mynetworks = 127.0.0.0/8

      postscreen_dnsbl_action = enforce
      postscreen_dnsbl_sites = truncate.gbudb.net*2 b.barracudacentral.org*1
      zen.spamhaus.org*1 bl.spamcop.net*1

      postscreen_dnsbl_threshold = 2

      postscreen_greet_action = enforce

      recipient_canonical_classes = envelope_recipient

      recipient_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
      tcp:127.0.0.1:10002

      sender_canonical_classes = envelope_sender

      sender_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
      tcp:127.0.0.1:10001

      smtp_tls_security_level = may

      smtp_tls_session_cache_database =
      btree:$data_directory/smtp_tls_session_cache

      smtpd_data_restrictions = reject_unauth_pipelining,
      reject_multi_recipient_bounce,

      smtpd_helo_required = yes

      smtpd_recipient_restrictions = reject_non_fqdn_sender,
      reject_non_fqdn_recipient, reject_unknown_sender_domain,
      reject_unknown_recipient_domain, reject_unauth_destination,

      smtpd_sasl_auth_enable = yes

      smtpd_sasl_exceptions_networks = $mynetworks

      smtpd_sasl_path = private/auth

      smtpd_sasl_security_options = noanonymous

      smtpd_sasl_type = dovecot

      smtpd_tls_ask_ccert = yes

      smtpd_tls_cert_file = /etc/ssl/self-signed/smtpd.crt

      smtpd_tls_key_file = /etc/ssl/self-signed/smtpd.key

      smtpd_tls_loglevel = 1

      smtpd_tls_received_header = yes

      smtpd_tls_security_level = may

      smtpd_tls_session_cache_database =
      btree:$data_directory/smtpd_tls_session_cache

      spamassassin_destination_recipient_limit = 1

      tls_random_source = dev:/dev/urandom

      transport_maps = hash:/etc/postfix/transport.cf

      virtual_alias_maps =
      proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf

      virtual_gid_maps = static:5000

      virtual_mailbox_base = /home/vmail

      virtual_mailbox_domains =
      proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf

      virtual_mailbox_maps =
      proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf

      virtual_transport = dovecot

      virtual_uid_maps = static:5000
    • Wietse Venema
      ... OK, the table is working as it should. Now let s find out why the bogus recipient is accepted: Next step: - Connect to the public (not content
      Message 2 of 28 , Mar 25, 2013
      • 0 Attachment
        Titanus Eramius:
        > Fri, 22 Mar 2013 19:12:40 -0400 (EDT) skrev Wietse Venema
        > <wietse@...>:
        >
        > > Test your lookups:
        > >
        > > postmap -q cogky.dk the-virtual_mailbox_domains-table
        > > This should return a result (the value does not matter).
        >
        > aptget:~# postalias -q cogky.dk
        > mysql:/etc/postfix/mysql_virtual_mailbox_domains.cf
        > cogky.dk
        >
        > > postmap -q real-user@... the-virtual_mailbox_maps-table
        > > This should return a result (the mailbox file name).
        >
        > aptget:~# postalias -q real-user@...
        > mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
        > cogky.dk/real-user/
        >
        > > postmap -q bogus-user@... the-virtual_mailbox_maps-table
        > > This should return no result (Postfix treats this as "user unknown
        > > in virtual mailbox table").
        >
        > And this does not return a result. Bash gives a error-status of 1.

        OK, the table is working as it should. Now let's find out
        why the bogus recipient is accepted:

        Next step:

        - Connect to the public (not content re-injection) SMTP port and try

        $ telnet hostname 25
        ehlo ...
        mail from:<>
        rcpt to:<real-user@...>
        rcpt to:<bogus-user@...>
        quit

        One recipient should be accepted, the other not.

        - Same experiment for mail over the submission port, if you have one:

        $ openssl s_client -starttls smtp -connect hostname:587
        ehlo ...
        mail from:<>
        rcpt to:<real-user@...>
        rcpt to:<bogus-user@...>
        quit

        This is just in case.

        Wietse
      • Titanus Eramius
        Mon, 25 Mar 2013 11:30:41 -0400 (EDT) skrev Wietse Venema ... Both RCPT TOs are successful titanus@asrock:~$ telnet 46.21.105.38 25 Trying 46.21.105.38...
        Message 3 of 28 , Mar 25, 2013
        • 0 Attachment
          Mon, 25 Mar 2013 11:30:41 -0400 (EDT) skrev Wietse Venema
          <wietse@...>:

          > Titanus Eramius:
          > > Fri, 22 Mar 2013 19:12:40 -0400 (EDT) skrev Wietse Venema
          > > <wietse@...>:
          > >
          > > > Test your lookups:
          > > >
          > > > postmap -q cogky.dk the-virtual_mailbox_domains-table
          > > > This should return a result (the value does not matter).
          > >
          > > aptget:~# postalias -q cogky.dk
          > > mysql:/etc/postfix/mysql_virtual_mailbox_domains.cf
          > > cogky.dk
          > >
          > > > postmap -q real-user@... the-virtual_mailbox_maps-table
          > > > This should return a result (the mailbox file name).
          > >
          > > aptget:~# postalias -q real-user@...
          > > mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
          > > cogky.dk/real-user/
          > >
          > > > postmap -q bogus-user@... the-virtual_mailbox_maps-table
          > > > This should return no result (Postfix treats this as "user unknown
          > > > in virtual mailbox table").
          > >
          > > And this does not return a result. Bash gives a error-status of 1.
          >
          > OK, the table is working as it should. Now let's find out
          > why the bogus recipient is accepted:
          >
          > Next step:
          >
          > - Connect to the public (not content re-injection) SMTP port and try
          >
          > $ telnet hostname 25
          > ehlo ...
          > mail from:<>
          > rcpt to:<real-user@...>
          > rcpt to:<bogus-user@...>
          > quit
          >
          > One recipient should be accepted, the other not.
          >
          > - Same experiment for mail over the submission port, if you have one:
          >
          > $ openssl s_client -starttls smtp -connect hostname:587
          > ehlo ...
          > mail from:<>
          > rcpt to:<real-user@...>
          > rcpt to:<bogus-user@...>
          > quit
          >
          > This is just in case.
          >
          > Wietse

          Both RCPT TOs are successful

          titanus@asrock:~$ telnet 46.21.105.38 25
          Trying 46.21.105.38...
          Connected to 46.21.105.38.
          Escape character is '^]'.
          220 aptget.aptget.dk ESMTP Postfix
          EHLO Hej
          250-aptget.aptget.dk
          250-PIPELINING
          250-SIZE 26214400
          250-ETRN
          250-STARTTLS
          250-AUTH PLAIN LOGIN
          250-AUTH=PLAIN LOGIN
          250-ENHANCEDSTATUSCODES
          250-8BITMIME
          250 DSN
          MAIL FROM:<>
          250 2.1.0 Ok
          RCPT TO:<real-user@...>
          250 2.1.5 Ok
          RCPT TO:<non-existent@...>
          250 2.1.5 Ok
          QUIT
          221 2.0.0 Bye
          Connection closed by foreign host.

          If non-existent@... is substituted with non-existent@...,
          then it is still rejected with "... unknown in virtual mailbox table".

          When trying with submission through telnet, I'm afraid I can't get the
          syntax right. But when using the mail client Claws Mail, Postfix
          accepts non-existent addresses for cogky.dk

          ...
          [17:51:52] ESMTP< 235 2.7.0 Authentication successful
          [17:51:52] ESMTP> MAIL FROM:<nicky@...> SIZE=371
          [17:51:52] SMTP< 250 2.1.0 Ok
          [17:51:52] SMTP> RCPT TO:<non-existent@...>
          [17:51:52] SMTP< 250 2.1.5 Ok
          ...

          Thank you, Titanus
        • Wietse Venema
          ... You appear to have a wild-card rule that replaces @cogky.dk with @aptget.dk. Such a rule matches all addresses including invalid ones. Instead use a MySQL
          Message 4 of 28 , Mar 25, 2013
          • 0 Attachment
            Titanus Eramius:
            > > OK, the table is working as it should. Now let's find out
            > > why the bogus recipient is accepted:
            > >
            > > Next step:
            > >
            > > - Connect to the public (not content re-injection) SMTP port and try
            ...
            > MAIL FROM:<>
            > 250 2.1.0 Ok
            > RCPT TO:<real-user@...>
            > 250 2.1.5 Ok
            > RCPT TO:<non-existent@...>
            > 250 2.1.5 Ok

            > If non-existent@... is substituted with non-existent@...,
            > then it is still rejected with "... unknown in virtual mailbox table".

            You appear to have a wild-card rule that replaces @... with
            @.... Such a rule matches all addresses including invalid ones.

            Instead use a MySQL query as decribed in
            http://tech.groups.yahoo.com/group/postfix-users/message/247913

            Wietse
          • Titanus Eramius
            Mon, 25 Mar 2013 14:09:04 -0400 (EDT) skrev Wietse Venema ... Thank you for the link, it was very informative, but didn t solve the problem. I also tried
            Message 5 of 28 , Apr 5, 2013
            • 0 Attachment
              Mon, 25 Mar 2013 14:09:04 -0400 (EDT) skrev Wietse Venema
              <wietse@...>:

              > Titanus Eramius:

              > > MAIL FROM:<>
              > > 250 2.1.0 Ok
              > > RCPT TO:<real-user@...>
              > > 250 2.1.5 Ok
              > > RCPT TO:<non-existent@...>
              > > 250 2.1.5 Ok
              >
              > > If non-existent@... is substituted with non-existent@...,
              > > then it is still rejected with "... unknown in virtual mailbox
              > > table".
              >
              > You appear to have a wild-card rule that replaces @... with
              > @.... Such a rule matches all addresses including invalid ones.
              >
              > Instead use a MySQL query as decribed in
              > http://tech.groups.yahoo.com/group/postfix-users/message/247913
              >
              > Wietse

              Thank you for the link, it was very informative, but didn't solve the
              problem. I also tried making a virtual_mailbox_maps MySQL query that
              always returned false, but Postfix still accepted all mail, and then
              bounced it after Dovecot rejected it.

              I have converted virtual_mailbox_maps and virtual_mailbox_domains to
              textfiles, so it should be easier to debug on the setup. Please note
              that I had to change server to experiment like this, since I depend
              on the other server.

              The servername is nt-data.dk, and the hosted domain (which all mail is
              accepted for) is nt-backup.dk. The behavior is the same, so mail sent
              to non_existent@... is rejected, while mail sent to
              non_existent@... is accepted, and then bounced.

              In main.cf (please see the bottom for postconf -n) is
              virtual_mailbox_domains =
              hash:/etc/postfix/virtual_mailbox_domains.cf
              virtual_mailbox_maps =
              hash:/etc/postfix/virtual_mailbox_maps.cf

              And the content of those files is
              virtual_mailbox_domains.cf:
              nt-backup.dk OK
              nt-data.dk OK

              virtual_mailbox_maps.cf:
              test@... OK
              info@... OK

              It all works like a charm, besides the point that Postfix accepts
              mail to non-existent users on the hosted domain.

              In addition I have read through the relevant documentation again, but I
              still can't figure out where or what the problem might be.

              Thanks again


              postconf -n
              alias_maps = hash:/etc/aliases

              bounce_template_file = /etc/postfix/bounce.cf

              broken_sasl_auth_clients = yes

              config_directory = /etc/postfix

              delay_warning_time = 4

              disable_vrfy_command = yes

              inet_interfaces = all

              local_recipient_maps = $virtual_mailbox_maps

              maximal_queue_lifetime = 15

              mydestination =

              myhostname = ntdata.nt-data.dk

              mynetworks = 127.0.0.0/8

              recipient_canonical_classes = envelope_recipient

              recipient_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
              tcp:127.0.0.1:10002

              sender_canonical_classes = envelope_sender

              sender_canonical_maps = hash:/etc/postfix/pfix-no-srs.cf,
              tcp:127.0.0.1:10001

              smtp_tls_security_level = may

              smtp_tls_session_cache_database =
              btree:$data_directory/smtp_tls_session_cache

              smtpd_data_restrictions =
              reject_unauth_pipelining,
              reject_multi_recipient_bounce,
              permit

              smtpd_helo_required = yes

              smtpd_recipient_restrictions =
              reject_non_fqdn_sender,
              reject_non_fqdn_recipient,
              reject_unknown_sender_domain,
              reject_unknown_recipient_domain,
              reject_rbl_client truncate.gbudb.net,
              reject_unauth_destination,
              permit

              smtpd_sasl_auth_enable = yes

              smtpd_sasl_exceptions_networks = $mynetworks

              smtpd_sasl_path = private/auth

              smtpd_sasl_security_options = noanonymous

              smtpd_sasl_type = dovecot

              smtpd_tls_ask_ccert = yes

              smtpd_tls_cert_file = /etc/ssl/self-signed/smtpd.crt

              smtpd_tls_key_file = /etc/ssl/self-signed/smtpd.key

              smtpd_tls_loglevel = 1

              smtpd_tls_received_header = yes

              smtpd_tls_security_level = may

              smtpd_tls_session_cache_database =
              btree:$data_directory/smtpd_tls_session_cache

              tls_random_source = dev:/dev/urandom

              transport_maps = hash:/etc/postfix/transport.cf

              virtual_mailbox_domains = hash:/etc/postfix/virtual_mailbox_domains.cf

              virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps.cf

              virtual_transport = dovecot
            • Brian Evans
              ... You say you return false ? Postfix expects to receive no results (a.k.a. 0 rows) if a virtual_mailbox_maps address in mysql does not exist. Do not return
              Message 6 of 28 , Apr 5, 2013
              • 0 Attachment
                On 4/5/2013 6:56 AM, Titanus Eramius wrote:
                > Mon, 25 Mar 2013 14:09:04 -0400 (EDT) skrev Wietse Venema
                > <wietse@...>:
                >
                >> Titanus Eramius:
                >>> MAIL FROM:<>
                >>> 250 2.1.0 Ok
                >>> RCPT TO:<real-user@...>
                >>> 250 2.1.5 Ok
                >>> RCPT TO:<non-existent@...>
                >>> 250 2.1.5 Ok
                >>> If non-existent@... is substituted with non-existent@...,
                >>> then it is still rejected with "... unknown in virtual mailbox
                >>> table".
                >> You appear to have a wild-card rule that replaces @... with
                >> @.... Such a rule matches all addresses including invalid ones.
                >>
                >> Instead use a MySQL query as decribed in
                >> http://tech.groups.yahoo.com/group/postfix-users/message/247913
                >>
                >> Wietse
                > Thank you for the link, it was very informative, but didn't solve the
                > problem. I also tried making a virtual_mailbox_maps MySQL query that
                > always returned false, but Postfix still accepted all mail, and then
                > bounced it after Dovecot rejected it.

                You say you return "false"?
                Postfix expects to receive no results (a.k.a. 0 rows) if a
                virtual_mailbox_maps address in mysql does not exist.
                Do not return "false", empty string, null, or any other value if it does
                not exist.

                Brian
              • Titanus Eramius
                Fri, 05 Apr 2013 08:49:39 -0400 skrev Brian Evans ... False may be the wrong word, and I m sorry if it is. What I mean is, virtual_mailbox_maps always returns
                Message 7 of 28 , Apr 5, 2013
                • 0 Attachment
                  Fri, 05 Apr 2013 08:49:39 -0400 skrev Brian Evans
                  <grknight@...>:

                  > > Thank you for the link, it was very informative, but didn't solve
                  > > the problem. I also tried making a virtual_mailbox_maps MySQL query
                  > > that always returned false, but Postfix still accepted all mail,
                  > > and then bounced it after Dovecot rejected it.
                  >
                  > You say you return "false"?
                  > Postfix expects to receive no results (a.k.a. 0 rows) if a
                  > virtual_mailbox_maps address in mysql does not exist.
                  > Do not return "false", empty string, null, or any other value if it
                  > does not exist.

                  False may be the wrong word, and I'm sorry if it is. What I mean is,
                  virtual_mailbox_maps always returns nothing from MySQL, like so:

                  titanus@ntdata:/etc/postfix$ sudo postmap -q test@...
                  mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
                  titanus@ntdata:/etc/postfix$ echo $?
                  1
                  (this user exists)

                  titanus@ntdata:/etc/postfix$ sudo postmap -q non_existent@...
                  mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
                  titanus@ntdata:/etc/postfix$ echo $?
                  1
                  (this user does not)

                  I did this because I had some trouble constructing the query-string
                  Wietse recommended, and thought this would be a simple and easy way to
                  test if virtual_mailbox_maps was the problem.

                  When trying the syntax within the MySQL CLI, a "Empty set" is returned
                  when querying for a non-existent user

                  mysql> SELECT username FROM mailbox
                  -> WHERE username = 'non_existent@...';
                  Empty set (0.00 sec)


                  I hope this better explains what I meant
                  Cheers
                • Titanus Eramius
                  Solved it :-) When sending to unknown users, Postfix now rejects the mail with User unknown in virtual mailbox table , and it does so for hosted (that is,
                  Message 8 of 28 , Apr 6, 2013
                  • 0 Attachment
                    Solved it :-)

                    When sending to unknown users, Postfix now rejects the mail with "User
                    unknown in virtual mailbox table", and it does so for hosted (that is,
                    virtual mailbox domains) domains as well.

                    It seems the SRS-daemon* I have been using with the main.cf parameters
                    recipient_canonical_maps
                    recipient_canonical_classes
                    sender_canonical_maps
                    sender_canonical_classes

                    was the root of the problem. I have just commented them out to solve
                    it. Reading through the documentation for those four parameters, does
                    not seem to indicate why they would mess with Postfix' ability to use
                    virtual_mailbox_maps.

                    But I guess my lack of understanding about Postfix internals is a
                    problem as well. I am sorry for the wasted time, and would like to
                    thank all who helped out.

                    Have a nice weekend


                    * https://github.com/Fruneau/pfixtools
                  Your message has been successfully submitted and would be delivered to recipients shortly.