Local@tgr.UUCP (12/11/85)
I don't think that rfc822 CLEARLY pointed out that
automatically generated replies should have a "return-path" of
null. In fact, rfc822 discusses computer generated messages and
states that since computer programs cannot be held accountable,
the SENDER field of the message should contain an path of the
human responsible. This means that a good header specification
resulting from a demon could be:
From: Demon@Node...
Sender: Demon-fixers@node..
By rfc822, Demon-fixers will recieve "notices of any
problems in transport or delivery of the original messages"
while Demon@node will recieve any replies. This works very well
except when the server/demon doesn't want any replies sent to
it. It can either discard them as the arrive, or since a
REPLY-TO field is the address that "the reply should go to..
and not the FROM field" the demon could simply indicate on its
messages that it does not wish replies (of any kind, automatic
or 'real') by including a REPLY-TO field of Null.
Comments?
-- John Curran
-- Umass/Amherstzben@umd5.UUCP (12/16/85)
In article <571@brl-tgr.ARPA> Local@tgr.UUCP writes: > > I don't think that rfc822 CLEARLY pointed out that >automatically generated replies should have a "return-path" of >null. In fact, rfc822 discusses computer generated messages and >states that since computer programs cannot be held accountable, >the SENDER field of the message should contain an path of the >human responsible. This means that a good header specification >resulting from a demon could be: > >From: Demon@Node... >Sender: Demon-fixers@node.. > > By rfc822, Demon-fixers will recieve "notices of any >problems in transport or delivery of the original messages" >while Demon@node will recieve any replies. This works very well >except when the server/demon doesn't want any replies sent to >it. It can either discard them as the arrive, or since a >REPLY-TO field is the address that "the reply should go to.. >and not the FROM field" the demon could simply indicate on its >messages that it does not wish replies (of any kind, automatic >or 'real') by including a REPLY-TO field of Null. > >Comments? > >-- John Curran >-- Umass/Amherst From RFC821 (NOT 822) section 3.6. "Relaying", page 15: "Of course, server-SMTPs should not send notification messages about problems with notification messages. One way to prevent loops in error reporting is to specify a null reverse-path in the MAIL command of a notification message. When such a message is relayed it is permissable to leave the reverse path null. A mail command with a null reverse-path appears as follows: MAIL FROM:<> ..." I think there is some confusion here about the SMTP return-path information retained OUT-OF-BAND until final delivery (at which point the information is to be transfered to a Return-Path: field) as opposed to the From:, Sender:, and Reply-To: fields. Problems in the transmission of a message are supposed to be sent back through the out-of-band information. Replies are not. One is supposed to extract information from the Reply-To: etc fields. Now, if you are using RFC822 format messages with a different transmission medium than SMTP, the out-of-band information does not enter the picture at all. While it can be simulated by adding fields to the message header: Return-Path: Major Flamer <zben@umd5> X-Really-To: Enemy one <foo@bar> X-Really-To: Enemy two <mikail's-navy@kremvax.KGB> there seem to be N batch SMTP schemes already, and there is little need to add another. One question... If a demon is sending out messages to servers on other machines asking "Please send me this" or "Please do this for me", how does the demon know if the request succeeded or failed, other than actually reading and parsing either a negative advisory or what one asked for? I.E, does this not presuppose the capability for such demons to at least minimally understand advisories, the lack of this capability causing the war stories that started this discussion? -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben