Link to home
Start Free TrialLog in
Avatar of jammy-d0dger
jammy-d0dger

asked on

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





ASKER CERTIFIED SOLUTION
Avatar of schaffs
schaffs

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of jammy-d0dger
jammy-d0dger

ASKER

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!