net/smtp: add Client.TLSConfig field and Client.SendMail method

[g13013]

smtp.SendMail actually does a great job, but the fact that it always uses smtp.Dial make it less flexible both for testing and for certain cases like ours, where we wanted to customize the Client.localName

In fact, in certain operations, Client.localName must correspond to the FQDN hostname sending the email (always localhost in the current implementation), this lack of flexibility led us to duplicate the entire SendMail (and tests) code just to address this issue.

I propose that we add a new public method smtp.SendMailWithDialer or smtp.SendMailWithDialerFunc and a new type Dialer/DialerFunc

type Dialer func() (*Client, error) // or DialerFunc ?

func SendMailWithDialer(dial Dialer, a Auth, from string, to []string, msg []byte) error

The change set required is very minimal and backward compatible, smtp.SendMail could use smtp.SendMailWithDialer just by passing smtp.Dial as the dialer:

func makeDialer(addr string) func() (*Client, error) {
	return func() (*Client, error) {
		return Dial(addr)
	}
}
func SendMail(addr string, a Auth, from string, to []string, msg []byte) error {
	return SendMailWithDialer(makeDialer(addr), a, from, to, msg)
}

This would allow for much more control both for testing and real uses cases with minimum code, for example:

func myDialer() (*smtp.Client, error) {
	cl, err := Dial("remoteSmtp:25")
	if err != nil { return nil, err }
	if err := cl.Hello("my_FQDN") {
 		return nil, err
	}
	return cl, nil
}

smtp.SendMailWithDialer(myDialer, auth, from, to, msg)

I am willing to make a CL if it is accepted

Edit:

• At first the proposal was about adding SendMailWithClient, but it turned out that line validation would be duplicate both in SendMailWithClient and SendMail as the validation must occur before the dial

• The proposal included a proposal to make config.localName public, but since Client.Hello exists and SendMail uses Client.hello internally which does nothing if a Hello was called before this change is no longer required as the Dialer function could call Hello before passing to SendMailWithDialer

[ianlancetaylor]

@g13013 Please only send patches using Gerritt or as a GitHub pull request, as described at http://golang.org/doc/contribute.html. Please don't post patches on the issue tracker. That avoids any concerns about copyright. Thanks.

[g13013]

@ianlancetaylor oh didn't know about that, sorry ! comment removed

[rsc]

Originally, smtp.SendMail was a tiny little wrapper around the Client type, a convenience.
It has gotten rather large as TLS and various validations were added.

@bradfitz points out maybe it would make sense to add a Client.SendMail method.
Then you can make the Client c however you want and call c.SendMail.
And it avoids a callback in favor of much more direct code.

Thoughts?

[g13013]

@rsc interesting, sounds good to me. I think it's even better than the original proposal.

[g13013]

Last thought,

I tend to think that adding Client.SendMail would solve the original issue but would not make smtp.Client as usable as it should be unless we include the Dial capability to initialize its state.

ex. : If a user wants to customize the TLS configuration to add a valid CA, a naive solution would be to extend Client and override Client.StartTLS, but since the Client.conn & Client.serverName are hidden and initialized only via smtp.Dial or smtp.NewClient which always return a smtp.Client struct, extending would not be possible. An example of this could be found in smtp.SendMail where the hook has been added for testing only and used here.

A solution to this would be to add Client.Dial in addition to Client.SendMail? which does pretty much what smtp.Dial and smtp.NewClient do all together, this would make the Client fully extensible and even make the Client instance reusable for further operations, if so, this would make smtp.Dial, smtp.NewClient and smtp.SendMail wrappers only for Client

what do you think ?

PS: We could even add Client.DialAndSend for convenience only!

[gopherbot]

Change https://golang.org/cl/242017 mentions this issue: net/smtp: allow more control on Client