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

Re: smtpd optional authentication and relay

Expand Messages
  • btb@...
    ... i d counsel against this. instead, set up a proper submission service [see the commented out example in master.cf], and use separate streams for mx and
    Message 1 of 16 , Jul 4 9:27 PM
    • 0 Attachment
      On Jul 4, 2013, at 20.44, W T Riker <wtriker.ffe@...> wrote:

      > On 7/4/2013 8:36 PM, Wietse Venema wrote:
      >> W T Riker:
      >>> On 7/4/2013 8:01 PM, Wietse Venema wrote:
      >>>> gw1500:
      >>>>> It is not clear from the documentation if this is possible or how to do
      >>>>> it but I want to make authentication optional but if a user does
      >>>>> authenticate then I want to permit relaying. Can someone help?
      >>>> This is how permit_sasl_authenticated works.
      >>>>
      >>>> http://www.postfix.org/SASL_README.html#server_sasl_authz
      >>> Thanks for the reply. I already have that much working. Where I am stuck
      >>> is permitting relaying from authenticated users regardless of host while
      >>> prohibiting everything else.
      >> I answered the question how "to make authentication optional".
      >>
      >> Perhaps someone else can figure out what you mean with "permitting
      >> relaying from authenticated users while prohibiting everything else"
      >> when only seconds ago you asked how "to make authentication optional".
      >>
      >> Wietse
      >>
      > Sorry that I was not clear. With this configuration, will any
      > non-authenticated client still be able to deliver mail to a local
      > recipient but not be permitted to relay email to non-local recipients?

      i'd counsel against this. instead, set up a proper submission service [see the commented out example in master.cf], and use separate streams for mx and submission. presumably you're asking about providing "relay" service for client [e.g. mua] software. clients should use submission [port 587], not port 25. port 25 is for servers to talk to other servers. setting up separate streams/services allows you to require encryption and authentication for all connections [eg. "clients"] to the submission service, and allows you to avoid offering it unnecessarily on port 25.

      -ben
    • W T Riker
      ... Indeed this is using port 587. I did not realize that that in itself was sufficient to prevent relaying from non-authenticated clients. Thanks.
      Message 2 of 16 , Jul 5 5:08 AM
      • 0 Attachment
        On 7/5/2013 12:27 AM, btb@... wrote:
        > On Jul 4, 2013, at 20.44, W T Riker <wtriker.ffe@...> wrote:
        >
        >> On 7/4/2013 8:36 PM, Wietse Venema wrote:
        >>> W T Riker:
        >>>> On 7/4/2013 8:01 PM, Wietse Venema wrote:
        >>>>> gw1500:
        >>>>>> It is not clear from the documentation if this is possible or how to do
        >>>>>> it but I want to make authentication optional but if a user does
        >>>>>> authenticate then I want to permit relaying. Can someone help?
        >>>>> This is how permit_sasl_authenticated works.
        >>>>>
        >>>>> http://www.postfix.org/SASL_README.html#server_sasl_authz
        >>>> Thanks for the reply. I already have that much working. Where I am stuck
        >>>> is permitting relaying from authenticated users regardless of host while
        >>>> prohibiting everything else.
        >>> I answered the question how "to make authentication optional".
        >>>
        >>> Perhaps someone else can figure out what you mean with "permitting
        >>> relaying from authenticated users while prohibiting everything else"
        >>> when only seconds ago you asked how "to make authentication optional".
        >>>
        >>> Wietse
        >>>
        >> Sorry that I was not clear. With this configuration, will any
        >> non-authenticated client still be able to deliver mail to a local
        >> recipient but not be permitted to relay email to non-local recipients?
        > i'd counsel against this. instead, set up a proper submission service [see the commented out example in master.cf], and use separate streams for mx and submission. presumably you're asking about providing "relay" service for client [e.g. mua] software. clients should use submission [port 587], not port 25. port 25 is for servers to talk to other servers. setting up separate streams/services allows you to require encryption and authentication for all connections [eg. "clients"] to the submission service, and allows you to avoid offering it unnecessarily on port 25.
        >
        > -ben
        Indeed this is using port 587. I did not realize that that in itself was
        sufficient to prevent relaying from non-authenticated clients. Thanks.
      • W T Riker
        ... Thanks. By this configuration I was referring to the section of the documentation referred to by Wietse.
        Message 3 of 16 , Jul 5 5:09 AM
        • 0 Attachment
          On 7/4/2013 11:21 PM, Noel Jones wrote:
          > On 7/4/2013 7:44 PM, W T Riker wrote:
          >> On 7/4/2013 8:36 PM, Wietse Venema wrote:
          >>> W T Riker:
          >>>> On 7/4/2013 8:01 PM, Wietse Venema wrote:
          >>>>> gw1500:
          >>>>>> It is not clear from the documentation if this is possible or how to do
          >>>>>> it but I want to make authentication optional but if a user does
          >>>>>> authenticate then I want to permit relaying. Can someone help?
          >>>>> This is how permit_sasl_authenticated works.
          >>>>>
          >>>>> http://www.postfix.org/SASL_README.html#server_sasl_authz
          >>>> Thanks for the reply. I already have that much working. Where I am stuck
          >>>> is permitting relaying from authenticated users regardless of host while
          >>>> prohibiting everything else.
          >>> I answered the question how "to make authentication optional".
          >>>
          >>> Perhaps someone else can figure out what you mean with "permitting
          >>> relaying from authenticated users while prohibiting everything else"
          >>> when only seconds ago you asked how "to make authentication optional".
          >>>
          >>> Wietse
          >>>
          >> Sorry that I was not clear. With this configuration, will any
          >> non-authenticated client still be able to deliver mail to a local
          >> recipient but not be permitted to relay email to non-local recipients?
          >>
          > That's the usual way for it to work, but we don't really know what
          > you mean by "this configuration". For a definite answer, we would
          > need to see your "postconf -n" settings.
          >
          >
          >
          > -- Noel Jones
          Thanks. By "this configuration" I was referring to the section of the
          documentation referred to by Wietse.
        • Larry Stone
          ... It doesn t. If 587 is configured the same as 25, it will behave just like port 25. There is nothing special about port 587 other than how YOU configure it
          Message 4 of 16 , Jul 5 6:51 AM
          • 0 Attachment
            On Fri, 5 Jul 2013, W T Riker wrote:

            > Indeed this is using port 587. I did not realize that that in itself was
            > sufficient to prevent relaying from non-authenticated clients. Thanks.

            It doesn't. If 587 is configured the same as 25, it will behave just like
            port 25. There is nothing special about port 587 other than how YOU
            configure it to be different.

            They key to understanding Postfix restrictions is they evaluate in order
            and the first to return a result other than DUNNO is what wins. A
            permit_xxxx restrictions generally returns PERMIT or DUNNO. A reject_xxxx
            restriction generally returns REJECT or DUNNO. So if you have
            permit_sasl_authernticated as the first test in a group of restrictions
            (e.g. smtpd_recipient_restrictions), if the user is SASL authenticated, it
            returns PERMIT and the mail is accepted and, if not destined locally,
            relayed. All remaining tests in that group of restrictions are then
            skipped. If the user is not SASL authenticated, it returns DUNNO and goes
            on to the next restriction in that group. If that next restriction is
            reject_unauth_destination (which in case it's not clear to you is the
            restriction that prevents relaying), an unauthenticated user will not be
            permitted to relay.

            So in short, a restriction group that permits authenticated users to send
            anywhere and unauthenticated users to only send to domains for which
            Postfix is configure to accept mail would be: permit_sasl_authenticated,
            reject_unauth_destination. However, don't just do what we suggest; make
            sure you understand it and that it is doing what YOU want.

            -- Larry Stone
            lstone19@...
          • W T Riker
            ... Thanks for that explanation. I think I understand the way it works now so I modified my restrictions a bit. Does this order pass the sniff test?
            Message 5 of 16 , Jul 5 7:00 AM
            • 0 Attachment
              On 7/5/2013 9:51 AM, Larry Stone wrote:
              > On Fri, 5 Jul 2013, W T Riker wrote:
              >
              >> Indeed this is using port 587. I did not realize that that in itself was
              >> sufficient to prevent relaying from non-authenticated clients. Thanks.
              >
              > It doesn't. If 587 is configured the same as 25, it will behave just
              > like port 25. There is nothing special about port 587 other than how
              > YOU configure it to be different.
              >
              > They key to understanding Postfix restrictions is they evaluate in
              > order and the first to return a result other than DUNNO is what wins.
              > A permit_xxxx restrictions generally returns PERMIT or DUNNO. A
              > reject_xxxx restriction generally returns REJECT or DUNNO. So if you
              > have permit_sasl_authernticated as the first test in a group of
              > restrictions (e.g. smtpd_recipient_restrictions), if the user is SASL
              > authenticated, it returns PERMIT and the mail is accepted and, if not
              > destined locally, relayed. All remaining tests in that group of
              > restrictions are then skipped. If the user is not SASL authenticated,
              > it returns DUNNO and goes on to the next restriction in that group. If
              > that next restriction is reject_unauth_destination (which in case it's
              > not clear to you is the restriction that prevents relaying), an
              > unauthenticated user will not be permitted to relay.
              >
              > So in short, a restriction group that permits authenticated users to
              > send anywhere and unauthenticated users to only send to domains for
              > which Postfix is configure to accept mail would be:
              > permit_sasl_authenticated, reject_unauth_destination. However, don't
              > just do what we suggest; make sure you understand it and that it is
              > doing what YOU want.
              >
              > -- Larry Stone
              > lstone19@...
              >
              Thanks for that explanation. I think I understand the way it works now
              so I modified my restrictions a bit. Does this order pass the sniff test?

              smtpd_recipient_restrictions =
              reject_non_fqdn_recipient,
              reject_non_fqdn_sender,
              reject_unlisted_recipient,
              permit_mynetworks,
              permit_sasl_authenticated,
              reject_unauth_destination,
              reject_invalid_helo_hostname,
              reject_unknown_sender_domain,
              reject_unknown_recipient_domain
            • Viktor Dukhovni
              ... Fine up to here. ... This is not a good idea in this context, you ve already checked the message is to one of your own domains. Unless you ve specified
              Message 6 of 16 , Jul 5 7:07 AM
              • 0 Attachment
                On Fri, Jul 05, 2013 at 10:00:02AM -0400, W T Riker wrote:

                > Thanks for that explanation. I think I understand the way it works now
                > so I modified my restrictions a bit. Does this order pass the sniff test?
                >
                > smtpd_recipient_restrictions =
                > reject_non_fqdn_recipient,
                > reject_non_fqdn_sender,
                > reject_unlisted_recipient,
                > permit_mynetworks,
                > permit_sasl_authenticated,
                > reject_unauth_destination,
                > reject_invalid_helo_hostname,
                > reject_unknown_sender_domain,

                Fine up to here.

                > reject_unknown_recipient_domain

                This is not a good idea in this context, you've already checked
                the message is to one of your own domains. Unless you've specified
                relay_domains (and you have relay_domains listed in
                parent_domain_mathes_subdomains) or inherit relay_domains via its
                default $mydestination, every domain you accept should be "known",
                you just risk deferring mail due to transient DNS lookup errors.

                You should generally avoid having subdomain matching in relay_domains,
                set parent_domain_matches_subdomains empty or perhaps just:

                parent_domain_matches_subdomains = smtpd_access_maps

                if your access tables rely on this to match a domain and all its
                subdomains.

                The backwards compatible default is:

                parent_domain_matches_subdomains =
                debug_peer_list,
                fast_flush_domains,
                mynetworks,
                permit_mx_backup_networks,
                qmqpd_authorized_clients,
                relay_domains,
                smtpd_access_maps

                --
                Viktor.
              • W T Riker
                Thanks. I fixed it.
                Message 7 of 16 , Jul 5 7:36 AM
                • 0 Attachment
                  Thanks. I fixed it.

                  On 7/5/2013 10:07 AM, Viktor Dukhovni wrote:
                  > On Fri, Jul 05, 2013 at 10:00:02AM -0400, W T Riker wrote:
                  >
                  >> Thanks for that explanation. I think I understand the way it works now
                  >> so I modified my restrictions a bit. Does this order pass the sniff test?
                  >>
                  >> smtpd_recipient_restrictions =
                  >> reject_non_fqdn_recipient,
                  >> reject_non_fqdn_sender,
                  >> reject_unlisted_recipient,
                  >> permit_mynetworks,
                  >> permit_sasl_authenticated,
                  >> reject_unauth_destination,
                  >> reject_invalid_helo_hostname,
                  >> reject_unknown_sender_domain,
                  > Fine up to here.
                  >
                  >> reject_unknown_recipient_domain
                  > This is not a good idea in this context, you've already checked
                  > the message is to one of your own domains. Unless you've specified
                  > relay_domains (and you have relay_domains listed in
                  > parent_domain_mathes_subdomains) or inherit relay_domains via its
                  > default $mydestination, every domain you accept should be "known",
                  > you just risk deferring mail due to transient DNS lookup errors.
                  >
                  > You should generally avoid having subdomain matching in relay_domains,
                  > set parent_domain_matches_subdomains empty or perhaps just:
                  >
                  > parent_domain_matches_subdomains = smtpd_access_maps
                  >
                  > if your access tables rely on this to match a domain and all its
                  > subdomains.
                  >
                  > The backwards compatible default is:
                  >
                  > parent_domain_matches_subdomains =
                  > debug_peer_list,
                  > fast_flush_domains,
                  > mynetworks,
                  > permit_mx_backup_networks,
                  > qmqpd_authorized_clients,
                  > relay_domains,
                  > smtpd_access_maps
                  >
                • Tom Hendrikx
                  ... I d say that reject_unlisted_recipient will also reject mail to offsite recipients, even when it is sent by an authenticated sender (since
                  Message 8 of 16 , Jul 5 7:52 AM
                  • 0 Attachment
                    On 07/05/2013 04:07 PM, Viktor Dukhovni wrote:
                    > On Fri, Jul 05, 2013 at 10:00:02AM -0400, W T Riker wrote:
                    >
                    >> Thanks for that explanation. I think I understand the way it works now
                    >> so I modified my restrictions a bit. Does this order pass the sniff test?
                    >>
                    >> smtpd_recipient_restrictions =
                    >> reject_non_fqdn_recipient,
                    >> reject_non_fqdn_sender,
                    >> reject_unlisted_recipient,

                    I'd say that reject_unlisted_recipient will also reject mail to offsite
                    recipients, even when it is sent by an authenticated sender (since
                    permit_sasl_authenticated is specified later).

                    >> permit_mynetworks,
                    >> permit_sasl_authenticated,
                    >> reject_unauth_destination,
                    >> reject_invalid_helo_hostname,
                    >> reject_unknown_sender_domain,
                    >
                    > Fine up to here.
                    >
                    >> reject_unknown_recipient_domain
                    >
                    > This is not a good idea in this context, you've already checked
                    > the message is to one of your own domains. Unless you've specified
                    > relay_domains (and you have relay_domains listed in
                    > parent_domain_mathes_subdomains) or inherit relay_domains via its
                    > default $mydestination, every domain you accept should be "known",
                    > you just risk deferring mail due to transient DNS lookup errors.
                    >
                    > You should generally avoid having subdomain matching in relay_domains,
                    > set parent_domain_matches_subdomains empty or perhaps just:
                    >
                    > parent_domain_matches_subdomains = smtpd_access_maps
                    >
                    > if your access tables rely on this to match a domain and all its
                    > subdomains.
                    >
                    > The backwards compatible default is:
                    >
                    > parent_domain_matches_subdomains =
                    > debug_peer_list,
                    > fast_flush_domains,
                    > mynetworks,
                    > permit_mx_backup_networks,
                    > qmqpd_authorized_clients,
                    > relay_domains,
                    > smtpd_access_maps
                    >
                  • W T Riker
                    ... Good point. I fixed that too. Thanks.
                    Message 9 of 16 , Jul 5 8:26 AM
                    • 0 Attachment
                      On 7/5/2013 10:52 AM, Tom Hendrikx wrote:
                      > On 07/05/2013 04:07 PM, Viktor Dukhovni wrote:
                      >> On Fri, Jul 05, 2013 at 10:00:02AM -0400, W T Riker wrote:
                      >>
                      >>> Thanks for that explanation. I think I understand the way it works now
                      >>> so I modified my restrictions a bit. Does this order pass the sniff test?
                      >>>
                      >>> smtpd_recipient_restrictions =
                      >>> reject_non_fqdn_recipient,
                      >>> reject_non_fqdn_sender,
                      >>> reject_unlisted_recipient,
                      > I'd say that reject_unlisted_recipient will also reject mail to offsite
                      > recipients, even when it is sent by an authenticated sender (since
                      > permit_sasl_authenticated is specified later).
                      >
                      >>> permit_mynetworks,
                      >>> permit_sasl_authenticated,
                      >>> reject_unauth_destination,
                      >>> reject_invalid_helo_hostname,
                      >>> reject_unknown_sender_domain,
                      >> Fine up to here.
                      >>
                      >>> reject_unknown_recipient_domain
                      >> This is not a good idea in this context, you've already checked
                      >> the message is to one of your own domains. Unless you've specified
                      >> relay_domains (and you have relay_domains listed in
                      >> parent_domain_mathes_subdomains) or inherit relay_domains via its
                      >> default $mydestination, every domain you accept should be "known",
                      >> you just risk deferring mail due to transient DNS lookup errors.
                      >>
                      >> You should generally avoid having subdomain matching in relay_domains,
                      >> set parent_domain_matches_subdomains empty or perhaps just:
                      >>
                      >> parent_domain_matches_subdomains = smtpd_access_maps
                      >>
                      >> if your access tables rely on this to match a domain and all its
                      >> subdomains.
                      >>
                      >> The backwards compatible default is:
                      >>
                      >> parent_domain_matches_subdomains =
                      >> debug_peer_list,
                      >> fast_flush_domains,
                      >> mynetworks,
                      >> permit_mx_backup_networks,
                      >> qmqpd_authorized_clients,
                      >> relay_domains,
                      >> smtpd_access_maps
                      >>
                      >
                      Good point. I fixed that too. Thanks.
                    • Noel Jones
                      ... Hash: SHA1 ... Nonsense. reject_unlisted_recipient does not reject mail offsite. http://www.postfix.org/postconf.5.html#reject_unlisted_recipient -- Noel
                      Message 10 of 16 , Jul 5 8:42 AM
                      • 0 Attachment
                        -----BEGIN PGP SIGNED MESSAGE-----
                        Hash: SHA1

                        On 7/5/2013 9:52 AM, Tom Hendrikx wrote:
                        > On 07/05/2013 04:07 PM, Viktor Dukhovni wrote:
                        >> On Fri, Jul 05, 2013 at 10:00:02AM -0400, W T Riker wrote:
                        >>
                        >>> Thanks for that explanation. I think I understand the way
                        >>> it works now so I modified my restrictions a bit. Does this
                        >>> order pass the sniff test?
                        >>>
                        >>> smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                        >>> reject_non_fqdn_sender, reject_unlisted_recipient,
                        >
                        > I'd say that reject_unlisted_recipient will also reject mail to
                        > offsite recipients, even when it is sent by an authenticated
                        > sender (since permit_sasl_authenticated is specified later).

                        Nonsense. reject_unlisted_recipient does not reject mail offsite.
                        http://www.postfix.org/postconf.5.html#reject_unlisted_recipient



                        -- Noel Jones
                        -----BEGIN PGP SIGNATURE-----
                        Version: GnuPG v2.0.20 (MingW32)
                        Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

                        iQEcBAEBAgAGBQJR1ul5AAoJEJGRUHb5Oh6gufoH/R1F4FLduLJ0Y/+eDBy4IP4V
                        VVGukAGWAQVVQBta6mZbKLLwTEPJUsfC7O11781nbfSXNe0I4q4T5UOmdO7Bh3F6
                        dN4JVhEFXSvEWPwHVnnDV7gz5OuVAgaesnHvVCEY940vb4nTeRcvOEbRyt3530Fa
                        45jLwNYzXXFB4tzZEfTMCF4EBl7zpdEliWNZpxHR7+1EZjrkpVWXkUNXw6rDApv6
                        4Qr7FMhpz4SvFkOfyDIJ1ZPhysaMcTmMwY1Byjxd0o6kmpNM8ahraQ/jb4i9RgNs
                        nSNJEWlBnXbg2Za//lnGH57CtowRFk4crqFJrnPQQe90av3r8IJfYXNQlCavnYI=
                        =kC/H
                        -----END PGP SIGNATURE-----
                      Your message has been successfully submitted and would be delivered to recipients shortly.