From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/22140 Path: main.gmane.org!not-for-mail From: Dmitry Yaitskov Newsgroups: gmane.emacs.gnus.general Subject: Re: bad (i.e. serious) mail problems Date: 30 Mar 1999 12:10:14 -0500 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 1035160114 26580 80.91.224.250 (21 Oct 2002 00:28:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:28:34 +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 MAA08640 for ; Tue, 30 Mar 1999 12:10:00 -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 LAB12579; Tue, 30 Mar 1999 11:09:16 -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 11:09:45 -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 LAA10536 for ; Tue, 30 Mar 1999 11:09:36 -0600 (CST) Original-Received: from mail.rdc1.on.home.com (imail@ha1.rdc1.on.wave.home.com [24.2.9.66]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id MAA08612 for ; Tue, 30 Mar 1999 12:09:26 -0500 (EST) Original-Received: from LUCY ([24.65.93.139]) by mail.rdc1.on.home.com (InterMail v4.00.03 201-229-104) with SMTP id <19990330170853.ARV17502.mail.rdc1.on.home.com@LUCY> for ; Tue, 30 Mar 1999 09:08:53 -0800 Original-To: Ding In-Reply-To: Stainless Steel Rat's message of "Tue, 30 Mar 1999 10:12:18 -0500" Original-Lines: 62 User-Agent: Gnus/5.07008 (Pterodactyl Gnus v0.80) XEmacs/21.2(beta13) (Demeter) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:22140 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:22140 Stainless Steel Rat wrote: > * Dmitry Yaitskov on Mon, 29 Mar 1999 > | Eh.... sorry, what *is* my MTA? I'm afraid I don't have one :). > > Yes, you do. MTA: Mail Transport Agent. Something like sendmail or > qmail or exim. You have to have one, or you would not be receiving > any mail at all. It is runinng on the machine from which you > retrieve your mail. I know what MTA stands for, thank you. I do not have one running on my machine. I am saying that the problem happens on my machine, not on the machine I retrieve my mail from. I retrieve my mail from 3(!) different pop3 servers, running on 3 different machines - 2 of them are unixes, one I dunno what. Without my patch, the problem shows with 2 of the 3 pop3 servers, *when I retrieve my mail from them via pop3*. If I telnet to them and use pine there, the bloody From gets escaped with a > on *both* unixes, whereas when fetching the same message via pop3 only one of their pop3 servers passes me the escaped From, whereas the other does not. And IMO it certainly does *not* have to. It (or rather they) is *not* broken. The "\n\nFrom " has special meaning *only* for mbox format - not for pop3. 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. So your reasoning is wrong in this case. The pop3 server knows perfectly well where one message ends and another begins, it does not have to store messages in mbox format, and when it gives messages to you (pop3-movemail) it splits them correctly, one by bloody one. 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. For crissake, even M$ bloody outlook express did *not* screw up this message although it received it from a server that does *not* escape the From. (And BTW, it of course did not escape the From - because it does not use mbox at all.) > | pop3-movemail gets messages from the servers one by one, so I do not see > | why it would be necessary for the "\n\nFrom " lines in messages' bodies > | to be escaped in any way > > It is not for pop3-movemail, but for the POP server it talks to. The > server needs to know where one message ends and the next begins. See above. The server knows perfectly well where one message ends and another begins. It is gnus who gets confused by the bad mbox built locally on my MTA-less machine. > If a > Content-Length header exists, it will be used; otherwise, the server will > scan through the spool file looking for RFC 821 (SMTP) envelopes (the > '\n\nFrom ' lines). Escaping envelope-like lines is an artifact of RFC > 821, not 822. > > Thus, if escaping of envelop-like lines is required on your system, it > should have been done long before pop3-movemail ever comes into play. No. See above. -- Cheers, -Dima.