Subject: Multiline error reports are an interoperability problem ?

From: [email-masked]
Date: Thu, 22 Apr 1999 18:24:41 +0300 (EET DST)

Hi,

	A ZMailer user reported problem with MS Outlook (didn't specify
	version, or other details), and it got me thinking about how
	obscure the part about multiline replies has been at RFC 821
	(Appendix E) -- but I find no fault in it...

	... however comparing that to smtpupd-10 draft leaves me a bit
	worried, the presentation layout feels quite messy when compared
	to 821 -- same text, just different layout.

	I suppose this multiline reply thing is a topic for interoperability
	test suites ?

/Matti Aarnio <[email-masked]>

> Connected to mail.onet.pl.
> 220 mail.onet.pl ZMailer Server 2.99.49p9 #1 ESMTP ready at Thu, 22 Apr 1999 15:38:24 +0200
> helo
> 250 mail.onet.pl expected "HELO mail.onet.pl"
> mail from: <underley@wdffwe4 werwer.pl>
> 501-5.5.2                     ^
> 501 5.5.2 Path data: Extra garbage before terminating ">"
> 
> Ok, but in some stupid programs, for example MS Outlook,
> this generate error like "0x800xxxxxx".
> 
> How to switch off this veryfication ?

	Hmm..  This one you can't configure away.
	Of course M$ is now telling people that "Outlook is available
	for free" (and all bugs in it are included in the price..)

	I have heard that MS Outlook is *not* the only email "client"
	with this same problem, and that for some reason a multiline
	error reply is prone to blow up various "clients" -- and that
	ZMailer appears to be the only server doing them, while RFC 821
	clearly specifies them..
....

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Apr 1999 15:50:43 -0000

> 	I suppose this multiline reply thing is a topic for interoperability

From http://pobox.com/~djb/proto/smtp/request.html:

   A few clients are unable to handle responses longer than one line to
   verbs other than EHLO, HELP, and EXPN, even though RFC 821 permits
   multiple-line responses under all circumstances. Simeon 4.1.5 is
   unable to handle a multiple-line greeting. I recommend that servers
   use one-line responses whenever possible.

---Dan

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Apr 1999 11:13:32 -0400

> 	to 821 -- same text, just different layout.

I'll see if that can be improved as I finish up -11.  But
the rule has been there forever.  As Dan points out, 
there is no need to tempt fate by sending these things 
when not needed, but any client that doesn't handle them 
is pretty badly broken.

The example given, of a multiline response with no 
real textual information in the first line, is certainly 
in bad aesthetic taste and even more fate-tempting than a
simple (more conventional) multiline reply.  This sort of
thing --not using multiline replies when they are not 
needed and avoiding lines with no text, multiline or 
not-- is precisely the sort of thing "conservative in 
what you send" is intended to recommend against.

What is obviously expected here by the server implementor
is that the user will be conducting a dialogue with the 
server in a way that causes sending and receiving lines 
to be aligned on the page/screen.  Maybe some log 
formats, but, in general, a silly assumption.

Incidentally, if the client being used here is actually 
putting out

> > mail from: <underley@wdffwe4 werwer.pl>

It has multiple stupid problems/bugs in addition to 
difficulties with multiline responses.

> 	ZMailer appears to be the only server doing them, while RFC 821

Multiline responses are essentially required to EXPN (if it is 
supported meaningfully) and EHLO, common to VRFY, and at least 
used to be not unusual in various intended-to-be-helpful "bad 
address" reports.

   john