Hello this is my first post on this site.
Now i encountered a strange problem with MIME. I am working on writing emlx mail files.
(objective c, cocoa)
now i have no problem with showing images in mails. the problems is that half of my .doc and pdf attachments don't show in the message.
An formatting example.
MessageLength in Bytes(i.e 8556)
From: some#email
To: some#email2
Subject: mailsubject
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="somerandomgeneratedstring"
--somerandomgeneratedstring
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Body Text(not html body)
--somerandomgeneratedstring
Content-Type: application/msword; name="somefile.doc"
Content-Disposition: attachment; filename="somefile.doc"
Content-Transfer-Encoding: base64
[base64 encoded data]
--somerandomgeneratedstring--
PlistStructure
The text body is always displayed properly. The problem is that some text file attachments like .doc and pdf are not displayed, i run the same code for multiple text files and some work and some do not i have no clue why. all pictures work.
The thing i don't get is if i use the same data that wont work for MIME and write is as a file to my desktop the file is displayed properly.
Is there something i am missing ? Is there something i have to take care of when encoding such files in base64 ? if so why do some files work and others dont ?(source is in binary format, i encode is using nsdata base64encoding in Xcode)
I have gone trough the mime documentation multiple times and i cant seem so find a solution.
Can anyone please give me some tips or suggestions ?
EDIT: omg i forgot about this, The problem was that i had a problem with the first line, length in bytes, after i fixed that it worked. Sorry for wasting time :(
You need to get rid of the blank line between the top-level MIME-Version and Content-Type headers. MIME headers and body are separated by a blank line, so your Content-Type is effectively ignored as a header and treated as body content instead.
From: some#email
To: some#email2
Subject: mailsubject
MIME-Version: 1.0
<-- get rid of this blank line
Content-Type: multipart/mixed; boundary="somerandomgeneratedstring"
Update: since this problem is not a factor anymore, the only remaining factor you have not shown yet is the actual base64 data. It is likely malformed in some way that is preventing proper decoding. Everything else you have shown is accurate.
Related
I try to import MIME emails. I get them by saving the incoming stream from an email server to a file.
It works very well except when there are attachments with very long filenames.
The content of the file is handled perfectly fine but the name and filename are shown in Outlook 365 as "Untitled attachment".
I use RDOMail.Import(string Path, [object Type]) from Redemption v5.21.0.05378.
Can you please give me a hint how to keep the original filename?
This is a part of an email I try to import:
[...]
Content-Type: text/plain; charset=UTF-8;
name*0="this is an attachment with a really long file name - i
hope "; name*1="it works like intended.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="this is an attachment with a really long file name - i
hope "; filename*1="it works as intended.txt"
This is the file content ...
[...]
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!
Been having some difficulty with an attachment issue on my site. At the moment our iOS app is pointing at an API endpoint for attachments, and sending a request similar to this:
POST /api/v2/attachments HTTP/1.1
--Boundary+0xAbCdEfGbOuNdArY
Content-Disposition: form-data; name="attachment"; filename="attachment.jpg"
Content-Type: image/jpeg
...image data...
--Boundary+0xAbCdEfGbOuNdArY--
Now, the request succeeds and the image is in fact uploaded, but it's turning out to be an invalid image because the boundary data is written to file. It basically looks like this:
file = Tempfile.new('attachment')
attachment_data = request.body.read
attachment_data.force_encoding('UTF-8')
file << attachment_data
attachment.asset = file
attachment.save!
Obviously request.body.read is including the entire request, Boundaries and all. We do actually have a stripping method that runs through each line of the file and strips out non-image data, but that's obviously not performant at all.
In an ideal world, we would just be getting the image data itself and using that to populate the tempfile, but I'm afraid I'm completely stumped about the best way to go about that.
Thoughts welcome. Thank you!
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.