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

Re: smtpd optional authentication and relay

Expand Messages
  • W T Riker
    ... Thanks. By this configuration I was referring to the section of the documentation referred to by Wietse.
    Message 1 of 16 , Jul 5, 2013
    • 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 2 of 16 , Jul 5, 2013
      • 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 3 of 16 , Jul 5, 2013
        • 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 4 of 16 , Jul 5, 2013
          • 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 5 of 16 , Jul 5, 2013
            • 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 6 of 16 , Jul 5, 2013
              • 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 7 of 16 , Jul 5, 2013
                • 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 8 of 16 , Jul 5, 2013
                  • 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.