Closed Bug 263913 Opened 20 years ago Closed 20 years ago

New email already marked as read; SPAM vulnerability

Categories

(MailNews Core :: Filters, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 196749

People

(Reporter: jkenner, Assigned: sspitzer)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Freshly received email is marked as already received because of custom Mozilla
headers contained in the email.

This is an issue because it allows insertion of already-read email into the
inbox. This email can contain words that will contaminate the bayesian filtering
system, furthermore, since its already marked read, it is unlikely to be noticed
and marked as spam for quite some time. 

Subsequent SPAM emails, if they contain similar terms as the initial email, are
thus far more likely to be marked as actual messages than as spam. 

Reproducible: Always
Steps to Reproduce:
Note: examples have had some server identifying information stripped and
replaced with examples/fake IPs

1. Craft a message with forged Mozilla headers:

telnet mail.example.com 25  
Trying 10.10.10.10...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP
MAIL FROM: spammy-preloader@example.com
250 ok
RCPT TO: spam-target@example.com
250 ok
DATA
354 go ahead
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Identity-Key: id1
Date: Sun, 10 Oct 2004 09:16:39 -0300
From: Pre Digested Spam <spam-sender@example.com>
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
Gecko/20040803 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: spam-target@example.com
Subject: Some pre-read email

This is a test of the pre-read email system. This is only a test.

keyword1 keyword2 keyword3 keyword4 keyword5 keyword6 keyword7 keyword8

.   
250 ok 123456789 qp 12345
quit
221 mail.example.com
Connection closed by foreign host.

2. POP your email to retrieve the message. Notice that the newly downloaded
message is marked read, even tho you have never opened it. DO NOT YET OPEN IT.

3. Examine its source and notice the DUPLICATE entry for X-Mozila-Status lines:

From - Mon Oct 11 13:15:50 2004 
X-UIDL: 123456789.12345.mail
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
Return-Path: <spam-sender@example.com>
Delivered-To: spam-target@example.com
Received: (qmail 12345 invoked by uid 0); 11 Oct 2004 20:28:39 -0000
Received: from unknown (HELO mail.example.com) (10.10.10.10)
  by 0 with SMTP; 11 Oct 2004 20:28:39 -0000
Received: (qmail 23072 invoked from network); 11 Oct 2004 20:39:39 -0000
Received: from ip-10-10-10-10.example.com (10.10.10.10)
  by mail.example.com with SMTP; 11 Oct 2004 20:39:39 -0000
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000 
X-Identity-Key: id1
Date: Sun, 10 Oct 2004 09:16:39 -0300
From: Pre Digested Spam <spam-sender@example.com>
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0   
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To:
Subject: Some pre-read email

This is a test of the pre-read email system. This is only a test.

keyword1 keyword2 keyword3 keyword4 keyword5 keyword6 keyword7 keyword8

Actual Results:  
Mail shows up in inbox; the little green dot for "unread email" is never lit.

Expected Results:  
Mozilla should still be capable of marking this email as unread. Clearly, from
examining the headers, it does this. Unfortunately, the mail client itself is
reading and trusting the sender-provided X-Mozilla-Status line over the one
inserted by itself, thus the unread email is interpreted as having already been
read.

Because all of the instances of this I have discovered "in the wild" appear to
have been accidental, caused not by deliberate filter preloading but rather,
lazy spammers simply pasting headers from messages they have already read into
their email bombing programs, I have marked this as a minor bug.

The easy workaround is to keep your inbox empty, and work instead from a
temporary folder. With nothing in the inbox, improperly marked messages should
be easy to spot. Spotting spam and marking it as such is the key to preventing
future spam.

Should this technique catch on, or if similar vulnerabilities are found to exist
in other software packages as well, this bug should be upgraded to "normal"
status if not yet corrected.
Problem is fixed in 1.8a nightlies, and TB 0.8, but unfortunately the fix didn't 
make it into the 1.7 branch in time for 1.7.3.  It will be fixed in 1.7.4.

*** This bug has been marked as a duplicate of 196749 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.