domodwyer / mailyak

An elegant MIME/SMTP email library with support for attachments

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mails have incorrect timestamp when reusing

jacksgt opened this issue · comments

Hey,

I am using this library in one of my projects and it was really easy to get started - thanks for great work!

After using it in production for a while, I noticed that the emails I send have an incorrect (old) timestamp.
Digging through the code a bit, it seems that the MailYak.date field is only set upon initializing a new instance, not when sending out emails (https://github.com/domodwyer/mailyak/blob/master/mailyak.go#L55).
I am following the advice in the README of re-using a single MailYak instance:

You can use a single instance of mailyak to send multiple emails after changing the to/body/whatever fields, avoiding unnecessary allocation/GC pressure.

var mail *mailyak.MailYak

...

	if mail == nil {
		mail = mailyak.New(SmtpHostPort, smtp.PlainAuth("", SmtpUser, SmtpPassword, SmtpHost))
	}
       // send email as usual

However, this results in "old" timestamp when the server is running for longer periods of time.
This behavior was introduced in PR #22

I see several ways to fix this:

  1. Automatically (re-)set the date timestamp when calling mailyak.Send(). IMO this is the correct behavior, because it ensures every email has the timestamp it actually deserves.
  2. Allow the user to set the timestamp. Either by exporting the .date field (-> .Date) or by exposing a method (mailyak.SetDate(time.Time)). This would allow to re-use the same timestamp for several emails, while also allowing the user to set arbitrary timestamps (could be useful? not sure...)
  3. Explicitly state in the README that when re-using mailyak instances, the timestamps will be old. This kind of mitigates the problem, but it also means that when I want to send each email with the correct timestamp, I need to create a new mailyak instance which involves TLS set up, authentication to the mail server etc.

What do you think?

Once we have agreed on a solution, I'm happy to submit a PR for this.

Sorry, duplicate submission (github returned 404?)
#50