Chris's Wiki :: blog/tech/SMTPParamParsingProblem Commentshttps://utcc.utoronto.ca/~cks/space/blog/tech/SMTPParamParsingProblem?atomcommentsDWiki2014-06-04T19:07:26ZRecent comments in Chris's Wiki :: blog/tech/SMTPParamParsingProblem.By Chris Siebenmann on /blog/tech/SMTPParamParsingProblemtag:CSpace:blog/tech/SMTPParamParsingProblem:9e6136bf64633377ac43c928504dbc28a59854b6Chris Siebenmann<div class="wikitext"><p>The thing is that RFC 724 was inevitable at the time, because there
really were significant systems on the ARPANet that needed the features
it included. The big chance SMTP had to change that was with ESTMP and
EHLO; they could have said that if a system EHLO'd it could no longer
use quoted local parts or route addresses and be done with it. Old
systems on the Internet that still required them would have stuck with
HELO'ing.</p>
<p>At this point it's clear that the only way SMTP is going to be simplified
is with a new protocol definition. Revisions of SMTP are not going to
be able to throw away backwards compatibility. Unfortunately such a new
protocol definition is unlikely to ever happen.</p>
</div>2014-06-04T19:07:26ZBy Chris Nehren on /blog/tech/SMTPParamParsingProblemtag:CSpace:blog/tech/SMTPParamParsingProblem:72721dd0d40221464b4efc243cea9280e98abd69Chris Nehren<div class="wikitext"><p>No, the problem goes all the way back to RFC 724. That RFC is the source of the stench and the peril. See <a href="https://www.youtube.com/watch?v=JENdgiAPD6c">https://www.youtube.com/watch?v=JENdgiAPD6c</a> for a humorous explanation of why things are terrible. Yes, it took place at a conference in Asia, but the speaker speaks fluent English and the slides are predominantly in English.</p>
</div>2014-06-04T13:35:52ZBy Ewen McNeill on /blog/tech/SMTPParamParsingProblemtag:CSpace:blog/tech/SMTPParamParsingProblem:57f4c1e2634771ba8ae1cf3416c9ea411e6f8694Ewen McNeill<div class="wikitext"><p>It seems to me that the problem is actually RFC 5321 (and all the earlier iterations) addresses. They're OMG complex and nearly impossible to parse "properly" because of all the syntaxes they allow to be embedded. About 90% of that complexity is (almost?) completely redundant now, because all the other mail systems being gatewayed to went away, and so really only [\w.\d_+-]+@[\w.\d_-]+ gets real world usage. (If only because there are so many "that's not a valid email address" web validations that actively discourage anything else...)</p>
<p>With almost no loss in modern real world functionality you could refuse to parse addresses with, eg, spaces or ">" in them, and treat anything after either of those as parameters, and anything before as the email address. (IIRC some MTAs already take that approach anyway, refusing anything else.)</p>
<p>I do agree, however, that the "let's just tack some parameters on the end" was an unfortunate design choice. Even if "soft fail" led the designers not to want to introduce new SMTP VERBs. (Despite there being a mechanism to detect if they'd be supported -- eg EHLO vs HELO.)</p>
<p>Ewen</p>
</div>2014-06-04T10:51:03Z