• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 424
  • Last Modified:

CDO mail attachment being renamed to invalid file extensions

Hi there,

Okay, here's a problem with CDO that hopefully someone can solve.  The code uses standard cdo message construct:

set oCdoMsg = server.createobject("CDO.Message")

and we are using the method:

strAttachPath = "http://www.ourdomainname.com/tocs2/toc.pdf"
oCdoMsg.AddAttachment strAttachPath

When we send this to various recipients we get various results.  For instance we've never seen the actual file name remain intact, at best we get an email attachment called ATT0024.pdf where the number seems to increment over time, and some other recipients get the attachment of 'File.dat' or 'File.bin'.

In fact on one test case, the attachment was sent to a BT account and it showed in webmail as being a MIME attachment of type PDF yet the file had still been renamed to File.bin.

What on earth is going on?

All help appreciated,

Jay





0
jammy-d0dger
Asked:
jammy-d0dger
1 Solution
 
schaffsCommented:
Jay,

The vb script I found on this appears below.  It appears by using the Attachment method your getting default functionality.  Another method to accomplish the same thing but with specific results appears to be to specify the
mime content-disposition with the filename parameter specified as in the level/2 image/gif section in the example code.

Hope this helps.

Dim iMsg
Dim iBp1
Dim iBp2
Dim iBp3
Dim Stm

Set iMsg = CreateObject("CDO.Message")

With iMsg
   .From    = "Sender@example.com"
   .To      = "PersonA@example.com, PersonB@example.com"
   .Subject = "A html and text message with attachment."
End With

''''''''''''''''''''''''''''''''
' Level 1: multipart/mixed (root)
''''''''''''''''''''''''''''''''
Set iBp1 = iMsg.BodyPart
iBp1.ContentMediaType = "multipart/mixed"


''''''''''''''''''''''''''''''''
' Level 2: multipart/alternative
''''''''''''''''''''''''''''''''
Set iBp2 = iBp1.AddBodyPart
iBp2.ContentMediaType = "multipart/alternative"


''''''''''''''''''''''''''
' Level 3: text/plain
''''''''''''''''''''''''''
Set iBp3 = iBp2.AddBodyPart
With iBp3
   .ContentMediaType        = "text/plain"
   .ContentTransferEncoding = "7bit"
   Set Stm = .GetDecodedContentStream
   Stm.WriteText "Here is the plain text version of the message"
   Stm.Flush
End With


''''''''''''''''''''''''''
' Level 3: text/html
''''''''''''''''''''''''''
Set iBp3 = iBp2.AddBodyPart
With iBp3
   .ContentMediaType        = "text/html"
   .ContentTransferEncoding = "quoted-printable"
   Set Stm = .GetDecodedContentStream
   Stm.WriteText "<html><body><p>Here is the HTML version of the message</p></body></html>"
   Stm.Flush
End With


'''''''''''''''''''''''''''''
' Level 2: image/gif
'''''''''''''''''''''''''''''
Dim Flds
Set iBp2 = iBp1.AddBodyPart
With iBp2
   .ContentMediaType = "image/gif"
   .ContentTransferEncoding = "base64"
   Set Flds = iBp2.Fields
   Flds("urn:schemas:mailheader:content-disposition") = "attachment; filename=""myimage.gif"""
   Flds.Update
   Set Stm = .GetDecodedContentStream
   Stm.LoadFromFile "c:\somewhere\myimage.gif"
   Stm.Flush
End With

' Clean up.
Stm.Close
Set Stm = Nothing
Wscript.Echo iMsg.GetStream.ReadText
0
 
jammy-d0dgerAuthor Commented:
Right schaffs,

This did help, so you can have the points, but I have to say, I didn't use any of the code you included!   Reading it through it seemed like a long-winded bit of code, (or just different from the way I'm used to!), but one thing stuck out, in the example the file is referenced as an absoloute path whereas I was using an HTTP path, (which it states in the MS docs I was reading at the time), but it turns out if you reference a file in the AddAttachment parameter as an HTTP source, it just creates a binary file from whatever it downloads from that path, (makes sense really), so I substituted the line:

strAttachPath = "http://www.ourdomainname.com/tocs2/toc.pdf"

for this one:

strAttachPath = server.MapPath("toc.pdf")

I have to use server.mapPath as it's hosted on an ISP's server but of course in your example the coded calls the path directly.  Hopefully this can be of use to someone else that has the same problem.  That'll teach me to trust the MSDN docs !

Anyway, it works a treat, no more problems.  

I guess if I was earning my points on this site, I'd claim that you didn't give me the answer, but hey I'm a subscriber and your code segment did make me think of the solution, even if it was indirectly ;)  And, you bothered to reply so...

Enjoy your 500, it's your lucky day!
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now