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 ...
[...]
Related
I'm using Twilio-python client. The vCard is rendered properly on android. However, on iPhone, it looks like a file and the extension (.vcard/.vcf) is visible. It still works but looks weird:
Twilio-to-iPhone (.vcard looks the same except for extension)
I tried sending a contact from android to iPhone and it was rendered properly by the iPhone:
Android-to-iPhone
Relevant posts that I have tried:
vCard sent with Twilio not properly rendered in iOS
Twilio - Sending vCard Not Rendering Properly
Generate VCard and Send Via Twilio
iOS failing to render vcf file
Vcard MMS file name is always "text 1"
Based on these posts, I tried several combinations of Content-Disposition, Content-Type, and Cache-Control headers in the media_url response but it still looks the same:
For Content-Disposition:
inline; filename="James.vcf"
attachment; filename="James.vcf"
inline; name="James"
attachment; name="James"
For Content-Type:
text/vcard
text/x-vcard
text/vcard
text/vcard; charset=utf-8; name="fileName.vcf"
Twilio blog for sending vcards via sms:
https://www.twilio.com/blog/send-vcard-twilio-sms
We are using Redemption (v5.26) to convert messages from .msg format to .eml format in an Outlook COM addin.
I have created an email with the following subject: ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP and copied the subject to the message body. I've sent the message and after I received the message I made my test to check one of out customers report.
Our code does the following:
saves the current email to a .msg file using the following method _mailItem is the Outlook native MailItem:
_mailItem.SaveAs(filename, OlSaveAsType.olMSG);
converts the .msg file to .eml using Redemption (the objects are released of course)
rdoSession = RedemptionLoader.new_RDOSession();
rdoMail = rdoSession.GetMessageFromMsgFile(input);
rdoMail.SaveAs(output, rdoSaveAsType.olRFC822_Redemption);
Then checked the generated file and this is what it represented:
the subject encoded like below:
Subject: =?iso-8859-2?B?wVJWzVpUVVJPIFTcS9ZSRtpS00fJUA==?=
which is ÁRVÍZTURO TÜKÖRFÚRÓGÉP encoded.
The message body is encoded like below:
--7A24CA1FB85D3A4CB677EFC32587A338-474D54B8_message_boundary
Content-type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: Base64
Content-Disposition: inline
Content-Description: Message text
wVJWzVpU21LVIFTcS9ZSRtpS00fJUA0K
--7A24CA1FB85D3A4CB677EFC32587A338-474D54B8_message_boundary
which is encoded correctly.
Our customer reported it the same behavior but in the To and From headers.
Can I do anything to fix these fields encoding or is this a bug?
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!
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.