Imagine you want to provide the ability to publish news on your website sending an email to a given address (like for example publish.news#domain.com).
1) The base strategy is: look for something that is text/html and not disposition, and this is the primary body of the email.
2) Then look for any other content that is disposition and is attachment (and you'll get all the attachments).
3) Discard any other content that is disposition and inline because, correct me if i'm wrong, it's kinda stuff like email signature and thus not needed.
So far so good this strategy works good. However i don't know how to:
deal with multipart/alternative content. Some clients seems to compose HTML with this primary/subtype content-type.
deal with multipart/mixed (even don't know what it means).
if any email clients let to compose in html adding your own images and encoding them in some way.
Any help is much appreciated.
multipart/alternative just means that each part is an alternative version of the same thing, just with a different content type (say, an HTML version and a plaintext version).
multipart/mixed is used to put different content types inline. This will allow a client to put (say) an image inline in a message that is otherwise (say) plaintext.
You can read about all the multipart MIME types in the spec at https://www.rfc-editor.org/rfc/rfc2046#section-5.1 or in the Wikipedia article.
Related
I would like to know whether it is technically possible to created an S/MIME-encrypted E-Mail that also contains un-encrypted part. The idea is that the user would see the un-encrypted part, if and only if the message could not be decrypted (e.g. missing private key). Otherwise, if the message can be decrypted, the encrypted part will be displayed to the user as always.
A possible solution would be to wrap the whole S/MIME structure into a "multipart/alternative" MIME structure. One part would be "text/plain" containing some info text, the other part would be "application/pkcs7-mime" containing the actual (encrypted) payload.
However, I cannot find any information on whether S/MIME does allow this. Also it would be important to know if standard Mail-Clients can handle such construct in the intended way.
Thanks in advance for any information!
Yes, MIME allows this. Whether you'll find any mail clients that support sending it is a completely separate matter.
I'm uploading messages into my IMAP mail server via IMAP store operation. However, I would like to add "comments" to these messages so that when I download these emails again I know the they are created by "store". Basically, I need to add text which will be ignored by the formal semantics of parsing RFC822.
The specification of http://www.ietf.org/rfc/rfc822.txt defines how to add comments but I cannot make it working :(
Does anybody has en example of a RFC822 message with a comment in it?
You are probably looking for IMAP's annotations. However, it's an extension which is far from being common -- quite a lot of IMAP servers do not support it.
It seems that having a special "flag" on each message you created is something which would be enough for you. If that is correct, then simply using IMAP flags (or keywords) is what you're looking for. Simply add one special flag, like thisIsProducedByFooSoftware to the APPEND operation. (You said you were doing that via STORE -- that's wrong, in IMAP, STORE manipulates just FLAGS, it doesn't add new messages. New messages are added by APPEND.)
I'm working on an email project. For reasons that I will not go into here, doing quoted-printable encoding on long email messages is problematic in the customer's environment.
Doing base64-encoding on the HTML and text sections of the SMTP emails we are sending seems like a viable option. In testing it, it seems to work just fine in a couple test clients (like Gmail).
However I'm wondering if this will present any issues across different email clients. From reading the RFC specs, it looks like base64 is a compliant encoding for text sections, but it's unusual enough for text & html sections that I'd like to know if there will be any potential issues to consider.
Things that seem like problematic possibilities:
perhaps some older or less robust clients don't expect base64 in text or HTML email sections, and will fail to encode it
perhaps some email clients do a preview or search based on the raw content, so recipients would see base64 instead of the actual content
perhaps base64 could negatively influence deliverability/spam scoring?
Does anybody have experiences they can share? This seems like a good solution but I'd like to make sure I'm not missing something.
This is hard to answer -- yes, quoted-printable is used more often simply because it wastes less bytes (on a mostly-ASCII text) and because the raw text of the mail body part resembles the decoded output (on a mostly-ASCII text). There is nothing which forbids using base64 for the textual message parts, though.
This is pretty much an open question -- you cannot ever be sure that a MUA somewhere is not hopelessly broken to the extent of not showing anything. There's a lot of "perhaps" in there, and you're right -- but the problem is that you will never know. If it will make you sleep better, the following companies all use base64-encoded HTML in the marketing spam I'm receiving:
Mellanox
Alza.cz
Aukro.cz
Journal of Modern Physics
Any MUA which can display embedded images has to include a base64 decoder. It is definitely possible that a MUA might explicitly refuse to use that code for decoding text/plain and text/html, but in that case, you're just screwed anyway.
As a fun fact, one of these companies is happy to break the UTF-8 encoded subject at the byte boundary, inside a multibyte character, and encode both halves of the text in separate encoded-words (RFC2047 terminology here).
I want my web app to send certain mails as HTML in order to include product images.
I could of course provide a text/plain alternative as well, but is it worth the effort in this day and age? Are there common mail clients that don't support text/html, do many people turn it off for some good reason (I suppose spam, bandwidth), are there other reasons such as decreasing the risk of being classified as spam?
I can theorize, but would be interested to hear if someone has statistics, experience or other insight to support or speak against going text/html only.
You are best to send both because:
It helps reduce your spam score, even more so if your text version has the same text and links as your HTML version. This is especially true on Outlook, where no text version almost guarantees it will go the Junk folder.
A lot of people do request a text version on the client-side. Some old Blackberries default to this setting, and Windows Mobile <= v5.
Provide both. HTML in email has a slew of security problems, so those that are security-minded tend to disable HTML email in favor of plain text. Also, reply quoting conventions are fairly well-establised for text/plain data and not for HTML, making meaningful discussions in pure-HTML mail threads ugly.
Since you do have control over the content of the message, please make the plain text version readable. Some MUAs tend to auto-create the text/plain part, and do a horrible job in doing so. So if your messages are intended for customers, make sure the text/plain part is formatted nicely so you do not alienate them.
I believe clients such as iOS mail use the text/plain version to preview the first couple of lines before the user opens the mail.
I think HTML only is OK, but it should be legible without images downloaded. Outlook and Gmail both block images by default to stop tracking and viruses.
You should always have a text/plain alternative. I don't have statistics, but I'm sure that a lot of people disable HTML emails. Including me, because I'm annoyed by all those product images and meaningless fancy newsletters.
Stats I found were that 90% of emails were viewed in html-capable email viewers. If you choose not to include an option for plain text, you could be losing out on 10% of your audience. On the other hand, a well designed html email could more than outperform the 10% loss, so it might be worth the trade off.
I am struggling to get both working on PHP with Hostgator, so I think I'm going to focus on the low hanging fruit (the 90% who view html emails) and not worry about the 10%. Like IE 7, there comes a point where you can no longer support all platforms.
Google does HTML email by default, this includes Google Apps for Business and Google Apps for Educations. Thus millions of Gmail users send and receive HTML email rather than plain text email. Not sure whether there are any better stats than that out there.
Aside from the visual splendor of HTML emails - links are the only thing keeping me from sending plain text emails. They are much simpler for users at times and reduce bandwidth by over 50%. However, forcing my users to copy/paste or (* shiver *) type the URL from the plain text email is not acceptable.
However, it seems like many services such as gmail and hotmail are converting URLs into HTML links. If that's true, then for some lighter emails I could finally switch to plain text (in certain cases) without bothering anyone.
Anyone know what percentage (or what systems or clients) convert text URLs into clickable links?
Some users access via the web (Hotmail/Yahoo/Gmail) while others use clients (Outlook/Thunderbird).
All email progams I know make links clickable, web-based and normal ones.
You should consider putting the links at the end of the mail, and use "[number]" to refer to them:
You should really visit PEAR[1] and friends, PHP[2]!
[1] http://pear.php.net/
[2] http://www.php.net/
That frees you from problems with longer URLs within the text, and it keeps the text readable.
You must not forget one simple fact and that is every mail client make this configurable. So I for one have the option of reading / sending html emails but I don't do that. So it's totally irrelevant how many mail clients support this, the relevant question is how many users have this enabled.