I was able to get the mail object with attachment using following API Call
https://graph.microsoft.com/v1.0/me/messages/${messageId}?$expand=attachments
I need to save raw MIME for the mail (i.e. .eml) which will be uploaded to our internal CRM.
I understand that one can make a simple .eml file in below fashion but I want to know if there is a simpler alternative to get this from the API directly.
To: Demo-Recipient <demo#demo.example.com>
Subject: EML with attachments
X-Unsent: 0
Content-Type: multipart/mixed; boundary=--boundary_text_string
----boundary_text_string
Content-Type: text/html; charset=UTF-8
<html>
<body>
<p>Example</p>
</body>
</html>
----boundary_text_string
Content-Type: application/octet-stream; name=demo.txt
Content-Transfer-Encoding: base64
Content-Disposition: attachment
ZXhhbXBsZQ==
----boundary_text_string
Content-Type: application/octet-stream; name=demo.log
Content-Transfer-Encoding: base64
Content-Disposition: attachment
ZXhhbXBsZQ==
----boundary_text_string--
There are two ways one can get a message in raw format (MIME), and both are now available in v1.0 of the Microsoft Graph API:
Append a $value to a get message operation.
If a message is attached as a file or item to another Outlook item (message or event) or group post, you can get that message attachment by appending $value to the get attachment operation.
Get MIME content of a message describes the two scenarios.
In general, keeping an eye on the Microsoft Graph blog site, the what's new topic, or the changelog topic (if it's API or permissions updates) would help you discover additions and updates you were looking for. In particular, the ability to get the MIME format of a message or message type attachment was introduced in April 2019 in the beta version, and promoted to v1.0 in September a few months later.
Related
It seems the MS REST (EWS) services are being deprecated toward the end of 2022 and moving to graph api is recommended.
All good, graph works just fine...except for the 4MB size limit on the payload!
Ok so there is this: https://learn.microsoft.com/en-us/graph/outlook-large-attachments?tabs=http
What a mare! But anyway I am posting MIME content as below:
https://learn.microsoft.com/en-us/graph/outlook-send-mime-message
ie. I'm posting plain text content like below to graph's sendMail endpoint
From: Some One <someone#example.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="XXXXboundary text"
Subject: This is a test
This is a multipart message in MIME format.
--XXXXboundary text
Content-Type: text/plain
this is the body text
--XXXXboundary text
Content-Type: text/plain;
Content-Disposition: attachment;
filename="test.txt"
this is the attachment text
--XXXXboundary text--
I don't understand how this would work with the upload-session aproach - so is it possible, and if so, how, can I send MIME content > 4MB using the graph api?
I have a COBOL batch program where I am able to send mail notification to an ID once my job is complete however, I also want to add an attachment in the mail of the processed file.
The following code attaches another mail as an attachment.
HELO SANTAANA
MAIL FROM:<abc#somting.com>
RCPT TO:<abc#something.com>
DATA
From: LandT P2P - LO <abc#something.com>
To: abc#something.com
Subject: File processed - Price_Change_10-27-15 07-08-44
MIME-VERSION: 1.0
CONTENT-TYPE: MULTIPART/MIXED;name="Price_Change_10-27-15.csv"
CONTENT-DISPOSITION: ATTACHMENT;
FILENAME="Price_Change_10-27-15 07-08-44.csv"
Note: I have also tried using SMTP and still does not work
Here is the sample of the mail i receive on running this code.
If you are generating the text of the email from within your Cobol program, which it sounds like, you would need to append another section, specify the Content-Type and Content-Disposition, filename and encoding, and then follow it with the properly encoded data, similar to this:
Content-Type: application/xml; name="Price_Change_10-27-15 07-08-44"
Content-Disposition: attachment; filename="Price_Change_10-27-15 07-08-44"
Content-Transfer-Encoding: base64
UEsDBBQABgAIAAAAIQDfrfoCnAEAAEcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
... and so on ...
I did notice that you had the content of those tags in upper case, that might be a problem. RFC1341 specifies those as "multipart/mixed" and "attachment" and so on. It is possible that your lack of mixed case is messing you up.
CONTENT-TYPE: MULTIPART/MIXED;name="Price_Change_10-27-15.csv"
CONTENT-DISPOSITION: ATTACHMENT;
FILENAME
Even easier than generating your own, have you looked into the excellent XMITIP package by Lyonel B. Dyck, it manages all that for you and you write a few config arms to control it, and you can easily call it from a Cobol program just like any other Rexx. Or you could add it to the end of your job stream as a separate step and make the task really easy.
I am using the Mail gem to send out emails with attachments from my application. Specifically, I have identical code living on my devbox and a server machine which is used to report a pdf file. However, pdfs sent as attachments from my devbox show up in Thunderbird and other clients fine, whereas attachments from the server show up only in SOME (not thunderbird) mail clients fine. I've opened the email source to compare the two and try to get some insight into the issue:
Devbox:
--_av-F3fhmdkLZDU59RCz4nm2gw--
--_av-ycGAp26idM_6kl-0lMcYmw
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.pdf"
JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9MZW5ndGggNjc4L0ZpbHRlci9G
bGF0ZURlY29kZT4+c3RyZWFtCnic7Zhdb9owFIZ7S37FuZm0SZA53wkSF1Bg
...
MzBhN2RlZDE0ZmJkZDMwNzU1MzU2Y2ZhPjxlYTM0OTMzOTEwN2RmYzI1NTJh
NDE5NTJmNDhmN2MwMD5dL0luZm8gMzMgMCBSL1NpemUgMzQ+PgpzdGFydHhy
ZWYKNDE2NjQKJSVFT0YK
--_av-ycGAp26idM_6kl-0lMcYmw--
Server:
----==_mimepart_561d49a469c4d_33ee3fea57ad63b8624ae
Content-Type: application/pdf;
charset=UTF-8;
filename=report.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=report.pdf
Content-ID: <561d49a46bc9f_33ee3fea57ad63b862596#autopilot-demo-east-web-1.mail>
JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9MZW5ndGggNjgwL0ZpbHRlci9G
bGF0ZURlY29kZT4+c3RyZWFtCnic7Zhdb9owFIZ7S37FuZm0SSVznJAPJC4o
oWs7qrVdql500xTAgNt8QGKg3a+fnQ5RbR3ttnYziQkR9jk+Pu95bEcKM+0V
nPjWcQ8WJMtpmjTBdI3RjQEnWcp9R/77tcfQbR19MW1u//Bxbe7RZH4Dpo51
..
N2I0MjdlNTE4ZTNmZGNmOGE5YzY1NTRjMzc+PGE1N2MzNmNkNTE0ZTQ1Mzlk
ZjY3OTU2ODZkY2M2ZDEzPl0vSW5mbyAzMyAwIFIvU2l6ZSAzND4+CnN0YXJ0
eHJlZgo0MTY2NgolJUVPRgo=
----==_mimepart_561d49a469c4d_33ee3fea57ad63b8624ae--
The simple line adding the attachment (Rails):
email.add_file filename: "sample.pdf", content: File.read("/public/sample.pdf")
Off the bat, the section identifiers are different (_av vs mimepart) and the way each attachment is encoded is also different after a few lines. My question is, what could be causing certain clients not to respect the "mimepart" sections as attachments? Beyond that, the next question would be why the same code would generate different output, but if I know the underlying issue I may be able to solve that myself. Thanks!
To exchange data with another system we send the data as an email attachment to a dedicated address. The email is generated using ActionMailer v3.2.12.
The problem is that when the email arrives at its destination, a redundant attachment named ATT00001.c is a part of the email, in addition to the attachment we created. This causes issues with the import routine at the other end.
A big part of the problem is that we know almost nothing about how the email is being handled at the destination . We also dont know what type of email server is in use and dont have access to check what the email actually looks like when it arrives. We can send it to one of our own addresses and it looks fine there.
I know this is not a lot to go on, but perhaps one of you guys have seen these ATT00001-attachments being added to machine generated emails before.
config.action_mailer.smtp_settings
address: smtp.<mailprovider>.com
port: 587
domain: ourdomain.com
authentication: login
user_name: <removed>
password: <removed>
enable_starttls_auto: false
Update:
We've been able to obtain a copy of the problematic email and it shows the email body rendered after the attachment as an attachment of its own.
We've tried setting ActionMailer's parts_order to make sure the attachment is generated after the email body, it did not help.
Update2:
Sending to my gmail account and showing original raw data I get this.
SENT MAIL
in receipt response from recipient to the correct attachment (the autocreated one creates an error log entry)
(...) cut: to from and through email header information
Mime-Version: 1.0
Content-Type: multipart/mixed;
charset=UTF-8
Content-Transfer-Encoding: 7bit
--
Date: Thu, 28 Feb 2013 12:15:23 +0100
Mime-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="thefile.mscons"
Content-ID: <512f3c4b6e875_a8f756dcc642fe#bjorns_arch.mail>
VU5BOisuPyAnVU5CK1VOT0M6Mys3MDgwMDAzNDExNzE2OjE0OlRJTUVSKzcw
... many more lines like this ...
ODAwMDUwNTEyMTc6MTQ6VElNRVIrMTMwMjI4OjEyMTUrUE9XRVNUMTMwMjI4
----
This is with body nil in actionmailer
Next is a RESPONSE from the recipient system, sent to my gmail. It's a receipt on the correct attachment (the extra attachement generates an error, flushing their system)
RECEIVED MAIL
(..) unintersting header stuff with addresses
Content-Disposition: attachment;
filename="afilename.txt"
Content-Transfer-Encoding: base64
Content-Type: Application/EDIFACT; charset="iso-8859-1"
Mime-Version: 1.0
Date: Sat, 16 Feb 2013 11:07:10 +0100
From: ediel#example.com
To: ***#gmail.com
Subject: thesubject
Message-ID: <511f5a53.850a700a.2fa0.2a0eSMTPIN_ADDED_BROKEN#mx.google.com>
X-TM-AS-Product-Ver: IMSS-7.0.0.6298-6.8.0.1017-19380.002
X-TM-AS-User-Approved-Sender: Yes
X-Greylist: Sender is SPF-compliant, not delayed by
milter-greylist-4.0 (isp-app27-vm.isp.example.com [213.239.116.46]);
Sat, 16 Feb 2013 11:07:11 +0100 (CET)
X-ExampleIKT-MailScanner-Information: Please contact the ISP for more information
X-ExampleIKT-MailScanner-ID: r1GA7BqD021150
X-ExampleIKT-MailScanner: Found to be clean
X-ExampleIKT-MailScanner-From: ediel#example.com
X-Spam-Status: No
VU5BOisuPyAnVU5CK1VOT0M6Mys3MDgwMDA1MDUxMjE3OjE0OlRJTUVSKzcwODAwMDM0MTE3MTY6
.. more..
pUSU1FUisxJ1VOVCszKzEnVU5aKzErMjAxMzAyMDAyNDg1Nzcn
something suspicious with the Content-Type? Is a new (empty) attachment generated from the stuff prior to -- in the sent email?
I believe this is to do with inline attachments and Exchange server. Some clients, Apple Mail in particular allow you to add inline attachments, that is, a MIME attachment sandwiched in between text/body parts of an email. Exchange server expects that all attachments appear after any text portion of a mail.
Everything after the attachment in your mail gets treated as an attachment, so the body gets stuffed into a file and named as you reported it to be named. Seeing as you're using ActionMailer, see this answer and possible this answer, which explains that you need to switch the order of the lines of code, and possibly play with some other settings.
Our problem is solved, though unfortunately I cant say what caused the redundant attachment. We worked around it by sending a non-multipart email that contained only the attachment. This solution obviously wont work for people who need to send a multipart email.
Sending non-multipart email with an attachment in Rails is not straight forward. You cant use the attachment helper method and a blank body, you need to put the attachment content in the email body and manually specify the disposition.
class MailMan < ActionMailer::Base
def test
attachment_content = "my attachment"
disposition = "attachment; filename=\"test.txt\""
mail(body: attachment_content, content_disposition: disposition)
end
end
I've got a mailer that as follows:
class Payments::LateNoticesMailer < AsyncMailer
def notice(payment_id)
#payment = PaymentDecorator.find(payment_id)
#invoice = #payment.invoice
template = "payments/invoices/#{#payment.made_with_type.downcase}/show"
attachments["#{#payment.invoice_filename}.pdf"] =
WickedPdf.new.pdf_from_string( render_to_string( pdf: #payment.invoice_filename,
formats: [:pdf],
template: template,
layout: "layouts/pdf.html"))
mail to: #payment.payer_email,
from: '"RentingSmart" <no-reply#rentingsmart.com>',
cc: #payment.landlord_email,
subject: "*** Your rent payment of #{#payment.amount_due} is overdue ***"
end
end
which I send using SendGrid. Here's my issue, if I open up the email via Gmail, everything works great, the text of the email is there, and the attachment is attached. However, if I open it up using OSX's Mail.app or on my iPhone, I simply get the following:
This is a multi-part message in MIME format...
Anybody have any tips? I think I am following the Rails guides correctly.
Here is the call that I make Payments::LateNoticesMailer.notice(payment.id).deliver
According to the api docs for ActionMailer::Base, if multiple template types are used, all of them are rendered and the mime-type is automatically set to multipart/alternative.
If you add an attachment, the attachment is placed inside a multipart/mixed container.
First question: Are you rendering other types such as text and html? I would not recommend sending out emails with just a pdf part. Even if the text and html parts simply instruct the recipient to open the attachment, they should be there. Ideally, there would be more information in the text/html parts.
Second, are you trying to view the pdf inline, and not as an attachment?
Can you take a look at the raw source of the email and update your post with the structure you're seeing? There will be an initial mime type set in the header. it will look something like this:
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="--==_mimepart_50596418be947_c7223fec9d834d3874256";
charset=UTF-8
Content-Transfer-Encoding: 7bit
This says the parts to follow are not alternative versions of the same information, but instead instruct the email client to display them distinctly.
Later on in the email, your text and html parts should proceeded by something like:
----==_mimepart_50596418be947_c7223fec9d834d3874256
Date: Wed, 19 Sep 2012 06:20:12 +0000
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_50596418be468_c7223fec9d834d38741a5";
charset=UTF-8
Content-Transfer-Encoding: 7bit
And finally, the encoded pdf part should have a mime header like:
----==_mimepart_50596418be947_c7223fec9d834d3874256
Date: Wed, 19 Sep 2012 06:20:12 +0000
Mime-Version: 1.0
Content-Type: application/pdf;
charset=UTF-8;
filename=terms.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=terms.pdf
With a simple test email I just sent to myself with text, html parts, and a large pdf, I can view the email on my iphone. It shows the html part and an icon that lets me download the pdf.
Some e-mail clients may require an e-mail to have a plain text part in order to display it correctly.
I just ran into this message while converting a Rails app from 2.3 to 3.2. I thought I converted my mailer correctly, but the old version specified content_type: "multipart/mixed" in the options. However, when I removed that, I received the attachments and the HTML and plain-text rendered correctly. I think that having that setting in there overrode whatever Rails does to put in different types of content, which was not what I wanted. Thanks to the original answer for leading me in that direction.