Vshank%Weizmann.BITNET@WISCVM.ARPA (Henry Nussbacher) (12/09/85)
Does a field exist in the MHS specification to specify whether a program
has created the mail?
Allow me to give an example: More and more programs (call it server
machines or deamons or whathaveyou) are learning to process RFC822
(RFC920) mail and to perform some function for the user (Database
search, batch FTP request, auto-reply, gateways, etc.).
Another feature becoming more common is for mail systems to return
bounced mail to the original user for various reasons (userid no
longer valid, disk quota used up, unable to connect to host, etc.)
We have all seen these bounced mail files. We read them and can
discern right away that the mail arrived via program generation and
not via a human being.
Scenerio: user@Uclamvs.Bitnet sends mail to a server/deamon. The
server/daemon processes the request and sends some output back to the
user. For some reason the mail software at Uclamvs cannot deliver the
mail and rejects it back to the sender. The mailer builds a From:,
To: and Subject: line in most cases and then imbeds the rejected mail
inside its own envelope. The mail is sent back to the server/daemon
which doesn't know that the incoming mail was computer generated
and attempts a reply. In most cases the syntax/format will not
be valid and the server/daemon will generate a piece of mail giving
some error message back to the mail system at Uclamvs. Infinite
network loop. Currently, I have a table built into my software; if
mail arrives with a character string of Daemon, Mailer, Mailman,
Postmast, System, Smtpuser (just to name a few of those I have
observed) then my software throws the mail into a wastebasket for
human processing at a later date. But quite often, some new node
in some network comes online and decides to send out it's mailer
generated mail with a From: line that is foreign to my table. Network
loop - until I spot it and add it in.
Users are starting to write programs/daemons to run on their ids
while they are away for vacation that sends out a predefined piece
of mail saying that they are on vacation until mm/dd/yy but don't
worry, your mail has been logged and will be read when they return.
What is needed is an additional field in RFC822 and a field in
MHS that indicates that the mail was computer generated rather
than human generated and therefore do not reply to it.
Example:
From: Network Mailer <mal%cornella.bitnet@Wiscvm.Wisc.Edu>
Auto: MAILER
where Auto: could be one of the following values:
MAILER
REPLY
PROGRAM
or anything else people could think of.
In Kille's chapter 2.3 he discusses Non-Delivery Notification and
Prevention of Non-Delivery Notification. If these fields are standard
X.400 then perhaps it is just the Internet that needs to come up with
a new field.
Comments encouraged.
Hankmrose%NRTC@USC-ECL.ARPA (Marshall Rose) (12/09/85)
In addition, MHS has the notion of a protocol field which says what type of protocol is being used. The only defined value is "P2" which stands for InterPersonalMessage. Other values will probably be defined in the future. In the standard 821 world, there is NO need for what you suggest. The message's envelope contains (among other things) a return-address. What programs which generate messages should do (if they don't want to see a failure notice) is simply leave the return-address blank. This is understood to mean "don't tell me about it if it loses". /mtr
Tommy_Ericson__QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (12/10/85)
Not only do we need a way to indicate WHO/WHAT has created a message, but also the TYPE of a NAME. Example: in X.400 the current definition of an O/R name cannot be used (properly) to refer to a distribution list (sending to it) or a distributor (after expansion). As for personal agents issuing On-Holiday messages I would like to have possibilities to adding things to a PersonalName, e.g. US.mumble.mumble.PersonalName.WatchDog or .FolderName which would allow easier mapping onto some well-known existing mail systems. Tommy
GRZ027%DBNGMD21.BITNET@WISCVM.AR (Peter Sylvester +49 228 303245) (12/10/85)
A comment to Hanks message:
Scenerio: user@Uclamvs.Bitnet sends mail to a server/deamon. The
server/daemon processes the request and sends some output back to the
user. For some reason the mail software at Uclamvs cannot deliver the
mail and rejects it back to the sender. The mailer builds a From:,
To: and Subject: line in most cases and then imbeds the rejected mail
inside its own envelope. The mail is sent back to the server/daemon
which doesn't know that the incoming mail was computer generated
and attempts a reply. In most cases the syntax/format will not
be valid and the server/daemon will generate a piece of mail giving
some error message back to the mail system at Uclamvs. Infinite
network loop. Currently, I have a table built into my software; if
mail arrives with a character string of Daemon, Mailer, Mailman,
Postmast, System, Smtpuser (just to name a few of those I have
observed) then my software throws the mail into a wastebasket for
human processing at a later date. But quite often, some new node
in some network comes online and decides to send out it's mailer
generated mail with a From: line that is foreign to my table. Network
loop - until I spot it and add it in.
The describe scenario is not true from the design point:
When the UCLAMAIL-mailer returns a message via the "RETURN
TO SENDER" feature, it uses a from: address as POSTMAN. In
the NJE header the Origin user is set to MAILER. When the
second invalid message is return it gets to either MAILER or
POSTMAN depending on what the server machine uses.
Therefore no loop will occur if server machines are
"replying" correctly. The error is that the UCLA-MAIL sets
MAILER as NJE header. I will change that in my version:
For a "RETURN-TO SENDER" message POSTMAN will be used in
both fields. That problem also applies to VM-Mailers I guess.
Hank: (please describe the LOOP situation in detail to ME.)
Users are starting to write programs/daemons to run on their ids
while they are away for vacation that sends out a predefined piece
of mail saying that they are on vacation until mm/dd/yy but don't
worry, your mail has been logged and will be read when they return.
What is needed is an additional field in RFC822 and a field in
MHS that indicates that the mail was computer generated rather
than human generated and therefore do not reply to it.
This problem cannot be cured by a new RFC822 fields. The EARN network
server uses another approach. It keeps a log of invalid requests
for any user. If a threshold is reached (like HOT IO ERRORS)
no further requests are accepted from this user. The node
manager of the users node has the ability to reset that state.
For interactive REPLY-MESSAGES (Gone, will be back in...) there
is a convention that they should start with an asterisk.
SERVER machines should not react on messages with *.
A good combination of SENDER/FROM-fields and NJE-header can help:
I discovered a problem with some server machines that if a mailer
is used, the server sends the reply to the MAILER and not to the
user. I.e. it uses the NJE-headers in those cases.
Two interpretation are possible: IF the server machine CLAIMS to
use RFC822 it should respond to the FROM/REPLY-TO address.
If the server is not able, it should reply to to the NJE sender
and put itself as FROM: field into the message.
If the MAILER does not claim to use RFC822, it is a problem of
the sending MAILER. Many server use the NJE-origin userid field
(display as user in a VM RDRLIST). In general VM-MAILER and
and also the UCLA-Mail mailer set the NJE filename to the userid.
In case of MAILER, these two fields are different. SERVER machines
could either reject such messages or send it to any of the
two userids. If it uses the SERVER userid the message will
normally be put in the target servers box (=postman's box.)
Kille's report only handle RFC822 mailers. The approach there is
obvoiusly the right one. BUT: MOST SERVER machines DO NOT
know anything about RFC822.
Comments encouraged.
Peter
BTW: if the following addresses are "distribution list" or
conferences, would anyone be so kind to add me?:
<MHS_implementation@wisc-rsch.ARPA> ,
<ARPA-mhs@BRL.ARPA>
..
QUIT