The first part of the text is taken from the instructions of the hosting provider Netangels . The second is the author.
Sending mail from scripts in PHP is a thing that is very common in web applications. Unfortunately, as practice shows, most developers use this function incorrectly, making the same mistakes in their scripts. As a result, it turns out that the letter to the recipient came in the wrong encoding, simply did not reach, or reached, but it does not appear at all in the way the author wanted.
In order to be sure that your message is being sent is really true, you must have at least a basic understanding of the format of the mail message. The format of an e-mail message is described in several standardizing documents, the main ones of which are
RFC 822 (describes the format for transmitting plain text in English) and
RFC 2045 and further (describes extensions of this format for transmitting arbitrary data).
Mail format
The following is the simplest example of a text message prepared in accordance with the standards listed above and ready to be sent.
')
From: =? Windows-1251? B? 0J7RgtC / 0YDQsNCy0LjRgtC10LvRjD89? = <Putin@kremlin.ru>
To: =? Windows-1251? B? 0J / QvtC70YPRh9Cw0YLQtdC70Yw / PQ ==? = <Info@netangels.ru>
Subject: =? Windows-1251? B? 0Y3RgtC + INGC0LXQvNCwINGB0L7QvtCx0YnQtdC90LjRjz89? =
Content-Type: text / plain; charset = "windows-1251"
Content-Transfer-Encoding: 8bit
This is a mail message in Russian.
Contains several lines
It is in this format that the client for sending mail (MS Outlook or Mozilla Thunderbird) prepares the message and then sends it to the recipient (by the way, most email clients allow you to view the source code of the message, in Mozilla Thunderbird, for example, the Ctrl + U key combination is used for this) . The task of our script language PHP - to achieve exactly the same letter format.
As you can see from the above example, the email contains two parts: in one (upper) headers are placed, and in the other (lower) text of the letter itself. These parts are separated from each other by an empty string. Headers consist of lines containing the subject of the letter (Subject), the name and address of the sender (From), the recipient (To) and other information. In the simplest case, each line contains a pair of "Name Header: Value Header." It is especially necessary to emphasize that, according to the standards, under no circumstances should the headers contain characters that are not present in the ASCII table - Latin letters, numbers, punctuation marks and pseudographies.
Proper use of Russian characters in email headers
So, in explicit form, the Russian text in the title should not be present, so in order to include it there, this text must first be encoded. Standards describe a way to encode "forbidden" characters. The general format is:
=? encoding? coding method? coded text? =
Encoding can be any of the windows-1251, koi8-r, utf-8, etc. list. In all cases, as a rule, the encoding of the message will coincide with the encoding in which the site works. That is, in most cases it will be “windows-1251”, less often - “utf-8”.
The encoding method indicates exactly how Russian characters will be converted into a safe set. There are two ways: the so-called “Q-encoding” (denoted by one letter “Q”) and “Base64” (denoted by one letter “B”).
Unfortunately, there is no regular function that could convert a regular string to Q-encoded text in PHP, but there is a function that can perform a similar conversion to Base64. So, the PHP code for the correct creation of the email subject header might look like this:
$ subject = "=? windows-1251? b?". base64_encode ($ _ POST ["subject"]). "? =";
Here it is assumed that in the $ _POST [“subject”] variable you have the subject of the email message, written in Russian in the windows-1251 encoding.
The address of the sender or recipient can be recorded in the form of “user@example.com” or in the form of “User name <user@example.com>”. In the second case, the user name must be converted in the same way as in the previous example. Below is an example that assumes that the variable $ _POST [“username”] contains the name of the user, and the variable $ _POST [“email”] contains his email address:
$ sender = "=? windows-1251? B?". base64_encode ($ _ POST ["username"]). "? = <". $ _POST ["email"]. ">";
Content-type: multipart / ???
This title is familiar to any developer who has had the opportunity to solve the problem of sending emails with attachments or HTML emails. And often letters formed without using libraries like
PEAR :: Mail_mime are displayed not very correctly. Practice shows that if you strictly adhere to the standard set in the RFC (in particular,
RFC 2046 ), the vast majority of client programs (including those who like to adhere to standards like Mozilla Thunderbird) display the letter correctly. Further, we will proceed from the fact that the reader of this document understands the basic syntax of the commands and understands that such a boundary is and why it is necessary to specify the Content-type for each of the parts of the letter. We will try to note the main mistakes.
Error one - invalid subtype
The multipart type has three subtypes - mixed, alternative and related, which are used syntactically the same, but have different purposes.
- mixed - used when there are several independent and equivalent parts within one email message. The simplest example of such a letter is a message with an attachment.
alternative - used when a single email message contains several parts containing the same information intended for display on different client software — for example, a textual and HTML version of the same letter.
related - used when a single email message contains several parts that form one final document. A striking example is an HTML letter with pictures. Remember, according to the standard, only in this case should references to the Contend-id elements (of the form <img src = "cid: image">).
Remember and use as directed.
Error two - wrong order of parts
The order of the parts in which they are indicated in the letter often has key meanings for how the message will be displayed to the customer.
- mixed - the order of the parts for our tasks does not matter.
alternative - parts should be arranged in order, from simpler to more complex. The RFC regulates the process of selecting one of the client’s client’s email versions like this: “In general, the email client should display the latest version of the document available to it”. Those. when forming a text and HTML-version of the letter, you must put text in advance.
related - the main part should go first (an HTML document, for example). Next - all the rest. By and large, the standard is regulated by a special parameter “start”, which indicates the main part of the document, but it is better not to abuse this.
Error three - select only one subtype
Often, the developer who forms the letter from the program forgets that any part of the letter can also have a Content-type: multipart, which means you can build some sort of tree structure that ensures that each part of the letter takes the right place. Here is how the structure of a letter that has a text and HTML version (HTML with pictures), as well as an attached MS Word document may look like:
- Content-type: multipart / mixed
- Content-type: multipart / alternative
- Content-type: text / plain
Content-type: multipart / related
- Content-type: text / html
Content-type: image / jpeg
Content-type: image / jpeg
Content-type: application / msword
And finally - a couple of recommendations.