I am learning networking recently.
It is known that SMTP only allows 7-bit ASCII.
I would like to know if SMTP can send attachment such as pictures, videos or files via email. If so, how can the attachment be sent?
Thank you
With SMTP, almost every email is using MIME (Multipurpose Internet Mail Extensions, RFC2045). MIME is independent of SMTP, but can be thought like extension to it. HTTP protocol is also using MIME.
MIME contains two parts. MIME headers and MIME content. MIME headers describe what the contents will be. MIME is full of features, but I'm only describing what is relevant to your question.
MIME headers of interest:
Content-Type describe what the content is. Simply, text is just text/plain and image/jpeg is JPEG image.
Content-Transfer-Encoding describe how the content is encoded. Common encodings in email are quoted-printable and base64. These encodings are designed for SMTP's 7bit delivery in mind.
Content-Disposition header contains for example attachments file name.
For sending attachment or multiple attachments, each attachment is encoded as described above (some headers + encoded content). First Content-Type header is set to multipart/mixed and given boundary tag like this:
Content-Type: multipart/mixed; boundary=4vvtTcl0dIpecpyi12ab54
And every attachment (headers + content) starts with boundary tag:
--4vvtTcl0dIpecpyi12ab54
followed by MIME headers and then contents. This way the email client can separate attachments from each other.
I would also like to mention that there is 8BITMIME extension to SMTP for 8 bit support. See RFC6152: SMTP Service Extension for 8-bit MIME Transport.
Related
I have been trying to locate all attachments on an email that has inline attachments with no content-disposition.
This is a snippet of the email
----boundary_4451_1ea18041-d01e-46e2-8f88-32770bfba1b7
Content-Type: application/octet-stream; name=img0.png
Content-Transfer-Encoding: base64
Content-ID: <image1>
..image base64 here..
----boundary_4451_1ea18041-d01e-46e2-8f88-32770bfba1b7
Have tried the Attachments collection but its obviously not in there.
Have also tried an approach where the "body" is identified and then everything else is treated as an attachment. However this picks up the html body as an attachment too because the headers for that are also suspect.
Any help appreciated or if you need more info please let me know. Thanks.
The MIME part that you've pasted the raw source for in your question will be located in MimeMessage.BodyParts because it is not tagged as an attachment via the Content-Disposition header, as you've noticed.
Every email client has its own idea of what constitutes an attachment and so it is up to you to decide how to determine if something is an attachment or not, that's not something that MimeKit can determine for you.
Have you checked out the HtmlPreviewVisitor sample code located in the FAQ?
That sample code snippet shows you how to render an email message as HTML and gather up all of the referenced image attachments, etc. and it collects all of the other non-referenced attachments into an attachment list.
We send out password-reset emails to business partners who use our intranet. The body of the email contains a hyperlink:
`http://www.ourdomain.com/ResetPassword.aspx?token=....`
But some of the people who receive these emails are saying there's an extra dot in the domain name:
`http://www.ourdomain..com/ResetPassword.aspx?token=....`
I do not see where that could be happening in the program I've written. I store the base url in the web.config:
`http://www.ourdomain.com`
and attach the name of the aspx page and append the token to it.
Are there any corporate anti-virus programs out there which deliberately mangle hyperlinks discovered in the body of emails, to render them invalid and thus unclickable?
This seems to be per the spec of quoted-printable encoding. It just so happens that the length of text in the message breaks to a new line right at the .com (72 characters maybe?). Please verify that this is the case by sending yourself a message and analyzing the quoted-printable source of the message.
System.Net.Mail creating invalid emails and eml files? Inserting extra dots in host names
The solution would be to not use quoted-printable encoding if some email programs cannot correctly interpret the spec.
plainText.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;
//or base64
If I want to include, in an email, both an HTML version and a plain text version (for non html email readers), what is the protocol to include in it to specify each?
MIME - http://en.wikipedia.org/wiki/MIME
It's an internet standard and it would be a rare language that doesn't have a library for creating and handling MIME email messages.
I am creating an email in MFMaiilComposeViewController and if I simply create some html snippets and assign them to the message body - all is well. The resulting email (in GMail and Yahoo) looks like the original HTML I sent.
[mailMan_ setMessageBody:body isHTML:YES];
On the other hand, if I also include an XML attachment, my email reader renders everything as plain text … including, the XML inlined. IE: my mail client (GMail, Yahoo) shows the raw HTHML and XML tags - including html tags that I didn't supply - ie: the html, head, body tags the iPhone provides around the content:
NSData *opmlData = [[NSData alloc] initWithData:[opml dataUsingEncoding:NSUTF8StringEncoding]];
NSString *fileName = [NSString stringWithFormat:#"%f.opml", [NSDate timeIntervalSinceReferenceDate]];
[mailMan_ addAttachmentData:opmlData mimeType:#"text/xml" fileName:fileName];
I pop3'd the mails to see what was happening and found that WITHOUT an attachment, the resulting html section of the email contains this block:
--0-1682099714-1273329398=:59784
Content-Type: text/html; charset=us-ascii
<html><body bgcolor="#FFFFFF"><div><h2 style="b
while on the other hand, WITH the XML attachment, the iPhone is sending this:
--0-881105825-1273328091=:50337
Content-Type: text/plain; charset=us-ascii
<html><body bgcolor="#FFFFFF"><div><h2 style="bac
Notice the difference? Look at the Content-Type … text/html vs text/plain. It looks like when I include an XML attachment, the iPhone is errantly tagging the HTML version of the body as plain text! Just to clarify, technically, both with and without the attachment, the iPhone also includes this:
--0-881105825-1273328091=:50337
Content-Type: text/plain; charset=us-ascii
Notebook
Carpentry
Bathroom floor tile
Bathroom wall tile
Scrape thinset
But this obviously isn't where the problem lies.
Am I doing something wrong? What must I do to actually "attach" XML without the iPhone labeling the entire HTML body as plain text. I tried reversing the assignments (attachment first and then body) but no luck.
For what it's worth, the email looks perfect from the iPhone's sending interface. Indeed, the HTML renders correctly and the attachment looks like a little icon at the bottom of the message. This problem has more to do with what the iPhone is actually sending.
Turns out - this problem is specific to Yahoo.
On the iPhone, if I change my provider to my Gmail account instead of my Yahoo account, the resulting email has more sections, is much more specific and renders correctly.
Moral of the story - be careful sending attachments from your iPhone via different providers.
Using SMTP, how do you send Unicode/UTF-8 e-mails?
Am I expected to base64 encode the UTF-8 body and specify that in the MIME header or...? How about the headers?
I'm sure there's a standard somewhere the describes this...
Check out the RFC 2047.