Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!limbo!taylor
From: taylor@Limbo.Intuitive.Com (Dave Taylor)
Newsgroups: comp.mail.elm
Subject: Re: In-Reply-To messing up
Message-ID: <051989101200.0001@limbo.intuitive.com>
Date: 19 May 89 17:12:00 GMT
References: <457@wubios.wustl.edu> <1321@sagepub.UUCP>
Reply-To: taylor@Limbo.Intuitive.Com (Dave Taylor)
Organization: Intuitive Systems, Los Altos CA, 94022, USA
Lines: 79

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