Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!ucsd!ames!vsi1!wyse!mips!sultra!dtynan
From: dtynan@sultra.UUCP (Der Tynan)
Newsgroups: comp.mail.uucp
Subject: Re: Rerouting considered GOOD
Summary: A suggestion for a new header.
Message-ID: <2540@sultra.UUCP>
Date: 24 Sep 88 00:57:47 GMT
References: <8809212215.AA21035@naggum.se>
Organization: Ultrasystems DSI, Sunnyvale, CA
Lines: 35


I've been watching all this stuff on re-routing, and am in two minds whether
or not it's a good thing.  One the one hand, I don't want stuff going off into
space because of poorly maintained maps or otherwise.  On the other hand, a
lot of times I haven't got the foggiest idea how to get mail to a given site,
and would appreciate a relay along the way cleaning up my routing (as an
exercise, pick a site in Ireland, and send them mail from California -- this
never works for me - I've tried it -- the routing is unwieldy).  I would
suggest that we generate a new line for the mail header, called "Options:".
This would contain some sort of options list, including whether or not the
mail should be re-routed.  I know, I know, no-one wants to do anything more
to RFC822, but it seems to me, that this could be extremely useful.  Some other
possible options could limit bouncing (A mail server about 400 miles from here
had one of its files bounced back by our mail-daemon, because there was a lock
on the mailbox (stupidly) -- why send ~50K of data back to its source?  What
did the mail-server care whether or not I got the data).  An option could say
route to /dev/null if undeliverable.  Also, what about auto-acknowledge.  Every
once in a while I get paranoid about routing and other stuff, when I send a
message to someone, and *nothing* happens.  I mean, I go through this soul-
searching, about whether to re-send or not.  If the recipient didn't get it,
then good - re-sending and/or checking the path will help.  If he did, and
hasn't had a chance to respond, re-sending the message will guarantee nasty
replies :-).  There are probably hundreds of good idea's for an Options: line,
and if the actual options are kept OUT of RFC822, it could be easy to maintain.
Furthermore, to aid in backwards/forwards/in/out compatibility, mail systems
which receive options they don't understand, would just put a note in any
bounce, or acknowledgment, saying such-and-such an option was ignored, instead
of getting sick all over the carpet.  Anyway, these are the ramblings of a
System Administrator, late on a Friday afternoon who is *still* waiting to
hear back from Richard Stallman (Are you listening, Richard???).  Regards...
						- Der
-- 
Reply:	dtynan@sultra.UUCP		(Der Tynan @ Tynan Computers)
	{mips,pyramid}!sultra!dtynan
	Cast a cold eye on life, on death.  Horseman, pass by...    [WBY]