Hi Wietse,
You wrote:
>> 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.
I think that for reasons of security - or trying to prevent
undesirable outcomes for human readers and software - which
would result from badly or maliciously designed remote server
error messages, it would suffice to:
1 - Remove any non-printing character except newlines,
perhaps a tab to a space.
2 - Wrap lines longer than 80 characters or so.
3 - Truncate to some not-unreasonable length limit, such
as 2k bytes.
This would get rid of tabs, backspaces, isolated CRs or LFs etc.
I don't see any benefit in removing newlines.
Your current code, which I think is in:
/bounce/bounce_notify_util.c bounce_diagnostic_log()
or perhaps another function which also has the comments:
/* Append a human-readable copy of the delivery error log.
* . . .
*/
Removes newlines, wraps at 80 columns and adds four spaces to
the start of the second and subsequent lines which result.
I don't understand how these extra actions improve security.
It would typically have the effect of making the resulting text
harder to read by humans and harder to parse by software.
I think Postfix would be better if it did just points 1, 2 and 3
above. Then, like qmail, it would communicate any reasonably
written diagnostic information to end-user without any changes.
> It's simple, basic stuff.
I think the current code goes beyond this - by removing newlines
and adding indentation.
You might think this looks better, from some kind of artistic or
layout perspective. But in the example I cited, the current
Postfix code disrupts the ability of the rejecting MTA to
communicate with the human sender about why the message was
rejected.
I tried sending a message to k...@denninger.net from a Microsoft
server and it also failed to produce a suitably communicative
email back to the sender. It simply included the first
diagnostic line, which is much more disruptive than the current
behaviour of Postfix.
> I recommend that people with artistic
> skills pursue opportunities in media other than mail server error
> messages, because no-one wants to read those.
I don't see what this sentence has to do with an MTA providing
informative diagnostics.
I, for one, want to read diagnostics verbatim, without something
in the middle - Postfix, or a Microsoft server - reformatting or
truncating the diagnostic, other than to wrap long lines and
remove non-printing characters other than newlines. Surely the
same would be true for many end-users and system administrators.
Also, for any software which attempted to use the diagnostics,
MTAs which concatenating lines, add spaces or needlessly truncate
the text is will make the task more complex and error-prone.
My desire for transparency in the reporting of MTA diagnostics
goes beyond what is required by the RFCs.
I don't see any benefit in the extra functions the current code
performs, so I don't understand what security or other problems
would arise if Postfix behaved like qmail in this regard.
- Robin
