tmoore@ciss.Dayton.NCR.COM (Tom.Moore@ciss.Dayton.NCR.COM) (02/17/89)
We have run into an interesting problem with mail from cron and the Elm mail system. Given that the following message from cron placed in your mailbox: + From ciss.Dayton.NCR.COM!root Wed Feb 15 23:58 EST 1989 + chmod: can't change dead.letter + /usr/lib/uucp/deadletter.sh: dead.letter: cannot create + + + ******************************************* + Cron: The previous message is the standard output + and standard error of one of your cron commands. When the message is read, it appears as: + Message 1/9 from ciss.Dayton.NCR.COM!root Feb 15 '89 at 23:58 pm + + + chmod: can't change dead.letter + /usr/lib/uucp/deadletter.sh: dead.letter: cannot create + + + ******************************************* + Cron: The previous message is the standard output + and standard error of one of your cron commands. So far so good. However when the user tries to print the same message, it prints out as: + From: ciss.Dayton.NCR.COM!root + Wed Feb 15 23:58 EST 1989 + + + ******************************************* + Cron: The previous message is the standard output + and standard error of one of your cron commands. The problem appears to be when Elm rearranges the header information, it simply discards the two lines of text assuming they are some sort of header lines that it does not understand. After all, they are before the blank line. The raises the questions: 1. Should Elm discard things that it does not understand. 2. Should Elm show me one thing on the screen and then print something else on the printer. This is particularly unfortunate since it is not noticed until after deleting the messages, exiting Elm, and strolling over to the printer to pick up the hard copy you thought you had. 3. Is there some reasonable way around this that someone already knows. Numbers 1 and 2 are open to discussion (as if I had a choice after posting this). Number 3 requires a resolution. It's hard to get people to use something when as soon as they start to feel good about it, something like this happens. For myself, I like Elm and will continue to use it. My short term solution for myself is "If it hurts, don't do it). -- * Tom Moore NCR Corporation PCD-6 (513) 445-1373 * * Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network Applications Dayton, OH 45479 Tom.Moore@Dayton.NCR.COM *
rob@pbhyf.PacBell.COM (Rob Bernardo) (02/18/89)
In article <447@ciss.Dayton.NCR.COM> tmoore@ciss.Dayton.NCR.COM (Tom.Moore@ciss.Dayton.NCR.COM) writes:
+
+We have run into an interesting problem with mail from cron and the Elm
+mail system. Given that the following message from cron placed in
+your mailbox:
+
++ From ciss.Dayton.NCR.COM!root Wed Feb 15 23:58 EST 1989
++ chmod: can't change dead.letter
++ /usr/lib/uucp/deadletter.sh: dead.letter: cannot create
++
++
++ *******************************************
++ Cron: The previous message is the standard output
++ and standard error of one of your cron commands.
+
AHA! This message does NOT conform to RFC822 standards and ELM presumes
it does. The 2nd and 3rd lines conform to RFC822 standards for header
lines by both their format and by their position in the message.
It has been noted by the ELM development group that mail/rmail, the
standard Sys V mail transport agent, does not insert the standard null
line between the header and the body of the message. This will
"confuse" ELM **OR ANY OTHER MAILER** that adheres to the RFC822
standards in expecting a null line between the header and the body.
This problem will occur if someone composes mail directly with USG mail,
instead of using mailx, elm, etc. The cron demon uses mail unfortunately.
I think AT&T has done a terrible misservice by not adhering to RFC822.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiasyd@dsinc.UUCP (Syd Weinstein) (02/19/89)
In article <447@ciss.Dayton.NCR.COM> tmoore@ciss.Dayton.NCR.COM (Tom.Moore@ciss.Dayton.NCR.COM) writes:
:
:We have run into an interesting problem with mail from cron and the Elm
:mail system. Given that the following message from cron placed in
:your mailbox:
:
:+ From ciss.Dayton.NCR.COM!root Wed Feb 15 23:58 EST 1989
:+ chmod: can't change dead.letter
:+ /usr/lib/uucp/deadletter.sh: dead.letter: cannot create
:+
:+
:+ *******************************************
:+ Cron: The previous message is the standard output
:+ and standard error of one of your cron commands.
Ah, yes, the USG not following RFC822 problem. Here is the
problem with this message: Header lines are defined as
all lines up to the first empty line. Elm showed you the
header because those items weren't on your weedout list.
What you have is that the standard Unix mailer in USG (system V)
systems does not apply RFC822 standards, yet Elm does.
Thus Elm cannot tell where the header stops.
:
:The raises the questions:
:
:1. Should Elm discard things that it does not understand.
Elm thought it did understand them, they were 'RFC822 Headers'
:2. Should Elm show me one thing on the screen and then print something
: else on the printer. This is particularly unfortunate since it is not
: noticed until after deleting the messages, exiting Elm, and strolling over
: to the printer to pick up the hard copy you thought you had.
Yes, Elm does not send all the headers to the printer if you tell
it not to (and I assume you did since it didn't copy the entire message)
:3. Is there some reasonable way around this that someone already knows.
From, cron, no, in general, it won't be a problem as the standard user
headers end up with a blank.
How we solved this problem for the future is we extended Elm to try
and cope with non RFC 822 mailers. We now define the end of the
header as the first line that doesn't look like a header or a header
continuation line. We can still get confused by lines that look
like headers, so it isn't a total fix.
(A header is a line starting in column 1 and containing a :, or a line
following a header line that starts with whitespace)
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
{allegra,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235rob@pbhyf.PacBell.COM (Rob Bernardo) (02/20/89)
In article <63@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes:
+How we solved this problem for the future is we extended Elm to try
+and cope with non RFC 822 mailers. We now define the end of the
+header as the first line that doesn't look like a header or a header
+continuation line. We can still get confused by lines that look
+like headers, so it isn't a total fix.
+(A header is a line starting in column 1 and containing a :, or a line
+following a header line that starts with whitespace)
And the only way to know if a header-appearing line is not a header
is to divine the sender's intentions, which, for the time being,
not a possibility with ELM :-)
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiatmoore@ciss.Dayton.NCR.COM (Tom.Moore@ciss.Dayton.NCR.COM) (02/20/89)
In article <63@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: >Yes, Elm does not send all the headers to the printer if you tell >it not to (and I assume you did since it didn't copy the entire message) This raises an interesting point. If I told Elm not to copy the entire message to the printer, I wasn't aware that I did it. Actually I looked through the documentation provided to see if there was a way to tell Elm print the entire message (something similar to using the "h" command while reading mail) and I found nothing. How does one tell Elm to print the enire message to the printer without interpreting headers? -- * Tom Moore NCR Corporation PCD-6 (513) 445-1373 * * Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network Applications Dayton, OH 45479 Tom.Moore@Dayton.NCR.COM *
les@chinet.chi.il.us (Leslie Mikesell) (02/21/89)
In article <4723@pbhyf.PacBell.COM> rob@pbhyf.PacBell.COM (Rob Bernardo) writes: >I think AT&T has done a terrible misservice by not adhering to RFC822. How else could they sell their extra-cost PMX mailers? Les Mikesell
les@chinet.chi.il.us (Leslie Mikesell) (02/21/89)
In article <63@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: >How we solved this problem for the future is we extended Elm to try >and cope with non RFC 822 mailers. We now define the end of the >header as the first line that doesn't look like a header or a header >continuation line. We can still get confused by lines that look >like headers, so it isn't a total fix. >(A header is a line starting in column 1 and containing a :, or a line >following a header line that starts with whitespace) Why don't you add the ability to recognize the headers used by AT&T's PMX mailers and the replacement for /bin/mail that comes with them? (I suspect this will become standard in SysVr4.) There is a Content-Type: header followed by a Content-Length: header. There is one blank line after the Content-Length header, then the number of characters specified as the length are unambiguously the body so you don't have to worry about lines that start with "From" or things that look like headers. A "Content-Type: Multipart" may precede several attachments, each with its own Content-Type: and Content-Length: header. It is a very handy feature to be able to attach files to mail and the PMX mailers will allow binary attachments if the receiving machine and intermediates are known to allow them. Les Mikesell
syd@dsinc.UUCP (Syd Weinstein) (02/23/89)
In article <7779@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Why don't you add the ability to recognize the headers used by AT&T's >PMX mailers and the replacement for /bin/mail that comes with them? >(I suspect this will become standard in SysVr4.) That is another issue entirely, the discussion about AT&T stemed from the default /bin/mail that does not put in a blank line. PMX and its /bin/mail does put in the blank line, so its not a problem. Its only the old /bin/mail that causes the problem. Using Elm solves that problem when you send messages, it cannot figure out what to do for read ones. PMX mailers would have a similar problem for other non standard headers if the blank line was missing. Its a universal problem, even AT&T has to live with it. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 {allegra,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
les@chinet.chi.il.us (Leslie Mikesell) (02/27/89)
In article <76@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: >>Why don't you add the ability to recognize the headers used by AT&T's >>PMX mailers and the replacement for /bin/mail that comes with them? >That is another issue entirely, the discussion about AT&T stemed from >the default /bin/mail that does not put in a blank line. But it is a solution to the same problem, just done by a different program (the /bin/mail that comes with PMX). On inbound messages from other systems that do not have the blank line it must figure out where the end of the previous headers is to insert the Content-Type etc. headers. Elm could do likewise. Seems a little nicer than discarding the content. Les Mikesell
syd@dsinc.UUCP (Syd Weinstein) (02/27/89)
In article <7826@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <76@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: >But it is a solution to the same problem, just done by a different program >(the /bin/mail that comes with PMX). On inbound messages from other >systems that do not have the blank line it must figure out where the >end of the previous headers is to insert the Content-Type etc. headers. >Elm could do likewise. Seems a little nicer than discarding the content. Again, if the message does not have a content-type/content-length already in them, and the messages in question, from cron, didn't, Elm would still have to guess where the content started even if it did add the headers. What happens is without the blank line, Elm would guess wrong and put in Content headers which still said the relavant text was headers. Either you make your headers RFC822 complient, or Elm can misguess. Elm 2.2 is a little better about guessing, but without trying to understand the content of the message itself, its impossible to be any better than that. And Elm is not an expert shell. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 {allegra,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235