Standarts for email source code - email

I am looking for standarts for email source code, just to know how to generate it using php.
My specific problem is with multipart/mixed email.
The email's subject is in cyrilic and when I am sending email it arives without errors, but subject of email can't be read. There is some problem with encoding.
Here is my email header:
From: no-reply#sample.eu\n
Reply-To: no-reply#sample.eu\n
Cc:\n
Bcc:\n
X-Priority: 1 (Highest)\n
X-Mailer: PHP/5.3.29\n
MIME-Version: 1.0\n
Content-Type: multipart/mixed;\n
boundary="==Multipart_Boundary_x3865d75cb66632b12851874c2aafd492x"\n
Please help!

The email standard is pretty large, but you should be able to work through the broad picture in a few days. The wikipedia page for email has links to all the RFC standards for the message format. It also has a broad overview of the format.
The standard for the main format is defined here. Mime/multimedia attachments are covered here and here.
IMHO, I would try to find a library to deal with this sort of stuff. It's easy to make mistakes when you are formatting this on your own. Here is one in PEAR that seems to do what you need.
Or, instead of trying to figure out how to do this in php, try to use a language with better unicode support like Python3 or Perl5 that actually does this for you automatically. You'll waste a lot less time.

Related

How to select a URL from an email in mutt and open it in a web browser?

When I read mails I sometimes would like to select one of the links in the mail's text to open it in a web browser.
Before you answer, I know there is urlview, but there are also BASE64-encoded (or other transfer encodings) mails from which urlview does not find any URLs. Then there are also HTML-only mails that can also be encoded with transfer encodings.
I wonder if there is a trivial and/or nice solution that I couldn't find. I cannot be the only one with this problem. It does not need to be based on urlview, of course.
urlview will work if you employ the "pipe_decode" setting. Example use in a macro, binding to "\u":
macro index,pager \\u "<enter-command>set pipe_decode = yes<enter><pipe-message>urlview<enter><enter-command>set pipe_decode = no<enter>" "view URLs"
with urlscan there exists a worthy successor to urlview.
Support for emails in quoted-printable and base64 encodings. [..] For HTML mails, a crude parser is used to render the HTML into text.

Replying to other email

I'm building webmail with PhpMailer.
I need advice about replaying to other email.
How to attach previous email? Should I simply attach it as a file - I think it's not good.
I prefer attach email text, but how? Using only blockquote? But what about previous mail's styles? I see in thunderbird blockquote with cite="mid:hash" attribute. What is it?
Maybe PhpMailer has some options regarding this?
It's generally pretty straightforward. Read this about how to deal with the headers (use addCustomHeader to set them) so that mail clients can identify it as a reply.
There's no particular standard for what to do with the body, though it's common to copy all the lines of the original body into the new message, preceded by >, though you could wrap it in a blockquote in HTML, or some other formatting. It's up to you what you do with attachments.

MIME Emails - PDF and Content-ID

We are sending Emails using The MIME-Format.
(Underlying language is Java, using MultiPartEmail).
It has been reported by customers that their system reads the .pdf-Attachment of our emails twice.
The reason for this is, apparently, the lack of a Content-ID for the attachment.
I'm trying to fix this but found really vague information about the content-ID. Reading the standard i figured it is just supposed to be some unique ID in the form of <ID#domain>.
So i added this into our email generation, so that the "slot" which references the .pdf-attachment looks something like this:
------=_Part_0_12345667890
Content-Type: application/pdf;
name=theName.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=theName.pdf
Content-ID: <1431939868331#domain>
Is that all there is about it? The number is current time in milliseconds.
I'm unclear about the domain. Is it critical that this domain is exactly the right one?
And how can i understand this Content-ID attribute? Is it simply what i think it is: an ID so that attachments can be uniquly referenced by some email-systems or is there more to it? Why is the domain important?
Edit: I don't know if its related, but it seems the .pdf-Attachment doesnt show in the iPhone Mail software. I can't think of any other reason it would not show, as .pdf is surely supported and the files are also quite small. (The icon of an attachment shows in the overview-list but the attachment is nowhere referenced in the opened email)
To answer my own question:
Yes, it does the trick for many email services. There just has to be some kind of ID for the elements contained in MIME and then they are rendered and read correctly.

Exchange Disclaimer plain text formatting

I am using a Transport Rule in Exchange Server 2010 to append some HTML to the end of our company emails. This is working just fine when an email is sent out as HTML. When the message is plain text, the HTML and images are converted into [links] and it looks a mess.
Is it possible to apply conditional formatting to append an HTML message at the end of HTML emails, and a different layout for plain text emails? Failing that, can I get it to simply ignore the rule if the message isn't in HTML?
Thank you
I have discovered that the only way to achieve what I was after is by using a 3rd party add-on. So the answer to the question really is "no" for both parts!
3rd party tools like Symprex or Exclaimer may help people out in a similar situation.

Multipart email best practices

I am developing a web app that sends out emails. Currently, all emails have a HTML part.
Questions:
Is it important to include a text part also?
Do you include both?
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part?
Thanks, Kevin
Is it Important to include a text part also? It's a best practice to provide a plain text version of the email. However, in my opinion and in this day and age, I would guess that it is not such a big deal to leave it out. However, if you know more about your recipients' email clients (eg: if you're sending the emails in a corporate environment and everyone uses a particular email client), then you can determine how necessary it really is.
Do you include both? The .net framework (which I use) provides an AlternateView class (MSDN) that allows you to easily specify copies of an email in different formats. It makes things very easy to include a plain text version of the email. Perhaps you can find something similar in apache/php.
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part? Technically, yes but be VERY CAREFUL here. A complex HTML layout that has been converted to plain text will look absolutely terrible if all you do is remove HTML tags and pile the content together. It really depends on your content and how much you can do to manipulate said content. Also, take a look at Campaign Monitor'ssuggestions for formatting plain text emails.
One final word of advice for you HTML emails to test, test, and then test some more. When you're finished testing, test again. HTML emails will render differently in different email clients and, if some of your recipients are using Microsoft Word 2007/2010 then you can forget about web standards. I urge you to take a look at Campaign Monitor's Guide to CSS support in email.