On Fri, Dec 02, 2011, Wietse Venema wrote: > Will the wire protocol be: > > int32-pktlen SMFIR_PRDR int32-reply-count reply-text*
It will be your original suggestion: int32-pkt-length SMFIR_PRDR nreplies int32-rcodes*nreplies rtext*nreplies where nreplies = int32-reply-count > Where each reply text is null-terminated, and is of the form > smtp-code SP enhanced-status-code SP text > Where smtp-code is required, the other fields may be absent, and > "text" is a single line without CRLF and without special meaning > for the % character (or any character besides null). Each reply text must be formatted according to the RFCs, i.e., including CRLF and it can be multi-line: smtp-code SP enhanced-status-code SP text \r\n or smtp-code - enhanced-status-code SP text1 \r\n smtp-code - enhanced-status-code SP text2 \r\n ... smtp-code SP enhanced-status-code SP textN \r\n That is, the text can be presented "as is" to the client. Hence the MTA doesn't have to do anything extra (of course it is probably a good idea to check the syntax for correctness -- as the MTA may do for replies from an SMTP server).
