[13062] in Athena Bugs
Re: comp is not RFC822-compliant
daemon@ATHENA.MIT.EDU (jhawk@MIT.EDU)
Mon Jan 2 08:16:26 1995
From: jhawk@MIT.EDU
Date: Mon, 2 Jan 1995 08:16:22 +0500
To: cfields@MIT.EDU
Cc: jcb@MIT.EDU, bugs@MIT.EDU
In-Reply-To: "[13060] in Athena Bugs"
> From: cfields@MIT.EDU
> To: jcb@MIT.EDU
> Cc: bugs@MIT.EDU
> > I tried to use comp to send a message with a "Sender:" line (which was
> > different from the "From:" line, as permitted in RFC822) in the header,
> > and it gave the following error message:
[822 fragment]
> I'm not an expert on RFC822, nor do I play one on TV (and what a
> boring TV show that would be!).
Well, I might not an RFC822 expert (alternatively, I might be one),
but I do play one on the net. :-)
> But, as I read this, the sender is to be an "authenticated
> identity." How can this have any prayer of being true if the user is
> allowed to specify it? As I understand it, if the from field doesn't
> match the machine's concept of who you are, it adds the sender field
> to say so.
>
> Does this sound reasonable, or did I just make it up?
It's reasonable, but doesn't quite wash :-)
Specifically, this behavior of being unable to specify the Sender:
field is an mh "feature" of enforcing it's own sort of facism. If all
other MUAs did this, could be argued as reasonable. On the other hand,
most MUAs _don't_. For instance, using the simplest, sendmail, you are
freely allowed to specify the Sender: [*].
It seems to me that it's appropriate for Athena to provide a consistant
user interface; it's a poor choice for one particular MUA to explicitly
prohibit you from doing something that others allow.
In the particular case of the Sender: header, there is a certain sort
of security-through-obscurity effect as few people really know about
it, and thus those who want to change it probably know what they're
doing. Additionally, the Sender: header is essentially just for
show. Almost no software in the real world relies upon it for
anything, and many people who set the Sender: header do so just to
show that they can do so... [I will admit to falling into this category
occasionally].
Further, SMTP has not ever been, and will not ever be, a secure
protocol. As long as you can access the protocol directly in a
trivial fashion (telnet host smtp), trusting the user (err, sender) is
about as authenticated you can get.
-------
[*] Well, it seems to perform some minor rewriting, like appending
@MIT.EDU if necessary, which is arguably inappropriate, but it
certainly allows you to specfiy; as an aside, it's my recollection
that some versions of sendmail do NOT allow you to specify the Sender:
header unless you are root, however this doesn't seem to be the case
(at least under the sendmail installed under Solaris...)
--jhawk
