Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!apple!ames!think!husc6!ogccse!schaefer
From: schaefer@ogccse.ogc.edu (Barton E. Schaefer)
Newsgroups: comp.mail.mush
Subject: Re: Two bugs in MUSH6.5
Keywords: reply headers
Message-ID: <2952@ogccse.ogc.edu>
Date: 26 May 89 18:36:10 GMT
References: <2270@aecom.yu.edu>
Reply-To: schaefer@ogccse.UUCP (Barton E. Schaefer)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 36

In article <2270@aecom.yu.edu> naftoli@aecom.yu.edu (Robert N. Berlinger)
writes:
} 
} If, for example a message is received from joe@pc.abc.edu 
} by joe@abc.edu, and joe@abc.edu has hostname set to abc.edu when 
} he replies to the message (note that alts is not set), the reply 
} is sent to "joe" (unqualified) instead of joe@pc.abc.edu.  This 
} is because the take_me_off routine considers joe@pc.abc.edu to be 
} the same person as joe@abc.edu.  
} 
} The fix (I think) would be to change 
} 
} 		if (!lcase_strncmp(tmp, addr, strlen(tmp))) {
} to
} 		if (!lcase_strncmp(tmp, addr, strlen(addr))) {

Nope, can't do that, because then "sys1!sys2!joe" != "sys2!joe".  The fix
is to test that addr[strlen(tmp)] is either '\0' or '!', that is, that
the lcase_strncmp examined a full host/domain and not just part of one.
Look for this in Patch #4.

} The second bug is that the headers routine (compose_hdr) seems to
} consider only login (mailbox) name when deciding whether it should show the
} the TO: type header (the recipients) or the normal header (the sender).
} This one is a bit hard to believe so maybe I'm off base.

Yes, this is a known shortcoming.  Because compose_hdr() is heavily used,
the very simple test you described was employed in the name of efficiency.
You are about the third person to complain about this, so it appears that
something should be done, but short of omitting the test entirely I'm
not sure what.
-- 
Bart Schaefer       "And if you believe that, you'll believe anything."
							-- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer