Opened 9 years ago
Closed 8 years ago
#420 closed task (fixed)
Document alternative outgoing email approaches
Reported by: | adehnert | Owned by: | leee |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Keywords: | ||
Cc: |
Description
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).
Change History (3)
comment:1 Changed 9 years ago by andersk
comment:2 Changed 8 years ago by leee
- Owner set to leee
I think this should do it: https://scripts.mit.edu/faq/160/how-can-i-reliably-send-email-from-scripts
comment:3 Changed 8 years ago by leee
- Resolution set to fixed
- Status changed from new to closed
Other alternatives include
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.)