🚀 go-pugleaf

In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes:
> From article by les@chinet.chi.il.us (Leslie Mikesell):
> > AT&T's PMX mailer products include a new /bin/mail that uses
> > Content-Type: and Content-Length: headers to avoid the problem.

> ..  If the text following Content-length bytes is not "From",
> seek back to Content-length and do normal "look for the From line"
> processing see, great solution :-() going to do with a file that has
> been altered by an unknowing editor (like vi or emacs)?  Once again
> another format has been chosen that absolutely solves nothing!

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.  However, I am speculating that this scheme is not intended for
MUAs at all.  It is probably intended for MTAs that are compatible.
If the MTAs are not compatible, then it either doesn't send the mail
(probably the case for the 8-bit binary mode) or it tries some sort of
conversion from its current format to a well-known one.

For example, if I were to mail myself a folder using this new /bin/mail
program, then I'm sure it would count the number of bytes in the folder,
add the Content-Lenth: header and then send it off to the other site.
Note that the folder I sent has other messages in it that also have
Content-Length: headers.  But the -real- content-length header will be
the only one read.

Ok, so the message goes off to the remote site and it indeed has the
compatible MTA that understand content-length, so the messages it gets
is deposited into the recipient's mbox.  Now, what does the MUA do with
it?  Does this also require an MUA that knows content-length?  And if
so, what does it do about error recovery?  Gregg points out that the
user could have edited his messages.  What then?

I think the content-lenth: and type are fine ideas as long as they
are restricted to the MTA and that the MTAs are compatible.  but,
assuming that the MUA understands the MTA is a -big- mistake.  The MTA
should also prepare itself to convert its "message" into a format which
is RFC822 compliant in case it talks to an MTA that isn'nt compatible
with the originating MTA.

Les' original question to me was: can Mush handle that?  My response
is the question I posed above: What should it do if content-length:
doesn't reprepsent the content length?  I need more "spec".

dan <island!argv@sun.com>
-----
My postings reflect my opinion only -- not the opinion of any company.