222189 - Add support for RFC 2505

Status: VERIFIED WONTFIX

Description

[Jay Zylstra]

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

[Matthias Versen [:Matti]]

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 ? 

Comment 2

[Christian Eyrich]

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.

Comment 3

[Jay Zylstra]

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

[Matthias Versen [:Matti]]

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

[Frank Wein [:mcsmurf]]

no this will not be fixed

Comment 6

[Mozilla_rocks]

verified