And actually, this reply has to possibly be transferred to a DSN as well (see https://tools.ietf.org/html/rfc3464#section-2.3.6 ). Those diagnostic-code field values may be multiline as well, but I presume one would leave the numeric codes out.
@Stefano: Not sure if I have the time, but good tip on checking if it is a bug or not. Yours, David On 7 July 2017 at 12:28, David Hofstee <opentext.dhofs...@gmail.com> wrote: > Yes, I know. The subsequent RFCs 2821 and 5321 are equally unclear on > this, I think. > > But it is a bit weird to say the human-readable text is for humans only. > Since it is transferred via SMTP, the RFC should define how to handle it. > And it is ambiguous. I would like option 1 best. > > David > > On 7 July 2017 at 12:03, Vladimir Dubrovin <dubro...@corp.mail.ru> wrote: > >> >> Hello David. >> >> RFC 821 is outdated, use RFC 2821 as proposed or RFC 5321 as a draft for >> SMTP. Also, there is an RFC 3463, it adds extended status codes and you >> should probably read it. >> >> According to RFC, only code (and potentially extended status code) are >> intended for machine interpretation. The rest of response is a >> human-readable text, which should not be automatically interpreted. So, as >> a human, you are absolutely free to use it in any reasonable way. You can >> either leave it as is, or remove status codes, or concatenate it in the >> single line (since it's a human readable form, you should probably replace >> CRLF + status code + delimiter characters with a whitespace, because in >> human-readable form you do not expect the words to be wrapped or the lines >> to contain extra spaces). >> >> 07.07.2017 12:27, David Hofstee пишет: >> >> Hi, >> >> I've an interesting RFC question. In an SMTP reply, one can have single >> line or multiline replies. E.g. >> >> 521 single line reply >> >> or >> >> 521-Line one >> 521-Line two >> 521 Line three >> >> See also https://tools.ietf.org/html/rfc821#page-50 . >> >> My question is: The reply is an answer that is, necessarily, formatted >> for SMTP. But how should the multiline answer be interpreted? What is its >> 'value'. >> >> *option 1: Remove superfluous return codes and <CRLF>s. E.g.:* >> 521 Line oneLine twoLine three >> >> *or option 2: Remove superfluous return codes but keep <CRLF>. E.g.* >> 521 Line one >> Line two >> Line three >> >> *or option 3: Remove superfluous <CRLF>s. E.g.* >> 521-Line one521-Line two521 Line three >> >> *or option 4: Convert <CRLF>s into '\r\n' to make it a one line answer. >> E.g.* >> 521-Line one\r\n521-Line two\r\n521 Line three >> >> *or option 5: Keep everything. Eg. * >> 521-Line one >> 521-Line two >> 521 Line three >> >> The RFC does not really state that. So I am not quite sure how that >> should be logged correctly. Where the formatting starts and what 'value' it >> is supposed to represent. When I look at other standards (e.g. >> http://json.org), the formatting and what it is to represent, is more >> clear. >> >> This came up when I saw 3 different outputs in different MTA's (1,4 and >> 5). Not sure if I have to file a bugreport to my favorite MTA supplier. >> >> Can anyone say something smart about how the reply should be seen? >> >> Yours, >> >> >> >> David >> >> >> _______________________________________________ >> mailop mailing >> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >> -- >> Vladimir Dubrovin >> @Mail.Ru >> >> > > > -- > -- > My opinion is mine. > -- -- My opinion is mine.
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
