🚀 go-pugleaf

andys@flatline.sbi.com (Andy Sherman) writes:
>We are running Solaris 2.1 and I've noticed a change in sendmail.  To better
>integrate with the multimedia mailtool, sendmail makes sure there are
>Content-Type and Content-Length headers in every message.  Since it
>now *knows* the body length of a message, it has no need to prepend a
>'>' to every line beginning with \nFrom.  So it doesn't.  The result is
>that when my boss forwards a message to me, inc splits it into two

What happens if a message already has a content-length header, but
Sun's sendmail doesn't agree with the length given?  TOPS20 used
a mailbox format which included file lengths... it sure was a pain
to edit those mailbox files.

As for MH, it supports the UUCP-style (From user date ...) and
MMDF-style (ctrl-A) mailbox formats.  It doesn't support the newly-
discovered Solaris-broken-UUCP-style mailbox format.

It seems likely that other UAs will also not understand the
Solaris-broken-UUCP-style mailbox format.  Perhaps fixing
/bin/mail to write the '>' characters is the right thing to do?
--
John Romine

andys@flatline.sbi.com (Andy Sherman) writes:
>Interesting problem here.  We are running Solaris 2.1 (a/k/a SunOS 5.1
>a/k/a Sun's SVr4), and I've noticed a change in sendmail.  To better
>integrate with the multimedia mailtool, sendmail makes sure there are
>Content-Type and Content-Length headers in every message.  Since it
>now *knows* the body length of a message, it has no need to prepend a
>> to every line beginning with \nFrom.  So it doesn't.  The result is
>that when my boss forwards a message to me, inc splits it into two
>parts.

I believe the AnswerBook covers this, but...

In your /etc/mail/sendmail.cf file, add the 'E' flag to the flags
in the local and prog mailers.  Re-freeze the config file, restart
sendmail, etc.  The SVR4 headers are still added, but the From
lines will be quoted.

My workaround to get rid of all of the SVR4-isms was to use
slocal and have my .maildelivery file just put everything into
/var/mail.  slocal at least did it properly.

Cheers!greg

PS.  I don't think the new mail format has anything to do with
mailtool but was a change made by AT&T.  Does someone have an
authoritative answer?

jromine@binky.ics.uci.edu (John Romine) writes:

>andys@flatline.sbi.com (Andy Sherman) writes:
>>We are running Solaris 2.1 and I've noticed a change in sendmail.  To better
>>integrate with the multimedia mailtool, sendmail makes sure there are
>>Content-Type and Content-Length headers in every message.  Since it
>>now *knows* the body length of a message, it has no need to prepend a
>>'>' to every line beginning with \nFrom.  So it doesn't.  The result is
>>that when my boss forwards a message to me, inc splits it into two

>What happens if a message already has a content-length header, but
>Sun's sendmail doesn't agree with the length given?  TOPS20 used
>a mailbox format which included file lengths... it sure was a pain
>to edit those mailbox files.

First of all, it isn't sendmail that adds the Content-Length: header,
it is the local mailer. It fixes the Content-length header if you
send a wrong one, as it should. (Or it simply always replaces it).

>As for MH, it supports the UUCP-style (From user date ...) and
>MMDF-style (ctrl-A) mailbox formats.  It doesn't support the newly-
>discovered Solaris-broken-UUCP-style mailbox format.

Ah. The ``ugly hack with >From'' is better? Bullshit. A Content-Length:
header seems the only right way (no need to escape anything in any message).

>It seems likely that other UAs will also not understand the
>Solaris-broken-UUCP-style mailbox format.  Perhaps fixing
>/bin/mail to write the '>' characters is the right thing to do?

Elm does understand Content-Length: headers. MH is the only other
mail agent we have installed that doesn't come with the system. All
Solaris UA understant Content-Length: headers.

Fixing MH would be the proper thing to do.

Casper

I originally asked: 

andys> We are running Solaris 2.1 and I've noticed a change in
andys> sendmail.  To better integrate with the multimedia mailtool,
andys> sendmail makes sure there are Content-Type and Content-Length
andys> headers in every message.  Since it now *knows* the body length
andys> of a message, it has no need to prepend a '>' to every line
andys> beginning with \nFrom.  So it doesn't.  The result is that when
andys> my boss forwards a message to me, inc splits it into two parts

>>>>> On 8 Jan 93 23:36:22 GMT, jromine@binky.ics.uci.edu (John Romine) said:

jromine> What happens if a message already has a content-length header, but
jromine> Sun's sendmail doesn't agree with the length given?  TOPS20 used
jromine> a mailbox format which included file lengths... it sure was a pain
jromine> to edit those mailbox files.

I haven't tested what sendmail does with pre-existing content-length
headers if broken transport agents change the body length.

jromine> As for MH, it supports the UUCP-style (From user date ...) and
jromine> MMDF-style (ctrl-A) mailbox formats.  It doesn't support the newly-
jromine> discovered Solaris-broken-UUCP-style mailbox format.

jromine> It seems likely that other UAs will also not understand the
jromine> Solaris-broken-UUCP-style mailbox format.  Perhaps fixing
jromine> /bin/mail to write the '>' characters is the right thing to do?

No, it is not in the cards for me to mung /bin/mail.  Another poster
pointed out that sendmail *does* have an option to quote From_ lines,
which I may do, although I'd much rather teach MH to grok
Content-Length headers (the ugly hack is building as we speak).  My
reasoning is that Sun did *not* break UUCP-style maildrops, but rather
they unbroke them in preparation for things like a) their multi-media
mail, b) MIME, and c) X.400, all of which use content-length to give
you a definitive answer to the question "Where does the $%$##@# body
end, anyway?"  IMHO, the >From convention is an ugly hack to deal
with the fact that the UUCP-style maildrop was deficient.  Since the
lack of >From-ing only affects the local system (since remote
/bin/rmail's will do what's right for themselves), I'll fix any local
3rd party tools to match Sun.  Now if they'd only have mailtool use
MIME instead of X-Sun headers.....


--
Andy Sherman
Salomon Inc  -  Unix Systems Support  -  Rutherford, NJ
(201) 896-7018  -  andys@sbi.com or asherman@sbi.com
"These opinions are mine, all *MINE*.  My employer can't have them."