knadh/smtppool

High throughput Go SMTP pool library with graceful handling of idle timeouts, errors, and retries.

smtppool

smtppool is a Go library that creates a pool of reusable SMTP connections for high throughput e-mailing. It gracefully handles idle connections, timeouts, and retries. The e-mail formatting, parsing, and preparation code is forked from jordan-wright/email.

Install

go get github.com/knadh/smtppool

Usage

package main

import (
	"fmt"
	"log"

	"github.com/knadh/smtppool"
)

func main() {
	// Try https://github.com/mailhog/MailHog for running a local dummy SMTP server.
	// Create a new pool.
	pool, err := smtppool.New(smtppool.Opt{
		Host:            "localhost",
		Port:            1025,
		MaxConns:        10,
		IdleTimeout:     time.Second * 10,
		PoolWaitTimeout: time.Second * 3,
	})
	if err != nil {
		log.Fatalf("error creating pool: %v", err)
	}

	e:= Email{
		From:    "John Doe <[email protected]>",
		To:      []string{"[email protected]"},

		// Optional.
		Bcc:     []string{"[email protected]"},
		Cc:      []string{"[email protected]"},

		Subject: "Hello, World",
		Text:    []byte("This is a test e-mail"),
		HTML:    []byte("<strong>This is a test e-mail</strong>"),
	}

	// Add attachments.
	if _, err := e.AttachFile("test.txt"); err != nil {
		log.Fatalf("error attaching file: %v", err)
	}

	if err := pool.Send(e); err != nil {
		log.Fatalf("error sending e-mail: %v", err)
	}
}

Licensed under the MIT license.

smtppool's Issues

Connections not returned to or removed from the pool may lead to dead pool

This ticket is related to the following listmonk issue. I am currently investigating the file pool.go. I suspect there may be a deadlock preventing unresponsive connections from being removed from the pool, and that as a result after dying one by one (because the SMTP Server is overloaded and cannot send messages fast enough) all the connections in the pool are actually dead ones.

This is the only way I can explain the behavior since looking at the source code, if connections were removed from the pool, a new connection would be created (which I know does not happen since the SMTP Server no longer receives any incoming connection). So far my investigations have not led me to an obvious suspect but I feel the solution lies somewhere in this file.

I will also look into whether or not there are differences with the way Linux and FreeBSD and handle locks that may lead to deadlocks in FreeBSD that wouldn't occur on Linux.

503 Sender already specified

Sometimes, when there is a lot of sending going on I get a "503 Sender already specified" from pool.Send() when the pool has been instantiated with

pool, err := smtppool.New(smtppool.Opt{
                Host:            os.Getenv("SMTP_HOST"),
                Port:            587,
                MaxConns:        10,
                IdleTimeout:     time.Second * 10,
                PoolWaitTimeout: time.Second * 3,
                Auth: smtp.PlainAuth("",
                        os.Getenv("SMTP_USERNAME"),
                        os.Getenv("SMTP_PASSWORD"),
                        os.Getenv("SMTP_HOST")),
                TLSConfig: &tls.Config{ServerName: os.Getenv("SMTP_HOST")},
        })

There seems to be some race condition going on possibly where a connection gets used by a different send request and I wonder if this explains also knadh/listmonk#300 (although I am not using listmonk, only smtppool).

I only send to only one address, but there are many send requests coming in in parallel sometimes.