5 ms·

"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 w

by aljones 10y ago

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

forgottenpass 10y ago
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.
aarmenaa 10y ago
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.
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
cbd1984 10y ago
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.

by aljones 10y ago

forgottenpass 10y ago

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.

aarmenaa 10y ago

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.

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

cbd1984 10y ago

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.