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

Re: disturbing TLS error

Expand Messages
  • Jan P. Kessler
    ... If you don t need TLS for yahoo you can disable it for that server. Take a look at
    Message 1 of 15 , Sep 14, 2013
    • 0 Attachment
      > So, there is nothing i can do ?

      If you don't need TLS for yahoo you can disable it for that server. Take
      a look at

      http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
    • Viktor Dukhovni
      ... There is nothing you should do. This may not even be a problem. Perhaps Yahoo have a reason for doing what they re doing. If it is a problem, they ll fix
      Message 2 of 15 , Sep 14, 2013
      • 0 Attachment
        On Sat, Sep 14, 2013 at 08:45:05AM +0200, Mathieu R. wrote:

        > >Yahoo sends "STARTTLS", Postfix says "go ahead" and Yahoo
        > >disconnects.
        > >There's is nothing more to it. Some strange problem on the Yahoo
        > >side, unless your firewall is blocking the handshake.
        >
        > My firewall is not doing such rude things.
        > Thank you a lot for your help.
        > So, there is nothing i can do ?

        There is nothing you should do. This may not even be a problem.
        Perhaps Yahoo have a reason for doing what they're doing. If it is
        a problem, they'll fix it.

        --
        Viktor.
      • James Cloos
        The mx lookup on effraie.org returns mx.effraie.org. The cert mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org. I bet that is why the
        Message 3 of 15 , Sep 15, 2013
        • 0 Attachment
          The mx lookup on effraie.org returns mx.effraie.org. The cert
          mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.

          I bet that is why the session failed.

          The mx for 400iso.net, mx.400iso.net, sends the same cert and also
          likely will fail tls negotiation with some senders.

          In general, the name returned by the MX lookup is used as the TLS server
          name when tls verification is attempted.

          -JimC
          --
          James Cloos <cloos@...> OpenPGP: 1024D/ED7DAEA6
        • Viktor Dukhovni
          ... I noticed this, but I thought it unlikely that a sender willing to accept self-signed certificates, would object to the peername in such a certificate.
          Message 4 of 15 , Sep 15, 2013
          • 0 Attachment
            On Sun, Sep 15, 2013 at 03:31:38PM -0400, James Cloos wrote:

            > The mx lookup on effraie.org returns mx.effraie.org. The cert
            > mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.
            >
            > I bet that is why the session failed.

            I noticed this, but I thought it unlikely that a sender willing to
            accept self-signed certificates, would object to the peername in
            such a certificate. SMTP clients SHOULD NOT attempt to perform
            *any* verification of SMTP server certificates without out-of-band
            information about how to do that (local secure-channel configuration,
            or DANE TLSA).

            Yes, the possibility does exist that you're right anyway, and the
            conservative (Postel) configuration is to have a matching CN or
            subjectAltName even in a self-signed certificate.

            > In general, the name returned by the MX lookup is used as the TLS server
            > name when tls verification is attempted.

            In general, with SMTP, when TLS is used it all it is TLS opportunistic
            and unauthenicated. I still think that either that Yahoo host was
            configured to perform some sort of probe function, or it was not performing
            as intended.

            --
            Viktor.
          • Mathieu R.
            ... As it seem to be a good advice, I did change my dns entries for mx to mail.effraie.org, wich is covered by the (new) cacert certificat of the mail server.
            Message 5 of 15 , Sep 15, 2013
            • 0 Attachment
              James Cloos <cloos@...> a écrit :
              >The mx lookup on effraie.org returns mx.effraie.org. The cert
              >mx.effraie.org sends has a number of dnsnames, but not mx.effraie.org.
              >
              >I bet that is why the session failed.
              >
              >The mx for 400iso.net, mx.400iso.net, sends the same cert and also
              >likely will fail tls negotiation with some senders.
              >
              >In general, the name returned by the MX lookup is used as the TLS
              >server
              >name when tls verification is attempted.
              >
              >-JimC


              As it seem to be a good advice, I did change my dns entries for mx to mail.effraie.org, wich is covered by the (new) cacert certificat of the mail server.

              I still have the same error in logs


              --
              Mathieu R.
              Envoyé depuis un téléphone. Excusez la brièveté.
            • Wietse Venema
              ... It does not matter what the server certificate says, because it is never sent. The evidence shows that the client hangs up before the TLS handshake.
              Message 6 of 15 , Sep 15, 2013
              • 0 Attachment
                Mathieu R.:
                > As it seem to be a good advice, I did change my dns entries for
                > mx to mail.effraie.org, wich is covered by the (new) cacert
                > certificat of the mail server.
                >
                > I still have the same error in logs

                It does not matter what the server certificate says, because it is
                never sent. The evidence shows that the client hangs up before the
                TLS handshake.

                Wietse
              • John Allen
                I ran into a problem that seems to have some of the same attributes. In my case Google was rejecting my email, however they may have been a little more polite
                Message 7 of 15 , Sep 15, 2013
                • 0 Attachment
                  I ran into a problem that seems to have some of the same attributes. In
                  my case Google was rejecting my email, however they may have been a
                  little more polite about doing so.

                  Have you checked your DNS and reverse DNS entries. Is your server a
                  dedicated system with a single IP address.

                  In my case I was running a multi-use server which had multiple IP
                  addresses. This resulted in email being sent out on a IP address whose
                  reverse DNS did not resolve to the published server. Google rejected my
                  email, but they did issue an error message.

                  I wonder if Yahoo is doing some sort of DNS to IP check and finding a
                  mismatch just dropping the connection instead of issuing a valid error
                  code. Not very polite of them, but past experience with not particularly
                  unusual for them.

                  To solve my problem, the first thing I did was to ensure that the rDNS
                  for my sever was correct.
                  Next added smtp_bind_address to the smtp entry in my master.cf.

                  the effect of this is to ensure that the address and reverse address
                  match, and that any DNS look up will not result in an error.

                  I don't know if this will solve you problem. but I hope it helps.
                Your message has been successfully submitted and would be delivered to recipients shortly.