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

Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch

Expand Messages
  • Simon Brereton
    ... Gah. There s like 5 people on this list I force myself to obey and you re one of them... But I thought the recommended best practice was to have it all
    Message 1 of 14 , Nov 2, 2011
    • 0 Attachment
      On 1 November 2011 18:53, Noel Jones <njones@...> wrote:
      > On 11/1/2011 1:31 PM, Simon Brereton wrote:
      >> On 31 October 2011 15:16, Noel Jones <njones@...> wrote:
      >>> On 10/31/2011 12:31 PM, Simon Brereton wrote:
      >>>> Googling led me to this thread:
      >>>> http://comments.gmane.org/gmane.mail.postfix.user/210413
      >>>>
      >>>> But I don't understand how myuser@... is not owned by myuser@...
      >>>
      >>> Apparently this user didn't authenticate.
      >>> You define who owns what address in smtpd_sender_login_maps.  There
      >>> are no "automatic" mappings.
      >>
      >> Okay, so without smtpd_sender_login_maps those restrictions are worthless, yes?
      >
      > Right.  You must define the user <-> sender address mapping.

      >> ## SPAM STUFF and REJECT CODES ##
      >> smtpd_recipient_restrictions =
      >>         reject_non_fqdn_sender,
      >>         reject_non_fqdn_recipient,
      >>         permit_sasl_authenticated,
      >>         check_helo_access hash:/etc/postfix/helo_checks,
      >>     permit_mynetworks,
      >>         reject_unauth_destination,
      >>         reject_unlisted_recipient,
      >>         check_recipient_access hash:/etc/postfix/laxdomains,  (this is
      >> one domain I host that doesn't want the checking done below)
      >>         check_client_access hash:/etc/postfix/ip_whitelist,
      >>         reject_invalid_helo_hostname,
      >>         reject_non_fqdn_helo_hostname,
      >>         reject_unknown_helo_hostname,
      >>         reject_unknown_sender_domain,
      >>         reject_unknown_recipient_domain,
      >>
      >> Jim Seymour has these two ABOVE permit_mynetworks - which I can see
      >> for the sender_domain, but if the recipient_domain was above
      >> permit_mynetworks, then wouldn't postfix reject everything that wasn't
      >> in $mydestination?  So, should it be above or below?  And surely if it
      >> should be above, then so should the helo_hostname checks, no?
      >
      > The checks "above" permit_mynetworks and permit_sasl_authenticated
      > are checks you want applied to your networks and authenticated
      > users.  Generally it's better to put those checks in
      > smtpd_sender_restrictions.

      Gah. There's like 5 people on this list I force myself to obey and
      you're one of them... But I thought the recommended best practice was
      to have it all in smtpd_recipient_restrictions.. :(

      So if I take them out of there, and add in:

      smtpd_sender_restrictions = reject_unknown_sender_domain,
      reject_unknown_recipient_domain, permit

      it won't break anything? Won't make me an open relay and won't make a
      backscatterer?

      Simon
    • James Seymour
      On Tue, 1 Nov 2011 14:31:14 -0400 Simon Brereton wrote: [snip] ... [snip] ... [snip] I don t know to which two you refer, but I
      Message 2 of 14 , Nov 2, 2011
      • 0 Attachment
        On Tue, 1 Nov 2011 14:31:14 -0400
        Simon Brereton <simon.brereton@...> wrote:

        [snip]
        >
        > ## SPAM STUFF and REJECT CODES ##
        > smtpd_recipient_restrictions =
        > reject_non_fqdn_sender,
        > reject_non_fqdn_recipient,
        > permit_sasl_authenticated,
        > check_helo_access hash:/etc/postfix/helo_checks,
        > permit_mynetworks,
        [snip]
        >
        > Jim Seymour has these two ABOVE permit_mynetworks -
        [snip]

        I don't know to which two you refer, but I have what I have above
        permit_mynetworks because I want them to apply to even my own local
        users.

        Regards,
        Jim
        --
        Note: My mail server employs *very* aggressive anti-spam
        filtering. If you reply to this email and your email is
        rejected, please accept my apologies and let me know via my
        web form at <http://jimsun.LinxNet.com/contact/scform.php>.
      • Simon Brereton
        ... Yes, that was my understanding when I followed your original instructions. But Rob and Noel were telling me that I had too much stuff before
        Message 3 of 14 , Nov 2, 2011
        • 0 Attachment
          On 2 November 2011 15:53, James Seymour <jseymour@...> wrote:
          > On Tue, 1 Nov 2011 14:31:14 -0400
          > Simon Brereton <simon.brereton@...> wrote:
          >
          > [snip]
          >>
          >> ## SPAM STUFF and REJECT CODES ##
          >> smtpd_recipient_restrictions =
          >>         reject_non_fqdn_sender,
          >>         reject_non_fqdn_recipient,
          >>         permit_sasl_authenticated,
          >>         check_helo_access hash:/etc/postfix/helo_checks,
          >>     permit_mynetworks,
          > [snip]
          >>
          >> Jim Seymour has these two ABOVE permit_mynetworks -
          > [snip]
          >
          > I don't know to which two you refer, but I have what I have above
          > permit_mynetworks because I want them to apply to even my own local
          > users.

          Yes, that was my understanding when I followed your original
          instructions. But Rob and Noel were telling me that I had too much
          stuff before reject_unauth_destination..

          I was referring to these two:

          reject_unknown_sender_domain,
          reject_unknown_recipient_domain,

          I guess this is a little off-topic now, but I can see why
          reject_unknown_sender_domain before permit_mynetworks would be
          sensible - it's stops my users trying to mail with a
          randomgibberish.tld but if I put reject_unknown_recipient_domain there
          postconf.5 says it will

          Reject the request when Postfix is not final destination for the
          recipient domain, and the RCPT TO domain has no DNS A or MX record, or
          when it has a malformed MX record such as a record with a zero-length
          MX hostname (Postfix version 2.3 and later).

          Unless that's meant to say it will Reject the request when Postfix is
          not final destination for the recipient domain, OR the RCPT TO domain
          has no DNS A or MX record, or when it has a malformed MX

          Simon
        • James Seymour
          On Wed, 2 Nov 2011 16:12:07 -0400 Simon Brereton wrote: [snip] ... No, it means just what it says it means. If the local
          Message 4 of 14 , Nov 2, 2011
          • 0 Attachment
            On Wed, 2 Nov 2011 16:12:07 -0400
            Simon Brereton <simon.brereton@...> wrote:

            [snip]
            > ... but if I put reject_unknown_recipient_domain there
            > postconf.5 says it will
            >
            > Reject the request when Postfix is not final destination for the
            > recipient domain, and the RCPT TO domain has no DNS A or MX record, or
            > when it has a malformed MX record such as a record with a zero-length
            > MX hostname (Postfix version 2.3 and later).
            >
            > Unless that's meant to say it will Reject the request when Postfix is
            > not final destination for the recipient domain, OR the RCPT TO domain
            > has no DNS A or MX record, or when it has a malformed MX

            No, it means just what it says it means. If the local Postfix instance
            is the final destination it will accept it. Or if a destination for
            the RCPT domain can be determined it will accept it. If the local
            Postfix instance is not the final destination or it cannot determine
            what is, it will be rejected.

            Regards,
            Jim
            --
            Note: My mail server employs *very* aggressive anti-spam
            filtering. If you reply to this email and your email is
            rejected, please accept my apologies and let me know via my
            web form at <http://jimsun.LinxNet.com/contact/scform.php>.
          • Simon Brereton
            ... Well, I think my postulation was closer to your explanation, but either way it s clear now. I ll restore them above mynetworks. Thank-you. Simon
            Message 5 of 14 , Nov 2, 2011
            • 0 Attachment
              On 2 November 2011 16:26, James Seymour <jseymour@...> wrote:
              > On Wed, 2 Nov 2011 16:12:07 -0400
              > Simon Brereton <simon.brereton@...> wrote:
              >
              > [snip]
              >> ... but if I put reject_unknown_recipient_domain there
              >> postconf.5 says it will
              >>
              >> Reject the request when Postfix is not final destination for the
              >> recipient domain, and the RCPT TO domain has no DNS A or MX record, or
              >> when it has a malformed MX record such as a record with a zero-length
              >> MX hostname (Postfix version 2.3 and later).
              >>
              >> Unless that's meant to say it will Reject the request when Postfix is
              >> not final destination for the recipient domain,  OR the RCPT TO domain
              >> has no DNS A or MX record, or when it has a malformed MX
              >
              > No, it means just what it says it means.  If the local Postfix instance
              > is the final destination it will accept it.  Or if a destination for
              > the RCPT domain can be determined it will accept it.  If the local
              > Postfix instance is not the final destination or it cannot determine
              > what is, it will be rejected.

              Well, I think my postulation was closer to your explanation, but
              either way it's clear now. I'll restore them above mynetworks.

              Thank-you.

              Simon
            • Wietse Venema
              ... The manpage text says, and really means to say, (A AND (B OR C)). This is equivalent to ((A AND B) OR (A AND C)). Your postulation is (A OR B OR C) which
              Message 6 of 14 , Nov 2, 2011
              • 0 Attachment
                Simon Brereton:
                > On 2 November 2011 16:26, James Seymour <jseymour@...> wrote:
                > > On Wed, 2 Nov 2011 16:12:07 -0400
                > > Simon Brereton <simon.brereton@...> wrote:
                > >
                > > [snip]
                > >> ... but if I put reject_unknown_recipient_domain there
                > >> postconf.5 says it will
                > >>
                > >> Reject the request when Postfix is not final destination for the
                > >> recipient domain, and the RCPT TO domain has no DNS A or MX record, or
                > >> when it has a malformed MX record such as a record with a zero-length
                > >> MX hostname (Postfix version 2.3 and later).
                > >>
                > >> Unless that's meant to say it will Reject the request when Postfix is
                > >> not final destination for the recipient domain, ?OR the RCPT TO domain
                > >> has no DNS A or MX record, or when it has a malformed MX
                > >
                > > No, it means just what it says it means. ?If the local Postfix instance
                > > is the final destination it will accept it. ?Or if a destination for
                > > the RCPT domain can be determined it will accept it. ?If the local
                > > Postfix instance is not the final destination or it cannot determine
                > > what is, it will be rejected.
                >
                > Well, I think my postulation was closer to your explanation, but
                > either way it's clear now. I'll restore them above mynetworks.

                The manpage text says, and really means to say, (A AND (B OR C)).
                This is equivalent to ((A AND B) OR (A AND C)).

                Your postulation is (A OR B OR C) which equals (A OR (B OR C)).
                Note the difference with what the manpage says.

                Wietse
              • Noel Jones
                ... That s a guideline, not a best practices -- big difference. If you want to apply some restriction to ALL connections -- both your own senders and outside
                Message 7 of 14 , Nov 2, 2011
                • 0 Attachment
                  On 11/2/2011 2:33 PM, Simon Brereton wrote:

                  >> The checks "above" permit_mynetworks and permit_sasl_authenticated
                  >> are checks you want applied to your networks and authenticated
                  >> users. Generally it's better to put those checks in
                  >> smtpd_sender_restrictions.
                  >
                  > But I thought the recommended best practice was
                  > to have it all in smtpd_recipient_restrictions.. :(

                  That's a guideline, not a best practices -- big difference.
                  If you want to apply some restriction to ALL connections -- both
                  your own senders and outside mail -- it makes sense to put it in a
                  different section.

                  And mostly applies to access tables (check_*_access) since those
                  must be handled carefully.

                  >
                  > So if I take them out of there, and add in:
                  >
                  > smtpd_sender_restrictions = reject_unknown_sender_domain,
                  > reject_unknown_recipient_domain, permit
                  >
                  > it won't break anything? Won't make me an open relay and won't make a
                  > backscatterer?

                  again, the final "permit" is unnecessary.

                  Should be fine, and it certainly won't make you an open relay.



                  -- Noel Jones
                • Simon Brereton
                  ... Finally, I get it (thanks Wietse and Jim).. I was confusing the binary (in most cases) action of check_*_access with the REJECT access of reject_* So,
                  Message 8 of 14 , Nov 3, 2011
                  • 0 Attachment
                    On 2 November 2011 18:23, Noel Jones <njones@...> wrote:
                    > On 11/2/2011 2:33 PM, Simon Brereton wrote:
                    >
                    >>> The checks "above" permit_mynetworks and permit_sasl_authenticated
                    >>> are checks you want applied to your networks and authenticated
                    >>> users.  Generally it's better to put those checks in
                    >>> smtpd_sender_restrictions.
                    >>
                    >> But I thought the recommended best practice was
                    >> to have it all in smtpd_recipient_restrictions..  :(
                    >
                    > That's a guideline, not a best practices -- big difference.
                    > If you want to apply some restriction to ALL connections -- both
                    > your own senders and outside mail -- it makes sense to put it in a
                    > different section.
                    >
                    > And mostly applies to access tables (check_*_access) since those
                    > must be handled carefully.

                    Finally, I get it (thanks Wietse and Jim).. I was confusing the
                    binary (in most cases) action of check_*_access with the REJECT access
                    of reject_*

                    So, these should be fine anywhere be fine anywhere before
                    reject_unauth_destination...

                    reject_invalid_helo_hostname,
                    reject_non_fqdn_helo_hostname,
                    reject_unknown_helo_hostname,
                    reject_unknown_sender_domain,
                    reject_unknown_recipient_domain,

                    If I put them above mynetworks it applies to my networks too, but
                    doesn't make me an open relay. And I put them above permit_sasl_auth
                    then it applies to all connections (but the HELO ones would likely
                    knock out any road-warriers (but they should be using the submission
                    port anyway, right)?

                    Thanks again for your patience and guidance.

                    Simon
                  • Noel Jones
                    ... Yes to all the above, but note it s generally considered bad form to reject your own users (either mynetworks or authenticated) for any but the most
                    Message 9 of 14 , Nov 3, 2011
                    • 0 Attachment
                      On 11/3/2011 9:28 AM, Simon Brereton wrote:

                      > So, these should be fine anywhere be fine anywhere before
                      > reject_unauth_destination...
                      >
                      > reject_invalid_helo_hostname,
                      > reject_non_fqdn_helo_hostname,
                      > reject_unknown_helo_hostname,
                      > reject_unknown_sender_domain,
                      > reject_unknown_recipient_domain,
                      >
                      > If I put them above mynetworks it applies to my networks too, but
                      > doesn't make me an open relay. And I put them above permit_sasl_auth
                      > then it applies to all connections

                      Yes to all the above, but note it's generally considered bad form to
                      reject your own users (either mynetworks or authenticated) for any
                      but the most egregious errors. Of course, you get to define what's
                      egregious for you. Many mail clients present the user a "confusing"
                      error when mail is rejected, triggering a support call, and it's
                      unfriendly to make your own users jump through the same
                      RFC-compliance hoops as a random possibly-hostile MTA.


                      > (but the HELO ones would likely
                      > knock out any road-warriers (but they should be using the submission
                      > port anyway, right)?

                      It doesn't make much sense for your system to present your users
                      different behavior based on the port they connect to.

                      I think putting additional restrictions on port 25 user submission
                      just makes it harder for the end user without any benefit.


                      -- Noel Jones
                    Your message has been successfully submitted and would be delivered to recipients shortly.