Closed
Bug 222189
Opened 22 years ago
Closed 22 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•22 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•22 years ago
|
Summary: The right way to fight spam - using SMTP headers → Add support for RFC 2505
Comment 2•22 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•22 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•22 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•22 years ago
|
||
no this will not be fixed
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•