Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!usc!csun!srhqla!Upacbell
From: comp-mail-mush@srhqla.uucp
Newsgroups: comp.mail.mush
Subject: Re: My domain in From: (mush 6.5)
Message-ID: <636@srhqla.UUCP>
Date: 17 May 89 09:49:39 GMT
Sender: Upacbell@srhqla.UUCP
Lines: 39

From: dheller@cory.Berkeley.EDU (Dan Heller)

> On May 16,  5:46pm, Milo Bloom said this about:
                      ^^^^^^^^^^
well, you went and hacked the source anyway.  That's cheating :-)

> > Indeed -- this was by design.  Error recovery and authentication schemes
> > were generated too much code to bother putting it in.  Frankly, I got lazy
> > and just disallowed it.  You couldn't do it pre-6.5 anyway, so you're not
> > losing any functionality.  In a future release when the address comparing
> > and storage code is more stabilized, then editing From: will probably be
> > possible.
> 
> But...  But...  But...

>   There are cases where I want to set
> my From: header to point at a alternate instance of me (a different account,
> possibly on another host or in another domain, etc).  There's no reason my
> MUA shouldn't allow this, 'cause its a simple trick around any such
> restrictions by just talking directly to the MTA.

There's no question that it is desireable to allow it.  I fully agree
with all arguments in favor of editing the From: header.  the strongest
arguments against it is the simple fact that malformed headers have to
be dealt with -- error recovery is complicated even when it's detected.
If undetected, there could be unpredictable results.  I would rather hear
the world bitch about the fact that it doesn't exist than hear everyone
whine about how ti doesn't work *right*.  It'll come in time :-)

> Besides, its in the realm
> of the MTA to construct a proper From: line.

What, are you now arguing against it :-)

> I just put "#ifdef DONT_EDIT_FROM" around all that code in "mail.c" and
> trod happily on.
That's the "expert" mode you were talking about.

					--dan