Date: Mon, 2 Dec 2002 10:54:30 +0100 From: Roman Neuhauser <neuhauser@bellavista.cz> To: "Gary W. Swearingen" <swear@attbi.com> Cc: freebsd-questions@FreeBSD.ORG, Giorgos Keramidas <keramida@ceid.upatras.gr> Subject: Re: Find abandoned packages Message-ID: <20021202095429.GI86826@freepuppy.bellavista.cz> In-Reply-To: <a44ra46mb3.ra4@localhost.localdomain> References: <000801c2915e$be8907c0$6400a8c0@windows> <9eel9eaber.l9e@localhost.localdomain> <20021125091339.GR77198@freepuppy.bellavista.cz> <tpfztp8m6a.ztp@localhost.localdomain> <20021126065739.GL77198@freepuppy.bellavista.cz> <a44ra46mb3.ra4@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
# swear@attbi.com / 2002-11-26 13:41:36 -0800:
> Roman Neuhauser <neuhauser@bellavista.cz> writes:
>
> > 4. You have already shown that you (falsely) think MIME email ==
> > HTML email.
>
> I surely didn't think that, but HTML was all I mentioned because I did
> (falsely) think that MIME email was almost always either HTML or
> complex stuff like MSFT Word or multipart things with images, etc. I
> didn't know it could be as simple as a non-MIME message with a
> "MIME-Version: 1.0" header inserted, with or without a
> "Content-type: text/plain; charset=something" header.
>
> Per your suggestion, I've just read some of RFC-2045, but not all 31
> pages or the several other RCFs which are essentially parts of it.
> But I think I've learned a few things new to me and, apparently, you.
not so new, but I obviously misread the 8BITMIME stuff in RFC 2821
(which obsoletes 821).
also, see e. g. SevenBitInput and EightBitMode Sendmail options.
> > AFAIK, this has changed with MIME. RFC 822 restricts email messages
> > to 7 bits (ASCII), ...
>
> Looks like we're both wrong, if non-STMP MTAs are allowed. MIME hasn't
> changed anything at the level I was thinking about (MTA) -- after MIME
> encoding, if any.
>
> First, both non-MIME and MIME messages MUST have only 7-bit data if they
> want to get thru a SMTP system. RFC-2045 says:
>
> RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with
> lines no longer than 1000 characters including any trailing CRLF line
> separator.
RFC 2821:
The [SMTP BODY] content is textual in nature, expressed using the
US-ASCII repertoire [1]. Although SMTP extensions (such as
"8BITMIME" [20]) may relax this restriction for the content body,
and:
Eight-bit message content transmission MAY be requested of the
server by a client using extended SMTP facilities, notably the
"8BITMIME" extension [20]. 8BITMIME SHOULD be supported by SMTP
servers. However, it MUST not be construed as authorization to
transmit unrestricted eight bit material. 8BITMIME MUST NOT be
requested by senders for material with the high bit on that is not
in MIME format with an appropriate content-transfer encoding;
servers MAY reject such messages.
> > BTW, RFC 2045 specifies a way to pass non-ASCII messages through
> > MTA's that assume all-ASCII world: the Content-Transfer-Encoding
> > header.
>
> Yes. The default MIME encoding is none; the message must be 7-bit clean
> for SMTP MTAs. The offending message used "quoted-printable" which is
> almost like 7-bit, except that 8-bit characters (and a few 7-bit'ers)
> are encoded as "=#", where "#" is the 8-bit value encoded as two ASCII
> HEX digits. (The offending message had that OK.) A more reliable
> (but unreadable) 7-bit encoding is "base64".
I know both q-p and base64. BTW, did you know that MSFT messaging
programs use one or the other based on a handful of criteria? The
content doesn't seem to matter, however. I haven't reliably tracked
the decision process down, yet.
> Other encodings allow for encodings to 8-bit data, no encoding, etc.
>
> There's a whole other aspect of this that deserves mention. Even if
> MSFT software worked correctly, telling the truth about its weird
> character set and properly encoding it, it's unlikely that my MUA
> (Xemacs) would know how to decode it properly. If it did, it would need
> to either decode to the original weird character and support the display
> of that, or translate the decoded character set to some other character
> set, like probably Unicode. (Which Xemacs might even support, I don't
> know -- I HAVE noticed that has started displaying trademark symbols,
> for instance where it probably used to show it as an octal number
> (\###).)
Mutt has IIRC provisions to get around this drain bamage: you can
tell it to display messages from a particular messaging software
that claim to use charset X using charset Y.
I don't use this feature, though.
--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021202095429.GI86826>