email from *nix to Exchange - text formatting issue

ETC Microsoft Windows
1

Oracle Linux 5.6 x-86-64 (Red Hat derivitive)

I have several shell scripts that capture output to a log file, then use that log file as the source of an email. For a very simplified example:

 
echo Today is `date` >> $logfile
/bin/mail -s "$subject" "$sendto" < $logfile

(yes, $subject and $sendto are also set)

Mail from the linux server is aliased and redirected to my Outlook account on the Exchange server.

Problem is that some of the lines get wrapped in the email. I've examined the log file with a hex editor and found that the x'0D' terminators are all exactly where they should be, but some lines are still wrapped in the body of the email. And it's not consistent. For example, if the log file has this:

 
abc
def
ghi
jkl
mno
pqr

The email may show

 
abc def ghi
jkl
mno
pqr

Or it may show

 
abc
def
ghi jkl mno
pqr

echo >> $logfile

I have also observed the same behavior when my servers were running HP-UX. But I've not had much like from that side so thought I'd see if there were any insights from this side of the house.

Of course, our in-house Exchange guys insist it must be a *nix issue. Riigght. :wall:

2

And there is not any message at the top of outlook which says,
Extra line breaks in this message have been removed. Click here to restore. ?

3

Assuming that your file has records terminated with carriage-return line-feed, we can probably eliminate the format of the file.

There is a little-known "feature" of Microsoft Outlook where a default changed at Outlook 2003 and has been wrong ever since:

From Outlook:
Tools / Options / Preferences /E-mail Options
Uncheck "Remove extra line breaks in plain text messages".

2 Likes
4

We frequently see our exchange server try to dink with carriage control in messages from unix. A common exchange notification when you open the message is:

"extra line breaks in this message were removed" in a blue band at the email head.
Clicking on the band resores the "extra" line breaks.

and we have lines that were separate globbed together by exchange, just like in your example. This appears to be your problem, too. We get arround it:

# note we add .txt so windows can open the file with word
unix2dos logfile logfile.txt
uuencode logfile.txt logfile.txt | mail -s 'subject'  who@where.com

Exchange does not mess with those attachments.

More of a UNIX-side solution

1 Like
5

That seems to have fixed the issue. Thanks

"Have I told you lately how much I dislike Windows?"

---------- Post updated at 12:06 PM ---------- Previous update was at 11:44 AM ----------

I've used that solution before and while I prefer something I can control from the *nix side, I also prefer - for these jobs - to just dump the log into the body of the mail instead of an attachment.

Also, I really was curious about the cause and not just a work-around without understanding what was really going on. Looks like another find MS "feature". It's really amazing how often I search for a solution to some Windows issue and find that people have been finding and reporting the same issue through multiple versions of Windows for several years and MS still has no answer.

1 Like
6

The answer to that and many other MS "features" would have been, "don't do that".

But since they did, it is now "standard" in their eyes and will not change unless they feel like it.

7

@edstevens
Like many Systems Administrators I work with a mixed M$ and unix/Linux (and more) environment. It never ceases to amaze me how M$ can make arbitary unannounced changes to their O/S without considering the consequences. This case was sort of trivial, but had worldwide impact on non-M$ systems.
I personally wasted a day finding out what was different between two of my desktops then spent another day writing-up a fix for umpteen other desktops which had a recent M$ "upgrade".