Robin Whittle:
> http://tools.ietf.org/html/rfc3464#section-2.3.6
>
> diagnostic-code-field =
> "Diagnostic-Code" ":" diagnostic-type ";" *text
>
> Since the Status code
> will sometimes be less precise than the actual transport diagnostic
> code, the Diagnostic-Code field is provided to retain the latter
> information. Such information may be useful in a trouble ticket sent
> to the administrator of the Reporting MTA, or when tunneling foreign
> non-delivery reports through DSNs.
Postfix example:
Diagnostic-Code: x-unix; procmail: Lock failure on
"/u1/username/var/.procmaillock
Here, Postfix reports the error output from a command that was
unable to deliver email.
> In addition to the Diagnostic-Code itself, additional textual
> description of the diagnostic, MAY appear in a comment enclosed in
> parentheses.
Postfix example:
Diagnostic-Code: smtp; 550 5.1.1 <u...@example.com> User unknown
(in reply to RCPT TO command)
Here, the SMTP server replied with "550 5.1.1 <u...@example.com>
User unknown".
Postfix provided as additional text "(in reply to RCPT TO command)".
Such additional text is useful, for example, when the SMTP server
sends "250 Ok" in reply to DATA commands, where it is inappropriate.
> What benefits could there be to Postfix's reformatting of the
> diagnostic information?
For security reasons Postfix never presents error messages and
responses "as is" especially when information does not have a
known-to-be trusted origin. Instead, Postfix removes control and
non-ASCII characters, truncates information that exeeds some
reasonable length, and wraps long lines.
It's simple, basic stuff. I recommend that people with artistic
skills pursue opportunities in media other than mail server error
messages, because no-one wants to read those.
Wietse
