[DONOTMERGE] Add the ability to keep mail delivery under a threshold (rate limit) and resend when the relay falls below the threshold again.

[barais]

When you have a huge amount of mail to deliver, you can't release the queue at once and let the server maximize the outgoing mail throughput ! The result will be: you'll get blacklisted from a lot of MX servers.
That's why you should take care of it and do traffic shaping

Many smtp providers (even those from universities) impose threshold values in terms of the number of messages sent per (message/mins or per message/hour) and the number of recipients...

As a result, it is sometimes required to stay below these thresholds. Particularly when emails are sent by applications. This PR provides a small extension to this great smtprelay project to add this feature. I don't think this PR should be merged because it goes against the original spirit of keeping the code very small without too many dependencies. The idea of the PR is undoubtedly to keep a history of this addition, which is so useful to others, but it can be closed without comment.

[1] #155
[2] Dependencies to otter and go-limiter
[3] Close to https://wiki.deimos.fr/Postfix:_limit_outgoing_mail_throttling

[decke]

Thanks for the PR! Ratelimiting is definitely a case where smtprelay is not the right tool anymore. One of the main concepts is to be as transparent as possible so it needs to forward any errors from upstream SMTP and should not store & forward mails at all. Following that principle if the upstream SMTP decides to ratelimit us we just forward the error to the client and it's the clients task to handle this (eg. retry later).

Theoretically one could write a smtpqueue which does exactly the opposite: receive the mail, store it locally, try to periodically send it to the STMP server (respecting ratelimits, handle errors etc.) - but then you're basically a classic MTA.

[decke]

I still think ratelimiting could be useful and fit into smtprelays design but then in a way that we just block the client for a short period (eg. seconds) before we contact the upstream SMTP. From a concept point of view this might fit very well into the connectionChecker to block before the HELO message.