phil@wubios.wustl.edu (J. Philip Miller) (05/18/89)
We are currently running 2.2 PL7. A problem which occured also in 2.1 and which is still occuring is that when doing a reply, the In-reply-to header occasionally gets built wrong. In particular it appears to pick up stray text from a previously sent message (I thank always from the body of the text of a previous reply). Not only does this produce some confusion in the rew recepient, but could cause a privacy question if the included text was "sensitive" at all. What makes it particularly difficult to spot is that since it is an error on the outgoing header, I do not see it (I have not systematically displayed the header editing screen so do not know if I could spot it by systematically looking). Anybody else see this? Anybody got any clues for what to look for (except to see if the error is displayed on the Editing Headers Screen)? -phil -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* J. Philip Miller - Div of Biostat - Washington Univ Medical School phil@wubios.WUstl.edu - Internet phil@wubios.wustl - bitnet (314) 362-3617 c90562jm@wuvmd - alternate bitnet
dfm@sagepub.UUCP (David F. McCune) (05/18/89)
In article <457@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes: >We are currently running 2.2 PL7. A problem which occured also in 2.1 and >which is still occuring is that when doing a reply, the In-reply-to header >occasionally gets built wrong. In particular it appears to pick up stray >text from a previously sent message (I thank always from the body of the >text of a previous reply). Yep, I've seen this problem. I sent a message (a reply, I think) that had a piece of the header and body of a previous message inserted into the text of the reply. The recipient of the message told me about the problem and then sent the garbled message back (which I then destroyed, alas). As you point out, the security problems are pretty clear, so I hope someone can track this down. If I see this problem again, I'll send the garbled message to the elm team. - David -- David McCune, Sage Publications, Inc. 2111 West Hillcrest Drive, Newbury Park, CA 91320 dfm%sagepub@quad.com uucp: ...srhqla!sagepub!dfm voice: (805) 499-0721 fax: (805) 499-0871
rob@PacBell.COM (Rob Bernardo) (05/19/89)
In article <457@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes:
+We are currently running 2.2 PL7. A problem which occured also in 2.1 and
+which is still occuring is that when doing a reply, the In-reply-to header
+occasionally gets built wrong. In particular it appears to pick up stray
+text from a previously sent message (I thank always from the body of the
+text of a previous reply).
I remember this during the development of 2.2. I remember I isolated a
context in which this symptom occurred and then fixed the bug that
caused it to occur (well ... at least in that context). I can't
remember what the source of the bug was offhand. Maybe Syd can scan
through the comments in the rcs versions between 2.1 and 2.2 as see if
the comments make reference to this symptom.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiaphil@wubios.wustl.edu (J. Philip Miller) (05/19/89)
In article <1321@sagepub.UUCP> dfm@sagepub.UUCP (David F. McCune) writes: >In article <457@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes: >>We are currently running 2.2 PL7. A problem which occured also in 2.1 and >>which is still occuring is that when doing a reply, the In-reply-to header >>occasionally gets built wrong. In particular it appears to pick up stray >>text from a previously sent message (I thank always from the body of the >>text of a previous reply). > I have done some more testing and the offending In-reply-to header is indeed displayed when you go to the edit header screen. The contents always appear to be 3-5 lines of some message in the current folder and then is concatinated with the correct In-reply-to text. In all cases that I have seen it it has been a reply to a local address. In some cases, there is a blank line in the included text which then becomes the delimiter between the headers and the body of the message (another bug :-) here is an example of an offending header: -----------------------------cut here--------------------------------------- From phil Thu May 18 11:06:17 1989 Received: by wubios.WUstl.EDU (4.1/Sun UNIX 4.0); Thu, 18 May 89 11:06:16 CDT From: phil (J. Philip Miller) Subject: Re: t1 To: phil@wubios (J. Philip Miller) (J. Philip Miller) Date: Thu, 18 May 89 11:06:16 CDT In-Reply-To: (JAY COOK HAS BEEN MOST HELPFUL.) Status: OR SHREE IS VISITNG BOSTON JUNE 1 NAD WILL COME BACK WITH MORE INFO ON MODIFYING T HE MUNSAT SThu; from "J. Philip Miller" at May 18, 89 11:03 am X-Mailer: ELM [version 2.2 PL7] > From phil Thu May 18 11:03:46 1989 > Received: by wubios.WUstl.EDU (4.1/Sun UNIX 4.0); Thu, 18 May 89 11:03:46 CDT > From: phil (J. Philip Miller) > Subject: Re: t1 > To: phil@wubios (J. Philip Miller) (J. Philip Miller) > Date: Thu, 18 May 89 11:03:45 CDT > In-Reply-To: ; from "J. Philip Miller" at May 18, 89 11:02 am > X-Mailer: ELM [version 2.2 PL7] [rest of message deleted] -phil -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* J. Philip Miller - Div of Biostat - Washington Univ Medical School phil@wubios.WUstl.edu - Internet phil@wubios.wustl - bitnet (314) 362-3617 c90562jm@wuvmd - alternate bitnet
taylor@Limbo.Intuitive.Com (Dave Taylor) (05/20/89)
J. Philip Miller <phil@wubios.UUCP> asks about: > We are currently running 2.2 PL7. A problem which occured also in 2.1 and > which is still occuring is that when doing a reply, the In-reply-to header > occasionally gets built wrong. In particular it appears to pick up stray > text from a previously sent message (I thank always from the body of the > text of a previous reply). I would have to guess that the problem is that the "message-id" variable that is used in the In-Reply-To: field isn't being initialized to valid text because the message that you're replying to doesn't have a message-id. That is: In-Reply-To: <message-id of original message>; from "name" at date comes out very strange if the message that you're replying to doesn't have a line like: Message-Id: <8905011012.AA5435@remote.host> in it. The fix is to go into the file mkhdrs.c in the routine generate-reply-to and change it to: generate_reply_to(msg) int msg; { /** Generate an 'in-reply-to' message... **/ char buffer[SLEN]; if (msg == -1) /* not a reply! */ in_reply_to[0] = '\0'; else { if (chloc(header_tabe[msg].from, '!') != -1) tail_of(header_table[msg].from, buffer, FALSE); else strcpoc(header_table[msg].from,'!') != -1) tail_of(header_table[msg].from, buffer, FALSE); else strcpy(buffer, header_table[msg].from); sprintf(in_reply_to, "%s; from \"%s\" at %s %s, %s %s", >>> hader_table[msg].messageid[0] == '\0'? "<no id>": header_table[msg].messageid, buffer, header_table[msg].month, header_table[msg].day, header_table[msg].year, header_table[msg].time); } } And then to go into "newmbox.c" and in the routine read-headers add a line to initialize each message ID value to a known null value: if (real_from(buffer, &header_table[count])) { header_table[ount].offset = (long) fbytes; header_table[count].index_number = count+; if (! rereading || count >= message_count) header_table[count.status = VISIBLE; /* default status! */ header_table[count].subject[0] = '\0'; /* clear Subj */ header_table[count].to[0] = '\0'; /* clear To */ >>> strcpy(header_table[count].messageid, "<no.id>"); if (count) header_table[count-1].lines = line; if (new_msg(header_table[count])) { header_table[count].status |= NEW; /* ne message! */ etc etc. I believe that those two simple modifications will fix the problem that you are occasionally encountering. -- Dave Taylor Intuitive Systems Los Altos, California {decwrl,apple} ! limbo!taylor taylor%limbo.uucp@apple.com taylor@limbo.intuitive.com or taylor%limbo.uucp@decwrl.dec.com