[2104] in Athena Bugs

home help back first fref pref prev next nref lref last post

sendmail.cf bug

daemon@ATHENA.MIT.EDU (hoffmann@EAGLE.MIT.EDU)
Fri Apr 21 17:43:25 1989

Date: Fri, 21 Apr 89 17:42:28 EDT
From: hoffmann@EAGLE.MIT.EDU
To: bugs@ATHENA.MIT.EDU
Cc: hoffmann@EAGLE.MIT.EDU
The sendmail.cf file on client workstations fails to include a valid From: 
field in the header of messages.  Although the mailhub attempts to make up for 
this by inserting one of it's own further up in the header, this is wrong, and 
causes some mail systems to fail (eg. CMU Andrew can't find the field buried 
in the Received: lines).  

The workstation should be inserting a From: field for another reason; It has 
access to the personal name field from the local password file entry.

Follows is an example from a generice 6.1C test workstation, though this bug 
has existed for A LONG TIME and I have reported it before.  Note that the only 
reason my name appears in the manufactured From: field is because I have an 
account on the mailhub...

==============================================================================
From hoffmann@ATHENA.MIT.EDU Fri Apr 21 17:13:12 1989
Received: by BITSY.MIT.EDU (5.45/4.7) id AA15986; Fri, 21 Apr 89 17:13:09 EDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA11446; Fri, 21 Apr 89 17:13:03 EDT
From: Ron M. Hoffmann <hoffmann@ATHENA.MIT.EDU>
Received: by E40-342-18.MIT.EDU (5.60/4.7) id AA01029; Fri, 21 Apr 89 17:12:57 
EDT
Date: Fri, 21 Apr 89 17:12:57 EDT
Message-Id: <8904212112.AA01029@E40-342-18.MIT.EDU>
To: hoffmann@bitsy.mit.edu
Subject: Test message
Status: R

This is from a supposedly generic 6.1C workstation.

-Ron
==============================================================================

Reading backwards from the body of the message, the From: field should appear 
before the Received: line that comes from the workstation.  The fact that it 
does not indicates that it didn't come from the workstation, but that 
ATHENA.MIT.EDU cobbled it from the return path provided during the SMTP 
dialog.  This is illegitimate, but a good faith attempt to make the message 
have a valid 822 header.

Can this please be fixed before 6.1 (or whatever the next public release is) 
goes out the door?

-Ron

ps.  I have reported this one before (don't ask me when, it's been MANY 
months) and it's been dropped on the floor.  Please don't let that happen 
again.  I'm the one who gets the compalaint mail from other postmasters on the 
Internet, about our malformed headers. -rmh


home help back first fref pref prev next nref lref last post