Apple Mail sends attachments as inline are are marked as alternate views #81
Conversation
…ews and the name of the attachment is lost. The behavious can be changed http://katiefloyd.me/blog/get-rid-of-inline-attachments-in-apple-mail otherwise an attachment will look like this: Content-Type: multipart/mixed; boundary=Apple-Mail-2--769176039 --Apple-Mail-2--769176039 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hello --Apple-Mail-2--769176039 Content-Disposition: inline; filename=" xxx.pdf" Content-Type: application/pdf; name=" xxx.pdf" Content-Transfer-Encoding: base64
|
The comment shuld be updated as well in that case. Do the existing unit tests succeed with this change? |
|
I didn't check any unit test |
|
MIME parts should only be considered AlternateViews if they are a child of a multipart/alternative multipart/mixed is not for alternate views |
|
Can I plead with you guys to use MimeKit once again? :-) I've gotten MimeKit to be as fast as native C code. I've also added TNEF support and it has full S/MIME and PGP support. |
|
Guys, I only noticed that for the emails originating from Apple Mail there are no attachment. The solution I gave seems simple and efficient and it works fine for me. It's up to you if you want to merge it |
…ing the attachment as body because the content disposition is inline
|
New bug found: when an email is sent by apple mail without a body there is no text/plain bodypart and the attachment has content disposition inline instead of attachment. Result: the attachment (pdf in my tests) is parsed as email body. My push fixes this issue. |
|
your patch assumes all consumers of S22.Imap can only handle text parts as the message body, but that is not how MIME is meant to be interpreted. If that was the case, there'd be no need for the Content-Disposition header :-) The Content-Disposition header is supposed to tell the receiving mail client whether it should render the MIME part item inline in the message view or show it as an attachment instead. IF AND ONLY IF the receiving client cannot render an "inline" MIME part should it show it as an attachment instead. |
|
if it's like you said, can you please tell us what other (not Text) ContentType can the body of the email have? also, if you think my solution is not good, please come with another one. i presented a case i faced: stupid apple mail with inline disposition for a pdf attachment and no body part. without my fix the inline pdf would be put as body and the attachment lost. anyway if the email would have a body the attachment is still lost because the content distribution is not attachment or unknown. |
|
It can have any Content-Type that the sending client is able to render. That could be image/jpeg, application/pdf, application/postscript, etc. Apple Mail sending an application/pdf as Content-Disposition: inline is not broken, it is perfectly legit. The problem is that S22.Imap's Message.Body property is a string and you are using it at all instead of iterating over the parts yourself. The idea that the message body will always be text is a flawed assumption. This is why I was pushing for S22.Imap to use MimeKit. |
|
You're still not giving a solution! Email content is lost with the implementation as it is. Message.Body as string sounds like a logic assumption and if it's not string then I don't think anyone would complain of having it as attachment. What I gave is a solution, if you think another one is better put it here; meanwhile my solution solved my problem. |
|
S22.Imap uses .NET builtin net.mail class to store parsed data, with its limitations (and in some parts that might actually be a good thing), inlined items have no clean implementation, but one could argue that they would go as attachments, but with ContentDisposition set (just a quick search found this example: http://blog.devexperience.net/en/12/Send_an_Email_in_CSharp_with_Inline_attachments.aspx) But regardless, please post the raw mail message to discuss it further, and/or so it can be included in a testcase that in a sense describes the reason for the implementation. |
|
The problem with using System.Net.Mail.MailMessage is that it was really only designed for the purpose of sending mail and so therefore could make assumptions about the structure of the message (because it only cared about supporting a few hard-coded structures) that do not hold true with messages that are floating around in the wild :-\ |
|
IMHO, for a "minimal" IMAP client library, Net.Mail.MailMessage is good enough, And what I was looking for. For now the question is what is the best way to handle these corner cases using System.Net.Mail.MailMessage. (And not if System.Net.MailMessage shuld be used or not, that is a different "issue", Even if I would be interested to see the ability to output in different instance formats.) But it is only Smiley22 that make the decision i guess. |
|
Delivered-To: user@email.com --Apple-Mail-1--436149936 JVBE --Apple-Mail-1--436149936-- |
Apple Mail sends attachments as inline are are marked as alternate views and the name of the attachment is lost.
The behavious can be changed http://katiefloyd.me/blog/get-rid-of-inline-attachments-in-apple-mail otherwise an attachment will look like this:
Content-Type: multipart/mixed; boundary=Apple-Mail-2--769176039
--Apple-Mail-2--769176039
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
Hello
--Apple-Mail-2--769176039
Content-Disposition: inline;
filename=" xxx.pdf"
Content-Type: application/pdf;
name=" xxx.pdf"
Content-Transfer-Encoding: base64