From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/22127 Path: main.gmane.org!not-for-mail From: Dmitry Yaitskov Newsgroups: gmane.emacs.gnus.general Subject: Re: bad (i.e. serious) mail problems Date: 29 Mar 1999 20:56:42 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035160104 26529 80.91.224.250 (21 Oct 2002 00:28:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:28:24 +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 UAA19399 for ; Mon, 29 Mar 1999 20:56:47 -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 TAB04757; Mon, 29 Mar 1999 19:56:05 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 29 Mar 1999 19:56:15 -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 TAA00672 for ; Mon, 29 Mar 1999 19:56:06 -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 UAA19362 for ; Mon, 29 Mar 1999 20:55:58 -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 <19990330015523.PCIP17502.mail.rdc1.on.home.com@LUCY> for ; Mon, 29 Mar 1999 17:55:23 -0800 Original-To: Ding In-Reply-To: Stainless Steel Rat's message of "29 Mar 1999 20:04:08 -0500" Original-Lines: 55 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:22127 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:22127 Stainless Steel Rat wrote: > I've gone back to determine where the problem might be. It is not Gnus, > and it is not pop3. > > * Dmitry Yaitskov on Sun, 28 Mar 1999 > | [...] If I understand that situation correctly (please tell me that I'm > | wrong) this is kind of by design. Or am I missing something here? > > Your MTA is. > > Gnus uses Content-Length headers, when they exist, to determine where to > split messages. When they do not exist, it uses SMTP envelopes (what you > mistakenly call 'headers') Where did I talk about headers? > just like Berkeley mail and every POP server > known to me to delimit messages. If your MTA does not generate a > Content-Length header, it is required to escape lines that look like > envelopes. All in all, Gnus has been very good at Doing the Right Thing > with properly formed messages. > > Your MTA is not generating Content-Length headers, nor is it escaping lines > that look like envelopes. In short, it is broken -- at least that is my > supposition. Eh.... sorry, what *is* my MTA? I'm afraid I don't have one :). Or I am again missing something, in which - quite probable - case I'd appreciate if you explained in more detail what you mean. I am on WinNT, and my mail is fetched from pop3 servers by, if I get this right, pop3-movemail. 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 - there is no boundaries between messages to determine at this stage. (I just looked up rfc1725 - it says that the message should comply with rfc822 - which I think doesn't say anything about "\n\nFrom ". So I don't think it is required by anything in this chain although of course I may be wrong.) pop3-movemail puts the messages in its crashbox (BTW, could it perhaps add Content-Length to messages missing it at this stage?), from where on it is Gnus (nnmail) who transports the messages to appropriate groups. What is the broken MTA here? > I do not want to add your patch to pop3.el. Message transports are not > allowed to modify message bodies in any way. Less (or perhaps more, > depending on one's perspective) importantly, your patch is a workaround for > what appears to be a really badly broken MTA, one that I have no means (or > intention, sorry) of testing against. I cannot support code that I cannot > (or for some reason will not) test against. Sorry. Is ok. :) -- Cheers, -Dima.