🚀 go-pugleaf

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