On Thu, Aug 16, 2001 at 10:32:03 -0300, hmh(_at_)debian(_dot_)org wrote:
On Tue, 14 Aug 2001, Byrial Jensen wrote:
Well, gettext, xgettext etc. works fine with \r even though they
complain.
They complain for a good reason. See the gettext docs.
Please tell me where in the docs I should search for the good
reason. All I found in the gettext manual about escape sequences
was the sentence:
Each of UNTRANSLATED-STRING and TRANSLATED-STRING respects the
C syntax for a character string, including the surrounding
quotes and imbedded backslashed escape sequences.
(From node "PO Files" in the info file).
However one problem exists that is not just cosmetic. The messsages
which contain \r are texts which may be mailed to the user by
fetchmail. Fetchmail delivers the e-mails generated by itself in
the same way as it delivers fetched mail. This is a problem when
the translated messages are send by for example SMTP -- the used
charset often has changed from ASCII to something else which is
illegal to send without encoding etc.
A SMTP interface is a SMTP interface. As long as you use the EOL convention
for SMTP, you're on the safe side, and MTAs that screw up on that deserve to
be "deprecated" by force.
Any non-ASCII text in mail headers should be encoded according to
RCF 2047.
And if the body of a mail message contains non-ASCII text, the
used charset should be declared in a Content-Type header and the
content encoding should be declared in a Content-Transfer-Encoding
header (unless it is 7bit which non-ASCII text seldom is)
according to RFC 2045. Additionally it may be preferable to do
Quoted-Printable or Base64 encoding of the body.
It may not be a problem for a receiving MTA if these things are
missing because the MTA don't care about the contents -- it just
transports the message.
But it certainly is a problem for the receiving MUA which must
known about charset and encoding in the received messages to
present them properly to the user.
I suppose that the best solution is /not/ to handle this in
fetchmail, but to deliver self-generated mail to a MUA which knowns
how to treat messages in the local charset.
No way. Forget it. We already had to file bugs around in Debian to get
programs to stop doing that.
Do you then want fetchmail to do RFC 2047 encoding and to add the
right MIME headers and to do body encoding? It is not simple to do
these things right, that's why I prefer to leave the task to a
specialized program, i.e. a MUA.
Programs -- even an MTA like fetchmail -- should not deliver
generated mail directly to an MTA.
Please think of the added security problems, as well as the added
reliability problems of using a MUA for that, and tell me just why should we
braindamage fetchmail like that?
Because it would be silly to reimplement something which already
are well done by other types of programs. The task of fetchmail is
to do mail transport, not to generate new mail with all necessary
encoding and headers.
No program, *especially* security daemons (which fetchmail isn't,
fortunately :P) is to use anything else than the documented, proven, and
reliable /usr/sbin/sendmail OR direct smtp/lmtp interfaces. Otherwise, you
are risking information loss on errors, security holes, etc.
I plainly disagree. It would be absurd if all mail sending
programs should know about MIME.
Best regards
Byrial Jensen