Nachfolgend habe ich meine Informationen, die ich bisher über das
Mail-11 Protokoll gesammelt habe, für all Interessierten einmal
zusammengestellt.

MfG Herbert Hanewinkel

Bitnet:    hanewink@dm0mpb51.bitnet
EAN/X.400: hanewinkel@mpib-martinsried.mpg.dbp.de
PSI:       45890040015::hanewinkel
-----snip----snip-----snip-----snip-----snip-----snip-----snip----
            Erweiterung des VMSmail utilities über
            das DECnet Mail Interface (Mail-11)

                 Herbert Hanewinkel
            Max-Planck-Institut für Biochemie
                 D-8033 Martinsried

1.  Das VMSmail utility unterscheidet intern zwei Betriebsarten, je
    nachdem ob es lokal oder als "network-server" akiviert wird.
    Zur Kommunikation über DECnet verwendet mail dabei ein  relativ
    einfaches Protokoll.

    Dieses DECnet-mail Protokoll (MAIL-11) wurde zur Erweiterung des
    VMSmail auch in die foreign mail protocol Syntax eingebunden.
    So sucht VMSmail bei einer Adressspezifikation der Form
             prot%address
    zuerst nach einem logischen Namen 
             MAIL$PROTOCOL_PROT
    und erst dann nach einem sharable Image
             SYS$SHARE:PROT_MAILSHR.EXE

    Falls der logische Name MAIL$PROTOCOL_PROT existiert wird dort die
    Spezifikation eines DECnet-Objects mit einem vorangestellten
    %-Zeichen erwartet. Mail unterhält sich mit diesem DECnet-Object
    wie mit einem mail-utility auf einem remote VMS System.
 
    Ankommend kann das mail utility als DECnet-Object 27 aktiviert werden
    und damit können über das gleiche Protokoll auch "fremde" (nicht VMS)
    messages über das VMSmail ausgeliefert werden.

---------------------------------------------------------------------
2. (aus: The NJE MAIL BRIDGE between VAX VMS and IBM VM/CMS
    Appendix A. John Osudar, Science Applications, Inc. 1983)

    The following is a summary of the protocol used by VMSmail to
    communicate with a remote slave mail over a DECnet logical link.
    This summary has been pput together from observations and experiments,
    and therefore is not guaranteed to be either complete or completly
    accurate.

    local mail                           slave mail
    ----------                           ----------
    send SENDERNAME
    send ADDRESSEE 1
                                         send success (+1)
                                         if valid addressee;
                                         send failure (low bit = 0)
                                         otherwise, followed by an
                                         error message text and another
                                         status line
    send ADDRESSEE 2
                                         (same as for first addressee above)
   
    ...                                  ...
    send ADDRESSEE n                     (same as for first addressee above)
    send a null byte to signal end
    send "To:" line
    send subject line
    send first text line
    ...
    send last text line
    send a null byte to signal end
                                         for each valid addressee:
                                         send success (+1) if message
                                         delivered; send failure (low bit = 0)
                                         if failed
