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]