Chris's Wiki :: blog/tech/SmtpResultConundrum Commentshttps://utcc.utoronto.ca/~cks/space/blog/tech/SmtpResultConundrum?atomcommentsDWiki2007-04-27T13:05:19ZRecent comments in Chris's Wiki :: blog/tech/SmtpResultConundrum.By Chris Siebenmann on /blog/tech/SmtpResultConundrumtag:CSpace:blog/tech/SmtpResultConundrum:4d5274eac49daae0ad8c9642db05d43c0eeb8447Chris Siebenmann<div class="wikitext"><p>I actually think the IETF SMTP working group is making the right choice
from both a standards perspective and a pragmatic perspective.</p>
<p>Clearly the existing specification is ambiguous for clients, so either
choice is valid and there are clients that do both. In this case it is
wrong to change the specification so that half of the clients are now
suddenly wrong; it is better to formally insist that both can be right,
especially if it was the intent all along that multi-line responses
need to use the same response code on each line.</p>
<p>From a pragmatic perspective, there are popular clients that do both
out in the field now. Even if a new SMTP RFC was issued tomorrow that
mandated one or the other, it would be years before even the majority
of those clients were updated, so the most useful thing to tell server
implementors is 'you must make all of the response codes the same, or
you will see explosions'.</p>
</div>2007-04-27T13:05:19ZFrom 68.215.50.125 on /blog/tech/SmtpResultConundrumtag:CSpace:blog/tech/SmtpResultConundrum:63da395475ffc70c8ef5349d4d08e1d873c1e1b0From 68.215.50.125<div class="wikitext"><p>Chris, </p>
<p>I wish I would of found your blog LAST WEEK!! I could of used you to second the issue regarding mixed codes in multiline responses. Like you, I was surprise to find EXIM reading the first code, not the last.</p>
<p>Like you, the RFC821 and RFC2821, both provides an interpretation that the LAST CODE is what is important and that all systems operated in the same manner.</p>
<p>In our case, we wanted to use 150- lines to help keep MUA clients alive during long mail processing jobs. For example, this works with most MTA and MUAs:</p>
<pre>
C: DATA
S: 354 Start sending email
C: [upload data]
S: 150-Please Wait... (50 secs)
S: 150-Please Wait... (100 secs)
S: 250 Message Accepted
</pre>
<p>Unfortunately, as we found out in the IETF SMTP working group discussion the update to RFC 2821BIS, it is not only EXIM, but QMAIL and other servers out there that have the same first code reading.</p>
<p>Thus it was deemed more important to correct the specification with new clarifying text that says all reply codes in multi-line response MUST be the same.</p>
<p>You should probably join the IETF-SMTP working group to get your input on the specification before it goes to draft. But you better hurry.</p>
<p>Here is a link to the current RFC2821bis draft:</p>
<p><a href="http://tools.ietf.org/html/draft-klensin-rfc2821bis-03">http://tools.ietf.org/html/draft-klensin-rfc2821bis-03</a></p>
<p>---
Hector Santos, CTO
Santronics Software, Inc.
<a href="http://www.santronics.com">http://www.santronics.com</a></p>
</div>2007-04-26T16:18:21ZBy Chris Siebenmann on /blog/tech/SmtpResultConundrumtag:CSpace:blog/tech/SmtpResultConundrum:dd70a5d5ec33eaab2a344fcfbd54d34b0a8363b7Chris Siebenmann<div class="wikitext"><p>I think I will say a heartfelt 'augh' at that code. I had no idea anyone
would do that (especially in what looks like real and serious code),
although I suppose I really shouldn't be too surprised.</p>
<p>(In this particular case we were actually generating multiple continued
lines, all with <code>250-</code> at the front, so that code still wouldn't get it
'right'.)</p>
<p>I suppose one good thing about ESTMP is that anyone who tries to use it
can't help but be aware of multiline replies, since multiline replies
from <code>EHLO</code> are routine.</p>
</div>2006-12-18T19:34:44ZBy DanielMartin on /blog/tech/SmtpResultConundrumtag:CSpace:blog/tech/SmtpResultConundrum:2656d57b72af3d385b933bbc863d3d8ff8042c97DanielMartin<div class="wikitext"><p>See, if I were writing a truly naive client, I would accept the first line's status code, and then accept the second line as the response to my RCPT TO, which would, in this case, result in vaguely acceptable behavior. (try again later)</p>
<p>I wouldn't be surprised if various spamming programs shared this behavior. In fact, <a href="http://www.google.com/search?q=%22RCPT+TO%22+socket+inurl%3A.pl">Googling for "RCPT TO" in perl scripts</a> leads me to believe that this pattern of coding is pretty common. Most people don't write code assuming multi-line replies.</p>
</div>2006-12-13T20:06:41ZBy Dan.Astoorian on /blog/tech/SmtpResultConundrumtag:CSpace:blog/tech/SmtpResultConundrum:0e861b83d9e76a128d93c2db41a56d8b8878ebd2Dan.Astoorian<div class="wikitext"><blockquote><p>In a multiline SMTP reply, which reply code should you use if different lines of the reply have different codes?</p>
</blockquote>
<p>As a matter of principle, IMHO, you <em>should</em> use <em>neither</em> code if you detect this condition. You should conclude that the server you're talking to is not speaking SMTP after all or has lost its mind, terminate the operation and the connection, and do whatever you would have done (such as falling back to the next MX host) if, <em>e.g.</em>, the server had closed the connection without warning.</p>
<p>However, practically speaking, one should not expected to detect this condition, let alone anticipate it, and one may reasonably use whichever code is programmatically expedient, and blame the server for any consequences that result. It's the client's job to comply with the standard, not to enforce it.</p>
<blockquote><p>(Sending such a multiline reply is not spec compliant, but our core mailer is held together by bailing wire and chewing gum, so these things surface every so often.)</p>
</blockquote>
<p>Although that explains the behaviour, it does not excuse it. (I know whereof I speak--I used to maintain that particular wad of chewing gum, before cks replaced the sticky tape with bailing wire.) As it usually does, it comes down to a fairly straightforward choice: fix (or at least improve) the behaviour, or tolerate the consequences. Figuring out what the SMTP client "should" do in the face of insane server behaviour amounts to blaming the victim.</p>
<p>--Dan</p>
</div>2006-12-13T15:23:57Z