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

Re: Specifying 'check_sender_access' during 'smtpd_recipient_restrictions' filters recipient as well?

Expand Messages
  • Ralf Hildebrandt
    ... Where s the main.cf snippet? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin
    Message 1 of 8 , Oct 1, 2009
    • 0 Attachment
      * URCentral Support (GMail) <urcentral@...>:
      > Hello list,
      >
      > This might be working as intended, but since it seemed a tad odd and I
      > couldn't find any conclusive documentation that explained it, I
      > figured I'd work up the courage and ask. I moved 'check_sender_access'
      > from the 'smtpd_sender_restrictions' to the
      > 'smtpd_recipient_restrictions' stage, and ran a test;
      >
      > Out: 220 nenya.dtnx.net ESMTP
      > In: EHLO arturia.xs4all.nl
      > Out: 250-nenya.dtnx.net
      > Out: 250-PIPELINING
      > Out: 250-SIZE 35651584
      > Out: 250-ETRN
      > Out: 250-ENHANCEDSTATUSCODES
      > Out: 250-8BITMIME
      > Out: 250 DSN
      > In: MAIL FROM:<urcentral@...>
      > Out: 250 2.1.0 Ok
      > In: RCPT TO:<postmaster@...>
      > Out: 550 5.7.1 <postmaster@...>: Recipient address rejected: You
      > are not a known MX for 'configcast.com'.
      > In: QUIT
      > Out: 221 2.0.0 Bye
      >
      > The rejection is from the hash database specified for
      > 'check_sender_access', which has a line for every domain this server
      > is responsible for, since all mail from those domains originates from
      > our own servers;
      >
      > configcast.com REJECT You are not a known MX for
      > 'configcast.com'.
      >
      > Since there is a seperate 'check_recipient_access' as well, I was
      > expecting 'check_sender_access' to work for 'MAIL FROM' only, but the
      > above example suggests it is consulted during the recipient stage as
      > well, if specified there.
      >
      > Is this by design, working as intended? Or am I missing something somewhere?

      Where's the main.cf snippet?

      --
      Ralf Hildebrandt
      Geschäftsbereich IT | Abteilung Netzwerk
      Charité - Universitätsmedizin Berlin
      Campus Benjamin Franklin
      Hindenburgdamm 30 | D-12203 Berlin
      Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
      ralf.hildebrandt@... | http://www.charite.de
    • URCentral @ Gmail
      On Thu, Oct 1, 2009 at 12:56 PM, Ralf Hildebrandt ... Guess I did miss something somewhere. This is how it looks like now; smtpd_sender_restrictions =
      Message 2 of 8 , Oct 1, 2009
      • 0 Attachment
        On Thu, Oct 1, 2009 at 12:56 PM, Ralf Hildebrandt
        <Ralf.Hildebrandt@...> wrote:

        >> Is this by design, working as intended? Or am I missing something somewhere?
        >
        > Where's the main.cf snippet?

        Guess I did miss something somewhere. This is how it looks like now;

        smtpd_sender_restrictions =
        permit_mynetworks
        reject_unknown_sender_domain
        reject_non_fqdn_sender
        check_sender_access
        hash:/etc/postfix/chk_sender_access

        smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unknown_reverse_client_hostname
        reject_non_fqdn_helo_hostname
        reject_unknown_helo_hostname
        reject_unauth_destination
        reject_non_fqdn_recipient
        reject_unknown_recipient_domain
        check_recipient_access
        hash:/etc/postfix/chk_recipient_access
        reject_unverified_recipient


        Which works; if 'postmaster@...' is used as a sender, it
        rejects the rest of the SMTP session, but if used as a recipient, it's
        fine, as expected. If I move 'check_sender_access' to the next stage
        however, like this;

        smtpd_sender_restrictions =
        permit_mynetworks
        reject_unknown_sender_domain
        reject_non_fqdn_sender
        check_sender_access
        hash:/etc/postfix/chk_sender_access

        smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unknown_reverse_client_hostname
        reject_non_fqdn_helo_hostname
        reject_unknown_helo_hostname
        reject_unauth_destination
        check_sender_access
        hash:/etc/postfix/chk_sender_access
        reject_non_fqdn_recipient
        reject_unknown_recipient_domain
        check_recipient_access
        hash:/etc/postfix/chk_recipient_access
        reject_unverified_recipient

        then it will reject the recipient with the action specified in the
        'check_sender_access' hash database;

        configcast.com REJECT You are not a known MX for
        'configcast.com'.

        Is that how it's supposed to work?

        Cya,
        Jona
      • URCentral @ Gmail
        ... Correcting myself; there are two hash databases specified on the live server, like this; check_sender_access hash:/etc/postfix/chk_sender_local
        Message 3 of 8 , Oct 1, 2009
        • 0 Attachment
          On Thu, Oct 1, 2009 at 6:46 PM, URCentral @ Gmail <urcentral@...> wrote:

          >>> Is this by design, working as intended? Or am I missing something somewhere?
          >>
          >> Where's the main.cf snippet?
          >
          > Guess I did miss something somewhere. This is how it looks like now;
          >
          > smtpd_sender_restrictions =
          >        permit_mynetworks
          >        reject_unknown_sender_domain
          >        reject_non_fqdn_sender
          >        check_sender_access
          >                hash:/etc/postfix/chk_sender_access
          >
          > smtpd_recipient_restrictions =
          >        permit_mynetworks
          >        reject_unknown_reverse_client_hostname
          >        reject_non_fqdn_helo_hostname
          >        reject_unknown_helo_hostname
          >        reject_unauth_destination
          >        reject_non_fqdn_recipient
          >        reject_unknown_recipient_domain
          >        check_recipient_access
          >                hash:/etc/postfix/chk_recipient_access
          >        reject_unverified_recipient
          >
          >
          > Which works; if 'postmaster@...' is used as a sender, it
          > rejects the rest of the SMTP session, but if used as a recipient, it's
          > fine, as expected. If I move 'check_sender_access' to the next stage
          > however, like this;
          >
          > smtpd_sender_restrictions =
          >        permit_mynetworks
          >        reject_unknown_sender_domain
          >        reject_non_fqdn_sender
          >        check_sender_access
          >                hash:/etc/postfix/chk_sender_access
          >
          > smtpd_recipient_restrictions =
          >        permit_mynetworks
          >        reject_unknown_reverse_client_hostname
          >        reject_non_fqdn_helo_hostname
          >        reject_unknown_helo_hostname
          >        reject_unauth_destination
          >        check_sender_access
          >                hash:/etc/postfix/chk_sender_access
          >        reject_non_fqdn_recipient
          >        reject_unknown_recipient_domain
          >        check_recipient_access
          >                hash:/etc/postfix/chk_recipient_access
          >        reject_unverified_recipient
          >
          > then it will reject the recipient with the action specified in the
          > 'check_sender_access' hash database;
          >
          > configcast.com                  REJECT You are not a known MX for
          > 'configcast.com'.

          Correcting myself; there are two hash databases specified on the live
          server, like this;

          check_sender_access
          hash:/etc/postfix/chk_sender_local
          hash:/etc/postfix/chk_sender_access

          The 'chk_sender_local' is currently empty. If I remove the first one
          so it actually matches the example given above, with just one hash
          database, the problem disappears and it works as expected.

          From the various examples I've seen I assumed that several type:table
          pairs per restriction are possible, and I can override the
          restrictions set in the second database by giving an 'OK' for
          'postmaster@...' in the first, but I guess that assumption
          is incorrect?

          Cya,
          Jona
        • Brian Evans - Postfix List
          ... If this was specified in recipient restrictions, it is equivalent to: check_sender_access hash:/etc/postfix/chk_sender_local check_recipient_access
          Message 4 of 8 , Oct 1, 2009
          • 0 Attachment
            URCentral @ Gmail wrote:
            > On Thu, Oct 1, 2009 at 6:46 PM, URCentral @ Gmail <urcentral@...> wrote:
            >
            >> Which works; if 'postmaster@...' is used as a sender, it
            >> rejects the rest of the SMTP session, but if used as a recipient, it's
            >> fine, as expected. If I move 'check_sender_access' to the next stage
            >> however, like this;
            >>
            >> smtpd_sender_restrictions =
            >> permit_mynetworks
            >> reject_unknown_sender_domain
            >> reject_non_fqdn_sender
            >> check_sender_access
            >> hash:/etc/postfix/chk_sender_access
            >>
            >> smtpd_recipient_restrictions =
            >> permit_mynetworks
            >> reject_unknown_reverse_client_hostname
            >> reject_non_fqdn_helo_hostname
            >> reject_unknown_helo_hostname
            >> reject_unauth_destination
            >> check_sender_access
            >> hash:/etc/postfix/chk_sender_access
            >> reject_non_fqdn_recipient
            >> reject_unknown_recipient_domain
            >> check_recipient_access
            >> hash:/etc/postfix/chk_recipient_access
            >> reject_unverified_recipient
            >>
            >> then it will reject the recipient with the action specified in the
            >> 'check_sender_access' hash database;
            >>
            >> configcast.com REJECT You are not a known MX for
            >> 'configcast.com'.
            >>
            >
            > Correcting myself; there are two hash databases specified on the live
            > server, like this;
            >
            > check_sender_access
            > hash:/etc/postfix/chk_sender_local
            > hash:/etc/postfix/chk_sender_access
            >
            >

            If this was specified in recipient restrictions, it is equivalent to:
            check_sender_access hash:/etc/postfix/chk_sender_local
            check_recipient_access hash:/etc/postfix/chk_sender_access

            This refers to the depreciated syntax of bare map in a restriction class.

            Postfix does not allow check_(*)_access to list multiple tables.
            The restriction *must* be repeated each time or an assumption takes
            place based on the past.

            > The 'chk_sender_local' is currently empty. If I remove the first one
            > so it actually matches the example given above, with just one hash
            > database, the problem disappears and it works as expected.
            >
            > From the various examples I've seen I assumed that several type:table
            > pairs per restriction are possible, and I can override the
            > restrictions set in the second database by giving an 'OK' for
            > 'postmaster@...' in the first, but I guess that assumption
            > is incorrect?
            >
            > Cya,
            > Jona
            >
          • URCentral @ Gmail
            On Thu, Oct 1, 2009 at 7:26 PM, Brian Evans - Postfix List ... Ahh, that makes sense. So given the above example; check_sender_access
            Message 5 of 8 , Oct 1, 2009
            • 0 Attachment
              On Thu, Oct 1, 2009 at 7:26 PM, Brian Evans - Postfix List
              <grknight@...> wrote:

              >> Correcting myself; there are two hash databases specified on the live
              >> server, like this;
              >>
              >>         check_sender_access
              >>                 hash:/etc/postfix/chk_sender_local
              >>                 hash:/etc/postfix/chk_sender_access
              >>
              >>
              >
              > If this was specified in recipient restrictions, it is equivalent to:
              > check_sender_access hash:/etc/postfix/chk_sender_local
              > check_recipient_access hash:/etc/postfix/chk_sender_access
              >
              > This refers to the depreciated syntax of bare map in a restriction class.
              >
              > Postfix does not allow check_(*)_access to list multiple tables.
              > The restriction *must* be repeated each time or an assumption takes
              > place based on the past.

              Ahh, that makes sense. So given the above example;

              check_sender_access hash:/etc/postfix/chk_sender_local
              check_sender_access hash:/etc/postfix/chk_sender_access

              would work?

              Cya,
              Jona
            • Brian Evans - Postfix List
              ... Indeed.
              Message 6 of 8 , Oct 1, 2009
              • 0 Attachment
                URCentral @ Gmail wrote:
                > On Thu, Oct 1, 2009 at 7:26 PM, Brian Evans - Postfix List
                > <grknight@...> wrote:
                >
                >
                >>> Correcting myself; there are two hash databases specified on the live
                >>> server, like this;
                >>>
                >>> check_sender_access
                >>> hash:/etc/postfix/chk_sender_local
                >>> hash:/etc/postfix/chk_sender_access
                >>>
                >> If this was specified in recipient restrictions, it is equivalent to:
                >> check_sender_access hash:/etc/postfix/chk_sender_local
                >> check_recipient_access hash:/etc/postfix/chk_sender_access
                >>
                >> This refers to the depreciated syntax of bare map in a restriction class.
                >>
                >> Postfix does not allow check_(*)_access to list multiple tables.
                >> The restriction *must* be repeated each time or an assumption takes
                >> place based on the past.
                >>
                >
                > Ahh, that makes sense. So given the above example;
                >
                > check_sender_access hash:/etc/postfix/chk_sender_local
                > check_sender_access hash:/etc/postfix/chk_sender_access
                >
                > would work?
                >

                Indeed.
              • /dev/rob0
                ... But as I posted in another thread on the same issue, dual lookups of the same type and maptype at the same point in restrictions does NOT make sense.
                Message 7 of 8 , Oct 1, 2009
                • 0 Attachment
                  On Thursday 01 October 2009 12:35:02 URCentral @ Gmail wrote:
                  > Ahh, that makes sense. So given the above example;
                  >
                  > check_sender_access hash:/etc/postfix/chk_sender_local
                  > check_sender_access hash:/etc/postfix/chk_sender_access
                  >
                  > would work?

                  But as I posted in another thread on the same issue, dual lookups of
                  the same type and maptype at the same point in restrictions does NOT
                  make sense. Consolidate these?
                  --
                  Offlist mail to this address is discarded unless
                  "/dev/rob0" or "not-spam" is in Subject: header
                Your message has been successfully submitted and would be delivered to recipients shortly.