Document alternative outgoing email approaches

[adehnert]

At the moment, outgoing email from scripts is unreliable. Hopefully something like #357 could improve that. In the short term, and possibly even once #357 gets fixed, users may be better served by sending their email in other ways. We should ideally document some options.

The obvious option is to tell people to use Kerberized auth to outgoing.mit.edu. It's an obvious, MIT-run service that (hopefully) has good deliverability, and I believe any principal can auth. However, I think many languages have mediocre support for Kerberized SMTP, so it may be hard to for our users to do this.

There are also various companies that provide this sort of service. Some options are:

• SparkPost?, which supports both a ​custom API and SMTP and ​allows 10K emails/month for free
• SendGrid?, which also has ​an API and SMTP support and ​seems to have a free 12K emails/month tier
• Mandrill/MailChimp?, which also has ​API/SMTP support, but appears to have a ​2K emails/account limit for the free trial, after which it's ​$10/month

These have the advantage of probably being easier to set up than kerberized outgoing.mit.edu and likely having better deliverability, but disadvantage of requiring a non-MIT party and having a lower free message cap (I think MIT is effectively 1K/day so ~30K/month).

[andersk]

Other alternatives include

• Unauth through outgoing.mit.edu:25 (should be trivial to set up and will likely still be more reliable than Scripts direct delivery).
• Get a Gmail account and send through smtp.gmail.com.

It should be noted that claiming a @mit.edu from address and sending through a mail server other than outgoing.mit.edu will trigger an SPF softfail, which may be used as a spam signal independent of the mail server’s reputation. (Does not apply to @scripts.mit.edu; see #129 for that.)

[leee]

I think this should do it: ​https://scripts.mit.edu/faq/160/how-can-i-reliably-send-email-from-scripts