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

Re: Configuring TLS with sender login maps

Expand Messages
  • Jeroen Geilman
    ... What do you mean, *after* ? ... You re not authenticated. ... This rejects mail from SASL ed clients who are not in the map AND non-SASL ed clients who ARE
    Message 1 of 12 , Apr 2, 2011
    • 0 Attachment
      On 04/02/2011 07:17 AM, Alex wrote:
      > Hi,
      > I have a fedora14 box that I'm trying to configure for use with
      > postfix with dovecot and TLS, permitting only TLS connections after
      > authenticating with sasl.

      What do you mean, *after* ?

      > It appears to mostly be working now, but
      > mail is rejected due to "not owned by user" errors.
      >
      >
      > Apr 2 01:03:54 fc14 postfix/smtpd[10284]: Anonymous TLS connection
      > established from unknown[184.XXX.XX.223]: TLSv1 with cipher
      > DHE-RSA-AES256-SHA (256/256 bits)
      >

      > Apr 2 01:03:55 fc14 postfix/smtpd[10284]: NOQUEUE: reject: RCPT from
      > unknown[184.XXX.XX.223]: 553 5.7.1<myuser@...>: Sender
      > address rejected: not owned by user alex; from=<myuser@...>
      > to=<remoteluser@...> proto=ESMTP
      > helo=<184-XXX-XXX-223.pools.mycellphone.net>
      >
      >

      You're not authenticated.

      > smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
      > smtpd_sender_restrictions = reject_sender_login_mismatch
      >

      This rejects mail from SASL'ed clients who are not in the map AND
      non-SASL'ed clients who ARE in the map.
      The above log line matches the latter condition, hence why it says that.

      > smtpd_tls_auth_only = yes
      >

      SASL is not offered before a secure connection is established.

      > smtpd_tls_security_level = encrypt
      >

      However, TLS is mandatory.

      > Are there any other options I should be concerned about with regards
      > to security, and ensuring I don't become a relay or risk of
      > unauthorized access?
      >

      Fix your client to properly use TLS AND THEN SASL.


      --
      J.
    • Reindl Harald
      ... send account-information unencrypted and after that encrypt data? who wants such bad things and why?
      Message 2 of 12 , Apr 2, 2011
      • 0 Attachment
        Am 02.04.2011 07:17, schrieb Alex:

        > I have a fedora14 box that I'm trying to configure for use with
        > postfix with dovecot and TLS, permitting only TLS connections after
        > authenticating with sasl.

        send account-information unencrypted and after that
        encrypt data? who wants such bad things and why?
      • Alex
        Hi, ... Oops. I m still learning this, and think I got confused writing this so late last night. ... I m using the K9 client for Android. Using this method
        Message 3 of 12 , Apr 2, 2011
        • 0 Attachment
          Hi,

          >> I have a fedora14 box that I'm trying to configure for use with
          >> postfix with dovecot and TLS, permitting only TLS connections after
          >> authenticating with sasl.
          >
          > What do you mean, *after* ?

          Oops. I'm still learning this, and think I got confused writing this
          so late last night.

          >> Apr  2 01:03:55 fc14 postfix/smtpd[10284]: NOQUEUE: reject: RCPT from
          >> unknown[184.XXX.XX.223]: 553 5.7.1<myuser@...>: Sender
          >> address rejected: not owned by user alex; from=<myuser@...>
          >> to=<remoteluser@...>  proto=ESMTP
          >> helo=<184-XXX-XXX-223.pools.mycellphone.net>
          >>
          >
          > You're not authenticated.
          >
          >> smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
          >> smtpd_sender_restrictions = reject_sender_login_mismatch
          >>
          >
          > This rejects mail from SASL'ed clients who are not in the map AND
          > non-SASL'ed clients who ARE in the map.
          > The above log line matches the latter condition, hence why it says that.
          >
          >> smtpd_tls_auth_only = yes
          >>
          >
          > SASL is not offered before a secure connection is established.
          >
          >> smtpd_tls_security_level = encrypt
          >>
          >
          > However, TLS is mandatory.
          >
          >> Are there any other options I should be concerned about with regards
          >> to security, and ensuring I don't become a relay or risk of
          >> unauthorized access?
          >>
          >
          > Fix your client to properly use TLS AND THEN SASL.

          I'm using the K9 client for Android. Using this method with TLS and
          SASL I need port 25 open for SMTP and TLS, and 587 for submission and
          SASL, correct?

          Thanks,
          Alex
        • Reindl Harald
          ... i believe you need some clarify SASL-Auth and TLS/SSL are independent TLS/SSL is the first step 587 = submission and implicit SASL-Auth, TLS may 25 = SASL
          Message 4 of 12 , Apr 2, 2011
          • 0 Attachment
            Am 02.04.2011 21:00, schrieb Alex:

            >> Fix your client to properly use TLS AND THEN SASL.
            >
            > I'm using the K9 client for Android. Using this method with TLS and
            > SASL I need port 25 open for SMTP and TLS, and 587 for submission and
            > SASL, correct?

            i believe you need some clarify

            SASL-Auth and TLS/SSL are independent

            TLS/SSL is the first step
            587 = submission and implicit SASL-Auth, TLS may
            25 = SASL may, TLS may
            465 = smtps (no TLS handshake, it is SSL per definition)

            the point is that TLS happens while connecting
            on 25/587 the server OFFERS TLS, but it is not requested
            so the first part of the connection is unencrypted
            after the client "sees" STARTTLS the SSL handshake can follow or even not

            on port 465 there is no "may offer", 465 is dedicated SSL

            SASL-Authentication happens AFTER the connection/tls/ssl-handshake
            that is why "SASL only after TLS" makes no sense

            SASL is used for allow or deny relay
            587 (submission) is used only for authenticated clients
            25 CAN be used for that, but is blocked by many providers because
            it maybe used without Authentication because other mailservers deliver their
            messages over port 25 to you and they can not authenticate to a MX
            for normal relaying their users mail

            that is why 25 form most client-networks is blocked outgoing because
            spambots are using port 25 for their crap and if yiu have a account
            you should use 587 for submit your messages to your mail-provider
          • Jeroen Geilman
            ... Um.. no. Submission can be done over port 25 or 587, and can use TLS or SASL, or both, or neither. YOU have configured postfix to only allow submission
            Message 5 of 12 , Apr 2, 2011
            • 0 Attachment
              On 04/02/2011 09:00 PM, Alex wrote:
              > I'm using the K9 client for Android. Using this method with TLS and
              > SASL I need port 25 open for SMTP and TLS, and 587 for submission and
              > SASL, correct?
              >

              Um.. no.

              Submission can be done over port 25 or 587, and can use TLS or SASL, or
              both, or neither.

              YOU have configured postfix to only allow submission when the client
              first secures the connection with TLS, and only then authenticates via SASL.

              If this is not what you want, change the server's configuration.

              If this is what you want, fix the client's configuration.



              --
              J.
            • Alex
              Hi, ... Okay, I think I have it working correctly now. I believe my mistake was with using the incorrect ports for authentication. I think I may not fully
              Message 6 of 12 , Apr 2, 2011
              • 0 Attachment
                Hi,

                >>> Apr  2 01:03:55 fc14 postfix/smtpd[10284]: NOQUEUE: reject: RCPT from
                >>> unknown[184.XXX.XX.223]: 553 5.7.1<myuser@...>: Sender
                >>> address rejected: not owned by user alex; from=<myuser@...>
                >>> to=<remoteluser@...>  proto=ESMTP
                >>> helo=<184-XXX-XXX-223.pools.mycellphone.net>
                >>
                >> You're not authenticated.

                Okay, I think I have it working correctly now. I believe my mistake
                was with using the incorrect ports for authentication. I think I may
                not fully understand the logic behind the whole process still,
                however.

                I've changed smtpd_tls_security_level to 'may' from 'encrypt' in
                main.cf because it also needs to be able to accept mail from non-TLS
                authenticated clients (which are actually other postfix servers) in
                addition to my K9 android mail client.

                Unlike my cell phone, these other mail server have fixed IP addresses.
                I believe there is a way to specify a list of servers that explicitly
                do not require TLS, is that correct?

                In master.cf, I have the following:

                submission inet n - n - - smtpd
                -o smtpd_tls_security_level=encrypt
                -o smtpd_sasl_auth_enable=yes
                -o smtpd_client_restrictions=permit_sasl_authenticated,reject
                -o milter_macro_daemon_name=ORIGINATING

                If I understand this correctly, the connection is first established
                over TLS through port 25, then this section enables SASL over that TLS
                connection, and only if there is a TLS connection, correct?

                I am using the default dovecot certificates. I have been unable to
                locate the applications to create a new cert on my fedora14 box. What
                am I missing that the lines below state a client certificate was not
                requested? Is that an issue with my mail client on my phone, or the
                dovecot configuration?

                Received: from XXX-YYY-86-66.pools.spcsdns.net
                (XXX-YYY-86-66.pools.spcsdns.net [XXX.YYY.86.66])
                (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
                (No client certificate requested)
                (Authenticated sender: alex)
                by myhost.myexample.com (Postfix) with ESMTPSA id B2CD3143A23
                for <myuser@...>; Sat, 2 Apr 2011 15:33:46 -0400 (EDT)

                Thanks,
                Alex
              • Jeroen Geilman
                ... Authentication doesn t have a port - it is an integral part of the SMTP protocol. ... You shouldn t run TLS at all on port 25 if you re not using it for
                Message 7 of 12 , Apr 2, 2011
                • 0 Attachment
                  On 04/02/2011 09:50 PM, Alex wrote:

                  > Okay, I think I have it working correctly now. I believe my mistake
                  > was with using the incorrect ports for authentication.

                  Authentication doesn't have a "port" - it is an integral part of the
                  SMTP protocol.

                  > I think I may
                  > not fully understand the logic behind the whole process still,
                  > however.
                  >
                  > I've changed smtpd_tls_security_level to 'may' from 'encrypt' in
                  > main.cf because it also needs to be able to accept mail from non-TLS
                  > authenticated clients (which are actually other postfix servers) in
                  > addition to my K9 android mail client.
                  >

                  You shouldn't run TLS at all on port 25 if you're not using it for
                  submission - and there is no reason to do so.

                  > Unlike my cell phone, these other mail server have fixed IP addresses.
                  > I believe there is a way to specify a list of servers that explicitly
                  > do not require TLS, is that correct?
                  >

                  Yes, but unnecessary.

                  > In master.cf, I have the following:
                  >
                  > submission inet n - n - - smtpd
                  > -o smtpd_tls_security_level=encrypt
                  > -o smtpd_sasl_auth_enable=yes
                  > -o smtpd_client_restrictions=permit_sasl_authenticated,reject
                  > -o milter_macro_daemon_name=ORIGINATING
                  >
                  > If I understand this correctly, the connection is first established
                  > over TLS through port 25, then this section enables SASL over that TLS
                  > connection, and only if there is a TLS connection, correct?
                  >

                  No.
                  Submission is a TCP service on port 587, so this daemon listens on port 587.

                  > I am using the default dovecot certificates.

                  Certificates have nothing to do with SMTP AUTH, and dovecot is not
                  involved in either SMTP or TLS.

                  They are used to validate the client in a TLS connection.

                  > I have been unable to
                  > locate the applications to create a new cert on my fedora14 box.

                  That would be openssl.
                  man openssl will have details on how to generate a certificate, but
                  X.509 is a whole 'nother subject.

                  > What
                  > am I missing that the lines below state a client certificate was not
                  > requested? Is that an issue with my mail client on my phone, or the
                  > dovecot configuration?
                  >
                  Since dovecot does not use the certificate in any way - unless you're
                  talking about *IMAP* over TLS - it is a postfix configuration issue.

                  Read http://www.postfix.org/postconf.5.html#smtpd_tls_ask_ccert for details.


                  --
                  J.
                • Reindl Harald
                  ... sorry but that is nonsense YOU SHOULD ENABLE IT OR YOU CAN DISABLE SSL ON IMAP/POP3 TOO what sense makes it to encrypt receiving messages over ssl with
                  Message 8 of 12 , Apr 2, 2011
                  • 0 Attachment
                    Am 02.04.2011 21:58, schrieb Jeroen Geilman:
                    > On 04/02/2011 09:50 PM, Alex wrote:
                    >
                    >> Okay, I think I have it working correctly now. I believe my mistake
                    >> was with using the incorrect ports for authentication.
                    >
                    > Authentication doesn't have a "port" - it is an integral part of the SMTP protocol.
                    >
                    >> I think I may
                    >> not fully understand the logic behind the whole process still,
                    >> however.
                    >>
                    >> I've changed smtpd_tls_security_level to 'may' from 'encrypt' in
                    >> main.cf because it also needs to be able to accept mail from non-TLS
                    >> authenticated clients (which are actually other postfix servers) in
                    >> addition to my K9 android mail client.
                    >>
                    >
                    > You shouldn't run TLS at all on port 25 if you're not using it for submission - and there is no reason to do so

                    sorry but that is nonsense
                    YOU SHOULD ENABLE IT OR YOU CAN DISABLE SSL ON IMAP/POP3 TOO

                    what sense makes it to encrypt receiving messages over ssl with
                    your client as long other mail-servers deliver thmen
                    unencrypted?

                    if you wuld like encrypted services EVERY host and protocol which is
                    involved should support TLS or you can disable it completly

                    secuity level "may" is correct because not every host supports encryption
                    but if the host support it tls should be used, so the message is encrypted
                    from one client to the receiver, least you minimize the count
                    of unencrypted hops
                  • Jeroen Geilman
                    ... I see Mr Reindl is butting his big mouth in again. I should do nothing. If the OP is running normal SMTP on port 25, then TLS is an added complexity, and
                    Message 9 of 12 , Apr 2, 2011
                    • 0 Attachment
                      On 04/02/2011 10:11 PM, Reindl Harald wrote:
                      >
                      > Am 02.04.2011 21:58, schrieb Jeroen Geilman:
                      >
                      >> On 04/02/2011 09:50 PM, Alex wrote:
                      >>
                      >>
                      >>> Okay, I think I have it working correctly now. I believe my mistake
                      >>> was with using the incorrect ports for authentication.
                      >>>
                      >> Authentication doesn't have a "port" - it is an integral part of the SMTP protocol.
                      >>
                      >>
                      >>> I think I may
                      >>> not fully understand the logic behind the whole process still,
                      >>> however.
                      >>>
                      >>> I've changed smtpd_tls_security_level to 'may' from 'encrypt' in
                      >>> main.cf because it also needs to be able to accept mail from non-TLS
                      >>> authenticated clients (which are actually other postfix servers) in
                      >>> addition to my K9 android mail client.
                      >>>
                      >>>
                      >> You shouldn't run TLS at all on port 25 if you're not using it for submission - and there is no reason to do so
                      >>
                      > sorry but that is nonsense
                      > YOU SHOULD ENABLE IT OR YOU CAN DISABLE SSL ON IMAP/POP3 TOO
                      >
                      I see Mr Reindl is butting his big mouth in again.
                      I "should" do nothing.

                      If the OP is running normal SMTP on port 25, then TLS is an added
                      complexity, and one he is apparently not sufficiently prepared for; so
                      if he can avoid it, I would advise him to do so.

                      > what sense makes it to encrypt receiving messages over ssl with
                      > your client as long other mail-servers deliver thmen
                      > unencrypted?
                      >

                      Because the primary value of TLS on a mail client is to be able to send
                      encrypted login information, and prevent sniffing on local LAN networks.

                      The majority of the internet is not sending encrypted mail between MTAs.

                      > if you wuld like encrypted services EVERY host and protocol which is
                      > involved should support TLS or you can disable it completly
                      >

                      I can only repeat that your preposterous "SHOULD" demands are silly.
                      Guaranteed end-to-end encryption is not a job for the MTA.
                      Use PGP or GPG to achieve message confidentiality.

                      > secuity level "may" is correct because not every host supports encryption
                      > but if the host support it tls should be used, so the message is encrypted
                      > from one client to the receiver, least you minimize the count
                      > of unencrypted hops
                      >
                      ..but that's utter bullshit, since you yourself said that encryption is
                      worthless unless ALL hops use it.
                      Now you're saying "oh, it's okay if they don't, but try to minimize them" ?

                      Make up your mind.


                      --
                      J.
                    • Reindl Harald
                      ... is your toilet broken or why is your neck so big? ... YOU can do waht you want, but do not recommend others wrong things ... YOU would, but who are you to
                      Message 10 of 12 , Apr 2, 2011
                      • 0 Attachment
                        Am 02.04.2011 23:17, schrieb Jeroen Geilman:

                        > I see Mr Reindl is butting his big mouth in again

                        is your toilet broken or why is your neck so big?

                        > I "should" do nothing.

                        YOU can do waht you want, but do not recommend others wrong things

                        > If the OP is running normal SMTP on port 25, then TLS is an added complexity, and one he is apparently not
                        > sufficiently prepared for; so if he can avoid it, I would advise him to do so.

                        YOU would, but who are you to suggest others "disable encryption is ok"?

                        > Because the primary value of TLS on a mail client is to be able to send encrypted
                        > login information, and prevent sniffing on local LAN networks

                        *lol*

                        you know about cram-md5 / digest-md5
                        this is for login-information

                        > The majority of the internet is not sending encrypted mail between MTAs

                        bullshit, you are not the majority

                        Untrusted TLS connection established to mx2.t-systems.at
                        Untrusted TLS connection established to gmail-smtp-in.l.google.com
                        Untrusted TLS connection established to mx04.brts.barracuda.com
                        Untrusted TLS connection established to mailw.lix.aon.at
                        Untrusted TLS connection established to mx1.nokia.com
                        Untrusted TLS connection established to mx.sil.at
                        Untrusted TLS connection established to mx.inode.at

                        > I can only repeat that your preposterous "SHOULD" demands are silly.
                        > Guaranteed end-to-end encryption is not a job for the MTA.
                        > Use PGP or GPG to achieve message confidentiality.

                        you were the who spoke about "the majority"?
                        the majority is not using GPG!

                        but the majority is using TLS for smtp(pop3/imap if they have
                        a smater sysadmin like you!

                        > ..but that's utter bullshit, since you yourself said that encryption is worthless unless
                        > ALL hops use it. Now you're saying "oh, it's okay if they don't, but try
                        > to minimize them" ?
                        >
                        > Make up your mind

                        shut up if you have no idea about the topic

                        again:
                        NOBODY needs TLS for auth, this is done by auth-mechanisms

                        if you provide TLS tou your clients you suggest that messages are encrypted
                        and they are if you have configured your server right and the customer sends
                        a message to gmail, but if you are too stupid the answer with the quoted
                        information come back unecnrypted
                      • Ansgar Wiechers
                        ... You ve repeatedly shown an attitude on this list that I consider objectionable, to say the least. Would you mind keeping it to yourself? Thank you. ... He
                        Message 11 of 12 , Apr 4, 2011
                        • 0 Attachment
                          On 2011-04-02 Reindl Harald wrote:
                          > Am 02.04.2011 23:17, schrieb Jeroen Geilman:
                          >> I see Mr Reindl is butting his big mouth in again
                          >
                          > is your toilet broken or why is your neck so big?

                          You've repeatedly shown an attitude on this list that I consider
                          objectionable, to say the least. Would you mind keeping it to yourself?
                          Thank you.

                          >> I "should" do nothing.
                          >
                          > YOU can do waht you want, but do not recommend others wrong things

                          He didn't.

                          [...]
                          >> Because the primary value of TLS on a mail client is to be able to
                          >> send encrypted login information, and prevent sniffing on local LAN
                          >> networks
                          >
                          > *lol*
                          >
                          > you know about cram-md5 / digest-md5
                          > this is for login-information

                          You do realize that these have other disadvantages, don't you? Like the
                          requirement to store the user's unencrypted password on the server.

                          [...]
                          >> I can only repeat that your preposterous "SHOULD" demands are silly.
                          >> Guaranteed end-to-end encryption is not a job for the MTA.
                          >> Use PGP or GPG to achieve message confidentiality.
                          >
                          > you were the who spoke about "the majority"?
                          > the majority is not using GPG!

                          Which doesn't change anything about the fact that PGP/GPG is suited for
                          ensuring end-to-end confidentiality, while TLS is not. TLS only ever
                          guarantees encrypted transmission to the next HOP. Period. Live with it.

                          Regards
                          Ansgar Wiechers
                          --
                          "Abstractions save us time working, but they don't save us time learning."
                          --Joel Spolsky
                        Your message has been successfully submitted and would be delivered to recipients shortly.