From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/22146 Path: main.gmane.org!not-for-mail From: Stainless Steel Rat Newsgroups: gmane.emacs.gnus.general Subject: Re: bad (i.e. serious) mail problems Date: 30 Mar 1999 19:30:25 -0500 Organization: The Happy Fun Ball Brigade Sender: owner-ding@hpc.uh.edu Message-ID: References: <99Mar30.101000est.13914-3@gateway.intersys.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035160119 26609 80.91.224.250 (21 Oct 2002 00:28:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:28:39 +0000 (UTC) Return-Path: Original-Received: from farabi.math.uh.edu (farabi.math.uh.edu [129.7.128.57]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA23114 for ; Tue, 30 Mar 1999 19:32:56 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by farabi.math.uh.edu (8.9.1/8.9.1) with ESMTP id SAB19711; Tue, 30 Mar 1999 18:31:31 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 30 Mar 1999 18:31:33 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id SAA15469 for ; Tue, 30 Mar 1999 18:31:18 -0600 (CST) Original-Received: from peorth.gweep.net (ratinox@adhara.ccs.neu.edu [129.10.116.158]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA23072 for ; Tue, 30 Mar 1999 19:30:59 -0500 (EST) Original-Received: (from ratinox@localhost) by peorth.gweep.net (8.8.7/8.8.8) id TAA01420; Tue, 30 Mar 1999 19:30:25 -0500 Original-To: "(ding)" X-Attribution: Rat In-Reply-To: Dmitry Yaitskov's message of "30 Mar 1999 12:10:14 -0500" Original-Lines: 70 User-Agent: Gnus/5.07008 (Pterodactyl Gnus v0.80) XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:22146 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:22146 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * Dmitry Yaitskov on Tue, 30 Mar 1999 | And IMO it certainly does *not* have to. Not just your opinion: POP is not allowed to muck with message bodies at all. | It (or rather they) is *not* broken. The "\n\nFrom " has special meaning | *only* for mbox format - not for pop3. Clarification: the SMTP envelope is of critical importance to SMTP (duh :). It just so happens that 'mbox' uses the envelope for something else, since it exist. It was a stupid decision, but the world is stuck with it. | When I retrieve mail via pop3 no mbox needs to be involved at all. Again, | pop3 protocol does *not* require "\n\nFrom " lines to be escaped in any | way, they do not have any special meaning for it. Not entirely true. If the mail host stores mail in mbox-style spool files, and the MTA or delivery agent does not generate Content-Length headers, then message body lines that resemble SMTP envelopes should be escaped by the MTA or local delivery agent on the mail host. If that does not happen, the POP server or local mail clients could become confused. The POP retrieveal mechanism cares not a whit about delimiters on the server, since the POP server has already done that work. [...] | It is the job of whoever builds the mbox to escape things having special | meaning for mbox (and for nothing else). So, it is gnus (or rather, | pop3-movemail) who screws things up in this case, because it | (pop3-movemail) builds an invalid mbox out of perfectly valid separate | messages. FYI, pop3-movemail (and the rest of the innards of the code) generate a crashbox that is identical to the spool file on the server (or as close as I can get given a certain university's widely used POP server that has a tendency to strip trailing whitespace from messages). If the mail host uses MMDF, an MMDF crashbox is generated. If the mail host uses Babyl, a Babyl crashbox is generated. If the mail host uses mbox, an mbox crashbox is generated. The only time pop3 generates an mbox-style crashbox is if the mail host uses none of these formats and/or the POP server is broken and strips away the message delimiters. Then, and only then, will pop3 generate an SMTP envelope style delimiter derrived from RFC 822 headers. And I have put much effort into making sure that the envelope-like delimiter is 100% accurate in format. Look at pop3-munge-message-separator for specifics. If after all that Gnus' spool file parsing code still barfs on a particular message, it means that the MTA or delivery agent on the mail host failed to either generate a Content-Length header or escape the envelope-like line. If that is not the case (show us the Content-Length header in that message), then you have stumbled onto a Genuine Bug in Gnus. -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE3AWyhgl+vIlSVSNkRAnwtAKCIU0h6DNSgP4YtScH26moR3NFyRgCg3gA1 gDaPZ6EcHqr5X4frqDwwJ2Q= =cSD9 -----END PGP SIGNATURE----- -- Rat \ Do not taunt Happy Fun Ball. Minion of Nathan - Nathan says Hi! \ PGP Key: at a key server near you! \