Maybe somebody who knows a lot about email can help me.  The only way I can
find to fix my current email problem is to do something that caused a worse
problem in the past.

We send reports out from the HP as attachments in rich text format, using the
nmmail program from Telamon / Vytek.  Almost everyone can read them just fine,
but two sites are having problems.  They both seem to be using webmail
programs which I am not familiar with (Yahoo & Juno).  Their symptom is that
the attachments show as if they were in the message body, with the RTF codes
visible.  Of the webmail programs I do know, AT&T's has the same problem and
SBC's has a different problem.  AOL, Outlook Express and Mozilla Thunderbird
all work correctly -- a few mouse-clicks, Word runs, and a correctly-formatted
report appears.

All this is with nmmail's attachment code '-a', which means "base64 encoded".
We are on the current version of the nmmail program, just downloaded last
week.

Experimenting with 10 different attachment / encoding codes, the only one that
works for Outlook Express and AT&T & SBC webmails is code '-zp', (quoted
printable, force binary).  2nd best is '-ap', (quoted printable not binary),
which fails on At&t.  Most combinations work with OE and fail on both webmails
with varying symptoms.

The command to send is something like:
MAIL.NETWORK.TELAMON "-t [log in to unmask] -zp h20000.rtf.ssidev=h20000.rtf -m
MSGBODY"
with the '-zp' changing for every test.


So far, this sounds easy.  Just change to quoted printable binary.  But,
quoted printable caused horrid problems with my other email application 18
months ago.


The other app sends text file attachments.  It used '-ap' quoted-printable
successfully for a few months, then we had one text file what would go partway
and die no matter who I tried to send it to.  Nmmail would issue an error code
and die, and the recipient would get about half the file.  I never figured out
what caused it, but changing to '-a' base64 encoded fixed it.

Re-testing with the current version of nmmail duplicates the problem, and
'-zp' quoted printable binary is even worse -- it hangs the email-sending job
and I have to abort it.  The problem file is not especially large, and does
not have any non-printable characters.

The original file has 127 lines, with the following near the middle:

POS#1/SCR#2/LT.GREEN- PLS MAKE IT SLIGHT LESS YELLOW & BLUER.

POS#2/SCR#1/DK.GREEN- IT IS TOO DARK, PLS MAKE IT LIGHTER.

and if I send it quoted-printed, non-binary, the attachment that arrives at my
PC ends with:

      POS#1/SCR#2/LT.GREEN- PLS MAKE IT SLIGHT LESS YELLOW & BLUER=

It always dies on the same line, but sometimes it ends with 'BLUE' instead of
'BLUER='.

Shortening the file to just the lines you see above still fails on the same
line.  But it works if I change it from variable length w/o trailing banks to
fixed-length with blanks, and also add nmmail's "b" code to tell it not to
strip trailing blanks.  However, I don't want to send trailing blanks to
everybody, on text files or rtf, and every file the HP sends is built
variable.

If I replace the 1st half of the problem line with random characters it works,
even variable w/o blanks.  If nobody has any better ideas, I'll eventually try
changing one byte at a time looking for one exact character combo that kills
it.  But that won't really matter because I can't live with something that
likes to fail on plausible-looking characters that might show up again.

The error message is:
3-060445843 Message accepted for delivery

550 Command not implemented


MAIL.NETWORK.TELAMON "-t [log in to unmask] -ap EA68485.TXT -nomsg"
Program terminated in an error state. (CIERR 976)


So, I'm afraid to change the encoding on my RTF attachments to "quoted
printable" untill I can be sure that won't mess up email-sending.  And that
means 'never' unless I know what makes that one text file fail.  I don't even
want to test with my problem customers because it might be awkward if we test
something that works and then I chicken out on implementing it because I don't
want our email-sending jobs to die.

Anybody know a fix ?  So I can safely send RTF attachments that webmail users
can read ?


Dave Powell,    MMfab

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *