From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57201 Path: main.gmane.org!not-for-mail From: Matthias Andree Newsgroups: gmane.emacs.gnus.general Subject: Re: mx.gnus.org being very strict Date: Mon, 03 May 2004 20:13:32 +0200 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <87ad0p4p57.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083608058 25937 80.91.224.253 (3 May 2004 18:14:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 May 2004 18:14:18 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M5741@lists.math.uh.edu Mon May 03 20:14:07 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKhx8-0000S8-00 for ; Mon, 03 May 2004 20:14:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BKhwq-0000FI-00; Mon, 03 May 2004 13:13:48 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BKhwm-0000FD-00 for ding@lists.math.uh.edu; Mon, 03 May 2004 13:13:44 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BKhwl-0007Vj-7u for ding@lists.math.uh.edu; Mon, 03 May 2004 13:13:43 -0500 Original-Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by justine.libertine.org (Postfix) with ESMTP id 2D7AE3A021D for ; Mon, 3 May 2004 13:13:42 -0500 (CDT) Original-Received: from m2a2.dyndns.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 417782ABAC; Mon, 3 May 2004 20:13:36 +0200 (CEST) Original-Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id EF15FBBF4B; Mon, 3 May 2004 20:13:34 +0200 (CEST) Original-Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09192-01; Mon, 3 May 2004 20:13:33 +0200 (CEST) Original-Received: by merlin.emma.line.org (Postfix, from userid 500) id EBE81BBF23; Mon, 3 May 2004 20:13:32 +0200 (CEST) Original-To: Miles Bader In-Reply-To: <87ad0p4p57.fsf@tc-1-100.kawasaki.gol.ne.jp> (Miles Bader's message of "03 May 2004 22:27:16 +0900") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) X-Virus-Scanned: by amavisd-new at m2a2.dyndns.org Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57201 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57201 Miles Bader writes: > Matthias Andree writes: >> Is there any difficulty with creating a custom header such as: >> >> To: destination@dd.re.ss >> Subject: my subject >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 8bit >> Content-Type: text/x-patch; charset="utf-8" > > I suspect that there is no coherent `charset' for the patch; it's just > bytes. Make the Content-Type: application/octet-stream when no information is available, or text/x-patch; charset="x-unknown". > Anyway, you know the old rule: be conservative in what you produce, > and liberal in what you accept. So yeah, it'd be nice if everyone > would use lots of headers, but rejecting mail outright because there > are no mime-headers on 8-bit mail is a bit overly strict. Well, if they are going to emit ("produce" doesn't seem right) the stuff they have accepted verbatim, accepting junk means producing junk, breaking the "conservative in what you produce" part. Gateways, Relays always face this problem. Accept liberally and emit garbage, or accept only conforming mail and emit conservatively formatted data. > It's the MUA and the recipient that are going to have a problem with the > email, if there is one -- and for the same reason, they're also the best > placed to judge whether there _is_ a problem. The standards "mail is 7-bit" have been in effect since 1982 and haven't changed, so you must not generate a patch that doesn't fit into 7-bit encodings in the first place (that's what uuencode used to be good for). If you want to overcome the 7-bit restriction, you MUST follow the standards, i. e. RFC-2045..2049. Anything outside this is certainly not "conservative". Only applying the robustness princible to the transports and not to the source and sink does not count. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95