uuencode not sending attachments in right format anymore

[KPS]

Hi,

We have been using uuencode to send attachments for reports to person's email boxes in Exchange/Outlook from HP-UX 11.11 OS for years.

Suddenly within the last week this started to not work properly. The recipients get the email and attachment, but the attachment is illegible and has control characters and incorrect format strings. Any ideas?

Our original syntax is:

uuencode report.txt report.txt|mailx -m -s "report.txt "

I've also tried: (Per another forum thread's recommendation)

ux2dos report.txt | uuencode report.txt report.txt|mailx -m -s "report.txt "

Would anyone have any other ideas on what could be suddenly causing this?????

[Peter Godron]

Hi,
looking at man uudecode:
"If an encoded file has the same name as the destination name specified in it, uudecode starts overwriting the encoded file before decoding is completed."

Start with changing the filenames. [Unlikely]

Ask the receiever to 'stitch' the attachments together and then do a uudecode.
[Proof format problem, not mailreader application]

Has anything changed in the transmission path ? Additional mail gateways/firewalls ?

[KPS]

Changing filenames didn't change the symptom. There are no firewall changes between my HP-UX server and the Exchange environment through/from which the email comes from.

[Yang Qin_1]

Can you send the same attachment from "elm" to exchange and see if the attachment displayed correctly? If it is correct, then ux2dos will not help.

Can you post email header here (attachment related info but not those relay address)? so we can understand more on how exchange treat the attachment sent from your Unix server.

[KPS]

elm is not setup on my system and to do so will cause me to submit change records to get this setup. I'd rather not go down the path of elm if I can help it.

Please indicate what you mean by email header?

[spex]

Hi,

I realize this may not suit your requirements, but if report.txt is ASCII data, you can simply make it the body of your message:

# mailx -m -s "report.txt appears in body" your@email.addr < report.txt

I suspect something has changed on your relay. Has new software (e.g. anti-virus, anti-spyware, firewall) been installed on the Windows server? Has the OS been updated recently?

Has anything changed on the client PCs?

PCS

[KPS]

Thanks for the recommendations for putting in the body of the email. I think we would feel more comfortable knowing why this has changed however.

(Realizing this is the more difficult road to take)

I talked to our Exchange folks and they're saying they have not done any changes since August. This issue started only a week or so ago.

[Yang Qin_1]

If you use Outlook to read emails sent to exchange, then from view/option you will find a field "Internet header" like this one:

.............
Message-Id: <451a1835.86@happydays.be>
From: XXXX
To: xxxxxx
Subject: xxxxxxx
Date: Wed, 27 Sep 2006 08:20:37 +0200
Reply-To: No Reply
X-MA-Reference: 5v7y12hn55Y5FI0_anz555W
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NexPart_000"
X-UIDL: 00000000001f871d.0000075f
X-MSP-STORE: Wed, 27 Sep 2006 08:20:50 +0200
Status:

[Steven E. Protter]

Shalom,

If it was working and you changed nothing and suddenly it does not work:

Its probably a change somewehre else. smtp gateway upgrades or changes can introduce bugs that make file attachments fail.

You script may not however be adequate to the new situation.

Here is a production script that works well. Do change the default email addresses in it if any are still hard coded.

http://www.hpux.ws/mailfile2

SEP

[KPS]

Attached is the email header you were wanting to look at.

[Yang Qin_1 · Accepted solution]

As you used "-m" option with mailx, Mime Version, Content Type & Content Encoding are not added to the header.

I did a test from my Unix server to exchange and the MIME header shows:

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

And the attachment looks OK with Wordpad but with Notepad, there is no line break

With
ux2dos report.txt | uuencode report.txt|mailx -m -s "report.txt "

The attachment can be read with Notepad without problem.

Because with ux2dos you used "ux2dos report.txt |uuencode report.txt report.txt|.." uuencode didn't take the output from ux2dos instead it read from the file report.txt. So, it make no difference.

[Arturo Galbiati]

Hi,
I got some problem in teh past. It was due to the chnage in outlook server by Microsoft.
You can fix this in 2 ways:
1. add -m to each of your mail command line
2. create a .mailrc file in the home directory of teh user used to send mail and put 'set mimeheader=no'
$ cat .mailrc
set mimeheader=no

The seond way it's better because avoid you to chnage all your scripts.

HTH,
Art

[KPS]

If you look at my original syntax earlier in this forum thread, I was using the -m option so I guess I already had your option #1 covered.

As far as option #2 goes, I have tried creating a .mailrc file and setting:

set mimeheader=no

Even with this set, I'm still seeing the same symptom of the attachment being illegible and in the incorrect format unfortunately.

Thanks everyone for your ideas and suggestions. I'm going back to the SMTP and Exchange folks with this issue as I believe this is where something has changed to affect this process.

[Calandrello]

the applicatory native of email that sends attached archives and the Elm.

[Hoey]

Hi KPS

We are having exactly the same problem like yours recently. All HP servers cannot send as attachment but servers running solaris can. No one changed any script, strange, isn't it? I wonder if you have your problem resolved?

Cheers

Davis

[KPS]

We are now fixed. We ended up routing our mail right to the SMTP Server rather than to relay servers at certain sites like we were doing.

We had to build a ruleset on the SMTP server to allow the client to forward the mail directly to it. We never really figured out what actually caused this, but we suspect this was a Service Pack on the MS Exchange side. Since it's now working, we didn't spin wheels to further troubleshoot. Hope this helps...

[KPS]

Our issue is now resolved. Thanks to all for their recommendations.