3 ms·

MX records were designed and implemented waay back when it was assumed that every new service would implement it's own super-specific (and probably binary) lay

by darkr 10y ago

MX records were designed and implemented waay back when it was assumed that every new service would implement it's own super-specific (and probably binary) layer 4 protocol rather than just defaulting to JSON over HTTP(S). In Internet time, SMTP is _ancient_.

walrus01 10y ago
SMTP is ancient and we've been piling crap on top of it for 20 years to keep it working (and all the OSI layer 5, 6 and 7 things that depend on mail continuing to flow). SPF, DKIM, DMARC, IMAP daemons that present email over TLS1.2, clamAV and realtime malware scanning/filtering, spamassassin, bayesian filtering and analysis of mail body contents, email-to-SMS gateway, SMS-to-email gateways, I could probably make this list 4x as long. But it doesn't seem to be going away anytime soon.
- emilburzo 10y ago
  I've added a new acronym to my personal mail servers over the weekend: SRS (fixes SPF when doing basic forwarding to another email address, e.g.: to gmail). And now I'm not even sure that was a correct move, since Gmail explicitly states[1] that you shouldn't change the envelope sender (which SRS does). [1] - https://support.google.com/mail/answer/175365?hl=en https://support.google.com/mail/answer/175365?hl=en
  - walrus01 10y ago
    Anything that breaks DKIM so the signature coming from your SMTPd is no longer valid, not matching the public key published in your DNS records, will make your mail MUCH more likely to be flagged as spam.
    - emilburzo 10y ago
      SRS[1] doesn't break DKIM, because the sender rewrite happens on my server, before DKIM. That's the thing, in theory I went from: spf: fail dkim: pass for forwarded mails, before SRS, to: spf: pass dkim: pass so it should be better, right? But as I said, they explicitly mention NOT changing the envelope sender (maybe they have an exception for SRS cases, but it's not documented anywhere). Oh yeah, and now I'm also responsible for any real spam forwarded to Gmail, since the From is @mydomain. [1] - http://www.openspf.org/SRS http://www.openspf.org/SRS

by darkr 10y ago

walrus01 10y ago

SMTP is ancient and we've been piling crap on top of it for 20 years to keep it working (and all the OSI layer 5, 6 and 7 things that depend on mail continuing to flow). SPF, DKIM, DMARC, IMAP daemons that present email over TLS1.2, clamAV and realtime malware scanning/filtering, spamassassin, bayesian filtering and analysis of mail body contents, email-to-SMS gateway, SMS-to-email gateways, I could probably make this list 4x as long. But it doesn't seem to be going away anytime soon.

emilburzo 10y ago
I've added a new acronym to my personal mail servers over the weekend: SRS (fixes SPF when doing basic forwarding to another email address, e.g.: to gmail). And now I'm not even sure that was a correct move, since Gmail explicitly states[1] that you shouldn't change the envelope sender (which SRS does). [1] - https://support.google.com/mail/answer/175365?hl=en https://support.google.com/mail/answer/175365?hl=en
- walrus01 10y ago
  Anything that breaks DKIM so the signature coming from your SMTPd is no longer valid, not matching the public key published in your DNS records, will make your mail MUCH more likely to be flagged as spam.
  - emilburzo 10y ago
    SRS[1] doesn't break DKIM, because the sender rewrite happens on my server, before DKIM. That's the thing, in theory I went from: spf: fail dkim: pass for forwarded mails, before SRS, to: spf: pass dkim: pass so it should be better, right? But as I said, they explicitly mention NOT changing the envelope sender (maybe they have an exception for SRS cases, but it's not documented anywhere). Oh yeah, and now I'm also responsible for any real spam forwarded to Gmail, since the From is @mydomain. [1] - http://www.openspf.org/SRS http://www.openspf.org/SRS