I am using Microsoft Graph to fetch mail and I recently noticed when an email has a .eml attachment, there are two cases:
If the sender attach that email through drugging emails to the composer, the attachment will be an item attachment type. <-- I can handle this case
If the sender attaches a .eml file through clicking "attach file", that attachment will be a type of file attachment. Up to this point, I think it is fine to be a file attachment. But when I try to fetch that attachment, the attachment content type is application/octet-stream which is wrong. Shouldn't it be message/rfc822? With application/octet-stream, I cannot create that attachment from our server.
It isn't wrong, application/octet-stream simply represents a generic/unknown binary file. From RFC 2046 ยง 4.5.1:
The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data.
Your application can make its own determination on how to handle the file. In this case, the .eml is just a text file. You can simply fetch the attachment and treat it as raw text.
Related
I am receiving a text file from a socket over TCP/IP. There is no file extension (or filename for that matter) as the data is received as bytes. I can take the data from this (in the form of NSData) and load it into a UITextView and display it fine.
I want to persist this data to a file. However, I don't know what format the data is in (txt, rtf, doc, docx)? I assume it as .txt and save it in the documents directory, but is there a programmatic way of finding out for sure? I've looked around StackOverflow and at the documentation and haven't been able to find anything.
And is there a way to get the details of the file attributes like the file creation date.
Thanks in advance.
When you send a file over a TCP/IP connection, only the file contents will be converted to data and be passed across. If you want the filename,extension and the file attributes, then you will have to add those details separately and append it with the data to be sent. Then you can parse it at the receiver end and use the results inside your app.
You can choose the file type you want when you save the data, you can get attributes from file,please refer to Get file creation date.
The flow is:
The user selects an image on the client.
Only filename, content-type and size are sent to the server. (E.g. "file.png", "image/png", "123123")
The response are fields and policies for upload directly to S3. (E.g. "key: xxx, "alc": ...)
The case is that if I change the extension of "file.pdf" to "file.png" and then uploads it, the data sent to the server before uploads to S3 are:
"file.png"
"image/png"
The servers says "ok" and return the S3 fields for upload .
But the content type sent is not a real content type. But how I can validate this on the server?
Thanks!
Example:
Testing Redactorjs server side code (https://github.com/dybskiy/redactor-js/blob/master/demo/scripts/image_upload.php) it checks the file content type. But trying upload fake image (test here: http://imperavi.com/redactor/), it not allows the fake image. Like I want!
But how it's possible? Look at the request params: (It sends as image/jpeg, that should be valid)
When I was dealing with this question at work I found a solution using Mechanize.
Say you have an image url, url = "http://my.image.com"
Then you can use img = Mechanize.new.get(url)[:body]
The way to test whether img is really an image is by issuing the following test:
img.is_a?(Mechanize::Image)
If the image is not legitimate, this will return false.
There may be a way to load the image from file instead of URL, I am not sure, but I recommend looking at the mechanize docs to check.
With older browsers there's nothing you can do, since there is no way for you to access the file contents or any metadata beyond its name.
With the HTML5 file api you can do better. For example,
document.getElementById("uploadInput").files[0].type
Returns the mime type of the first file. I don't believe that the method used to perform this identification is mandated by the standard.
If this is insufficient then you could read the file locally with the FileReader apis and do whatever tests you require. This could be as simple as checking for the magic bytes present at the start of various file formats to fully validating that the file conforms to the relevant specification. MDN has a great article that shows how to use various bits of these apis.
Ultimately none of this would stop a malicious attempt.
So I have an attachment on my incoming Pop3 message,
Msg.MessageParts.Items[msgpart] as TidAttachmentFile
but, is it possible to get the content of this attached file in the format specified by Msg.MessageParts.Items[msgpart].ContentTransfer (so base64 ascii) instead of creating a temp file, calling SaveToFile, and then re-reading the file and re-connverting back to base64?
If TIdMessage.NoDecode is set to False, then no, it is not possible. When NoDecode is False, TIdMessageClient decodes the email as it is being read off the socket and places decoded binary data into attachment objects. The only way to get the original base64 data is to set TIdMessage.NoDecode to True and parse the raw email data manually (it is stored as-is in the TIdMessage.Body) as you would effectively be disabling TIdMessageClient's entire decoding system.
On the other hand, if you just want to avoid the temp file, you can use the TIdMessage.OnCreateAttachment event to have Indy create TIdAttachmentMemory objects instead of the default TIdAttachmentFile objects. The base64 will still be auto-decoded and stored as binary in the attachment, but at least the attachment would be solely in memory so your re-encode would be faster.
I run a small e mail client build with delphi and indy 10. Some mails i receive have the mime format or html format. With the current code I just copy the bode.lines to a memo.lines
MyMailMemo.Lines.AddStrings
(TIdMessage(Msg.Body);
How do I copy the content of mime emails?
MIME-encoded emails do not use the TIdMessage.Body property. They use the TIdMessage.MessageParts property instead, where textual MIME parts are stored as TIdText objects and attachments are stored as TIdAttachment-derived objects. You have to look at the TIdMessage.ContentType property to know whether you are working with an HTML email or a MIME email. Even then, chances are that HTML emails are actually MIME encoded, as they usually include an alternative plain-text MIME part for non-HTML email readers. You can loop through the TIdMessage.MessageParts looking for a TIdText object whose ContentType is HTML, then copy the TIdText.Body content into your TMemo.
Wondering if there's a way I can avoid fetching the attachments as well.
Yes, it returns the entire email source. The attachments are encoded as email parts.
You can use the Ruby Mail library to extracts all the attachments.
If all you want to do, is download the email body(ies), there isn't a clean way of doing this (at least none that I disovered).
What I had to do, was first download the headers and the body structures. Once I had the headers, I could determine what type of email it was (multi-part, alternative, or just a single bodied email).
Once I knew the structure, I could download the plain text or html body part as a body section.
Does that help?
--Dave
I don't know about ruby , but it can be done only fetching Email Header.
I am Fetching Email header in Python like below:
resp, data = obj.uid('FETCH' , ','.join(map(str,uid_lst)),'(RFC822.HEADER RFC822.SIZE)')
where uid_lst is the list of uids of emails which you want to fetch.
Note: Email which has value of header field Content-Type = 'Multipart-Mixed' has an attachment.