I'm creating an email message using CDO object (and VB6, but that doesn't really matter).
With New CDO.Message
.To = "<address>"
.Subject = "Manifest test 8"
.Organization = "<company>"
.From = "<address>"
.Sender = .From
With .Configuration
.Fields(cdoSendUsingMethod).Value = cdoSendUsingPort
.Fields(cdoSMTPServer).Value = "192.168.0.4"
.Fields.Update
End With
With .AddAttachment("c:\import\customermanifestOURACCOUNT11122008110032.dat")
.Fields(cdoContentDisposition).Value = "attachment; filename=""Consignor.dat"""
.Fields.Update
End With
.Send
End With
As you can see, the message is empty and contains an attachment that I rename in the email.
The attachment is an ASCII text file, fixed-width, that contains some output from our systems, one record per line, separated with CRLF.
When the message gets sent, all CRs get stripped out the attachment, so the receiver gets a file that only has LFs and therefore is corrupted.
I tried to change ContentEncoding to 7bit and base64, didn't work.
I tried to set ContentMediaType for the attachment to text/plain, didn't work.
I tried to not rename the attachment after adding, didn't work.
The ContentMediaType for the attachment is set to application/octet-stream by default, so I can't figure out why (and by what) it gets changed in the first place.
If I execute .SaveToFile() on the attachment right after .Send(), it saves valid file on the disk.
Is this a problem in my code, or is it a mail server setting or something?
Ok, that was weird.
We used our gmail accounts to test that thing, more specifically, gmail web interface. We clicked attachments links to save reveived files. And the files were corrupted.
As soon as we instead tried some thick clients, it turned out to be fine. All files get download properly without any corruptions.
So I assume this is a bug in gmail web interface (as opposed to gmail POP3 interface).
I have not used CDO in a long time, but i remember having this issue in the past. By trying different things, we figured that if there was any content in the body of the message the attachments were sent properly.
Weird, i know.
try it and let us know.
I just got this same trouble. I switched to Jmail and my CSV (text file) was now exactly like the original when I read it from gmail.
I compared the original message (in Gmail, option - view original message) and discovered that with CDO.Message, the attachment is not encoded really well, it is kept in text format, and the mail client do what he wants with it. With Jmail, the message is encoded in Base64 so it is kept in its original state from the start to the end. So, be careful when using CDO.Message with text file attachments! Try using Jmail (free) instead.
CDO.message: Content-Transfer-Encoding: quoted-printable
Jmail.message: Content-Transfer-Encoding: base64
Related
I'm building a LotusScript agent looping through a set of documents then - based on a given condition - create mail messages with formatted html text. The recipients will be mostly Non-Notes users (Outlook etc) that's why I want to make sure that subject and message body are formatted correctly. At least one copy is sent to a Domino mail-in database, though.
The code basically creates a MimeEntity, sets "To", "CC" and "Subject" headers then puts a pre-configured message into the mail body and sends it off.
In regards to the body I experimented both with a simple MimeEntity formatted as "text/html" as well as with a multipart message (Content-Type = "multipart/alternative") with 2 child entities (1: "text/plain" without any formatting, 2: "text/html" i.e. html-formatted); in my final code I plan to go for the latter method.
What is really weird is that the recipients (using Outlook as well as other mail clients like Thunderbird) see 3 "To:" and 3 "Cc:" items instead of just one. Looking at the doc in the receiving Domino mail-in database there is only one instance of each item (i.e. SendTo and CopyTo).
Here's the message's source code (taken from Thunderbird) showing those 3 instances of each item:
Return-Path: <sendername#myorg.de>
Received: (removed info here)
Subject: =?UTF-8?B?RWluIGdlbcO8dGxpY2hlcyBzaW1wbGVzIFRlc3RtYWlsIGF1cyBTT1A=?=
MIME-Version: 1.0
Auto-Submitted: auto-generated
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
Message-ID: <OFBCA50979.C1582837-ONC125856E.00548385-C125856E.0054838A#MYORG.DE>
From: Lothar Mueller <sendername#myorg.de>
This the basic code creating these mails (the simple non-multipart version):
Set docMemo = db.Createdocument()
Call docMemo.Replaceitemvalue("Form", "Memo")
Set nMimeBody = docMemo.Createmimeentity()
'SendTo
Set nMimeHead = nMimeBody.Createheader("To")
Call nMimeHead.Setheaderval("user1#otherorg.de,user2#3rdorg.de")
'CopyTo
Set nMimeHead = nMimeBody.Createheader("CC")
Call nMimeHead.Setheaderval("my-mail-in-db")
'Subject
Set nMimeHead = nMimeBody.Createheader("Subject")
Call nMimeHead.Addvaltext("Subject with ä-ö-ü-ß", "UTF-8")
'html version only for simple non-multipart MIME
Call nStream.Writetext({<p style="font-weight:bold;">Some simple formatted HTML content</p>})
Call nMimeBody.Setcontentfromtext(nStream, {text/html; charset="UTF-8"}, ENC_NONE)
Call nStream.Close()
'finally send
Call docMemo.Send(False)
Now, I can work around this behavior by simply setting the recipients as plain old Notes items, like:
Call docMemo.SendTo = recipientArray
Call docMemo.CopyTo = copyArray
instead of setting those values as MIME headers. In this case there are no more multiple instances of "To" and "CC" items at the recipients' mail clients.
I know that I did this already some years ago in a different project, and back then I didn't have those problems.
Anyone having an idea what could be the cause for this? Could it be due to the Domino version in use (now it's 10.0.1 FP4, back then it was some 9.0.1 version)?
Guess I found the cause for this, at least partially:
As I mentioned in an update to my post this behavior only can be observed when the agent is running in the client as opposed to running on the server:
examining the resulting mail through Ytria's scanEZ I find that there's a difference in regards to the fields that are created:
the run-on-server version just creates the expected fields "To:" and "Cc:" which turn up as "SendTo" and "CopyTo" in the resulting Notes document
If the code is running in the client some more fields are created in the Notes document: in addition to the standard fields there are also "INetSendTo", INetCopyTo, "AltSendTo" and "AltCopyTo". I assume that those extra fields are then rendered by the router to become addition "To:" and "Cc:" header items.
Thanks again to #DaveDelay for bringing up that idea regarding the router and mail.box
I've just noticed that Microsoft OWA does not display some attachments. Some people use images in their footer (which are attachments). I'm not sure if the only difference between a "normal" attachment and this emedded attachment is that it is embedded in the email.
Is there another difference? How can I get only attachments which OWA* displays as attachements?
* and probably most other email clients; I think I've seen a similar behavior in Google Mail
Those attachments have a content_id. They are referenced within the mail.body as cid:[CONTENT-ID]. The content_id looks like this:
cid:image001.jpg#01D3151A.F9036A80
where image001.jpg is the filename.
looking for cid:image_name inside mail body fails for embedded images with src referring to a link rather than cid.
so the best solution would be to use attachments.is_inline property which is built in exchangelib.
for attachment in msg.attachments:
if msg.has_attachments == True:
if isinstance(attachment, FileAttachment):
if attachment.is_inline:
print("Embeded Image")
else:
print("Normal Attachment")
reference: https://github.com/ecederstrand/exchangelib/issues/562
When I try to add an MHTML file as an attachment to an email message in VBScript, the ContentMediaType is incorrectly set to "message/rfc822" (RFC 822). From what I understand, this is correct according to Microsoft, but is incorrect according to RFC 2557 which states that it should be "multipart/related". This is a problem, because most (if not all) mail clients interpret "message/rfc822" as an email message. Since the file extensions ".mht" and ".mhtml" do not match any valid file extension of an email message, the mail client appends one of ".msg", ".eml", etc. to the filename. When a user opens the attachment, it opens as an email message and doesn't display correctly since an MHTML file and an email message are saved differently.
Sub SendEmail(FromAddress, ToAddress, Subject, Body, Attachment)
Call Err.Clear
On Error Resume Next
Schema = "http://schemas.microsoft.com/cdo/configuration/"
Set Configuration = Sys.OleObject("CDO.Configuration")
Configuration.Fields.Item(Schema + "sendusing") = 2
Configuration.Fields.Item(Schema + "smtpserver") = SMTPServer
Configuration.Fields.Item(Schema + "smtpserverport") = 25
Configuration.Fields.Item(Schema + "smtpauthenticate") = 1
' Configuration.Fields.Item(schema + "sendusername") = ""
' Configuration.Fields.Item(schema + "sendpassword") = ""
Call Configuration.Fields.Update
Set Message = Sys.OleObject("CDO.Message")
Set Message.Configuration = Configuration
Message.From = FromAddress
Message.To = ToAddress
Message.Subject = Subject
Message.HTMLBody = Body
If Not IsEmpty(Attachment) Then
'CDO.Message.AddAttachment doesn't set the correct content media type for an MHTML file.
Call Message.AddAttachment(Attachment)
End If
Call Message.Send
End Sub
When I run this code, Message.Attachments.Item(1).ContentMediaType is set to "message/rfc822". I need it to be "multipart/related" if Attachment (a string) ends with ".mht" or ".mhtml" (case-insensitive). I can do this with the following code.
If Len(Attachment) >= 4 And InStr(Len(Attachment) - 3, Attachment, ".mht", vbTextCompare) Or Len(Attachment) >= 4 And InStr(Len(Attachment) - 5, Attachment, ".mhtml", vbTextCompare) Then
Message.Attachments.Item(1).ContentMediaType = "multipart/related"
End If
For some unknown reason, this undefines the attachment from Message.Attachments.
I've looked at manually adding the attachment per these instructions, but when I call Message.Attachments.Item(1).Fields.Update, the object becomes undefined. I think setting the attachments's ContentMediaType, implicitly invokes it's Fields's Update method which is what I think is responsible for this unexpected behavior.
How can I get around this and send an MHTML file with the "multipart/related" content type while maintaining the proper file extension?
So your problem is that at least some email clients save MHTML attachment incorrectly if content type for the attachment is set as content-type="message/rfc822".
First, it is worth noting that your analysis of a root cause of the issue is flawed. You appear to be confused by where multipart/related MIME type comes into play. As a matter of fact, RFC 2557 does NOT state that body part corresponding to MHTML attachment must have content-type="multipart/related". Instead, MIME multipart/related is internal structure of MHTML file itself. Quoting Wikipedia article:
The content of an MHTML file is encoded as if it were an HTML e-mail message, using the MIME type multipart/related.
I.e. if you open MHTML file with text editor, you should see the following:
Content-Type: multipart/related; ...
Microsoft states that MHTML files should be served with content-type="message/rfc822" in KB937912. This is exactly what CDO does by default when you attach such file via AddAttachment method. I believe such behavior does not contradict RFC 2557 in any way. As per the RFC:
There are a number of document formats... that specify
documents consisting of a root resource and a number of distinct
subsidiary resources referenced by URIs within that root resource.
There is an obvious need to be able to send such multi-resource
documents in e-mail [SMTP], [RFC822] messages.
The standard defined in this document specifies how to aggregate such
multi-resource documents in MIME-formatted [MIME1 to MIME5] messages
for precisely this purpose.
To recap, you definitely should not set content type of MHTML attachment to multipart/related.
While message/rfc822 seems to be the way to use with MHTML files, it obviously triggers the problem you described in the question. I tested with Outlook 2010 and OWA 2010, and was able to reproduce it.
Alternative content types that are used by various email clients for MHTML attachments are application/octet-stream and application/x-mimearchive. These two didn't exhibit the problem in my tests.
I need your help in order to send email message that includes text in Greek, from within R, using the function sendmail {sendmailR}.
I tried using the function iconv, like that but it didn't work
subject <- iconv("text in greek", to = "CP1253")
sendmail(from, to, subject, msg, control=list(smtpServer="blabla"))
The mail arrives immediately but the greek characters are unreadable. Any ideas?
EDIT
Another question that came up:
The second argument to accepts one recipient. What if want to send it to more than one? (I think 'll try sapply ing the sendmail function to a vector of recipients) - Ok, that worked. However, I'm not completely satisfied because each one of the recipients has no way to know who else has received the message.
Mail client won't be able to understand any encoding without Content-Type: charset=..., so you must add it:
msg<-iconv("text in greek", to = "utf8");
sendmail(from, to, subject, msg,
control=list(smtpServer="blabla"),
headers=list("Content-Type"="text/plain; charset=UTF-8; format=flowed")
);
that is for UTF8 (which I believe should be used), for CP1253:
msg<-iconv("text in greek", to = "CP1253");
sendmail(from, to, subject, msg,
control=list(smtpServer="blabla"),
headers=list("Content-Type"="text/plain; charset=CP1253; format=flowed")
);
multisend by hidden copies can also be done with header magick, still I think sapply loop is a better idea -- then the user will see that the mail was send directly to her/himself.
Just want a basic understand of what parts a email message may have.
I know there is a messageId, date, subject, from, cc, bcc, body, etc.
Specifically I want to know how attachments and images may be embedded in the email.
At this point I think there are 2, please correct me if I am wrong.
attachments
embedded attachments/images
is that correct?
The official answer for this question is contained in RFC5322 and some related RFC's. The Wikipedia entry for email does a pretty good job of referencing the RFC numbers. To get started with MIME see RFC2045.
Attachments are encoded as multipart similar to multipart file uploads. Basically the message has a header saying there is an attachment and sets a boundary ( random string of characters to announce the start of the attachment) The boundary says when the data of the attachment starts. I think the filename is set on the boundary as well (if i remember correctly). I am doing a bit of hand waving, but this is the basic idea.
so you get somthing like
To: ...
From: ...
Content-Type: Multpart...
Content-Boundry: ewafoiuasfjasdfoashiafhj
message here
--------- Content-boundry: ewafoiuasfjasdfoashiafhj
attachement here