daemon@srhqla.UUCP (05/17/89)
This issue is: setting a new From: header while having $edit_hdrs set. Mush doesn't let you do it for various reasons (discusssed below), but there are things that the user might wish to do which editing the From: header would solve. Specifically, making "from" display a correctly formed domain-style hostname. > On May 15, 10:44am, "Barton E. Schaefer" wrote: > On May 14, 8:36pm, Ronald Khoo wrote: > } Subject: My domain in From: (mush 6.5) > } > } From: ronald@ibmpcug ... where's my domain? !! > This is an artifact of mush trying to be completely uucp compatible as > well as conforming to RFC822. Mush does look up the domain name [and all > other aliases it can get from gethostbyname()] but it only uses the basic > host name from gethostname() when constructing addresses, You can set hostname = "ibmpcug.co.uk" in your. Now, the From: line that is constructed will contain that as your hostname. Note that setting your "hostname" from within mush will override all preexisting values of hostname and they cannot be retrieved. Therefore, I recommend using: mush> set hostname = "whatever... $hostname" > It ought to be OK to edit the From: field as long as the address given > remains you@valid.alternate.domain or localmachine!you. If you want > to redirect replies to a different address, that's what the Reply-To: > header is for. However, rather than trying to compare the From: line to > every possible alternate name, mush took the cowardly way out and simply > forbade you to change it. 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. --dan
comp-mail-mush@srhqla.uucp (05/17/89)
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
comp-mail-mush@srhqla.uucp (05/17/89)
From: Marc Rouleau <mer6g@virginia.acc.virginia.edu> On May 16, 16:03, Dan Heller wrote: > > There's no question that it is desireable to allow it. 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 haven't been following this discussion too closely, so please forgive me if I'm treading ground already covered. What's so hard about error _detection_? Just hand the message off to the MTA -- if you get a bad return (!= MTA_EXIT), dump it in dead.letter and forget about it. If you get a good return, it's the MTA's responsibility to deal with it. The worst case is that the user puts an incorrect or even syntactically illegal string in the From: line and the MTA accepts the message only to find later that it (or some MTA farther down the line) cannot return it. In that case it'll drop it in the local "orphanage" or somesuch for the local administrator to deal with. Really, is this, the _worst_ case, so bad? I think there oughta be a variable (not an #ifdef) allow_from_edit or whatever so that the "experts" can do what they want. Occasionally one of them will send a piece of mail that is neither delivered nor returned, but that's his/her problem, not mush's. -- Marc Rouleau