problem with attachments using tcllib smtp/mime
Ulrich Schöbel
I'm having a strange problem when sending out mails with
attachments using tcllib's mime/smtp package. Most of the
mails are received fine with all attachments readable. A
few receivers complain they cannot open the attachment (a
MS Word document).
It is attached with a name and file name of "HM01.doc", but
receive it as "ATT00040.dat" or similar. What causes this
strange name change? When the same mail is sent out by MS
Outlook, everything is fine.
Looking at the raw message text I see three differences:
1.) There are a couple of headers in the Outlook version,
which I don't have in my mails:
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Virus-Scanned: ClamAV using ClamSMTP
Status: R
X-Status: NT
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:
Can they be responsible for this behaviour?
2.) The boundary string in Outlooks messages starts with
"------=_NextPart......."
mine starts with
"----- =_........." (contains a blank before the =)
3.) between the headers section and the first mime part
there is a message "This is a multi-part message in MIME format.".
I know this message is ignored by mime readers, but maybe
some MS mail clients rely on its presence.
I don't know wether this behaviour is a malfunction of
the receiving mail servers or their virus scanners or by
the mail clients.
Did someone in this group experience similar effects?
What can I do get my mails delivered to those clients?
Any help or suggestions are welcome. An entire project
depends on getting this clear.
Thanks and kind regards
Ulrich
Michael Schlenker
> Hi all,
>
> I'm having a strange problem when sending out mails with
> attachments using tcllib's mime/smtp package. Most of the
> mails are received fine with all attachments readable. A
> few receivers complain they cannot open the attachment (a
> MS Word document).
>
> It is attached with a name and file name of "HM01.doc", but
> receive it as "ATT00040.dat" or similar. What causes this
> strange name change? When the same mail is sent out by MS
> Outlook, everything is fine.
>
> Looking at the raw message text I see three differences:
>
> 1.) There are a couple of headers in the Outlook version,
> which I don't have in my mails:
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
> X-Virus-Scanned: ClamAV using ClamSMTP
> Status: R
> X-Status: NT
> X-KMail-EncryptionState:
> X-KMail-SignatureState:
> X-KMail-MDN-Sent:
Those headers are irrelevant.
>
> Can they be responsible for this behaviour?
>
> 2.) The boundary string in Outlooks messages starts with
>
> "------=_NextPart......."
>
> mine starts with
>
> "----- =_........." (contains a blank before the =)
Boundary strings are arbitrary...
>
> 3.) between the headers section and the first mime part
> there is a message "This is a multi-part message in MIME format.".
> I know this message is ignored by mime readers, but maybe
> some MS mail clients rely on its presence.
>
> I don't know wether this behaviour is a malfunction of
> the receiving mail servers or their virus scanners or by
> the mail clients.
>
> Did someone in this group experience similar effects?
> What can I do get my mails delivered to those clients?
>
> Any help or suggestions are welcome. An entire project
> depends on getting this clear.
>
What headers do you set on the attachements mime part, that determines
the file name
and other things, can you post the mail sending code?
Michael
Ulrich Schöbel
Am Sat, 30 Sep 2006 15:22:27 +0200 schrieb Michael Schlenker:
> Ulrich Schöbel schrieb:
>> X-KMail-MDN-Sent:
>
> Those headers are irrelevant.
Yes, at least according to the specs.
>
> Boundary strings are arbitrary...
They should be, yes.
> What headers do you set on the attachements mime part, that determines
> the file name
> and other things, can you post the mail sending code?
General structure of a mail as sent:
MIME-Version: 1.0
Content-ID: <1621.115...@localhost.localdomain>
Subject: Newsletter HM01
From: "Senders Address" <na...@domain.tld>
Return-Path: <na...@domain.tld>
To: reci...@recdomain.tld
X-Mailer: NLDP Distribution Daemon
Content-Type: multipart/mixed;
boundary="----- =_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y="
------- =_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y=
MIME-Version: 1.0
Content-ID: <1621.115...@localhost.localdomain>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Some text message.
------- =_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y=
MIME-Version: 1.0
Content-Disposition: attachment;
filename="HM01.doc"
Content-ID: <1621.115...@localhost.localdomain>
Content-Type: application/msword;
name="hm01.doc"
Content-Transfer-Encoding: base64
U0EgbGF1bmNoZXMgbWFsYXJpYSByZXNlYXJjaCBpbml0aWF0aXZlCgpTQ0lF
...... lots of base64 stuff ...........
IEJ1c2luZXNzIERheSwgOCBGZWJydWFyeSAyMDA2Cg==
--------=_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y=--
Everything looks ok in my eyes, but the recipient receives
an attachment named "ATT00040.dat", obviously changed by
a receiving virus scanner, which he cannot open due to
windows dependency on extensions. Renaming it to "xxx.doc"
makes it perfectly readable. But the receivers aren't
willing to rename attachments, they probably don't even
know how.
I'm stuck. Why do their servers or virus scanners or email
clients accept a message sent by Outlook, but not the one
sent by the smtp/mime package?
Peeling the code out of the app is a bit more work to do,
I hope the above result of this code gives enough hints.
If not, I can provide the code later.
Did someone see similar effects and found a way to solve
that? I'm sure it's only a minor thingie which makes one
of the receiving components hiccup.
Thanks
Ulrich
David Gravereaux
Hash: SHA1
Ulrich Schöbel wrote:
> ------- =_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y=
> MIME-Version: 1.0
> Content-Disposition: attachment;
> filename="HM01.doc"
> Content-ID: <1621.115...@localhost.localdomain>
> Content-Type: application/msword;
> name="hm01.doc"
> Content-Transfer-Encoding: base64
>
> U0EgbGF1bmNoZXMgbWFsYXJpYSByZXNlYXJjaCBpbml0aWF0aXZlCgpTQ0lF
> ....... lots of base64 stuff ...........
> IEJ1c2luZXNzIERheSwgOCBGZWJydWFyeSAyMDA2Cg==
>
> --------=_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y=--
Looks perfect to me, too. I know it isn't possible for you to control
the mistakes of a virus scanner along the path of delivery, but it might
be worthwhile to contact someone either at the company that wrote it, or
the person responsible for operating it and get them to explain *their*
bug to you.
- --
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFHtt5lZadkQh/RmERArgBAJ9ZB4soXpajHSiBCv7jAkeiNOPmtACfSClp
1sCJU3srcpf7c2sdK0pfMok=
=JMdS
-----END PGP SIGNATURE-----
Ulrich Schöbel
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ulrich Schöbel wrote:
>
>> ------- =_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y=
>> MIME-Version: 1.0
>> Content-Disposition: attachment;
>> filename="HM01.doc"
>> Content-ID: <1621.115...@localhost.localdomain>
>> Content-Type: application/msword;
>> name="hm01.doc"
>> Content-Transfer-Encoding: base64
>>
>> U0EgbGF1bmNoZXMgbWFsYXJpYSByZXNlYXJjaCBpbml0aWF0aXZlCgpTQ0lF
>> ....... lots of base64 stuff ...........
>> IEJ1c2luZXNzIERheSwgOCBGZWJydWFyeSAyMDA2Cg==
>>
>> --------=_RDkwOEMzQTJEMzZGRUVERkREMjBDQzUyQjBGNDU0N0Y=--
>
>
> Looks perfect to me, too. I know it isn't possible for you to control
> the mistakes of a virus scanner along the path of delivery, but it might
> be worthwhile to contact someone either at the company that wrote it, or
> the person responsible for operating it and get them to explain *their*
> bug to you.
>
Hi David,
thanks for verifying the correctness. Unfortunately I'm in a
really bad position in this game: The receivers are clients
of my client, lack any technical knowledge and are absolutely
unwilling to cooperate. They simply say "It works the other
way, so make it work your way." I have to mimic the Outlook
behaviour, be it correct or not. My hope was, I'm not the
first one to fall into this trap.
It's good to know my way is correct, but it doesn't really
help.
Thanks
Ulrich
Michael Schlenker
Ulrich Schöbel
Hi Michael,
this seems to be a very hot hint. I'll take a closer
look at it. It may take quite some time to report
success/failure, as I need to find a volunteer
recipient for tests.
Thank you so much
Ulrich
John Mercogliano
I had something similiar happen with Novell Groupwise with the
attachments showing up as part.001 part.002...
I added the name clause to my canonical string and that fixed it
for me. Example:
set token [mime::initialize -canonical
"application/txt;name=\"testdoc.rtf\"" -file testdoc.rtf]
Hope this helps.
John