Some considerations related to the double opt-in signup script:
- This is written in Bash, a common linux/unix scripting language.
- There are variables near the top that you will need to edit to specify things like the name of your list, the email address to send from, etc.
- You can block various domains, usernames and email addresses using the BADDOMS, BADUSERS and BADEMAILS variables.
- There are a few lines you can comment out to disable things like the unsub notification email, DNS checks, and the new subscriber notification email. Search for the word "comment" to find these points.
- Email authentication is a function of your mail server and DNS configuration in this context, not my script. Meaning my script does not add SPF or DKIM or DMARC -- you add these by way of configuring DNS and your mail server for your domain.
- You can look at the gen_code subroutine if you want to modify the way the opt-in link looks. Be careful not to make it so simple that anybody could manipulate a URL to cause a forged opt-in subscription.
- To export subscribers, use this script. It reads the log, exporting every person whose current status is "subscribed."
- I think this process of using a log file and finding status via the log file is a clunky-but-good-enough way to manage a database without actually using a database. You could implement a SQL database to track active subscriptions and logs if you like, but I wanted to minimize my reliance on additional tools for this particular project.
- The script generates fairly long/random opt-in URL codes. This is to prevent opt-in forgeries. You don't want people to be able to "hack" URLs to cause forged subscriptions or even forged unsubscribes. For this reason, you should never expose the email address in the opt-in URL.
- My opt-in URLs don't expire. Maybe they should, and maybe they will in a future update.
- To prevent "opt-in confirmation bombing," this tool allows a user to re-request an opt-in confirmation twice, for a total of three opt-in confirmation emails. After that it won't send you another. If you subscribe, then later unsubscribe, the counter is reset and you could receive three more. That way it allows re-sends for users who might resubscribe in the future.
- The script checks subscriber domain validity by matching the TLD against a fixed list of TLDs. This will eventually go out of date as somebody adds the latest new, weird TLD to the world, but is probably good enough for government work. It is unlikely that anyone with an email address of email@example.com is going to try to sign up for your list, even if "dot squirrelunderpants" ends up being a valid TLD in the future. I suppose I could do a live call out to the IANA TLD list, but why add the network noise?
- The script also requires that the sending domain have a valid MX record or A record. If it doesn't, mail won't be accepted anyway, so why bother sending a confirmation mail? Similarly, it looks for an SPF record that suggests that a domain sends no mail. A domain configured like that isn't likely to have valid users who want to receive your mail. A lot of spamtrap domains are configured this way; let's not bother them with confirmation requests.
Anyway, the reason I put all this together was just to remind myself that double opt-in isn't hard. I hacked this script together over a few hours here and there last weekend, and somebody putting more time, effort and planning into it could do a better job than I do. You could take this script and use it to manage signups for your list, and know that every signed up address has been properly validated, accurate and truly opted-in, without spending a dime on an external vendor.
(Updated 3/2/2020: I've renamed the list management tool "WombatMail," since it's a domain name I've had forever but do very little with.)