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

Re: warning:xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms

Expand Messages
  • Wietse Venema
    ... Well there is at least one section that covers not found or missing authentication mechanisms. The problem is a mis-match between
    Message 1 of 13 , Dec 5, 2012
    • 0 Attachment
      jugree@...:
      > > Consider reading Postfix documentation.
      > > The error message is described there.
      >
      > I haven't found it. Could you paste it?

      Well there is at least one section that covers "not found" or
      "missing" authentication mechanisms.

      The problem is a mis-match between smtpd_sasl_security_options
      (e.g., noplaintext) and the available server mechanisms (e.g.,
      plaintext only).

      Wietse
    • jugree@lavabit.com
      ... I ve configured UNIX-domain socket communication, enabled SASL authentication and authorization(0), but I m still getting `fatal: no SASL authentication
      Message 2 of 13 , Dec 5, 2012
      • 0 Attachment
        > The problem is a mis-match between smtpd_sasl_security_options
        > (e.g., noplaintext) and the available server mechanisms (e.g.,
        > plaintext only).

        I've configured UNIX-domain socket communication, enabled SASL
        authentication and authorization(0), but I'm still getting `fatal: no
        SASL authentication mechanisms'.

        Is it connected with my configuration? Is it connected with the
        version of Postfix?

        dovecot.conf:
        mechanisms = plain

        main.cf:
        smtpd_sasl_security_options = noanonymous, noplaintext

        AFAICT, it can't be connected with `noplaintext' because it `allows
        plaintext mechanisms, but only over a TLS-encrypted connection'(1).

        # postconf -a
        cyrus
        dovecot

        (0) http://www.postfix.org/SASL_README.html#server_dovecot_comm
        (1) http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options
      • Noel Jones
        ... If you re using dovecot now, make sure you set in main.cf smtpd_sasl_type = dovecot Make sure postconf -n output contains the settings you expect! ...
        Message 3 of 13 , Dec 5, 2012
        • 0 Attachment
          On 12/5/2012 7:23 PM, jugree@... wrote:
          >> The problem is a mis-match between smtpd_sasl_security_options
          >> (e.g., noplaintext) and the available server mechanisms (e.g.,
          >> plaintext only).
          >
          > I've configured UNIX-domain socket communication, enabled SASL
          > authentication and authorization(0), but I'm still getting `fatal: no
          > SASL authentication mechanisms'.
          >
          > Is it connected with my configuration? Is it connected with the
          > version of Postfix?
          >
          > dovecot.conf:
          > mechanisms = plain

          If you're using dovecot now, make sure you set in main.cf
          smtpd_sasl_type = dovecot

          Make sure "postconf -n" output contains the settings you expect!


          >
          > main.cf:
          > smtpd_sasl_security_options = noanonymous, noplaintext

          Well there's the problem. Postfix says noplaintext but dovecot only
          has PLAIN.

          >
          > AFAICT, it can't be connected with `noplaintext' because it `allows
          > plaintext mechanisms, but only over a TLS-encrypted connection'(1).

          For the above statement to be true, you need both
          smtpd_sasl_security_options = noanonymous, noplaintext
          smtpd_sasl_tls_security_options = noanonymous

          and for the above to /work/ dovecot needs to offer a non-plaintext
          mechanism, such as CRAM-MD5.

          I would strongly suggest removing the "noplaintext" keyword during
          testing.



          -- Noel Jones
        • jugree@lavabit.com
          ... Can it be used on a regular basis (i.e., not just for testing)? Will it be better to enable a non-plaintext mechanism? Which one is the best? (I haven t
          Message 4 of 13 , Dec 6, 2012
          • 0 Attachment
            > and for the above to /work/ dovecot needs to offer a non-plaintext
            > mechanism, such as CRAM-MD5.

            > I would strongly suggest removing the "noplaintext" keyword during
            > testing.

            Can it be used on a regular basis (i.e., not just for testing)? Will it be
            better to enable a non-plaintext mechanism? Which one is the best?

            (I haven't tried yet.)
          • Noel Jones
            ... Yes, tell dovecot to offer non-plaintext mechanisms. Alternately, tell postfix to not offer non-TLS AUTH with main.cf smtpd_tls_auth_only = yes ... There
            Message 5 of 13 , Dec 6, 2012
            • 0 Attachment
              On 12/6/2012 4:54 AM, jugree@... wrote:
              >> and for the above to /work/ dovecot needs to offer a non-plaintext
              >> mechanism, such as CRAM-MD5.
              >
              >> I would strongly suggest removing the "noplaintext" keyword during
              >> testing.
              >
              > Can it be used on a regular basis (i.e., not just for testing)?

              Yes, tell dovecot to offer non-plaintext mechanisms.

              Alternately, tell postfix to not offer non-TLS AUTH with main.cf
              smtpd_tls_auth_only = yes

              > Will it be
              > better to enable a non-plaintext mechanism? Which one is the best?

              There is no best, there is only what fits your needs. I expect it's
              common to specify
              smtpd_sasl_security_options = noanonymous
              smtpd_sasl_tls_security_options = noanonymous

              and then after verifying that SASL works, adding
              smtpd_tls_auth_only = yes


              -- Noel Jones
            • jugree@lavabit.com
              ... Thank you. It worked. ... Does it mean that my session will be encrypted using TLS, but there won t be any encryption inside the tunnel? I assume it s
              Message 6 of 13 , Dec 6, 2012
              • 0 Attachment
                > I would strongly suggest removing the "noplaintext" keyword during
                > testing.

                Thank you. It worked.

                > There is no best, there is only what fits your needs. I expect it's
                > common to specify
                > smtpd_sasl_security_options = noanonymous
                > smtpd_sasl_tls_security_options = noanonymous

                > and then after verifying that SASL works, adding
                > smtpd_tls_auth_only = yes

                Does it mean that my session will be encrypted using TLS, but there
                won't be any encryption inside the tunnel?

                I assume it's pretty secure for most cases. Could you confirm?

                Anyway, I'll try to configure a non-plaintext mechanism.
              • Noel Jones
                ... Right, postfix won t offer AUTH unless the session is TLS-encrypted, and all credentials are protected by TLS. Postfix (and the SASL backend) will still
                Message 7 of 13 , Dec 6, 2012
                • 0 Attachment
                  On 12/6/2012 9:54 PM, jugree@... wrote:
                  >> common to specify
                  >> smtpd_sasl_security_options = noanonymous
                  >> smtpd_sasl_tls_security_options = noanonymous
                  >
                  >> and then after verifying that SASL works, adding
                  >> smtpd_tls_auth_only = yes
                  >
                  > Does it mean that my session will be encrypted using TLS, but there
                  > won't be any encryption inside the tunnel?


                  Right, postfix won't offer AUTH unless the session is TLS-encrypted,
                  and all credentials are protected by TLS.

                  Postfix (and the SASL backend) will still happily use any supported
                  mechanisms inside TLS, but now there's no particular advantage for
                  the non-plaintext mechanisms since everything is already encrypted
                  with TLS.


                  > I assume it's pretty secure for most cases. Could you confirm?

                  More secure, because with TLS the mail content is encrypted, not
                  just the credentials.


                  >
                  > Anyway, I'll try to configure a non-plaintext mechanism.
                  >

                  Many popular desktop clients only support PLAIN and LOGIN (both
                  considered plain-text equivalent), but it (most likely) won't hurt
                  to offer additional mechanisms.



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