Eric,
 
let me start by saying that I agree that this document should not impose
requirements on BITNET. I will state this more explicitly in
the abstract.
I have never had the illusion that we could/should tell BITNET what to
do. If the abstract says that the requirements should be followed by
all connected mail networks, we mean only those networks over which we
have 'control' (all networks that don't have such requirements yet and
might want to adapt this as a standard. I.e. The Internet mail
community, GO-MHS, COSINE-MHS, and perhaps Y-net, national research
mail networks and public mail service providers). And even then, there
will always be MBSs that are not conformant. This cannot be tested
extensively. However, we consider it useful to be able to judge about
who is causing the problem in the case of a mail loop/storm/explosion,
since such problems involve at least two MBSs.
I'll quickly explain the background of the paper to show what it is all
about. It started out with the connectivity checking tool 'concord',
which uses echo servers and distribution lists to check a meshed mailer
connectivity. concord was developed within the context of the COSINE
MHS project, in which also XNREN (The Internet X.400 project)
participates. After two major mail storms it was decided that clear
requirements for such mail based servers were needed.  (the initial
concord requirements can be found on the COSINE MHS server,
nic.switch.ch:/e-mail/COSINE-MHS/procedures/echo-server-reqs
a description of the concord software requirements can also be found there:
nic.switch.ch:e-mail/COSINE-MHS/tools/development/concord). These
original requirements were written in RFC822 terminology, but at the
initiative of Peter Sylvester (former EARN office employee....), it was
decided that a more general Internet Draft on the subject would rather
use X.400 terminology. The document itself explains why. I agree that
in order to make the document better understandable for X.400 novices,
an important work item for a next version is to extend chapter 6,
'Mapping to X.400(88) and RFC822'.
 
> >     - Command servers shall not send an output message if
> >       the input message contains an P2.inReplyTo or
> >       P2.crossReferences field. Instead, the input message
> >       is forwarded to the MBS administrator.
>
> End users generally find it more  convenient to use the REPLY function of
> their user  agent than composing a  new message - this  should be obvious
> enough. I  know a number of  users who permanently keep  one message from
> their closest  LISTSERV in their  mailbox, just  so that they  can easily
> send more commands  by replying to the  old message. I see  no reason why
> this  should  be  taken  away   from  them.  Ignoring  messages  with  an
> 'In-Reply-To:' field does  not even prevent loops,  since delivery errors
> do not normally have that field  in the header. Only user agents generate
> this field, as far as I know.
 
Messages from command servers that conform to this Internet Draft will not
have the command server address in the From: field in the first place. The
From: field contains the address of the command server administrator (this
is already done by many command servers nowadays), so hitting the 'r' for
reply won't work.
This requirement is not arbitrary at all. If you like, I can give you a
very simple scenario where not following this requirement can cause a
loop.  That is, if not both servers involved in the loop follow the
requirements that we propose. And since one of the two looping servers
might not be in our control, e.g. in BITNET ...... This is just an extra
safety belt for _our_ servers.
 
> >     - Repliers shall not send output messages to addresses
> >       which are likely to be MBSs, such as addresses with
> >       the following values in the Surname attribute:
> >
>            echo
>
>            autoanswer
>
>            listserv
>
>            netserv
>
> LISTSERV is such a complex server that it falls in most of the categories
> of servers  described in the document,  if one ignores the  fact that the
> various definitions do  not always match the exact  behaviour of LISTSERV
> to the last comma (the classification is actually another immature aspect
> of the draft).  LISTSERV is, among others, a  replier. LISTSERV routinely
> receives requests from peer servers (usually via NJE, but this can happen
> via e-mail as well), and, depending on the request, may generate a reply.
> The requests are received in the exact same format as end-users requests,
> although the  servers usually  ask for  internal information  rather than
> trying  to subscribe  to  lists.  We are  not  talking  about a  separate
> server-to-server communication  medium, but just about  different command
> verbs. And, in  fact, some of the  command verbs are used  by servers and
> users alike.
>
> Furthermore LISTSERV and NETSERV have had,  from as far as I can remember
> (1984), the ability  to detect and handle "dumb repliers"  and avoid what
> is known  in BITNET lore  as "message wars".  It is disappointing  to see
> that  these  usernames have  been  included  in  a proposed  standard  as
> potential troublemakers  without contacting their authors  to discuss the
> issue.
 
As said, these requirements are not supposed to affect BITNET, we just
don't want _our_ repliers to automatically reply to other repliers. I think
BITNET would also benefit from this behaviour.
It all works the other way around too: _you_ can't expect other networks to
follow all BITNET loop detection mechanisms, so it is just a fact that the
interaction with MBSs outside BITNET is likely to cause loops. You take
your pecautions, we take ours.
 
Thanks for your comments.
 
Kind regards,
JH
----
PS1. Sorry for unnecessarily causing you sleepless nights :-)