Closed
Bug 222189
Opened 21 years ago
Closed 21 years ago
Add support for RFC 2505
Categories
(MailNews Core :: Filters, enhancement)
Tracking
(Not tracked)
VERIFIED
WONTFIX
People
(Reporter: JWZylstra, Assigned: sspitzer)
References
()
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: n/a I continue to be surprised by the many ineffective ways that people suggest dealing with the spam problem. From the exaggerated (considering every single message whose subject begins with "ADV" to be spam) to the unenforceable (making it illegal for anyone to send spam, even those beyond our borders) to the calamitous (accepting only mail from known senders), none demonstrate a sufficient understanding of the nature of spam, and the system that enables it. The real problem isn't that people are sending spam; this is America, after all, where our freedom of speech is Constitutionally protected. The problem is that we can't easily identify it when we get it. And since spam is so much cheaper to send than other forms of speech, and so much more disruptive than most other cheap alternatives, we're quickly overwhelmed. Once we can reliably identify spam, then a variety of options that have been suggested can be employed to deal with it. Instead, we should fight it by using the built-in capabilities of the very system that enables it. Specifically, we should require that spam be identified by a new SMTP header describing each message's intent. Whether that header is required by federal law or by ISPs' user agreements pushed down from the top (UUNet, Above.net), every mail message containing commercial solicitations would have to be identified by a code describing the message's content. In fact, IANA (http://www.iana.org) could establish codes for all types of E-mail content: personal, political, infrastructure (ISP announcements, CERT advisories), mailing lists where recipient is a member, non- profit solicitations, for-profit solicitations, requested solicitations, solicitations where sender has previous business with recipient, etc. By forcing spam to be identified at the header level, and not within the body (whether explicitly according to a silly ADV subject prefix or deductively by analyzing the body), spam can be programmatically denied before it's even transferred, significantly reducing its impact on the recipients' resources. This technique is further described in IETF RFC 2505 (http://www.ietf.org/rfc/rfc2505.txt). Best of all, such a solution wouldn't break the current implementations of SMTP because it complies with RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt). As it is, existing mail transfer agents will just forward along any mail that they should, new headers and all. Over time, these transfer agents can be upgraded to include filters that can thwart spam further upstream (provided that RFC 2821, section 3.7 is amended to allow this). But for now, the focus will be on adding filters to the user agents (Microsoft Outlook, AOL, etc.) to allow users to each deal with spam as they see fit. Some may wish to discard all spam, some may want to receive certain spam, and some won't care. But all will be empowered to better deal with spam, as well as all other E-mail, as they see fit. There are no first amendment arguments against such an approach because spammers are still free to do what they will; we will just be better equipped to ignore them. JayZ Reproducible: Always Steps to Reproduce:
Comment 1•21 years ago
|
||
Reporter: Please add a SHORT summary what do you think that Mozilla should do ? (What you currently can't do) Why do you write 30 lines about why SPAM is a problem ? That doesn't belongs in a bug report (and SPAM is a known problem). And why do you think that SPAM is only a problem in the USA ?
Updated•21 years ago
|
Summary: The right way to fight spam - using SMTP headers → Add support for RFC 2505
Comment 2•21 years ago
|
||
I read through it but can't see what impact RFC 2505 would have on Mozilla. We have a MUA, not an MTA. Please specify what you want us do to.
Reporter | ||
Comment 3•21 years ago
|
||
I mentioned RFC 2505 to provide background to my proposal, although its purpose is to describe a way to move spam filtering upstream from the user agent, and so obviously doesn't have direct relevance to Mozilla. However, it, like all other current solutions, relies on deductive logic to analyze and identify spam by its content, from address, and other typical approaches. This is prone to error, and is inefficient. In response, many states are mandating the the 'ADV' subject prefix for all spam, which is much easier to detect and filter, but is prone to false positives, and not granular enough to distinguish between the various types of spam (i.e. unsolicited commercial, solicited, non- profit, political) so different actions can be taken. When I have been proposing to IETF, IANA, ICRA, IAB, the Internet Society, and my congressmen is a new SMTP (and even HTTP) header to describe the intent of content, just as there already are headers to describe the MIME-type and encoding of content. The possible values for the header would be far more granular than the 'ADV' subject prefix, perhaps using a bitmask to specify the various aspects of mail. For example: Content-class Header Value Definiation ======== Bits 0 & 1: Solicitation 00 - Explicitly requested 01 - Explicit previous business 10 - Implicit request or previous business 11 - Unsolicited Bit 2: (reserved for future use) Bits 3 & 4: Sender Type 00 - Personal 01 - Business 10 - Political 11 - Charity / Non-profit Bit 5: (reserved for future use) Bit 6 - Profitability 0 - Not intended to solitic payment 1 - Intended to solicit payment Bit 7: (reserved for future use) Content-class Header Usage Examples ======== 00000000 - Reply from an acquaintance 00000001 - Announcement from an acquaintance 01000001 - Request for money from an acquaintance 01001000 - Announcement that you requested that a product is in stock for sale 01001001 - Announcement that a product is for sale from a previous supplier 01001010 - Announcement that a product is for sale from a site you once visited 01001011 - Announcement that a product is for sale from an unknown site 00010010 - Newsletter from your representative/senator 01011010 - Request for donation from charity to which a previous dontation was made Thus, I have submitted my proposal to Mozilla for use both in filters, and to add a dialog/drop-down/whatever to the compose mail window so senders can easily set the header for messages they send. JayZ
Comment 4•21 years ago
|
||
sending SPAM ist in illegal in many countries and other countries don't care. Why do you think that spammers would set such a header ? Such a header is useless and doesn't help with the SPAM problem. BTW: You can currently already filter on such a header and you can also send a special header with each mail. I vote for WONTFIX
Comment 5•21 years ago
|
||
no this will not be fixed
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•