[2104] in Athena Bugs
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