🚀 go-pugleaf

In article <114277@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) writes:

>It's obvious that we know nothing about the proposed scheme right now.
>Les didn't give much information at all and I would like more -- a lot
>more.

Here's a sample of the PMX-mailer headers.  This was sent from a PC
using PMX-starmail from afbf02!les2 to afbf01!les.  The mail appears
to be from the unix host and remains in the normal unix mailbox until
the PC requests it.  The headers up to one line below the first
Content-Length: do not have the PC-style carriage returns at the ends of
the lines.  The rest of the message did and they are included in the
length counts (I deleted them). Going the other direction (unix mail to
PC), CR's are added during the transfer and the length values are adjusted
to match.
(A) It seems a little strange to me to have an End-of-Header: and
    End-of-protocol: header followed by more headers.
(B) Inserting a Status: header before the blank line will mess up the
    count unless you note that the count starts *after* the blank line.
(C) I could not decode the contents with the version of atob that I had
    on a 3B2 although the format looks right after the CR's are taken out.
    Are there incompatible versions of atob?
|------------sample----------
|From uucp Tue Jul 11 15:22 CDT 1989
|>From les2 Tue Jul 11 15:28 CDT 1989 remote from afbf02
|Message-Version: 2
|>To: afbf01!les 
|From: les2
|Date: Tue Jul 11 14:34:50 CDT 1989
|UA-Content-ID: <PMX-LAN-2.01-910404-afbf02-les2-1205>
|End-of-Header:
|Email-Version: 2
|UA-Message-ID: <PMXSTAR-S2.0-les2-3>
|Subject: test from pmx-starmail
|To: afbf01!les 
|End-of-Protocol: 
|Content-Type: multipart
|Content-Length: 14871        
|
|Content-Type: Text
|Content-Length: 56        
|
|This is text in the body of the message.
|text
|text
|
|
|Content-Type: Binary
|Content-Name: E:\DC\PKXARC.COM
|Content-Abstract: this was entered as a description
|Encoding-Algorithm: btoa
|Content-Length: 14605
|
|xbtoa Begin
|pQAVU!U9Z<!NkQma5+XAeS*<Q(>?Dgo@<bGeRlo%^5E,k]mV?YIK1hGmF`cE 1C'E0UfaT!L*#o.&k
|<o!oEt0!T+%4!T+=D!T*k*zzzzzzzzzz   S1  !It-MgXg4rm8e9JAm]6RGSY*<[hi$03>[zzz7S%
|    [ 179 lines of 78 chars + CR/LF deleted ]
|V\Db+;$*DU$#Bg3_,F$F\*Bh<Ks /AS^E((m0E^jinzzzzzzzz   #$"53`bz
|xbtoa End N 11482 2cda E 82 S 13fdec R 9e78bdcc
|
-----------------
Without encoding, binary attachments would omit the Encoding-Algorithm: line
and include the binary image after the blank line following the
Content-Length: header (useful only if your MTA can handle it).  Text
file attachments are similar but with Content-Type: Text.

Les Mikesell