FAQ
Hello,
Shouldn't the caller of smtp.NewClient be able to set the tls field of
the new Client?

I'm dealing with a server that requires TLS from the start and I'm
making my own TLS connection and passing it to smtp.NewClient, but
this makes the smtp.PlainAuth authentication fail with "unencrypted
connection".

Making a wrapper authentication method to fake the TLS field of
smtp.ServerInfo is trivial but wouldn't it be better to have an
accurate tls field that can be used by other authentication method?
Only the caller of smtp.NewClient knows what kind of net.Conn is
providing.

Thanks,
Leo III

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Kyle Lemons at Feb 11, 2013 at 10:28 pm
    I have not used the package, but what if you give NewClient a tls.Conn?

    On Mon, Feb 11, 2013 at 2:09 AM, wrote:

    Hello,
    Shouldn't the caller of smtp.NewClient be able to set the tls field of
    the new Client?

    I'm dealing with a server that requires TLS from the start and I'm
    making my own TLS connection and passing it to smtp.NewClient, but
    this makes the smtp.PlainAuth authentication fail with "unencrypted
    connection".

    Making a wrapper authentication method to fake the TLS field of
    smtp.ServerInfo is trivial but wouldn't it be better to have an
    accurate tls field that can be used by other authentication method?
    Only the caller of smtp.NewClient knows what kind of net.Conn is
    providing.

    Thanks,
    Leo III

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Germanium at Feb 12, 2013 at 12:53 am

    On 11 Feb, 23:28, Kyle Lemons wrote:
    I have not used the package, but what if you give NewClient a tls.Conn?
    That's exactly what I'm doing, but NewClient leaves the Client.tls
    field set to false no matter what kind of net.Conn you give it:
    http://golang.org/src/pkg/net/smtp/smtp.go?s=1576:1630#L49
    and that value goes to the ServerInfo.TLS field:
    http://golang.org/src/pkg/net/smtp/smtp.go?s=3940:4008#L135
    and it makes the PlainAuth authentication method fail:
    http://golang.org/src/pkg/net/smtp/auth.go?s=2015:2090#L46

    As a workaround I'm embedding an smtp.Auth in my own type and
    redefining the Start method to set the ServerInfo.TLS field to true
    before calling the underlaying Start.

    But as I said, wouldn't it be better to fix the tls field, since the
    authentication methods rely on it? NewClient could check if the
    net.Conn is a tls.Conn or take a specific argument and set the tls
    field accordingly.

    Thanks,
    Leo III

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at Feb 12, 2013 at 2:32 am
    Oh, I misread your message as making your own Conn not connecting your own
    tls.Conn and passing it in. Whoops.

    On Mon, Feb 11, 2013 at 4:53 PM, wrote:
    On 11 Feb, 23:28, Kyle Lemons wrote:
    I have not used the package, but what if you give NewClient a tls.Conn?
    That's exactly what I'm doing, but NewClient leaves the Client.tls
    field set to false no matter what kind of net.Conn you give it:
    http://golang.org/src/pkg/net/smtp/smtp.go?s=1576:1630#L49
    and that value goes to the ServerInfo.TLS field:
    http://golang.org/src/pkg/net/smtp/smtp.go?s=3940:4008#L135
    and it makes the PlainAuth authentication method fail:
    http://golang.org/src/pkg/net/smtp/auth.go?s=2015:2090#L46

    As a workaround I'm embedding an smtp.Auth in my own type and
    redefining the Start method to set the ServerInfo.TLS field to true
    before calling the underlaying Start.

    But as I said, wouldn't it be better to fix the tls field, since the
    authentication methods rely on it? NewClient could check if the
    net.Conn is a tls.Conn or take a specific argument and set the tls
    field accordingly.

    Thanks,
    Leo III
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stephen Weinberg at Feb 12, 2013 at 1:29 am
    I ran into this problem before. I even submitted a bug report here:
    http://code.google.com/p/go/issues/detail?id=3609 .

    It was decided it was working as intended. The easiest way around it
    is to have smtp do the encryption using StartTLS(). If that is
    impossible, you can copy the smtp.plainAuth implementation and remove
    the TLS check.

    The implementation is at http://golang.org/src/pkg/net/smtp/auth.go?#L41
    from line 41 to 72.

    -- Stephen
    On Feb 11, 2:09 am, german...@gmx.us wrote:
    Hello,
    Shouldn't the caller of smtp.NewClient be able to set the tls field of
    the new Client?

    I'm dealing with a server that requires TLS from the start and I'm
    making my own TLS connection and passing it to smtp.NewClient, but
    this makes the smtp.PlainAuth authentication fail with "unencrypted
    connection".

    Making a wrapper authentication method to fake the TLS field of
    smtp.ServerInfo is trivial but wouldn't it be better to have an
    accurate tls field that can be used by other authentication method?
    Only the caller of smtp.NewClient knows what kind of net.Conn is
    providing.

    Thanks,
    Leo III
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Germanium at Feb 12, 2013 at 9:12 am

    On Feb 12, 2:29 am, Stephen Weinberg wrote:
    I ran into this problem before. I even submitted a bug report here:http://code.google.com/p/go/issues/detail?id=3609.
    On May 10 2012, 1:34 pm, rsc wrote:
    I think the benefits of making sure people don't send passwords in
    clear text over networks accidentally outweigh the inconvenience of
    not being able to use PlainAuth when you do intend to send a password
    over a network in clear text.

    PlainAuth is just a helper and does not do anything that requires help
    from net/smtp. I would suggest to copy the PlainAuth implementation
    into your own package and delete the lines that require TLS. It's
    under 20 lines of code.
    I think the problem is not PlainAuth failing if TLS is off. The
    problem is ServerInfo.TLS not being accurate.
    It will probably never happen, but if someone wants to write a new
    authentication method he can not reliably check if TLS is off (because
    if you pass a tls.Conn to NewClient, ServerInfo.TLS will be false).
    Why not making NewClient check if the net.Conn is a tls.Conn and set
    the Client.tls field accordingly?

    Thanks,
    Leo III

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Germanium at Feb 12, 2013 at 9:14 am

    On Feb 12, 2:29 am, Stephen Weinberg wrote:
    It was decided it was working as intended. The easiest way around it
    is to have smtp do the encryption using StartTLS(). If that is
    impossible, you can copy the smtp.plainAuth implementation and remove
    the TLS check.
    I'm doing it like this:

    type fakeAuth struct {
    smtp.Auth
    }

    func (a fakeAuth) Start(server *smtp.ServerInfo) (string, []byte,
    error) {
    server.TLS = true
    return a.Auth.Start(server)
    }

    auth := fakeAuth{smtp.PlainAuth("", username, password, host)}

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 11, '13 at 10:09a
activeFeb 12, '13 at 9:14a
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase