hoey@NRL-AIC.ARPA (Dan Hoey) (03/06/84)
I know I'll regret this, but I think some of these ideas need straightening out, so I'll try. The return-path is, I am told, supposed to be the address of the sender of the message, routed in reverse order of the message's delivery. Many uses have been inferred for it, but in this pragmatic world I can tell you what it's used for (and if I've left your favorite use out, I'd like to hear it): 1. An address to send delivery errors back to. This saves the rfc-writers from having to document an ``Errors-to'' header field. 2. A fallback reply address. If the ``From'' or ``Reply-to'' field is garbage--some of them get typoed by hand, you know--the return path is sometimes usable. 3. A quick index to the ``Received'' lines, useful when those lines are out of order or missing. This can be useful in diagnosing mail problems. 4. A testament by the systems involved as to the actual origin of the message, useful when the mail is somehow unlawful and the malefactors are being rounded up. It should be noted that (1) is somewhat in conflict with (2) through (4), but since (1) is an important and routine function that hasn't otherwise been provided for we live with it. Incidentally, I imagine (4) is what Rich Zellich is talking about becoming more important with Milnet, but I'm not sure. The ``deliver-at-all-costs'' philosophy might better be stated as ``deliver even if you can't get back from here.'' When such a philosophy is taken, all the benefits of 1-4 are lost. The loss of (1) and (2) means that the message could get to a point where even with human intervention, there's no way of telling who the message is for or from, an uncomfortable situation for us dead-letter-office personnel. Loss of (3) could lead to not being able to figure out why we get into all these uncomfortable situations. And loss of (4) could prevent us from calling a halt to the chain letters, cranks, ransom notes, and other Trojan thoughts that we can't deliver, return, or diagnose anyway. Unfortunately, the ``responsibility'' philosophy seems to imply that you can't send mail unless it can be returned. With so many protocols around, one site's mailbox is another site's host name. Rudy's example of "_" in a host name is an example, but I'm aware of various uses of certain other @=." )\!:([%] special characters that might be insufficiently quoted--or quotable--to permit returning of the mail. It seems unfortunate that person A out in funny-character-land should be prohibited from sending his phone number to person B in easy-address-ville because host C in the middle is feeling responsible. I can suggest some more strategies for people who want to sail gracefully between the explosive source and the yawning sink. I'm pretty sure they're orthogonal, and some of them may even be easy. 1. Try to patch the return-path. For instance, put quotes around it? Maybe put parens around it and add "Postmaster"? I don't know if quotes and comments fit the return path syntax, but it's a try. 2. Stuff an error message containing the offending return-path onto the message before sending the message with an empty return-path. 3. Send a notification back along the return-path to warn that delivery errors may happen and the sender may not hear about them. 4. Log it locally so InterNetPol can track it back to its source if necessary. An ideal site might implement them on both sides (server and user). I would be interested in seeing other solutions to the problems of unusable return-paths. Somehow I can't get into this philosophy jazz, though. Dan Hoey
don.provan@CMU-CS-A.ARPA (03/07/84)
what we need is two new types of error messages. one to indicate that the mail may be delivered but errors cannot be returned and another to indicate that the mail will be delivered but there was still something bogus about the return path. this general discussion is fine, but the times i've had mail rejected because of what the server thought was a syntax error in the return path, the mail would have been delivered immediately by the server, so there was no danger of the return path being used, anyway.