- •If it is impossible to deliver the mail to the sender, a service message with a refusal comes. There are three main reasons for the refusal:
- •In addition to the service information, the message headers also store information displayed to the user, this is usually the sender of the letter, the recipient, the subject and the date of sending.
- •In addition to the standard, mail clients, mail servers and robots can add their own headers, starting with “X-“ (for example, X-Mailer, X-MyServer-Note-ok or X-Spamassasin-Level).
- •2. Dhtml version
- •Images - array of all images of the document;
- •3. Appendix a. Css properties (style properties), css parameters
In addition to the service information, the message headers also store information displayed to the user, this is usually the sender of the letter, the recipient, the subject and the date of sending.
Message headers can only contain 7-bit characters [10]. If you need to use national symbols in some fields, you need to use encodings. Typically, this is Base64 or Quoted-Printable.
Commonly used headers
Return-Path: (RFC 821, RFC 1123) – the return address in case of failure, when it is impossible to deliver the letter to the destination address. It can differ from MAIL FROM and From: header, Sender: or Reply-To: header, but it usually matches MAIL FROM.
Received: (RFC 822, RFC 1123) – data about the message passing through each specific mail server (MTA). When passing through several mail servers (the usual situation), new headers are added over the previous ones, eventually the transfer log will be written in the reverse order (from the nearest to the receiver of the node to the farthest).
MIME-Version: (RFC 1521) is the version of the MIME with which this message was created. Often this header is created before everyone else, so it is usually the first (that is, the last one in the list).
From: (RFC 822, RFC 1123, RFC 1036) – the name and address of the sender (it is in this header that a text field with the sender’s name appears). It may not coincide with the return-path and not even coincide with the SMTP MAIL FROM: header.
Sender: (RFC 822, RFC 1123) – the sender of the letter. Added for the possibility to indicate that a letter from someone’s name (from) was sent by another person (for example, a secretary on behalf of the chief). Some email clients show a message when there is sender and from as “message from ‘sender’ on behalf of ‘from’.” Sender is an information header (and may also differ from the SMTP MAIL FROM header).
To: (RFC 822, RFC 1123) – the name and address of the recipient. It can be kept several times (if the letter is addressed to several recipients). Based on this field, the contents of the SMTP RCPT TO field are generated.
Cc: (RFC 822, RFC 1123) – (from English carbon copy) contains the names and addresses of the secondary recipients of the letter to which the copy is sent. Participates in the formation of the SMTP RCPT TO field, as well as the “To” field.
Bcc: (RFC 822, RFC 1123) – (from English blind carbon copy) contains the names and addresses of the recipients of the letter whose addresses should not be shown to other recipients. Participates in the formation of the SMTP RCPT TO field, as the “To” and “Cc” fields, but is absent in the message being sent.
Reply-To: (RFC 822, RFC 1036) is the name and address of the answers to this email. If, for example, a letter is sent by a robot, then the Reply-To address will contain the address of the mailbox, ready to accept the reply to the letter.
Message-ID: (RFC 822, RFC 1036) is a unique message identifier. It consists of the address of the sending node and the number (unique within the node). The algorithm for generating a unique number depends on the server / client. It looks something like this: AAB77AA2175ADD4BACECE2A49988705C0C93BB7B4A@example.com. Together with other identifiers it is used to search for the passage of a specific message in the journals of the postal system (postal systems fix the message passing through its Message-ID) and to point to a letter from other letters (used for grouping and building conversation chains). It is usually created by the mail client (MUA) at the time of composing the letter.
In-Reply-To: (RFC 822) – indicates the Message-ID for which this email is the answer (with this, mail clients can easily build a conversation chain – each new response contains a Message-ID for the previous message).
Subject: (RFC 822, RFC 1036) is the subject of the letter.
Date: (RFC 822, RFC 1123, RFC 1036) – the date the email was sent.
Content-Type: (RFC 1049, RFC 1123, RFC 1521, RFC 1766) is the content type of the message (HTML, RTF, Plain text) and the encoding in which the message was created (see encoding below)
Return-Receipt-To: (RFC 2076) – the e-mail where the recipient’s mail server should send the delivery notification. RFC 2076 is mentioned in the “Not Internet standard” section, so it may not be supported by servers.
Disposition-Notification-To: (RFC 3798) – e-mail where the recipient’s mail client should send a delivery notification if the user allows it (through settings, etc.).
