December 15, 2007 at 08:49

How to correctly send mail from scripts (in particular - in PHP)

    The first part of the text is taken from the instructions of the hosting provider Netangels . The second is copyright.

    Sending mail from scripts to 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, it just didn’t reach, or it did, but it is displayed in a completely different way than the author wanted.

    In order to be sure that your message is sent truly true, you must have at least basic ideas about the format of the mail message. The format of the mail message is described in several standardizing documents, the main of which are RFC 822(describes the format for transmitting plain text in English) and RFC 2045  onwards (describes the extensions of this format for transmitting arbitrary data).

    Email format


    The following is the simplest example of a text message compiled in accordance with the above standards and ready to be sent.

    From: =? Windows-1251? B? 0J7RgtC / 0YDQsNCy0LjRgtC10LvRjD89? =
    To: =? Windows-1251? B? 0J / QvtC70YPRh9Cw0YLQtdC70Yw / PQ ==? =
    Subject: =? Windows-1251? B? 0Y3RgtC + INGC0LXQvNCwINGB0L7QvtCx0YnQtdC90LjRjz89? =
    Content-Type: text / plain; charset = "windows-1251"
    Content-Transfer-Encoding: 8bit

    This is a Russian language mail message.
    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, use the keyboard shortcut Ctrl + U) . The task of our script in the PHP language is to achieve exactly the same letter format.

    As you can see from the above example, the email contains two parts: the headers are placed in one (upper), and the text of the letter in the other (lower). These parts are separated from each other by an empty string. Headings consist of lines containing the subject of the letter (Subject), name and address of the sender (From), receiver (To) and other information. In the simplest case, each line contains a pair of “TitleName: Title value”. It is especially necessary to emphasize that, according to the standards, the headings should under no circumstances contain characters that are not present in the ASCII table - Latin letters, numbers, punctuation and pseudographics.

    Proper use of Russian characters in the headers of the mail message


    So, in the explicit form, the Russian text in the title should not be present, therefore, in order to include it there, this text must first be encoded. Standards describe a method for encoding “forbidden” characters. The general format is as follows:
    =? encoding? encoding method? encoded text? =
    The encoding can be any of the list “windows-1251”, “koi8-r”, “utf-8”, etc. In all cases, as a rule, the encoding of the message will coincide with the encoding in which the site operates. That is, in most cases it will be "windows-1251", less often - "utf-8".

    The encoding method indicates how the Russian characters will be converted to a secure set. Two methods are defined: the so-called “Q-encoding” (indicated by a single letter “Q”) and “Base64” (indicated by a single letter “B”).

    Unfortunately, there is no native function that could convert a regular string into Q-encoded text in PHP, but there is a function that can perform a similar conversion in Base64. So, the PHP code for correctly creating the email subject line header can look like this:

    $ subject = "=? windows-1251? b?". base64_encode ($ _ POST ["subject"]). "? =";
    Here it is assumed that in the variable $ _POST ["subject"] you have the subject of the mail message recorded in Russian in the encoding windows-1251.

    The sender or recipient address can be written in the form of "user@example.com" or in the form of "Username". In the second case, the username must be converted in the same way as in the previous example. The following is an example that assumes that the variable $ _POST ["username"] contains the username and the variable $ _POST ["email"] contains its email address:
    $ sender = "=? windows-1251? B?". base64_encode ($ _ POST ["username"]). "? = <". $ _POST ["email"]. ">";

    Content-type: multipart / ???


    Any developer who has managed to solve the problems of sending letters with attachments or HTML letters is familiar with this heading. And often letters formed without using libraries like PEAR :: Mail_mime are not displayed correctly. Practice shows that if you strictly adhere to the standard that is set in the RFC (in particular, RFC 2046 ) when composing a letter, 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 commands and understands what boundary is and why it is necessary to specify a Content-type for each part of the letter. We will try to note the main mistakes.

    Mistake One - Invalid Subtype


    The multipart type has three subtypes - mixed, alternative and related, which are used syntactically in the same way, but have different purposes.
    • mixed - used when within a single mail message there are several independent from each other, and equivalent parts. The simplest example of such a letter is a message with an attachment.
      alternative - is used when a single mail message contains several parts containing the same information intended for display on different client software - for example, a text and HTML version of the same message.
      related - is used when a single mail 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 links to the Contend-id of elements (of a view ) work.
      Remember and use as directed.

      The second mistake - the wrong order of parts

      The order of the parts in which they are indicated in the letter is often of key importance for how the message will be displayed to the client.
      • 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 letter versions by the client’s client something like this: “In general, the mail client should display the latest version of the document available to it.” Those. when forming text and HTML versions of the letter, you need to put the text ahead.
        related - the first part in the queue should be the main part (HTML document, for example). Following are all the others. By and large, the standard regulates the special parameter “start”, which indicates the main part of the document, but it is better not to abuse it.

        Third error - select only one subtype

        Often the developer who forms the letter from the program forgets that any part of the letter may also have Content-type: multipart, which means that it is possible to build some semblance of a tree structure that ensures that each part of the letter takes the right place. Here is how the structure of a letter with text and HTML versions (HTML with pictures), as well as the attached MS Word document, might 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 more recommendations

    Tags:

    Also popular now: