From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/22167 Path: main.gmane.org!not-for-mail From: Kai.Grossjohann@CS.Uni-Dortmund.DE Newsgroups: gmane.emacs.gnus.general Subject: Re: bad (i.e. serious) mail problems Date: 31 Mar 1999 15:13:21 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <99Mar30.101746est.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 1035160136 26715 80.91.224.250 (21 Oct 2002 00:28:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:28:56 +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 IAA08842 for ; Wed, 31 Mar 1999 08:14: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 HAB27981; Wed, 31 Mar 1999 07:14:00 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 31 Mar 1999 07:14:22 -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 HAA26293 for ; Wed, 31 Mar 1999 07:14:13 -0600 (CST) Original-Received: from waldorf.cs.uni-dortmund.de (waldorf.cs.uni-dortmund.de [129.217.4.42]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id IAA08817 for ; Wed, 31 Mar 1999 08:13:58 -0500 (EST) Original-Received: from ramses.cs.uni-dortmund.de (ramses.cs.uni-dortmund.de [129.217.20.180]) by waldorf.cs.uni-dortmund.de with SMTP id OAA20870 for ; Wed, 31 Mar 1999 14:13:23 +0100 (MET) Original-Received: (grossjoh@localhost) by ramses.cs.uni-dortmund.de id PAA23450; Wed, 31 Mar 1999 15:13:22 +0200 Original-To: ding@gnus.org Original-Lines: 107 User-Agent: Gnus/5.07008 (Pterodactyl Gnus v0.80) Emacs/20.3 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:22167 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:22167 Stainless Steel Rat writes: > * Kai.Grossjohann@CS.Uni-Dortmund.DE on Tue, 30 Mar 1999 > > | Right. So, the client (including pop3.el) knows that the end of the > | message must be right before the dot. pop3.el, however, does not make > | sure that these are the endings of messages in its output file. > > The '.' line is a terminator for the *protocol* (and is in fact the same > terminator used in other mail-related areas). It signals the POP client > that the RETR command has completed. [...] It also indicates the end of the message. In fact, it is the *only* end of message present in the response of the RETR command. Hm. I have now read RFC 1939 (I hope this is the right one), and it contains the following two snippets: ,----- | Responses to certain commands are multi-line. In these cases, which | are clearly indicated below, after sending the first line of the | response and a CRLF, any additional lines are sent, each terminated | by a CRLF pair. When all lines of the response have been sent, a | final line is sent, consisting of a termination octet (decimal code | 046, ".") and a CRLF pair. If any line of the multi-line response | begins with the termination octet, the line is "byte-stuffed" by | pre-pending the termination octet to that line of the response. | Hence a multi-line response is terminated with the five octets | "CRLF.CRLF". When examining a multi-line response, the client checks | to see if the line begins with the termination octet. If so and if | octets other than CRLF follow, the first octet of the line (the | termination octet) is stripped away. If so and if CRLF immediately | follows the termination character, then the response from the POP | server is ended and the line containing ".CRLF" is not considered | part of the multi-line response. `----- The above snippet indicates that the dot-line and *only* the dot-line indicates the end of the response. It also indicates that some lines in the response might be changed -- the ones beginning with a dot. It does not impose any other restrictions whatsoever on multi-line responses. In particular, it does not require that there be only one From_ line in the multi-line response. ,----- | RETR msg | | Arguments: | a message-number (required) which may NOT refer to a | message marked as deleted | | Restrictions: | may only be given in the TRANSACTION state | | Discussion: | If the POP3 server issues a positive response, then the | response given is multi-line. After the initial +OK, the | POP3 server sends the message corresponding to the given | message-number, being careful to byte-stuff the termination | character (as with all multi-line responses). | | Possible Responses: | +OK message follows | -ERR no such message | | Examples: | C: RETR 1 | S: +OK 120 octets | S: | S: . | `----- The above snippet indicates that the response to a RETR command is exactly one message (or an error). Therefore, even if the response of a RETR command were to look like this: ,----- | +OK 109 octets | From foo | From: foo | To: bar | Subject: msg 1 | | msg 1 text | | From bar | From: bar | To: foo | Subject: msg 2 | | msg 2 text | . `----- ... this would still be just one message, right? You are assuming this is two messages, which is wrong. If the RFC tells us that the above is an invalid response, please quote the relevant portion. kai -- I'd like to welcome you and an orange juice, please.