This standard specifies the format of advertising e-mails that are transmitted on the domestic Internet and comply with relevant national laws and regulations, mainly including the vocabulary of advertising e-mails, the format of header fields and message bodies, and the syntax of header fields. The purpose of formulating this standard is to define the format of message content transmitted between mail systems, and mail systems may or may not use this format when storing messages locally, that is, the local storage method is not within the scope of this standard. This standard is applicable to senders and publishers of advertising e-mails to write and check the format of Internet advertising e-mails and prevent spam e-mails. At the same time, this standard is also the technical basis for Internet e-mail management departments to supervise and inspect advertising e-mail services. YD/T 1310-2004 Requirements for the format of Internet advertising e-mails YD/T1310-2004 Standard download decompression password: www.bzxz.net
This standard specifies the format of advertising e-mails that are transmitted on the domestic Internet and comply with relevant national laws and regulations, mainly including the vocabulary of advertising e-mails, the format of header fields and message bodies, and the syntax of header fields. The purpose of establishing this standard is to define the format of the message content transmitted between mail systems. Mail systems may or may not use this format when storing messages locally, that is, the local storage method is not within the scope of this standard. This standard is applicable to senders and publishers of advertising mails to write and check the format of Internet advertising emails and to prevent spam emails. At the same time, this standard is also the technical basis for Internet email management departments to supervise and inspect advertising email services.

Communication industry standard of the People's Republic of China
YD/T1310-2004
Requirements of internet advertising e-mail format
The requirements of internet advertising e-mail format2004-03-24Release
Implementation on 2004-03-24
Ministry of Information Industry of the People's Republic of ChinaBefore release
2Normative references...
3Definitions and abbreviations
4Format of electronic documents:
Appendix ANormative appendix:Requirements for the format of electronic documentsA. River method analysis.
03Grammar
Institute BAnti-standard appendix)MIE Mail header section: B.1 MIME version field
B.2 Content type header field
B.3 Content-transfer encoding header field
B.4 Content header field
B5 Content description header section.
Additional MDM header section
YD/T1310-2004
YD/T1310-2004
This standard is one of the Internet email series standards. The name and structure of this series of standards are as follows: 1. YD/T13T0-2004 Internet Email Format Requirements; 2. YDT1311-2004 Technical Requirements for Preventing Internet Spam Electronic Files. The standard is based on ETF RHC2322 Multi-user Internet Mail Format and TET KHC2045 Multi-user Internet Mail Extension (MTMF Part 1: Internet Message Body Format 3, and is formulated in accordance with the actual situation of domestic network services. With the advancement of network technology, this standard will be gradually supplemented and completed. Appendices A and B of this standard are normative appendices. This standard is proposed by China Information Technology Standardization Association and drafted by: Telecommunication Research Institute of Ministry of Information Industry. This standard is submitted by: YD/T1310-2004
With the development of the Internet, a large number of commercial advertising emails still need to be transmitted through the Internet, which is in line with the current situation. At the same time, a large number of junk emails are spreading on the Internet. In order to combat and prevent the transmission of junk emails and ensure the legitimate development of Internet advertising email services, it is necessary to formulate corresponding advertising email format standards and prevention and control email standards, so as to provide a basis for the mail system to distinguish legitimate advertising emails from junk emails, and pass legitimate advertising emails to users, and send junk emails.
In reality, the vast majority of junk emails are advertising emails, and there are also emails that endanger the safety of users and information security. Among the advertising emails, there are a large number of illegal advertising emails that are sent against the will of users and are difficult to insure and trace. These should be identified as spam. E-mail. Only the advertising e-mails approved by the relevant national management departments and published by the advertising e-mail operators in accordance with the format regulations of the Ministry of Advertising are legal advertising e-mails. 1 Scope
Requirements for the format of Internet advertising e-mails
YD/T1310-2004
This standard stipulates the format of e-mails that are transmitted through the Internet and comply with the relevant national laws and regulations, mainly including the format of the advertising e-mail, the format of the header field and the message body, and the format of its sub-fields. The purpose of formulating this standard is to define the format of the message content transmitted by the mail system, and the mail system may or may not use this format when storing the message locally, that is, the format of the local storage is not Within the scope specified in this standard, this standard applies to senders and publishers of advertisement emails, and also includes the format of the emails sent to and published on the Internet to check the weak scope of spam emails: At present, this standard is also the technical basis for the Internet email management department to monitor and check the advertisement email business. 2 Normative reference documents
The clauses in the following documents are referenced by this standard and are the clauses of this standard. They are dated reference documents: all subsequent changes (excluding errata) or revisions are not applicable to this standard. However, the parties who reach an agreement based on this standard are encouraged to study whether the latest version of this document can be used. The latest version of the document without an undated date applies to this standard RFC2822
KFC 2045
RFC 2234
3 Definitions and Abbreviations
3.1 Definitions
Internet Message Format or
Use Internet Mail Extensions (MTME) Part 1, BNF Grammar Specification for Internet Message Body Format Enhancement
Internet Advertising Email: Internet email for advertising purposes. Internet Spam Email (hereinafter referred to as Spam): Email that conceals information such as the sender's identity or address: Email that contains false information such as the source, sender or route. Emails that meet any of the above characteristics should be considered spam. Grammar, the actual rules for the structure of each part of the email message: the description of each part and the rules for how the parts should be unpacked. Advertising email sender: can be a legal person who commissions others to design, produce, publish, and distribute advertising emails in order to promote products or provide exhibition services; can also be a legal person who is commissioned to provide advertising email design, production, and agency services; other economic organizations or individuals
Advertising email sender: for the purpose of publishing advertising emails, the advertising email sender meets the legal status of the advertising email publisher. The advertising component publisher and the advertising email sender can be the same entity. 3.2 Abbreviations This standard makes use of the following abbreviations and abbreviations: ABNF Augerled Baukus Naur Form Enhanced Backus-Naur Rule American Standard Code for Inlunaution Encerchange American Information Interchange Standard Code 1 Customer Standard Industry Data Free Download YD/T 1310-2004 Multipurpose Internet MailExtensinns Siaple Muil Transter PrutoculLniversal Time Coordinated
4 Advertising e-mail format
Grid mail extension for the purpose of article
Simplified Chinese Mail Transfer Protocol
International Coordinated Time
An advertising e-mail message contains several header characters and an optional message body after the header fields: The header contains a few lines that conform to the standard syntax: The message body is the character sequence after the header, separated by a white line. For general format requirements of emails, please refer to the provisions of Appendix A of this standard. The following chapters only focus on the format requirements of attachments of advertising emails. 4.1 Message Body
The message body of an advertising email should contain the real identity information and contact method of the sender of the advertising email so that the recipient can contact the sender of the advertising email.
The advertising email should also contain at least one way to unsubscribe and a specific method in its message body. The unsubscribe method can be an email address for unsubscribe or a hyperlink to a web page for unsubscribe. In addition to the above two unsubscribe methods, other clear and effective methods can also be used.
The advertising email should add a hyperlink to the spam email center at the end of the message: for users to request to submit emails. The length of the message body of the advertising email should not exceed kB. Note: For multimedia emails, please refer to the provisions of Appendix B. 4.2 Header Fields
All header fields of a message have the same general structure: field name, followed by number, followed by field body. The specific syntax of each field is defined in Appendix A.
4.2.1 Sender Field
The sender field is mandatory: only authorized institutions (or mail service providers) with the qualifications to operate online advertising mail can operate online advertising mail business, including the publishing and sending of advertising mail: when sending advertising mail, the authorized advertising mail sender should use the mail address uniformly registered with the management agency as the sender address, and entrust the authorized advertising mail publisher to publish. The mail sender should use the mail server (fixed address) uniformly registered with the management agency to send the advertising mail. 4.2.2 Destination Address Field
According to the requirements of the State Council for preventing spam emails, the total length of the address list of the above three fields of the advertising email should not exceed 30.
4.2.3 Identification field
The mese-id of the advertising component should start with the English character A and contain the complete address of the sending machine, for example [email protected]:xxx go! The unique identifier of the publisher of the advertising email. The identifier of the publisher of the advertising email should be registered with the management agency. The content of the identifier field should be determined by the server that publishes the advertising email according to the information sent by the advertising email: 4.2.4 Information field
The header of the advertisement email must start with "advertisement" in Chinese or "ad" in English, and cannot be empty. The header of the advertisement email should contain the identifier of the advertisement, such as: real estate, stock market, automobile, etc.:
Customer category standard industry data free download 4.2.5 Trace field
YD/T1310-2004
The server that originally sends the email should record the publisher's address of the advertisement email in the trace section. The format should fully include the publisher's identification, such as: Reported: from galaigul.vrg (linuxaid.cemm.cn [202.90.11.120) by nhil.alpha.con.ci... is invalid. Design: At present, due to the low success rate of reverse address reduction, the content of Rceied learning and destruction is temporarily not strictly required. YD.T1310-2004
Appendix A
(Normative Appendix)
The format of the email should be This standard adopts the formal definition of ABNF notation specified in RHC 2234: characters can be represented by decimal values ​​(such as %65 for uppercase A, %95 for lowercase a), or by case-insensitive text in quotation marks (such as "A" for uppercase or lowercase A). A.1 Method Analysis A.1.1 Overview An email message consists of 11 characters: A small email message that conforms to this standard is composed of characters with values ​​1-127 and is interpreted as an ASCII character: for convenience, This standard refers to characters in this range as ASCH characters (there are actually more than 127 ASCI characters). Multimedia mail messages use values ​​other than 1-127 (refer to RFC2045 Multipurpose Internet Mail Extensions (MME) Part 1: Network Message Format).
Email messages can be divided into lines of characters. A line is a series of strings, which are delimited by a carriage return (A5CH value 13) and a line feed (ASCI value ID). Usually, CRLF is used. A message contains several header characters. The header and body of the message are separated by a line. The header is a line that conforms to the syntax of this standard. The body of the message is a sequence of characters after the header. The length of each line in a message is determined by the character string. A.1.1.1 Line length restrictions
There are two restrictions on the length of each line in a message: first, except for CREF, each line should not exceed 8 characters. Second, except for CRT.F, it is recommended that each line not exceed 998 characters. The reason for the 998-character limit is that many of the machines that send and receive Internet mail cannot handle lines longer than 9 characters. The receiving tool should handle the case where a line contains a suffix for robustness reasons. However, many tools cannot handle messages longer than 10 characters (including CRLF): it is therefore important to require that tools not generate such messages. The more conservative designation of not exceeding 78 characters is based on the fact that many users of display messages may truncate or freeze the portion of a line that exceeds 78 characters. Violations of this standard are not tolerated. Even with this limit on messages, the handling of very long lines (99% of the characters or less) by the display message tool may still impose a load on the program's performance. A.1.2 Header Characters
A header line consists of a field name, a user name, a character, and a carriage return and line feed. The field name must consist of printable ASCT characters (values ​​between 33 and 126), but not a character number. Note that the character string must not contain a carriage return or line feed. The body of a field may contain any line feed character. However, when header folding and major folding are used, the body of the field may contain line feed characters. All field bodies must conform to the syntax specified in A.2 of this standard.
A.1.2.1 Unstructured header body
Some paragraph bodies are unstructured, and no special requirements are imposed on their format: in this case, the body of the header field is simply treated as a line feed character, without any other characters, except for header folding and major folding for long header paragraphs: A.1.2.2 Structured header body
Some fields have an undefined syntactic structure, called structured header body. Structured header body is a sequence of undefined lexical symbols: grammatically, annotations may be added before or after these symbols (the method of annotation is described in A.2.3.3).
YDT 1310-20Q4
defined) or space (ASCII value 32:, horizontal tab character (ASCII value 9) space and horizontal stop character are collectively referred to as word space characters (WSP: these automatic spaces should comply with the provisions of the header folding and de-folding in 1.2.3, and the meaning of the structured header field is analyzed to derive their grammatical provisions
A.1.2.3 long header field
The paragraph is logically a line of characters, including the name of the character, the script number and the paragraph, but in order to deal with the limitation of 9988 characters per line, the characters of the header field can be divided into multiple lines, called "registration", the general principle is: in the technical standard barrier Where white space is allowed, a carriage return and line feed character may be inserted before it: the comma is inserted at the beginning of the sentence, but not at any other position (although between two "" characters, this is not recommended). The process of converting a multi-line header field to a single line is called "decompression". Except for the CRL character before the space,
A.1.3 Message Body
In short, the message body is a number of lines, each line consists of ASC characters. The two characters CKLF must appear together in the message body of the email!
Except for CRLF, each line should be less than 998 characters, and less than 7R characters are recommended. Design: For multimedia email, please refer to the regulations in Appendix B. A.2 Syntax
A2.1 Introduction
This section defines the syntax for Internet messages: Messages conforming to this standard must conform to the specifications of this specification. The primitive symbols used in the expressions defined but not specified are from RFC 2234. In these definitions, there are non-terminal symbols with names beginning with "u-". These non-terminal symbols are Internet syntax symbols defined by the user: In all cases, these symbols shall be ignored. However, when interpreting messages, these symbols shall be recognized as legal parts of the syntax.
A2.2 Lexical Symbols
The following rules are used to define the lower-level lexical analyzer, which will respond to the higher-level parsers. This section defines the symbols used to construct the header fields.
The syntax is used for both lower-level and higher-level grammars. Specifically, spaces and groupings defined in RHC 22.3 are used here as coaxial symbols, which are then defined as part of the coaxial symbols: therefore, even without explicit meaning, spaces and groupings may appear in coaxial symbols.
A.2.2.1 Primitive symbols
are primitive symbols referred to in other parts of this standard, rather than those defined in RHC 2.234. Some of them will not appear in other parts of the grammar, but may be referenced in other parts of this standard: NOTE: The following "coial" symbols are for convenience only. The characters in the "eials" symbol can be used as a point in the vocabulary analysis NO-WS-CTT
ad14-317
: ASC control characters
: brackets, line feed
: and white space characters
W customer standard industry data free download YD/T1310-2004
speciuty
d14-127/
obs-text
\t\+\y\f
DQUOTE
These column numbers have no special semantics, they are just single characters. A.2.2.2 Quotation characters
: Characters other than carriage and line feed
: Special characters used in other parts of the grammar Some characters are reserved for special interpretations, such as delimiter lexical characters. In order to interpret these characters in a special way, a method of quoting characters is provided.
quoted-pair
(\\ ccxt)/ cbs-qp
Where a quotation pair appears, only the text characters in it should be interpreted. That is, "" as part of a quotation pair is invisible.
Note: "" may not be part of a quotation pair. In the general case, a single "," is not invisible. Reference characters are used for the following syntax: #coonteot, qconteat, dcontent., nn-fol.J-qwoie and mur-fulu lirrul: A22.3 Whitespace characters (defined in 4.1.2.2) including whitespace characters used for folding (the [carriage feed character in A.1.2.3) may appear between many elements of a header paragraph. Similarly, characters used as comments may appear in bracketed form in the structured header field body. The string of characters in the following definitions of folding whitespace and comment characters shall be considered a comment unless it appears within reference characters (defined in A.2.2.5).
In this standard, some places allow insertion of comments and folding white space (written as FWS). In order to meet the grammatical requirements, a special CFWS symbol is defined to represent HWS and: or) where comments can appear. However, the current insertion method of CFWS in this standard does not use any of the required header words - the implementation is entirely up to the WP group! No other content: Fws
[*WSPCRIFI1+WSP)
ahs-Fws
NO-WS-CTL
d33-397
&d93-126
: folding white space
: control characters other than white space
except (" " and "\"
, ASCI characters
ocrontenl
aimmen[
ckxt/ quoted-pair / coument
\(\[FwS] ccontent)[FwS]\y\([Fws]cunment)((iFwsloomment)/ws)YD/T 1310-2004
Where FWS appears in this standard, it indicates the position of the header field described in A.1.2.3. If the header field appears in the same place as the comment field, it should be removed before further decomposition of the header field according to the standard: In other words, the CRI.F of FWS is not semantically visible, and the standard usually uses the field field to provide information that is easy to understand. Since comments are allowed to contain FWS, comments are allowed in comments: Because quote character pairs can appear in comments, parentheses and backslash characters can appear in comments as long as they are used as quote character pairs. Semantically speaking: the closed left and right parentheses are not part of the comment, while the comment is the content of the parentheses. As mentioned above, in the standard interpretation, the backslash "" in any quote character pair and the CRLF in FWS are semantically invisible and are not part of the comment.
In structured header fields, consecutive FWS between ciphertext characters may be interpreted as a single space character. A.2.2.4 Atoms atam
Some structured header fields are simple characters consisting of certain basic characters, called aoms. Some structured header fields also allow a period (ASCII value 46) to appear in the atom1 sequence. For this purpose, an additional dot-arom symbol is defined.
ist-alu
sl-wn-tex
ALIHA/DIGIT! 5 Any character other than ciphertext characters, space characters, and STeeials characters \\f\\
\$\-%\?
\_\f\m
\_\1\}
\f\[\]
: Used in atoms
[CFwS] ]*atext [CHwS]bzxZ.net
CFwS] dot-arom-ext [CFwS]
+*atext *(\.\ [*atext)
A.2.2.5 Quoted Character Strings A string consisting of
characters (including characters not allowed in wm) can be expressed as a quoted character string format, where the characters are preceded by a quotation mark (DQUOTE, ASCI 34). Qrex
NO-WS-CTL/
: Control characters other than space
: Except for quotes and "" characters
YD/T 1310.-2004
gconent
quored-string
%d35-91?
qtext I qunted-pait
[CFWS1
, the ASCI characters
DQUOTE +([EWSIqconten) [FWS DQUOTE[CPWS]
are treated as a unit in the quoted string: that is, the quoted string is semantically the same as the original string, because the quoted string can contain FWS, so it can be folded. Because the ! pair can appear in the quoted string, the slash and backslash characters can appear in the quoted string as long as they are used as quotes. Semantically, the optional CFW and punctuation characters are not part of the quoted string, but are part of the quoted string. As mentioned above, in the quoted string, the backslash "\" in any quoted pair and the CRLF in FWS/CHWS are not semantically visible because they are not part of the quoted string. A2.2.6 Miscellaneous Symbols
Define three additional symbols: wamd and phras are combinations of source (or) quoted pairs, and utndructured is used for unstructured header words and certain structured header fields. word
phrase
unstruclured
A.2.3 Date and time specifications
atom / quoted-string
J*word/ans-pnrase.
NO-WS-CTL/
bs-ufext
: Control strings other than whitespace
: Other ASCI derivatives
*([FwS] utext) [FwS]
Dates and times are sometimes used in header fields. This section specifies the syntax for the full date and time format: In the date-time format, whitespace may appear, but it is recommended that only one space character appear at each FWS occurrence (whether required or optional). Some older implementations may not correctly interpret the additional whitespace. dare-tire
day-ot-week
day-nac
month-oame
ine-of-day
[ day-of-week -\ ] dete FwS tim- [CFwS][[Fws] daynane? /ubs-duy-f-weck\Mon\/\Tue\\\wed\/\Thu\f\Fi\,\Sar\f\Sun\day month veau
4*DIGIT / obs.year
(FwS month-naneFwS)/ubei-rntu\Jau\\Feb\/\Mus }\Apr\ f\May\\\Jun\/\Ju!\}\Aug\\Sep\I\Ort\j\Now\ Dex
(FWS*2IGrT)/obs-day
timc-uf-day Fws zone
hour\,\minetc [\\\ sccond ]2DIGT /obs-hour
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.