From owner-freebsd-questions Mon Dec 2 1:55: 4 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07D8237B401 for ; Mon, 2 Dec 2002 01:55:02 -0800 (PST) Received: from bellavista.cz (mail.bellavista.cz [62.168.44.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B87B743EF4 for ; Mon, 2 Dec 2002 01:54:57 -0800 (PST) (envelope-from neuhauser@bellavista.cz) Received: from lilith.bellavista.cz ([10.1.0.1]) by bellavista.cz (8.9.3/8.9.8) with ESMTP id KAA24358; Mon, 2 Dec 2002 10:54:31 +0100 Received: from freepuppy.bellavista.cz (freepuppy.bellavista.cz [10.0.0.10]) by lilith.bellavista.cz (Postfix) with ESMTP id 8E6F628; Mon, 2 Dec 2002 11:52:47 +0100 (CET) Received: by freepuppy.bellavista.cz (Postfix, from userid 1001) id 1E1BE2FDAE4; Mon, 2 Dec 2002 10:54:30 +0100 (CET) Date: Mon, 2 Dec 2002 10:54:30 +0100 From: Roman Neuhauser To: "Gary W. Swearingen" Cc: freebsd-questions@FreeBSD.ORG, Giorgos Keramidas Subject: Re: Find abandoned packages Message-ID: <20021202095429.GI86826@freepuppy.bellavista.cz> Mail-Followup-To: "Gary W. Swearingen" , freebsd-questions@FreeBSD.ORG, Giorgos Keramidas References: <000801c2915e$be8907c0$6400a8c0@windows> <9eel9eaber.l9e@localhost.localdomain> <20021125091339.GR77198@freepuppy.bellavista.cz> <20021126065739.GL77198@freepuppy.bellavista.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG # swear@attbi.com / 2002-11-26 13:41:36 -0800: > Roman Neuhauser 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