4 ms·

@supermatt you really get this stuff. Is there an OReilly (or other) book you'd recommend, or is all this knowledge part of the vast, distributed online corpus

@supermatt you really get this stuff. Is there an OReilly (or other) book you'd recommend, or is all this knowledge part of the vast, distributed online corpus of IETF RFCs and StackOverflow questions?

KronisLV 6y ago
Agreed, any links (or references to books) about the subject matter would be helpful! At this point i feel like a lot of e-mail related topics are full of "unknown unknowns" to me and many other developers. It's hard to say whether we're missing bits of information that are considered common knowledge or maybe e-mail related development doesn't have enough discoverability (like blog posts, tutorials and so on) to make it easier, like configuring HTTPS in Apache2/httpd would have. Or maybe the whole domain is just full of inherent complexity due to its history (SPF, DKIM, DMARC etc.).
- supermatt 6y ago
  SPF, DKIM and DMARC arent really that complex. > SPF Is the relay authorised for this domain > DKIM Which domain(s) authored/approved this email > DMARC Formalises some behaviours for the above + reporting Much of this is to prevent a bad actor sending out emails from a domain they do not control (i.e. prevent spoofing). The REAL problems with email come with deliverability. Basically an MTA not forwarding or accepting mail from you. This can be for a variety of reasons: you are misconfigured, they are misconfigured, one of your relays is on a blocklist, your relay exceeds a rate limit, your emails exceed some spam score, etc. This is the stuff that makes service management painful. For example, gmail may give you a few "spam points" for sending them more email than they are used to from your relay - this means your emails end up in spam, get bounced and requeued for delivery (if you are configured correctly!), outright refused, or even mysteriously blackholed. It takes time to build reputation in that respect. Emails may be marked as spam by recipients, which can further tarnish your relays reputation with that provider (potentially multiple if they share reports with other providers). Using an IP with a history of abuse, or having bad neighbours on your subnet, or having emails flagged with a spam reporting service can result in you being added to blocklists - requiring you to be vigilant in log monitoring, postmaster duties, etc. Email isnt difficult, its just that bad actors have meant that you need to establish a positive reputation, rather than simply avoiding a bad one if you want to send any realistic volume of email to a large provider. DMARC/SPF/DKIM are intended to give accoutability in order to establish domain-based, rather than relay-based reputation - but ultimately its up to the receiving provider (and occasionally 3rd party relays, depending on your setup) how they handle it.
supermatt 6y ago
The RFCs are the best bet. They arent really that "distributed". The current definitive reference for DKIM is https://tools.ietf.org/html/rfc6376 https://tools.ietf.org/html/rfc6376. Theres also an "official" website at http://www.dkim.org http://www.dkim.org. Other RFCs are either obsolete, or talk about some crypto specifics. All you really need to know is that DKIM signs the message to prevent tampering. This includes the content and "from" header (optionally other stuff). Anyone can sign it, but its up to the verifier to decide which of the signatories to "trust". For example, you dont NEED to sign with the senders domain key, which is why google is flagging this 3rd party signature with some custom UI. DMARC formalises this with identifer alignment, to ensure that a signatories domain key matches the "from" address domain.

KronisLV 6y ago

Agreed, any links (or references to books) about the subject matter would be helpful! At this point i feel like a lot of e-mail related topics are full of "unknown unknowns" to me and many other developers. It's hard to say whether we're missing bits of information that are considered common knowledge or maybe e-mail related development doesn't have enough discoverability (like blog posts, tutorials and so on) to make it easier, like configuring HTTPS in Apache2/httpd would have. Or maybe the whole domain is just full of inherent complexity due to its history (SPF, DKIM, DMARC etc.).

supermatt 6y ago
SPF, DKIM and DMARC arent really that complex. > SPF Is the relay authorised for this domain > DKIM Which domain(s) authored/approved this email > DMARC Formalises some behaviours for the above + reporting Much of this is to prevent a bad actor sending out emails from a domain they do not control (i.e. prevent spoofing). The REAL problems with email come with deliverability. Basically an MTA not forwarding or accepting mail from you. This can be for a variety of reasons: you are misconfigured, they are misconfigured, one of your relays is on a blocklist, your relay exceeds a rate limit, your emails exceed some spam score, etc. This is the stuff that makes service management painful. For example, gmail may give you a few "spam points" for sending them more email than they are used to from your relay - this means your emails end up in spam, get bounced and requeued for delivery (if you are configured correctly!), outright refused, or even mysteriously blackholed. It takes time to build reputation in that respect. Emails may be marked as spam by recipients, which can further tarnish your relays reputation with that provider (potentially multiple if they share reports with other providers). Using an IP with a history of abuse, or having bad neighbours on your subnet, or having emails flagged with a spam reporting service can result in you being added to blocklists - requiring you to be vigilant in log monitoring, postmaster duties, etc. Email isnt difficult, its just that bad actors have meant that you need to establish a positive reputation, rather than simply avoiding a bad one if you want to send any realistic volume of email to a large provider. DMARC/SPF/DKIM are intended to give accoutability in order to establish domain-based, rather than relay-based reputation - but ultimately its up to the receiving provider (and occasionally 3rd party relays, depending on your setup) how they handle it.

supermatt 6y ago

The RFCs are the best bet. They arent really that "distributed". The current definitive reference for DKIM is https://tools.ietf.org/html/rfc6376 https://tools.ietf.org/html/rfc6376. Theres also an "official" website at http://www.dkim.org http://www.dkim.org. Other RFCs are either obsolete, or talk about some crypto specifics. All you really need to know is that DKIM signs the message to prevent tampering. This includes the content and "from" header (optionally other stuff). Anyone can sign it, but its up to the verifier to decide which of the signatories to "trust". For example, you dont NEED to sign with the senders domain key, which is why google is flagging this 3rd party signature with some custom UI. DMARC formalises this with identifer alignment, to ensure that a signatories domain key matches the "from" address domain.