------------------------------------------------------------------------
3.  ( nach Informationen über INFO-VAX von Mike Kimura,
      Hughes Aircraft Company)
    When delivering mail via DECnet using Mail-11 protocol, VMS MAIL uses
    non-transparent task-to-task communication which enables MAIL to send
    and receive a NCB (Network Connect Block) from the remote server.  MAIL
    puts configuration data in the NCB to tell the server what operations
    and modes it would like to use.  The server must send back a modified
    NCB to indicate what operations and modes it is capable of performing.

    VMS MAIL assigns a channel with a mailbox to "_NET:" and issues a
    $QIO(IO$_ACCESS) to the remote node using a NCB in the following format:

    node::"MAIL=/<word 0><count><configuration data><0 pad>"

    <word 0>        is a word of 0's
    <count>            is the length of the configuration data
    <configuration data>    is the configuration data
    <0 pad>            padded to 17 bytes (including byte count)

    the remote server translates the logical name "SYS$NET" to read the NCB,
    the NCB will look similar to:

    node::"0=<username>/<2 byte link#><count><config><pad><NUL><ESC>"

    it assigns a channel with a mailbox to "_NET:" and sends back a modified
    NCB indicating which operations requested can be processed by the server
    (this NCB is sent back using $QIO(IO$_ACCESS) and will be read by the
    requestor in it's mailbox).

    The configuration data looks like the following for VMS MAIL 4.4

    /*+
    /*Configuration data passed/read from remote node
    /*-

    cnf_b_version    /*Mail-11 protocol version
    cnf_c_vers = 3
    cnf_b_eco        /*Mail-11 protocol ECO level
    cnf_c_eco = 0
    cnf_b_custeco    /*Mail-11 protocol Customer ECO
    cnf_b_os        /*Operating system number
    cnf_c_vaxvms = 7
    cnf_l_options    /*Send "receiving user notified msgs"
    cnf_l_iomode    /*Message send/receive mode
    cnf_v_blksend        /* Sender wants to send in block mode
    cnf_v_blkrecv        /* Receiver will accept block mode
    cnf_v_pfxsend        /* Sender wants to add node name
    cnf_v_pfxrecv        /* Receiver will let sender do it
    cnf_v_ccsend        /* Sender wants to send CC field
    cnf_v_ccrecv        /* Receiver will accept CC field
    cnf_b_rfm        /*Message record format
    cnf_b_rat        /*Message record attributes
    cnf_b_spare1    /*Spare byte
    cnf_b_spare2    /*Spare byte

    cnf_c_length = 16    /*Length of above cnf_ structure

    For VAX/VMS Version 5.x, VMS MAIL sets cnf_c_eco to 1, and it will set
    the bit cnf_v_ccsend in cnf_l_iomode to indicate that it wants to send
    the CC field.  A VAX/VMS Version 4.4 VMS MAIL server will gladly receive
    the CC field and will set the cnf_v_ccrecv bit on to indicate so.  The
    support for CC lines was already built into the VMS MAIL as of VAX/VMS
    Version 4.4 (possibly before) which you can see for yourself by sending
    a message from a 5.x node to a 4.x node and specifying a CC. The "CC:"
    line will show up on the message on the 4.x node.

    The "CC:" line is transmitted after the "To:" line but _ONLY_ if the
    server has sent a NCB back to the requester using non-transparent
    task-to-task communication that indicates the server can handle a "CC:"
    line.  If you use transparent task-to-task communication, an empty NCB
    will be transmitted back and the requester will not send the "CC:" line.

    VMS MAIL will use block mode if you send a file but _ONLY_ if the server
    is using non-transparent task-to-task communication since it requires
    the NCB to have the cnf_v_blkrecv bit set to indicate that the server
    can use block mode.

    Therefore, a full function Mail-11 protocol mailer _MUST_ use
    non-transparent task-to-task communication.  Using transparent
    task-to-task operation by simply using an RMS open on "<node>::MAIL="
    (requestor) or SYS$NET (server) will result in a mailer that can not use
    block mode and that can not send/receive the CC field.

    This information was determined from the VAX/VMS V4.4 micro-fiche.
---------------------------------------------------------------------
4.  Beispiel:
    Ein Beispiel in DCL, das wir hier verwenden um messages aus dem VMSmail
    über unsere eigene RSCS Emulation ins Bitnet abzuschicken.

    $ mcr ncp set object mail2gm number 0 file mpi:[network]mail2gm.com
    $ define /system MAIL$PROTOCOL_GMAIL "%0::task=""mail2gm"""

    Mit diesen Kommandos wird die nachfolgende DCL-Prozedur als
    foreign protocol GMAIL% definiert.
   
    $! mail2gm.com
    $!
    $ set noon
    $ null     = "0"
    $ null[0,8]= %X0
    $ eins     = "1"
    $ eins[0,8]= %X1
    $ temp     = f$cvtime(,,"DAY")+f$cvtime(,,"TIME")-":"-":"-"."
    $!
    $ on error then goto errex
    $ open /write net sys$net	! open the link
    $ read        net sender
    $la:
    $ k = f$locate("::", sender)
    $ if k .eqs. f$length(sender) then goto le
    $ sender = f$extract(k + 2, f$length(sender) , sender)
    $le:
    $ sender = f$extract(0, f$locate("""", sender), sender)
    $ from_user_full == f$edit(sender, "TRIM")
    $!
    $ i = 0
    $rec_loop:
    $ read /error=rec_end net receiver'i'
    $ if f$extract(0,1,receiver'i') .eqs. null then goto rec_end
    $ write net eins
    $ i = i + 1
    $ goto rec_loop
    $rec_end:
    $!
    $ read net to
    $ read net subject
    $!
    $ open /write fd mail_'temp'.txt
    $!
    $text_loop:
    $ read /err=text_end net text
    $ if f$extract(0,1,text) .eqs. null .and. f$length(text) .eq. 1 then -
         goto text_end
    $ write fd text
    $ goto text_loop
    $text_end:
    $!
    $ close fd
    $!
    $ NJE   == "@MPI:[network.rscs.programs]njepunch"
    $ GMAIL == "@MPI:[network.gmail]gmail %"
    $ define gmail_flag_confirm "0"
    $!
    $ j = 0
    $ack_loop:
    $ r = receiver'j'
    $ on error then continue
    $ gmail /noself /subject="''subject'" mail_'temp' "''r'"
    $ write net eins
    $ j = j + 1
    $ if j .lt. i then goto ack_loop
    $!
    $ close net
    $!
    $ dele mail_'temp'.txt;
    $ exit 1
    $!
    $errex:
    $ close fd
    $ close net
    $ dele mail_'temp'.txt;
    $ exit 0
----------------------------------------------------------------------
    Die Möglichkeiten mit "nontransparent task-to-task communication"
    habe ich bisher nur auf unserer CONVEX mit UNIX in einem mail-Interface
    für deren DECnet Emulation (COVUEnet) eingesetzt. Es funktioniert
    wie oben beschrieben sowohl mit VMS 4.x und VMS 5.0 Systemen.