Comment by Felz | Hacker News Reader

Comment by Felz | Hacker News Reader

Parent Full thread

1. We require SPF, but don't have DKIM/DMARC yet. DKIM as far as I can tell doesn't actually... do... anything, but I need to look closer.

2. Same way anyone does it, I'd assume. Shared IPs, rate limits on sending, banning users who send spam emails. I'll likely need to hone exact approaches more.

3. Not that I know of? The mailserver I'm using might handle that.

4. Yea, fairly generic Spamassassin setup that I'm tuning.

5. I think signatures work through Roundcube, and maybe clientside encryption too.

6. I don't have SLAs yet (it's a beta!). My architecture allows for continuous deployment with no planned downtime, though. Delivery from gmail -> my servers and back seems to take about a minute as far as I know, but I can't answer the delivery time metrics without more data. You should get a bounce email on final delivery failure, which should take a maximum of about 208 minutes.

7. They're stored encrypted and compressed in S3, with an encryption key based off of a derivative of your password. Specifically: The encryption is AES/GCM with a per-message key encrypted by a libsodium crypto box, whose private key can be retrieved with a derivative of the user's password. The bucket also has AES-256 encryption in place.

Good questions! I'm going to work on documentation tomorrow. And yea, I realize that sending emails is going to suck.

Thanks for the quick and honest answers :)

About DKIM: It adds another layer of authentication to the email by adding a signature. It being absent isn't really a bad indicator, because unfortunately email headers might change during delivery. This will invalidate the DKIM signature. But it being there is a strong positive that the email comes from the domain it says it does. From another perspective: An email that might be filtered as spam without DKIM is more likely to go through with a positive DKIM result.

Don't SPF/SSL also provide proof that email comes from where it says it does? As far as I can tell, DKIM's advantage is to allow for direct message forwarding (not remailing), which is a fair use case, but pretty specific. In return it introduces a fair chunk of complexity to do right, with signing and message key rotation and keeping track of who you gave keys to.

SpamAssassin assigns small positive scores for valid SPF/DKIM/whatnot headers (and larger negative for lacking either), but it's not really an effective spam deterrant. Spammers can set up their own domains that pass all the checks (although I've heard they're having good times just sending from Gmail).

SPF authenticates the envelope-from domain, while DKIM authenticates the header-from domain. They're both useful, specially coupled with DMARC.

DMARC authorizes recipient servers to outright refuse email from your domain if it does not contain a valid DKIM signature, and/or comes from a non-authorized IP.

In short, SPF+DKIM+DMARC prevent email spoofing from your domain, protecting you from backscatter and reputation degradation.

For shared IPs -- suppose I am microsoft.com and I send official email through your service. I set my SPF record to the IP address you give me, from which all my email gets sent.

If that IP is shared, what's stopping someone else from signing up with you and then sending email that purports to come from microsoft.com?

DKIM/DMARC are fairly important. SPF, not so much, except as it pertains to DMARC.

Reply on news.ycombinator.com