fetchmail-friends
[Top] [All Lists]

Re: [fetchmail]'\r' in internationalized messages (was: Security patch to gold version?)

2001-08-18 18:13:59
On Thu, 16 Aug 2001, Byrial Jensen wrote:
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:

(looks through the entire damn info docs for gettext)

Ugh, can't find the passages I was (mis?)remembering when I said that. There
is no direct "don't do that" advice, but the docs do warn one should keep
the stuff sent to gettext as agnostic as possible to avoid trouble; Adding
control characters other than \n (and maybe even that, in specific cases) is
usually a bad idea.

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.
[...]

Yes, you're right on that. I was concentrating in the EOL conventions, and
missed the obvious fact.

Maybe it is time to update the entire gettext support in fetchmail to the
new GNU gettext releases, flush the horrid tales of horror caused by gettext
braindamaged in intl/* (which are fixed in newer GNU gettexts) drown the
drain, drop in proper plural handling (I can already see the complains THAT
one will generate), AND address the charset issue.  We should also drop any
claims to support non-gnu gettext while at that, IMHO.

New GNU gettext can, and does full charset conversion, so one CAN know
beforehand (and even force) which charset gettext will generate, regardless
of which charset was used in the .po file for that particular language.

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

It is the only sane way, unfortunately.  Either that, or stick to plain
US-ASCII for error messages sent to the MTA.  

One could generate the RFC2047-encoded localized messages from .po files at
build time, and store them already pre-encoded, and THAT could make use of a
MUA (find me one which will work on every system and do that encoding
reasonably... I don't think that will be possible), or a MIME-convertion
package to do the encoding (safer, if we can find one that will do the job).

Because it would be silly to reimplement something which already
are well done by other types of programs. The task of fetchmail is

Sorry, that is not an acceptable option IMNSHO. The correct answer is to
either have that in a library, or to do it at build-time.

I plainly disagree. It would be absurd if all mail sending
programs should know about MIME.

Well, then they should not attempt to send non-7-bit-clean, non-USASCII text
over the wire.  Ugly? I certainly think so. I don't claim to like the utter
ugly text I send down the wire when I'm writting in portuguese [after the
MIME encoding]...  fortunately almost all the software in my system can do
MIME right.

Isn't there a library out there with proper MIME handling functions?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh