RFC4096 日本語訳
4096 Policy-Mandated Labels Such as "Adv:" in Email Subject HeadersConsidered Ineffective At Best. C. Malamud. May 2005. (Format: TXT=31618 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Malamud Request for Comments: 4096 Memory Palace Press Category: Informational May 2005
Network Working Group C. Malamud Request for Comments: 4096 Memory Palace Press Category: Informational May 2005
Policy-Mandated Labels Such as "Adv:" in Email Subject Headers
Considered Ineffective At Best
Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
Abstract
This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective.
This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective.
Table of Contents
Table of Contents
1. Labeling Requirements ...........................................2
1.1. Terminology ................................................3
2. Subject Line Encoding ...........................................3
3. Implementing a Labeling Requirement .............................5
4. Subjects are For Humans, Not Labels .............................6
5. Solicitation Class Keywords .....................................8
6. Security Considerations ........................................10
7. Recommendations ................................................10
8. Acknowledgements ...............................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................11
1. Labeling Requirements ...........................................2 1.1. Terminology ................................................3 2. Subject Line Encoding ...........................................3 3. Implementing a Labeling Requirement .............................5 4. Subjects are For Humans, Not Labels .............................6 5. Solicitation Class Keywords .....................................8 6. Security Considerations ........................................10 7. Recommendations ................................................10 8. Acknowledgements ...............................................10 9. References .....................................................11 9.1. Normative References ......................................11 9.2. Informative References ....................................11
Malamud Informational [Page 1] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 1] RFC 4096 Policy Labeling Ineffective May 2005
1. Labeling Requirements
1. Labeling Requirements
The U.S. Congress and President have enacted the Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (CAN-SPAM Act of 2003) [US], which requires in Section 11(2) that the Federal Trade Commission:
The U.S. Congress and President have enacted the Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (CAN-SPAM Act of 2003) [US], which requires in Section 11(2) that the Federal Trade Commission:
"[transmit to the Congress] a report, within 18 months after the
date of enactment of this Act, that sets forth a plan for
requiring commercial electronic mail to be identifiable from its
subject line, by means of compliance with Internet Engineering
Task Force Standards, the use of the characters "ADV" in the
subject line, or other comparable identifier, or an explanation of
any concerns the Commission has that cause the Commission to
recommend against this plan."
"[transmit to the Congress] a report, within 18 months after the date of enactment of this Act, that sets forth a plan for requiring commercial electronic mail to be identifiable from its subject line, by means of compliance with Internet Engineering Task Force Standards, the use of the characters "ADV" in the subject line, or other comparable identifier, or an explanation of any concerns the Commission has that cause the Commission to recommend against this plan."
The Korean Government has enacted the Act on Promotion of Information and Communication and Communications Network Utilization and Information Protection of 2001 [Korea]. As explained by the Korea Information Security Agency, the government body with enforcement authority under the act, Korean law makes it mandatory as of June, 2003 to:
The Korean Government has enacted the Act on Promotion of Information and Communication and Communications Network Utilization and Information Protection of 2001 [Korea]. As explained by the Korea Information Security Agency, the government body with enforcement authority under the act, Korean law makes it mandatory as of June, 2003 to:
"include the '@' (at) symbol in the title portion (right-side) of
any commercial e-mail address, in addition to the words
'(Advertisement)' or '(Adult Advertisement)' as applicable. The
inclusion of the '@' symbol, as proposed by the Korean government,
is intended to indicate an e-mail advertisement. Because e-mails
easily cross international borders, the '@' symbol may be used as
a symbol for filtering advertisement mails." [KISA]
"include the '@' (at) symbol in the title portion (right-side) of any commercial e-mail address, in addition to the words '(Advertisement)' or '(Adult Advertisement)' as applicable. The inclusion of the '@' symbol, as proposed by the Korean government, is intended to indicate an e-mail advertisement. Because e-mails easily cross international borders, the '@' symbol may be used as a symbol for filtering advertisement mails." [KISA]
The State of Colorado has enacted the Colorado Junk Email Law, which states:
The State of Colorado has enacted the Colorado Junk Email Law, which states:
"It shall be a violation of this article for any person that sends
an unsolicited commercial electronic mail message to fail to use
the exact characters "ADV:" (the capital letters "A", "D", and
"V", in that order, followed immediately by a colon) as the first
four characters in the subject line of an unsolicited commercial
electronic mail message." [Colorado]
"It shall be a violation of this article for any person that sends an unsolicited commercial electronic mail message to fail to use the exact characters "ADV:" (the capital letters "A", "D", and "V", in that order, followed immediately by a colon) as the first four characters in the subject line of an unsolicited commercial electronic mail message." [Colorado]
The Rules of Professional Conduct of the Florida Bar require, in Rule 4-7.6(c)(3) states:
The Rules of Professional Conduct of the Florida Bar require, in Rule 4-7.6(c)(3) states:
"A lawyer shall not send, or knowingly permit to be sent, on the
lawyer's behalf or on behalf of the lawyer's firm or partner, an
associate, or any other lawyer affiliated with the lawyer or the
lawyer's firm, an unsolicited electronic mail communication
"A lawyer shall not send, or knowingly permit to be sent, on the lawyer's behalf or on behalf of the lawyer's firm or partner, an associate, or any other lawyer affiliated with the lawyer or the lawyer's firm, an unsolicited electronic mail communication
Malamud Informational [Page 2] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 2] RFC 4096 Policy Labeling Ineffective May 2005
directly or indirectly to a prospective client for the purpose of
obtaining professional employment unless ... the subject line of
the communication states 'legal advertisement.'" [Florida]
directly or indirectly to a prospective client for the purpose of obtaining professional employment unless ... the subject line of the communication states 'legal advertisement.'" [Florida]
A subject line that complies with the above requirements might read as follows:
A subject line that complies with the above requirements might read as follows:
Subject: ADV: @ (Advertisement) legal advertisement
Subject: ADV: @ (Advertisement) legal advertisement
A more comprehensive survey of applicable laws would, no doubt, lengthen the above example considerably.
A more comprehensive survey of applicable laws would, no doubt, lengthen the above example considerably.
1.1. Terminology
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].
2. Subject Line Encoding
2. Subject Line Encoding
The basic definition of the "Subject:" of an electronic mail message is contained in [RFC2822]. The normative requirements that apply to all headers are:
The basic definition of the "Subject:" of an electronic mail message is contained in [RFC2822]. The normative requirements that apply to all headers are:
o The maximum length of the header field is 998 characters.
o The maximum length of the header field is 998 characters.
o Each line must be no longer than 78 characters.
o Each line must be no longer than 78 characters.
A multi-line subject field is indicated by the presence of a carriage return and white space, as follows:
A multi-line subject field is indicated by the presence of a carriage return and white space, as follows:
Subject: This
is a test
Subject: This is a test
On the subject of the three unstructured fields ( "Subject:", "Comments:", and "Keywords:"), the standard indicates that these are "intended to have only human-readable content with information about the message." In addition, on the specific subject of the "Subject:" field, the standard states:
On the subject of the three unstructured fields ( "Subject:", "Comments:", and "Keywords:"), the standard indicates that these are "intended to have only human-readable content with information about the message." In addition, on the specific subject of the "Subject:" field, the standard states:
The "Subject:" field is the most common and contains a short
string identifying the topic of the message. When used in a
reply, the field body MAY start with the string "Re: " (from the
Latin "res", in the matter of) followed by the contents of the
"Subject:" field body of the original message. If this is done,
only one instance of the literal string "Re: " ought to be used
since use of other strings or more than one instance can lead to
undesirable consequences.
The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message. If this is done, only one instance of the literal string "Re: " ought to be used since use of other strings or more than one instance can lead to undesirable consequences.
Malamud Informational [Page 3] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 3] RFC 4096 Policy Labeling Ineffective May 2005
Further guidance on the structure of the "Subject:" field is contained in [RFC2047], which species the mechanisms for character set encoding in mail headers. [RFC2978] specifies a mechanism for registering different character sets with the [IANA].
Further guidance on the structure of the "Subject:" field is contained in [RFC2047], which species the mechanisms for character set encoding in mail headers. [RFC2978] specifies a mechanism for registering different character sets with the [IANA].
In addition to choosing a character set, [RFC2047] uses two algorithms, known as "Base64 Encoding" and "Quoted Printable", which are two different methods for encoding characters that fall outside the basic 7-bit ASCII requirements that are specified in the core electronic mail standards.
In addition to choosing a character set, [RFC2047] uses two algorithms, known as "Base64 Encoding" and "Quoted Printable", which are two different methods for encoding characters that fall outside the basic 7-bit ASCII requirements that are specified in the core electronic mail standards.
Thus, an encoded piece of text consists of the following components:
Thus, an encoded piece of text consists of the following components:
o The string "=?", which signifies the beginning of encoded text.
o The string "=?", which signifies the beginning of encoded text.
o A valid character set indicator.
o A valid character set indicator.
o The string "?", which is a delimiter.
o The string "?", which is a delimiter.
o The string "b" if "Base64 Encoding" is used or the string "q" if
"Quoted Printable" encoding is used.
o The string "b" if "Base64 Encoding" is used or the string "q" if "Quoted Printable" encoding is used.
o The string "?", which is a delimiter.
o The string "?", which is a delimiter.
o The text, which has been properly encoded.
o The text, which has been properly encoded.
o The string "?=", which signifies the ending of the encoded text.
o The string "?=", which signifies the ending of the encoded text.
A simple example would be to use the popular [8859-1] character set, which has accents and other characters not found in the ASCII character set:
A simple example would be to use the popular [8859-1] character set, which has accents and other characters not found in the ASCII character set:
o "Subject: This is an ADV:" is an unencoded header.
o "Subject: This is an ADV:" is an unencoded header.
o "Subject: =?iso-8859-1?b?VGhpcyBpcyBhbiBBRFY6?=" is encoded using
Base64.
o "Subject: =?iso-8859-1?b?VGhpcyBpcyBhbiBBRFY6?=" is encoded using Base64.
o "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using
Quoted Printable.
o "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using Quoted Printable.
o "Subject: =?iso-8859-1?q?This=20is=20an=20=41=44=56=3A?=" is also
encoded using Quoted Printable, but instead the last four
characters are encoded with their hexadecimal representations.
o "Subject: =?iso-8859-1?q?This=20is=20an=20=41=44=56=3A?=" is also encoded using Quoted Printable, but instead the last four characters are encoded with their hexadecimal representations.
Note that both character set and encoding indicators are case insensitive. Additional complexity can be introduced by appending a language specification to the character set indication, as specified in [RFC2231] and [RFC3066]. This language specification consists of
Note that both character set and encoding indicators are case insensitive. Additional complexity can be introduced by appending a language specification to the character set indication, as specified in [RFC2231] and [RFC3066]. This language specification consists of
Malamud Informational [Page 4] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 4] RFC 4096 Policy Labeling Ineffective May 2005
the string "*", followed by a valid language indicator. For example, "US-ASCII*EN" indicates the "US-ASCII" character set and the English language.
the string "*", followed by a valid language indicator. For example, "US-ASCII*EN" indicates the "US-ASCII" character set and the English language.
When a message is read, the "Subject:" field is decoded, with appropriate characters from the character set displayed to the user. Section 7 (Conformance) of [RFC2047] specifies that a conforming mail reading program must perform the following tasks:
When a message is read, the "Subject:" field is decoded, with appropriate characters from the character set displayed to the user. Section 7 (Conformance) of [RFC2047] specifies that a conforming mail reading program must perform the following tasks:
"The program must be able to display the unencoded text if the
character set is "US-ASCII". For the ISO-8859-* character sets,
the mail reading program must at least be able to display the
characters which are also in the ASCII set."
"The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the ASCII set."
However, there is no requirement for every system to have every character set. Mail readers that are unable to display a particular set of characters resort to a variety of strategies, including silently ignoring the unknown text, or generating an error or warning message.
However, there is no requirement for every system to have every character set. Mail readers that are unable to display a particular set of characters resort to a variety of strategies, including silently ignoring the unknown text, or generating an error or warning message.
Two characteristics of many common Message User Agents (MUAs) (e.g., mail readers) are worth noting:
Two characteristics of many common Message User Agents (MUAs) (e.g., mail readers) are worth noting:
o Although the subject line is, in theory, of unlimited length, many
mail readers only show the reader the first few dozen characters.
o Although the subject line is, in theory, of unlimited length, many mail readers only show the reader the first few dozen characters.
o Electronic mail is often transmitted through gateways, reaching
pagers or cell phones with SMS capability. Those systems
typically require short subject lines.
o Electronic mail is often transmitted through gateways, reaching pagers or cell phones with SMS capability. Those systems typically require short subject lines.
3. Implementing a Labeling Requirement
3. Implementing a Labeling Requirement
In this section, we posit a hypothetical situation with two key players:
In this section, we posit a hypothetical situation with two key players:
o John Doe [Doe] is an attorney at the firm of Dewey, Cheatem &
Howe, LLC [Stooges].
o John Doe [Doe] is an attorney at the firm of Dewey, Cheatem & Howe, LLC [Stooges].
o The Federal Trust Commission (FTC) has been entrusted with
implementing a recent labeling requirement, promulgated by the
Sovereign Government of Freedonia [Duck]. Specifically, President
Firefly directed the FTC to "make sure that anybody spamming folks
get the symbol 'spam:' in the subject line and or shoot them, if
you can find them."
o The Federal Trust Commission (FTC) has been entrusted with implementing a recent labeling requirement, promulgated by the Sovereign Government of Freedonia [Duck]. Specifically, President Firefly directed the FTC to "make sure that anybody spamming folks get the symbol 'spam:' in the subject line and or shoot them, if you can find them."
Based on this directive, the FTC promulgated a very simple regulation which read: "Please obey the law." John Doe, being a lawyer, read the law, and promptly proceeded to spam everybody using a fairly
Based on this directive, the FTC promulgated a very simple regulation which read: "Please obey the law." John Doe, being a lawyer, read the law, and promptly proceeded to spam everybody using a fairly
Malamud Informational [Page 5] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 5] RFC 4096 Policy Labeling Ineffective May 2005
obvious loophole: he made sure his subject line was really long, and he shoved all the stuff like "spam:" and the "@" symbol and other verbiage near the end of the 998 allowed characters. He was complying with the law, but of course, nobody saw the labels in their reader.
obvious loophole: he made sure his subject line was really long, and he shoved all the stuff like "spam:" and the "@" symbol and other verbiage near the end of the 998 allowed characters. He was complying with the law, but of course, nobody saw the labels in their reader.
Based on a periodic review, the FTC decided to be more specific, and re-promulgated their regulation as follows: "If you send spam, put 'spam:' at the _beginning_ of the subject line." The Freedonian FTC promptly received a visit from the Sylvanian Ambassador, who complained that this conflicted with his country's requirements under the Marx Doctrine to place the string "WATCH OUT! THE CONTENTS OF THIS MESSAGE ARE SUSPECT!" at the beginning of the subject line.
Based on a periodic review, the FTC decided to be more specific, and re-promulgated their regulation as follows: "If you send spam, put 'spam:' at the _beginning_ of the subject line." The Freedonian FTC promptly received a visit from the Sylvanian Ambassador, who complained that this conflicted with his country's requirements under the Marx Doctrine to place the string "WATCH OUT! THE CONTENTS OF THIS MESSAGE ARE SUSPECT!" at the beginning of the subject line.
The re-promulgation of the regulation was rescinded, more experts were called in, and a new regulation was issued: "Put it as close to the beginning of the subject line as you can, modulo any requirements by other governments." John Doe looked at this, scratched his head, and applied a clever little hack, picking the ISO [8859-8] character set for Hebrew, and duly spelling out the letters ":" Mem Alef Pe Samech.
The re-promulgation of the regulation was rescinded, more experts were called in, and a new regulation was issued: "Put it as close to the beginning of the subject line as you can, modulo any requirements by other governments." John Doe looked at this, scratched his head, and applied a clever little hack, picking the ISO [8859-8] character set for Hebrew, and duly spelling out the letters ":" Mem Alef Pe Samech.
Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?=
Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?=
Some receivers of this message get an error message because they don't have Hebrew installed on their systems. Others get some cryptic indicator of a missing character set, such as "[?iso-8859-8?]".
Some receivers of this message get an error message because they don't have Hebrew installed on their systems. Others get some cryptic indicator of a missing character set, such as "[?iso-8859-8?]".
The FTC called a summit of leading thinkers, and the regulation was amended to read "but don't use languages that go from right to left or up and down instead of plain old left to right." Needless to say, the reaction from the Freedonian League for the Defense of Linguistic Diversity killed that proposed regulation really quickly.
The FTC called a summit of leading thinkers, and the regulation was amended to read "but don't use languages that go from right to left or up and down instead of plain old left to right." Needless to say, the reaction from the Freedonian League for the Defense of Linguistic Diversity killed that proposed regulation really quickly.
The commission continued the cycle of re-promulgation and refinement, but ultimately, the regulations continued to contain either a loophole, objectionable requirements, or violations of the relevant RFCs.
The commission continued the cycle of re-promulgation and refinement, but ultimately, the regulations continued to contain either a loophole, objectionable requirements, or violations of the relevant RFCs.
4. Subjects are For Humans, Not Labels
4. Subjects are For Humans, Not Labels
The use of an unknown character set, or of a very, very long subject line are just two examples of how people can try to get around labeling requirements. In order to specify a regulation without ambiguity, it would need to be extremely complex in order to avoid loopholes such as these.
The use of an unknown character set, or of a very, very long subject line are just two examples of how people can try to get around labeling requirements. In order to specify a regulation without ambiguity, it would need to be extremely complex in order to avoid loopholes such as these.
Malamud Informational [Page 6] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 6] RFC 4096 Policy Labeling Ineffective May 2005
Drafting of regulations is one issue, but there is another. Subject lines are used to specify, as [RFC2822] says, a "short string identifying the topic of the message."
Drafting of regulations is one issue, but there is another. Subject lines are used to specify, as [RFC2822] says, a "short string identifying the topic of the message."
Any regulation has to compete with the other words in the subject, and this mixing of purposes makes it very difficult for a machine to filter out messages at the direction of the user. For example, if one looks for the "@" symbol, per the Korean law, checks have to be made that this symbol is not a legitimate part of a legitimate message.
Any regulation has to compete with the other words in the subject, and this mixing of purposes makes it very difficult for a machine to filter out messages at the direction of the user. For example, if one looks for the "@" symbol, per the Korean law, checks have to be made that this symbol is not a legitimate part of a legitimate message.
Not only do multiple labeling requirements compete with legitimate subject lines, but also there is no easy way for the sender of a legitimate message to effectively insert other labels that indicate to the recipient that-- although the message may have a required label-- it is actually a message the user might want to see, based on, for example, a prior relationship.
Not only do multiple labeling requirements compete with legitimate subject lines, but also there is no easy way for the sender of a legitimate message to effectively insert other labels that indicate to the recipient that-- although the message may have a required label-- it is actually a message the user might want to see, based on, for example, a prior relationship.
Even if one considers only the sender of the message, it is very difficult to specify a loophole-free way of putting a specific label in a specific place. And, even if we could control what the sender does, it is an unfortunate fact of life that other agents may also alter the subject line. For example, mailing list management software and even personal email filtering systems will often "munge" the subject line to add information such as the name of a mailing list, or the fact that a message comes from a certain group of people. Such transformations have long been generally accepted as being potentially harmful [RFC0886], and are the subject of continued discussions, which are outside the scope of the present document (see [Koch] and [RFC3834]).
Even if one considers only the sender of the message, it is very difficult to specify a loophole-free way of putting a specific label in a specific place. And, even if we could control what the sender does, it is an unfortunate fact of life that other agents may also alter the subject line. For example, mailing list management software and even personal email filtering systems will often "munge" the subject line to add information such as the name of a mailing list, or the fact that a message comes from a certain group of people. Such transformations have long been generally accepted as being potentially harmful [RFC0886], and are the subject of continued discussions, which are outside the scope of the present document (see [Koch] and [RFC3834]).
The "Subject:" field is currently overloaded; it has become a handy place for a variety of agents to attempt to insert information. Because of that overloading, it is a poor location for specifying mandatory use of a label, because it is unlikely that label will "rise to the top" and become apparent to the reader of a message or even to the mail-filtering software that examines the mail before the user. The difficulty of implementing subject line labeling, without taking additional steps, has been noted by several other commentators, including [Moore-1], [Lessig], and [Levine]. Indeed, the problem is a general one. Keith Moore has pointed out seven good reasons why tags of any sort in the "Subject:" field have potential problems:
The "Subject:" field is currently overloaded; it has become a handy place for a variety of agents to attempt to insert information. Because of that overloading, it is a poor location for specifying mandatory use of a label, because it is unlikely that label will "rise to the top" and become apparent to the reader of a message or even to the mail-filtering software that examines the mail before the user. The difficulty of implementing subject line labeling, without taking additional steps, has been noted by several other commentators, including [Moore-1], [Lessig], and [Levine]. Indeed, the problem is a general one. Keith Moore has pointed out seven good reasons why tags of any sort in the "Subject:" field have potential problems:
1. The "Subject:" field space is not strictly limited and long
fields can be folded.
1. The "Subject:" field space is not strictly limited and long fields can be folded.
Malamud Informational [Page 7] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 7] RFC 4096 Policy Labeling Ineffective May 2005
2. PDAs, phones, and other devices and software have only a limited
space to display the "Subject:" field.
2. PDAs, phones, and other devices and software have only a limited space to display the "Subject:" field.
3. A variety of different kinds of labels such as "ADV:" and
"[Mailing List Name]" compete for scarce display space.
3. A variety of different kinds of labels such as "ADV:" and "[Mailing List Name]" compete for scarce display space.
4. There are conflicting legal requirements from different
jurisdictions.
4. There are conflicting legal requirements from different jurisdictions.
5. There is a conflict between human use of the "Subject:" field and
use of that field for filtering and filing:
5. There is a conflict between human use of the "Subject:" field and use of that field for filtering and filing:
* Machine-readable tokens interfere with human readability.
* Machine-readable tokens interfere with human readability.
* Representation of human-readable text was not designed with
machine interpretation in mind and, thus, does not have a
canonical form.
* Representation of human-readable text was not designed with machine interpretation in mind and, thus, does not have a canonical form.
6. Lack of support in a few existing mail readers for displaying
information from elsewhere in the message header (e.g., from
newly-defined fields), along with familiarity, motivates
additional uses of the "Subject:", further compounding the
problem.
6. Lack of support in a few existing mail readers for displaying information from elsewhere in the message header (e.g., from newly-defined fields), along with familiarity, motivates additional uses of the "Subject:", further compounding the problem.
7. Any text-based tags added or imposed by outside parties (i.e.,
those that are not the sender or recipient of the message) will
not be reliably meaningful in the recipient's language.
7. Any text-based tags added or imposed by outside parties (i.e., those that are not the sender or recipient of the message) will not be reliably meaningful in the recipient's language.
Source: [Moore-2].
Source: [Moore-2].
5. Solicitation Class Keywords
5. Solicitation Class Keywords
[RFC3865] defines the "solicitation class keyword", an arbitrary label that can be associated with an electronic mail message and transported by the ESMTP mail service, as defined in [RFC2821] and related documents. Solicitation class keywords are formatted like domain names, but reversed. For example, the registrant of "example.com" might specify a particular solicitation class keyword such as "com.example.adv" that could be inserted in a "No-Solicit:" header or in a trace field. Anybody with a domain name can specify a solicitation class keyword, and anybody sending a message can use any solicitation class keyword that has been defined by themselves or by others.
[RFC3865] defines the "solicitation class keyword", an arbitrary label that can be associated with an electronic mail message and transported by the ESMTP mail service, as defined in [RFC2821] and related documents. Solicitation class keywords are formatted like domain names, but reversed. For example, the registrant of "example.com" might specify a particular solicitation class keyword such as "com.example.adv" that could be inserted in a "No-Solicit:" header or in a trace field. Anybody with a domain name can specify a solicitation class keyword, and anybody sending a message can use any solicitation class keyword that has been defined by themselves or by others.
Malamud Informational [Page 8] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 8] RFC 4096 Policy Labeling Ineffective May 2005
This memo argues that the "No-Solicit:" approach is either a superior alternative or a necessary complement to "Subject:" field labeling requirements because:
This memo argues that the "No-Solicit:" approach is either a superior alternative or a necessary complement to "Subject:" field labeling requirements because:
o One can specify very precisely what a label should be and where it
should go using the "No-Solicit:" header, which is designed
specifically for this purpose.
o One can specify very precisely what a label should be and where it should go using the "No-Solicit:" header, which is designed specifically for this purpose.
o The sender of a message can add additional solicitation class
keywords to help distinguish the message. For example, if the
"Freedonian Direct Marketing Council" wished to form a voluntary
consortium of direct marketers who subscribe to certain practices,
they could specify a keyword (e.g.,
"org.example.freedonia.good.spam") and educate the public to set
their filters to receive these types of messages.
o The sender of a message can add additional solicitation class keywords to help distinguish the message. For example, if the "Freedonian Direct Marketing Council" wished to form a voluntary consortium of direct marketers who subscribe to certain practices, they could specify a keyword (e.g., "org.example.freedonia.good.spam") and educate the public to set their filters to receive these types of messages.
o Message Transfer Agents (MTAs) may insert solicitation class
keywords in the "received:" trace fields, thus providing
additional tools for recipients to use for filtering messages.
o Message Transfer Agents (MTAs) may insert solicitation class keywords in the "received:" trace fields, thus providing additional tools for recipients to use for filtering messages.
o A recipient can also define a solicitation class keyword, a tool
that allows them to give friends and correspondents a "pass key"
so the recipient's mail filtering software always passes through
messages containing that keyword.
o A recipient can also define a solicitation class keyword, a tool that allows them to give friends and correspondents a "pass key" so the recipient's mail filtering software always passes through messages containing that keyword.
As can be seen, the solicitation class keyword approach is flexible enough to serve as a tool for government-mandated labeling and for other purposes as well.
As can be seen, the solicitation class keyword approach is flexible enough to serve as a tool for government-mandated labeling and for other purposes as well.
Most modern email software gives users a variety of filtering tools. For example, the popular Eudora program allows a user to specify the name of a message header, the desired match (e.g., a wild card or regular expression, or simply a phrase to match), and an action to take (e.g., moving the message to a particular folder, sounding an alarm, or even automatically deleting messages with harmful content such as viruses). There is one popular email reader that only allows filtering on selected fields, such as "To:", "From:", or "Subject:", but that program is the exception to the rule.
Most modern email software gives users a variety of filtering tools. For example, the popular Eudora program allows a user to specify the name of a message header, the desired match (e.g., a wild card or regular expression, or simply a phrase to match), and an action to take (e.g., moving the message to a particular folder, sounding an alarm, or even automatically deleting messages with harmful content such as viruses). There is one popular email reader that only allows filtering on selected fields, such as "To:", "From:", or "Subject:", but that program is the exception to the rule.
In summary, for senders and receivers of email, use of the "No-Solicit:" mechanism would be simple to understand and use. For policy makers, it would be extremely simple to specify the format and placement of the solicitation class keyword. Needless to say, the issue of how to define what classes of messages are subject to such a requirement, and how to enforce it, are beyond the scope of this discussion.
In summary, for senders and receivers of email, use of the "No-Solicit:" mechanism would be simple to understand and use. For policy makers, it would be extremely simple to specify the format and placement of the solicitation class keyword. Needless to say, the issue of how to define what classes of messages are subject to such a requirement, and how to enforce it, are beyond the scope of this discussion.
Malamud Informational [Page 9] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 9] RFC 4096 Policy Labeling Ineffective May 2005
6. Security Considerations
6. Security Considerations
The use of labels in the "Subject:" field gives users and policy makers an unwarranted illusion that certain classes of messages will be "flagged" correctly by the MUA of the recipient. The difficulty in specifying requirements for labels in the "Subject:" field in a precise, unambiguous manner makes it difficult for the MUA to systematically identify messages that are labeled; this leads to both false positive and false negative indications.
The use of labels in the "Subject:" field gives users and policy makers an unwarranted illusion that certain classes of messages will be "flagged" correctly by the MUA of the recipient. The difficulty in specifying requirements for labels in the "Subject:" field in a precise, unambiguous manner makes it difficult for the MUA to systematically identify messages that are labeled; this leads to both false positive and false negative indications.
In addition, conflicting labeling requirements by policy makers, as well as other current practices that use the "Subject:" for a variety of purposes, make that field "overloaded." In order to meet these conflicting requirements, software designers and bulk mail senders resort to a variety of tactics, some of which may violate fundamental requirements of the mail standards, such as the practice of an intermediate MTA inserting various labels into the "Subject:" field. Such practices increase the likelihood of non-compliant mail messages and, thus, threaten interoperability between implementations.
In addition, conflicting labeling requirements by policy makers, as well as other current practices that use the "Subject:" for a variety of purposes, make that field "overloaded." In order to meet these conflicting requirements, software designers and bulk mail senders resort to a variety of tactics, some of which may violate fundamental requirements of the mail standards, such as the practice of an intermediate MTA inserting various labels into the "Subject:" field. Such practices increase the likelihood of non-compliant mail messages and, thus, threaten interoperability between implementations.
7. Recommendations
7. Recommendations
This document makes three recommendations:
This document makes three recommendations:
1. There is widespread skepticism in the technical community that
labels of any sort will be effective. Such labels should
probably be avoided as ineffective at best.
1. There is widespread skepticism in the technical community that labels of any sort will be effective. Such labels should probably be avoided as ineffective at best.
2. Despite the widespread skepticism expressed in point 1, over 36
states in the U.S. and 27 countries have passed anti-spam
measures, many of which require labels [Sorkin]. If such labels
are to be used, despite the widespread skepticism expressed in
point 1, there is a fairly broad consensus in the technical
community that such labels should not be put in the "Subject:"
field and should go in a designated header field.
2. Despite the widespread skepticism expressed in point 1, over 36 states in the U.S. and 27 countries have passed anti-spam measures, many of which require labels [Sorkin]. If such labels are to be used, despite the widespread skepticism expressed in point 1, there is a fairly broad consensus in the technical community that such labels should not be put in the "Subject:" field and should go in a designated header field.
3. If, despite points 1 and 2, a policy of mandating labels in the
"Subject:" field is adopted, a complementary requirement to use
the "No-Solicit:" should also be added.
3. If, despite points 1 and 2, a policy of mandating labels in the "Subject:" field is adopted, a complementary requirement to use the "No-Solicit:" should also be added.
8. Acknowledgements
8. Acknowledgements
The author would like to thank the following for their helpful suggestions and reviews of this document: Joe Abley, Harald Alvestrand, Elwyn Davies, Alain Durand, Frank Ellermann, Ted Hardie, Tony Hansen, Scott Hollenbeck, Peter Koch, Bruce Lilly, Keith Moore, Pekka Savola, and Mark Townsley.
The author would like to thank the following for their helpful suggestions and reviews of this document: Joe Abley, Harald Alvestrand, Elwyn Davies, Alain Durand, Frank Ellermann, Ted Hardie, Tony Hansen, Scott Hollenbeck, Peter Koch, Bruce Lilly, Keith Moore, Pekka Savola, and Mark Townsley.
Malamud Informational [Page 10] RFC 4096 Policy Labeling Ineffective May 2005
Malamud Informational [Page 10] RFC 4096 Policy Labeling Ineffective May 2005
9. References
9. References
9.1. Normative References
9.1. Normative References
[IANA] IANA, "Registry of Official Names for Character Sets That
May Be Used on the Internet", February 2004,
<http://www.iana.org/assignments/character-sets>.
[IANA]IANA、「インターネットで使用されるかもしれない文字コードのための正式名称の登録」、2004年2月、<http://www.iana.org/課題/文字の組>。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
解放された[RFC2231]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[RFC2978]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer
Protocol (SMTP) Service Extension", RFC 3865,
September 2004.
[RFC3865]マラマッド、C.、「請求していないシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3865、2004年9月。
9.2. Informative References
9.2. 有益な参照
[8859-1] International Organization for Standardization,
"Information technology - 8-bit single byte coded graphic
- character sets - Part 1: Latin alphabet No. 1, JTC1/
SC2", ISO Standard 8859-1, 1987.
[8859-1] 国際標準化機構、「情報技術--8ビットの単一のバイトはグラフィック--文字の組--第1部をコード化しました:、」 ローマ字No.1、JTC1/ SC2"、ISO Standard8859-1、1987。
[8859-8] International Organization for Standardization,
"Information Processing - 8-bit Single-Byte Coded Graphic
Character Sets, Part 8: Latin/Hebrew alphabet",
ISO Standard 8859-8, 1988.
[8859-8] 国際標準化機構、「単一のバイトのコード化された図形文字が設定する8情報処理--ビットは8を分けます」。 「ラテン語の、または、ヘブライのアルファベット」、ISO Standard8859-8、1988。
Malamud Informational [Page 11] RFC 4096 Policy Labeling Ineffective May 2005
効果がない2005年5月をラベルするマラマッド情報[11ページ]のRFC4096Policy
[Colorado] Sixty-Second General Assembly of the State of Colorado,
"Colorado Junk Email Law", House Bill 1309, June 2000,
<http://www.spamlaws.com/state/co.html>.
コロラド州の[コロラド]の第62国会、「コロラドくずのメール法」、下院のビル1309、2000年6月、<http://www.spamlaws.com/状態/co.html>。
[Doe] Frank Capra (Director), "Meet John Doe", IMDB Movie
No. 0033891, 1941, <http://us.imdb.com/title/tt0033891/>.
[ドウ]フランク・キャプラ(ディレクター)、「群衆。」IMDB映画No.0033891、1941、<http://us.imdb.com/title/tt0033891/>。
[Duck] The Mark Brothers, "Duck Soup", IMDB Movie No. 0023969,
1933, <http://us.imdb.com/title/tt0023969/>.
[すくめます] マーク兄弟、「我輩はカモである」、IMDB映画No.0023969、1933、<http://us.imdb.com/title/tt0023969/>。
[Florida] The Florida Bar, "Rules of Professional Conduct", 2005,
<http://www.flabar.org/divexe/rrtfb.nsf/
WContents?OpenView&Start=1&Count=30&Expand=4.8#4.8>.
[フロリダ]フロリダバー、「職業倫理」、2005、<http://www.flabar.org/divexe/rrtfb.nsf/WContents--OpenViewと始めは、1とカウント=30と等しく、=4.8#4.8>を広くします。
[KISA] Korea Information Security Agency, "Korea Spam Response
Center -- Legislation for Anti-Spam Regulations: Mandatory
Indication of Advertisement", 2003,
<http://www.spamcop.or.kr/eng/m_2.html>.
[吉舎]韓国情報警備機関、「韓国のスパム応答センター--、反スパム規則のための法律:、」 「広告の義務的なしるし」、2003、<http://www.spamcop.or.kr/eng/m_2.html>。
[Koch] Koch, P., "Subject: [tags] Considered Harmful", Work in
Progress, November 2004.
[コッホ]コッホ、P.、「Subject:」 「有害であると考えられた[タグ]」は進歩、2004年11月に働いています。
[Korea] National Assembly of the Republic of Korea, "Act on
Promotion of Information and Communication and
Communications Network Utilization and Information
Protection of 2001", 2001, <http://www.mic.go.kr/eng/res/
res_pub_db/res_pub_mic_wp/2003/whitepaper2003/in3_7.htm>.
[韓国]大韓民国国民議会、「2001年の情報とコミュニケーションの販売促進、通信網利用、および情報保護での条例」、2001、<http://www.mic.go.kr/eng/res/res_パブ_db/res_パブ_mic_wp/2003/whitepaper2003/in3_7.htm>。
[Lessig] Lessig, L., "How to unspam the Internet", The
Philadelphia Inquirer, May 2003, <http://www.philly.com/
mld/inquirer/news/editorial/5778539.htm?1c>.
[Lessig]Lessig、L.、「どうインターネットを「非-ばらま」く」、フィラデルフィア・インクワイアラー、2003年5月、<は://www.philly.com/mld/尋問者/ニュース/社説/5778539.htmをhttpします--1c>。
[Levine] Levine, J., "Comments In the Matter of: REPORT TO CONGRESS
PURSUANT TO CAN-SPAM ACT", Federal Trade Commission,
Matter No. PO44405, February 2004, <http://www.ftc.gov/
reports/dneregistry/xscripts/dne040226pm.pdf>.
[レヴィン]レヴィン(J.)は「以下のIn Matterについて論評します」。 「缶スパム条例に従った議会へのレポート」、連邦取引委員会、件のNo. PO44405、2004年2月、<http://www.ftc.gov/レポート/dneregistry/xscripts/dne040226pm.pdf>。
[Moore-1] Moore, K., "Individual Comment of Mr. Keith Moore Re:
Label for E-mail Messages", Federal Trade Commission of
the U.S., NPRM Comment RIN 3084-AA96, February 2004, <http
://www.ftc.gov/os/comments/adultemaillabeling/
040216moore.pdf>.
[ムーア-1] ムーア、K.、「キースムーアRe:さんの個々のコメント」 「メールメッセージのためのラベル」、米国連邦取引委員会、NPRMコメントRIN 3084-AA96、2004年2月、<http://www.ftc.gov/OS/コメント/adultemaillabeling/040216moore.pdf>。
[Moore-2] Moore, K., "E-mail Message to the Author and the IESG",
March 2005.
[ムーア-2] ムーア、K.、「作者とIESGへのメールメッセージ」、2005年3月。
Malamud Informational [Page 12] RFC 4096 Policy Labeling Ineffective May 2005
効果がない2005年5月をラベルするマラマッド情報[12ページ]のRFC4096Policy
[RFC0886] Rose, M., "Proposed standard for message header munging",
RFC 886, December 1983.
[RFC0886] ローズ、M.、「メッセージヘッダーの変更を加えることの提案された標準」、RFC886、1983年12月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to
Electronic Mail", RFC 3834, August 2004.
[RFC3834] ムーア、K.、「電子メールへの自動応答のための推薦」、RFC3834、2004年8月。
[Sorkin] Sorkin, D., "http://www.spamlaws.com/", 2005,
<http://www.spamlaws.com/>.
[ソーキン]ソーキン、D.、" http://www.spamlaws.com/ "、2005、<http://www.spamlaws.com/>。
[Stooges] The Three Stooges, "Heavenly Daze", IMDB Movie
No. 0040429, 1948, <http://us.imdb.com/title/tt0040429/>.
[引き立て役を務めます] スリー・ストゥージズ、「天のぼうっとした状態。」IMDB映画No.0040429、1948、<http://us.imdb.com/title/tt0040429/>。
[US] United States Congress, "The Controlling the Assault of
Non-Solicited Pornography and Marketing Act of 2003 (CAN-
SPAM Act of 2003)", Public Law 108-187, 117 STAT. 2699, 15
USC 7701, December 2003, <http://frwebgate.access.gpo.gov/
cgi-bin/getdoc.cgi?dbname=108_cong_public_laws
&docid=f:publ187.108.pdf>.
[米国]合衆国議会、「2003年(2003年の缶のスパム条例)のスパム規制法」、公法108-187(117スタット)。 2699、15USC7701、2003年12月、<http://frwebgate.access. gpo.gov/cgi-bin/getdoc.cgi--dbname=108_cong_公共の_法とdocid=f: publ187.108.pdf>。
Author's Address
作者のアドレス
Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US
カールマラマッドメモリ宮殿プレスの私書箱300 6、または97476米国
EMail: carl@media.org
メール: carl@media.org
Malamud Informational [Page 13] RFC 4096 Policy Labeling Ineffective May 2005
効果がない2005年5月をラベルするマラマッド情報[13ページ]のRFC4096Policy
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Malamud Informational [Page 14]
マラマッドInformationalです。[14ページ]
一覧
スポンサーリンク
