Hacker News Reader

Comment by aljones | Hacker News Reader

"Email is so important to the functioning of the Internet that it gets its own record type."

Well that is one way of looking at it. Probably the appropriate way if you're teaching, but if you want to be critical then it reeks of poor design for a particular service to get special treatment by a fundamental part of the internet. It isn't that MX records aren't needed. They just shouldn't only be useful for email.

View on HN

That's what SRV records are for. MX is just older than that convention.

Edit: And it wasn't as bad of a design decision back when changes to important network protocols was a thing that happened, not a case of the sky falling.

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_.

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.

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

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.

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

It made more sense when you could assume each machine was tended by a sysadmin who was responsible for running it, so having a quick way to reach that person in the Net's distributed "phone book" was a fairly obvious thing to do. Spam... existed, actually, but it was solved by social mechanisms. ("Hey, tell that loser to knock it off or AUP him off your system, wouldja?") DNS is old.

We no longer think of DNS as a "phone book" style directory system, and we no longer assume that every reachable machine is cared for individually.

I assume that if email was coming along today it would look more like internet telephony, which is built on things like e164 to encode addresses into DNS using A, SRV, and NAPTR as the record types.

Reply on news.ycombinator.com