Subject: [Asrg] Let's try something different

From: "Jed Margolin" <[email-masked]>
Date: Thu, 6 Mar 2003 10:08:02 -0800

I have heard that you are interested in reducing spam. Here is my Proposal:

The way email currently works is:

1. Sender's email is stored on Recipient's server.

2. Sender can broadcast email.

3. Sender can forge headers, making it impossible to complain to Sender's
ISP.

I propose:

1. Sender's email is stored on Sender's server. Recipient is sent a message
with a unique link to the message and a maximum Subject line of 80
alphanumeric characters.

2. Sender can be anonymous, but not to Sender's ISP. There will be a feature
(a button) so Recipient can tell Sender's ISP, "Don't send me any further
email from this Sender."

3. Broadcasting is prohibited. If Sender wishes to send 1 million identical
messages, then Sender's server will contain 1 million copies of the message.

4. Sender's ISP will be notified if (and when) the email has been read so it
can be deleted from Sender's server. Alternatively, email can be deleted
from Sender's server at the end of the day (or week) that it is read.

It would also be nice if the Mailreader could be configured to automatically
show messages in text format first and then let the user decide whether or
not to view it in html.

Jed Margolin

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 06 Mar 2003 12:25:16 -0600

In <00a101c2e40b$54e40cc0$ca81bbd0@kit> "Jed Margolin" <[email-masked]> writes:

> I propose:
> 
> [storing messages on the sender's server until they are delivered]

Obviously, this will require a different protocol than SMTP.

What you have described is available on several different web BBS
systems right now.  So, the new protocol is just HTTP and the new MUA
is just your browser.

This idea isn't taking off that quickly, but the fact that some people
are going back to having several different ways of sending and
receiving "email" tells you how bad the spam problem is.  *sigh*

-wayne

---

From: Nate W <[email-masked]>
Date: Thu, 6 Mar 2003 14:49:04 -0800 (PST)

> with a unique link to the message and a maximum Subject line of 80

We already see spam of this form.  It seems to me that what you propose
essentially to force spammers to put more of their content on a web
server.  Since they do that already, I don't think it is a step forward.  
Sure, their web sites get shut down, but that doesn't seem to deter them.

> (a button) so Recipient can tell Sender's ISP, "Don't send me any further

Blacklisting senders does not work.  Spammers already use a new identity
(read: becomes a different Sender) for every spamming.  If there was a
reliable way to associate sender identities with sending individuals, we
could do all kinds of useful things even using the existing SMTP
infrastructure.

> messages, then Sender's server will contain 1 million copies of the message.

It seems that this limitation would necessarily be enforced at the
server.  When the spammer controls the server, the limitation won't be
there.

--

Forcing the sender to bear the storage costs is not a bad idea, but it is
not, by itself, a solution.  It leaves much bigger problems unsolved:

First and foremost, how can we filter out the messages themselves?  The
message with the "unique link to the message" that you describe, is still
spam and must still be filtered.

Also, how can a recipient reliably identify a sender with information
contained in (or sent with) the message?  

How can we prevent spammer-operated messaging servers from misbehaving?  
I tend to assume that the answer to the last question is "we can't," which
makes the first two questions all the more critical.

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 7 Mar 2003 00:24:03 +0000 (GMT)

On Thu, 6 Mar 2003, Jed Margolin wrote:

> I propose:
> 
> 1. Sender's email is stored on Sender's server.

[snip]

http://cr.yp.to/im2000.html

---

From: Nate W <[email-masked]>
Date: Thu, 6 Mar 2003 16:37:47 -0800 (PST)

> http://cr.yp.to/im2000.html

I have tons of respect for DJB, but I'm not so sure about this idea.  
With a 'pull' mail system, recipients either need to poll senders, or
senders need to send notifications when new messages are available.

Notification messages are themselves subject to many of the same problems
as 'push' mail (including spam) becuase they are, basically, pushed to the
recipiients.  The overhead associated with polling all of the potential
senders is probably bigger than the overhead associated with bounce
messages.

It might be a cool alternative to current mailing lists though.

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com

---

From: "Gary Feldman" <[email-masked]>
Date: Fri, 7 Mar 2003 10:53:54 -0500

> It might be a cool alternative to current mailing lists though.

This is at least the second time someone has mentioned mailing
lists and mailing list alternatives, with Usenet newsgroups
having been mentioned at least once.

Let me point out (in case it isn't obvious) that a large variety
of web-based bulletin board systems already serve as alternatives.
In my opinion, the concept is very successful and far superior
to conventional mailing lists.  Whether the economic models of
the service sites that run them will be successful is another
story.

This is only relevant to this list to the extent that such
alternatives introduce questions about the role of mailing lists
as a major mode of email usage in the future.

Gary

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 07 Mar 2003 12:15:43 -0500

> as a major mode of email usage in the future.

In the large scale, perhaps.  But when you realize that every receiver 
list is tantamount to a mailing list, and things like web-based chat 
groups don't scale down to the small, you'll realize that the overall 
number of mailing lists are unlikely to go down.

So, whatever we come up with should be compatible _at least_ with BCP in 
mailing lists.

---

From: Brad Davis <[email-masked]>
Date: Fri, 07 Mar 2003 11:12:40 -0700

> with a unique link to the message and a maximum Subject line of 80

As has been pointed out, spammers are already going down this path with HTML 
encoded email.

> from Sender's server at the end of the day (or week) that it is read.

These are useless since the spamming software (and often the spamming machine) 
is controlled by the spammer.  (Some of the most "interesting" spam I've 
received is for software to do spamming from a Windows PC without the need for 
an ISP mail server (complete with a list of open SMTP relays and other open 
proxies to use)).

Solutions must assume that the other side (the spam server) is totally under 
control of spammers, that the other software was completely written by and for 
spammers, that the other ISP supports spamming (it can be lucrative for the 
ISP), and that the ISP's connection to the backbone is supportive of spamming 
(spamming may provide needed hard cash for poor 3rd world nations).

This implies two things: spam control must be performed at the client SMTP agent 
and international organizations must be willing to censure countries that fail 
to police their assigned domains and addresses (i.e. cut them off).

We (the IETF) can work on the first.  Are we willing to push for the second? 
Without the second, we just have an escalating arms war (with, I fear, the 
advantage to the spammers).

Brad Davis

---

From: "Jed Margolin" <[email-masked]>
Date: Fri, 7 Mar 2003 13:49:17 -0800

> As has been pointed out, spammers are already going down this path with
HTML

The HTML encoded spam I receive uses bandwidth *and* links.

> an ISP mail server (complete with a list of open SMTP relays and other
open

Why would someone leave their SMTP relay open?

> (spamming may provide needed hard cash for poor 3rd world nations).

Traffic from ISPs who refuse to play by the rules will be refused by the
Internet Community.

In other words, they will be excommunicated.

JM

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 7 Mar 2003 20:41:45 -0500

>In other words, they will be excommunicated.

I that is demonstrably not true.  The system has gotten too big for 
that, and the need for connectivity too large.  Blacklisting is no 
longer a sufficient threat, and attempts to do so to mixed-use 
providers have resulted in law-suits (witness MAPS).  The entire 
thing is complicated by the subjective nature of spam, and the 
question of when to pull the trigger on an ISP.  Are they spam 
friendly, or just having trouble keeping their system clean?

I've yet to find any blacklist that was reliable.  Even the proxy 
list someone recently posted a URL to here promptly gave us false 
positives--including ones for some people on this list!
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Mar 2003 10:38:41 -0500

Kee Hinckley wrote:

 > Even the proxy list
 > someone recently posted a URL to here promptly gave us false

I suppose I can understand why people have such myopic views of such
things. But one glance at the metrics our tools produce of such things
would make a believer out of just about anyone.

The hugely critical thing is how you handle false positives.  Do you
just sigh, and say "blacklists are STUPID!!!" and turn them off, or do
you take a broader view and get the open proxy fixed? It's not as if a
given FP is something you can't do something about.

A FP or two?  So what?  If you're doing it right, the worst that happens
is that the email is delayed a bit.

For example, there are class Bs in Brazil that have 500 IPs pumping
email at us, and a simple combination of, say, BOPM and Monkeys lists
over 95% of them.  The _accuracy_ of BOPM's and Monkey's listings is
easily seen - virtually every one of those IPs is pumping 10 (or a
hundred or even a thousand) times as much email into our spamtraps as
they manage to address to real users. We're talking hundreds or
_thousands_ of daily spamtrap hits.

The well run proxy lists are fiendishly accurate - at the time the test
was done, they _were_ open, and in almost every case, pumping only spam,
no legit email (remember, that most open proxies are things like default
open AnalogX proxies on ADSL lines that were never intended to send any
email in the first place).

But, of course, this leaves a hole - the blacklists often don't get
realtime notification of closure, and won't know to delist.  This is
clearly MUCH more pronounced in less well known/used blacklists[*].

Consider this, then, if _every_ mail system made use of open proxy
blacklists, and every mail system utilized a reasonably sane method of
back-notifying legit senders from these IPs of the blacklisting. [Hence,
for example, my posting of points for a BCP on filtering.]

Result?  Senders get their systems fixed ASAP, and things get delisted
in a timely fashion.  The FPs have been resolved.  Virtually no harm
done. The only ones left open are the ones not sending any legit email,
just spam.  Better accuracy.  Fewer spam sources.

I'd almost suggest that the ASRG propose a BCP that at least recommends
that MTAs reject email from promiscuous proxies. I can't think of a
faster way to get them all fixed and take a pretty substantial bite out
of our current spam loads.  At least it may prompt the developer of
AnalogX to _finally_ make the thing default to non-promiscuous - I've
tried, no joy.

[*] we run a combination of DNSBLs in addition to other filtering
techniques.  We also have a well developed procedure for being notified
of false positives and pushing fixes, retests and delistings.  When we
introduced these blacklists, we had an initial flurry of FPs as
small-time senders encountered a system using blacklists for the first
time. We forward the blocked email, queue the retests, and help the
sender get their problem fixed and delisted - if it's still open. One of
the most compelling results was that the highest FP ratio (FPs per IP
listed) was that of an open relay blacklist that only two systems on the
planet use (ours and the BL maintainer.  We're big.  The BL owner is
about 600 times larger.).  Its accuracy  is obviously directly dependent
on the number of MTAs that actually use it.

You know what?  At first, we routinely saw 5-10 FPs per day (repeat
after me: forward the email, send the sender boilerplate of why it was
blocked, queue the retests, help the sender get the problem fixed.  No
harm done).  We're now averaging about 2/day.  Soon, we'll be seeing a
few per week.  Each being handled the same way - no harm done.

Our users are paranoid about losing email.  Our company _relies_ on
email for business purposes.

---

From: Matt Sergeant <[email-masked]>
Date: Sat, 8 Mar 2003 16:00:52 +0000 (GMT)

> positives--including ones for some people on this list!

The SBL seems very sane and very reliable. The removal mechanism is swift 
and responsive, and they seem to achieve action not by threat, but by 
communication.

I'd like to see more DNSBLs run like the SBL.

Matt.

---

From: Matt Sergeant <[email-masked]>
Date: Sat, 8 Mar 2003 16:18:54 +0000 (GMT)

> just spam.  Better accuracy.  Fewer spam sources.

I like DNS blacklists, I really do. I think they're the right thing to do 
most of the time, when they are sane lists. My one big problem with them 
is bounce messages - they suck. We need a friendlier bounce message system 
than "MAILER-DAEMON" messages so my mum can understand why her email 
didn't get through.

Matt.

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Mar 2003 11:57:31 -0500

> than "MAILER-DAEMON" messages so my mum can understand why her email 

This is in fact the biggest problem in handling FPs - making the return 
email legible enough so that the user understands what it means.

Our rejection messages are pretty explicit: "this email was blocked by 
our spam filters. If you believe this to be in error, please forward 
this message, including session ID, to <whitelistedaddress>, sessionID: 
123244.4444"

Three problems:

1) A few MTAs manage not to show these messages to the sender AT ALL. 
They just get a generic "it didn't work".

2) Many MTAs bury these strings so deep in bafflegab about NDRs/X.400 
gunk and other sillyness (like listing each MX and retry in 
excrutiatingly useless detail), that it's very easy to miss the message.

3) Language.

Here's an idea: extend RFC2821 to mandate a series of response codes 
that MTAs can interpret and display to the senders.

Eg, some sort of SMTP policy return error:

55x <RFC2821 extended code> <policyflag> <how to get it fixed>

Ie:

554 a.b.c NOUBE MAIL [email-masked]

or:

554 a.b.c NOUBE URL http://ourblacklist.foo.bar/lookup?ip=A.A.A.A

or:

554 a.b.c SENDERPAYS POSTAGE http://postoffice.bar.foop/?session=<magic 
cookie>

Then the sending MTA has a chance to generate a much more intelligible 
reject - ie: couch it in the user's own language, etc.

If we can push to make FPs less painful, then filtering becomes more 
palatable with less collateral damage.

If this is standardized in an RFC, you could use it right away (it could 
often be explanatory enough without any MTA support on the sender's 
side) and MTAs fully understanding the return codes will get more common 
with time.

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 8 Mar 2003 10:27:04 -0700 (MST)

> From: "Chris Lewis" <[email-masked]>

> ...

> ...
> ...

That does nothing at all for your first two problems.  It also does
nothing for the third problem without a whole other system that does
not exist on all platforms and that in any case would require a lot
of new code in MTAs.  That other system is required to translate the
extended codes into "localized" natural language.  (Never mind that
the local language of the MTA doing the translating might be Spanish
while the language of the person using the MUA that finally sees the
bounce that might be delivered via a third MTA could be Finnish.)

However, the fact that fancy response codes wouldn't help your three
problems is not the worst.  Worse is that it is yet another solution
that depends on deploying extended policyflag decoding software in
10,000,000 MTAs.

But wait, there's still more.  In 35 years I've been in the software
trade, I've seen a lot of "error code" systems.  *ALL* of them are
the same at the end.  Sometimes the translation from a number (e.g.
"ABEND 1234" or "killed signal 10") to a string (e.g. "bad pointer")
is automatic and sometimes is manually finding the number in a list of
numbers and strings.  In either case, you get a general message that
is meaningless except to the high priests of the system.

The best and only working solution is to do as SMTP does.  That is to
include numbers that some software might but probably won't understand
as well as English for humans.  The English can be tailored for special
cases such as including a telephone number.  In special cases it can
be a language other than English.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Mar 2003 13:14:30 -0500

> of new code in MTAs.

You missed one of guiding principles.  That the extended return 
convention be specifically designed to be human readable, and at the 
same time easy to machine parse.

Our experience has been that even when the person receiving our bounce 
doesn't understand english prose, there's enough hints in it that they 
can usually react properly.  Abuse desks in China often don't understand 
a word of english.  But a forwarded email with the word "spam" in the 
subject is pretty obvious...

As is our experience - I get a significant fraction of FP reports with 
non-english text, or even non-8-bit character sets. I still manage to 
figure out what the problem is and fix it.  Even if they don't 
understand my reply.

With a standard convention for doing this, even people who don't 
recognize english meanings at all can learn (from their friends if 
necessary) how to react since it'd be consistent across bounces from all 
systems generating the conventions.

In essence, with zero MTA support, the situation is no worse than it is 
now.  It provides for extended functionality when it becomes available. 
  Because it would.  Not having it doesn't cripple email or cause more 
bounces (as trying to deploy a stamp/signature system would).  Having a 
compliant MTA simply makes it easier to decipher the bounces you'd get 
anyways.  A painless deployment, and trivial/no brainer to implement for 
the next iteration of MTAs.

MTA bounce "presentation" has always been an overlooked area. It's time 
that someone paid a little attention to it and did some useful things - 
at least at a BCP level.

> That other system is required to translate the
> extended codes into "localized" natural language.

Perhaps I shouldn't have phrased it that way.  It'd be _more_ than 
adequate to simply generate text consistent with the language that the 
MTA is already configured to generate (ie: all of our reported FPs that 
contain MTA bounce notices in French.  Or Arabic.  Or even in unicode). 
  Leave true "sender language" generation for those willing to go that 
extra mile with their "Language-Preference" headers and other gunk. Nice 
feature, but not required.

> that depends on deploying extended policyflag decoding software in

Doesn't require that at all.  I could do it _now_ with our mailers 
without anyone anywhere parsing the results, and it'd still work fine.

100% backwards compatible.

> is meaningless except to the high priests of the system.

But it doesn't need to be.  All it is is a protocol "escape" to 
something with more power to explain exactly what happened.

If you got:

550 x.y.z NOSPAM http://foo.bar.blat?reason=XYZ

I don't expect or even want the user to be able to instantly say 
"ohmygosh my proxy is open!", and go off and try to "fix" something - 
anything.

All I want is the user to click on the link (or cut-and-paste it into a 
browser).

Or, if it says:

550 x.y.z NOSPAM FORWARDBOUNCE mailto:[email-masked]?subject=XYZ

simply send email to the address.

The idea is to get the user to "call" something that can do a much 
better job of explaining what's going on, using routine, every-day, 
current web (or human beings behind a mailbox etc) practise.

> be a language other than English.

This is "doing as SMTP does".  It's simply providing an additional 
machine-readable convention for better interpretation of the message the 
rejecting MTA is trying to communicate in an ordinary SMTP response 
code.  It's a lot easier for the sending MTA than the rejecting MTA to 
get closer to a language other than english - it's already configured 
that way.  But it ain't hard to make the convention human readable. 
There's less than a dozen different meanings you're trying to convey anyway.

---

From: Kee Hinckley <[email-masked]>
Date: Sat, 8 Mar 2003 13:20:05 -0500

>given FP is something you can't do something about.

I used to spend time tracking down that kind of thing.  The volume 
exceeded what I could deal with years ago.  But more critically, now 
that I'm running a service, I simply cannot afford it.  Do the math 
on what someone pays to have their email spam-free, and then compare 
that to the amount of time it takes to track down and complain about 
proxies.  No can do.  I'd far rather spend my time here trying to fix 
the problem for once and for all than run around sticking my fingers 
in dikes.  You can afford to do it for two reasons.  One, you're 
relatively large.  Two, your salary isn't being paid *just* by spam 
filtering income--you're subsidized.

>is that the email is delayed a bit.

This is a common misconception.  "False positives aren't a problem, 
they just go into a queue that people can check."  Technically, it's 
true.  Practically, it doesn't work.

I've got bad news for you.  People don't check the queues.  Oh sure, 
our technical users do.  They understand fuzzy matching, they know 
that this kind of technology isn't 100% reliable.  Our non-technical 
users don't, and furthermore, when they do look at them, they delete 
them without scanning them all.  The longer they use the system, the 
less carefully they check.  And the problem gets worse.  The better 
your filtering gets, the less likely the user is to scan the queue. 
In other words, the lower the false positive rate, the more likely 
the end user is to delete the false positive without seeing it.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Jim Youll <[email-masked]>
Date: Sat, 8 Mar 2003 13:29:34 -0500

>the end user is to delete the false positive without seeing it.

I would like to add that scanning such a queue for errors becomes 
increasingly more _difficult_ and error-prone as the accuracy goes 
up... it's not entirely the user's fault when one "good" message is 
obscured in a field of hundreds of bad ones.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Mar 2003 14:08:17 -0500

> that I'm running a service, I simply cannot afford it.  Do the math on 
> what someone pays to have their email spam-free, and then compare that 
> to the amount of time it takes to track down and complain about 
> proxies.  No can do.

Simple.  Do what we do. We blacklist the open proxies, and let the 
people who hit the blacklist (if any do) report it. We provide pretty 
boilerplate responses for the sender to give to their provider. That's 
much easier than trying to figure out what the responsible email address 
corresponding to the IP of a given open proxy. By definition, the user 
hitting the blacklist will have a better idea of who to contact.

> This is a common misconception.  "False positives aren't a problem, they 
> just go into a queue that people can check."  Technically, it's true.  
> Practically, it doesn't work.

I think you missed a step.  The sender sees the reject, and reports the 
FP as instructed in the reject.

> I've got bad news for you.  People don't check the queues.

Pardon my french: Like hell I don't!

In case you missed it, I'm the FP handler for the entire company.  When 
I say 5-10 FPs per day, that's for ALL email coming into the 50,000 seat 
company (a bad day at that, and that's including FPs not due to blacklists)

I process the queue.  There's too many people watching (CC'd on the FP 
handling address, many capable themselves of handling most FPs if I'm 
not around) for me not to.

[FP handling takes me about 15 minutes/day - for the whole company.  I'm 
in the midst of handing over the "problem resolver" tool over to 
operations, so I won't even have to do that anymore.]

So, let's say you don't want to funnel your FP reports into a 
FP-handling service, or you're worried that too FPs doesn't get reported 
by the sender.  Simple, do what Brightmail does (and we're currently 
trialing something similar).  Send each user, according to whatever 
schedule they may choose, a single email containing dates, froms and 
subject lines of mail that's been filtered. Give them the opportunity 
(via a link to your quarantine server) to view or discard the blocked 
emails.  Or even provide a mechanism for selecting automatic forward 
(ie: based on from) without having to adjust the front-end server-wide 
filtering.

Simply by scanning the email they get, they can decide not to bother 
checking, or, see something that perhaps shouldn't have been blocked, 
and go get it.

Then no user has a plausible excuse for missing anything - nothing to 
"remember" to check.  It's in their face, just as if the email got 
through in the first place.

Even moderately high levels of FPs (1-10%) are truly irrelevant if you 
handle them properly.

Full deployment of our spamviewer facility will permit the filters to 
become far more draconian than they are now.

Don't say it doesn't work.  It does.  We've been doing it for >5 years 
already, and nobody's shot me yet ;-)

---

From: Kee Hinckley <[email-masked]>
Date: Sat, 8 Mar 2003 15:36:50 -0500

At 2:08 PM -0500 3/8/03, Chris Lewis wrote:
>people who hit the blacklist (if any do) report it. We provide 
>pretty boilerplate

A company, especially a small company, cannot afford to do that to a 
potential customer.  If someone sends my consulting company email 
asking for my business, and I bounce it and tell them they can't talk 
to me until they straighten it out with their ISP--I've just lost a 
potential client.

It also doesn't work for the prototypical end-user.  For a year I 
sent back a response to everyone who sent email to 
[email-masked].  It explained why they were getting the 
response, why they shouldn't send email to the address, why they 
should take it out of their address book.  Every day I'd get dozens 
of responses.  "Who are you?"  "How did you get my email?"  "You 
aren't in my address book!".  So I gave up and started bouncing the 
stuff with an extended bounce message explaining the message.  Now I 
just get 3-4 messages a day saying the same thing.  (That's about a 
1% "I'm confused" response rate.)  And then there are the people who 
completely ignore the bounces and keep sending mail over and over 
again.  When I finally get them to listen, I ask them why they 
ignored the bounce.  "I didn't know what it was."  "I thought it was 
spam."  "I thought it was a virus."  "My ISP told me never to respond 
to email from someone I didn't know." (E.g. MAILER-DAEMON).  And then 
there are people's address books.  wormalert tends to get email sent 
to everyone in the address book.  When people repeatedly do this, I 
would reply-all to their message.  So here's someone who has been 
sending email to everyone in his address book for days (at least). 
When I send to those addresses, I get a dozen bounces.  This guy has 
been getting dozens of bounces a day from bad addresses in his 
address book, and he has ignored them all.  And this is *common*.  We 
are talking of hundreds and thousands of people doing this.

These are the people who have been told over and over again that they 
shouldn't open mail from someone they don't know.  They get email 
from MAILER-DAEMON (pretty scary name if you think about it) and we 
expect them to open the message, read past the garbage, find the 
place where it says they were blocked because we thought they were 
sending spam, figure out that this isn't a permanent problem, and 
forward it to their ISP?

>>they just go into a queue that people can check."  Technically, 
>>it's true.  Practically, it doesn't work.
>
>I think you missed a step.  The sender sees the reject, and reports 
>the FP as instructed in the reject.

See above.  Try thinking like someone's grandmother.

>Pardon my french: Like hell I don't!

You didn't read the next line did you.  Techies do.  But even techies 
get sloppy over time.

>In case you missed it, I'm the FP handler for the entire company.  When I say

And that makes you about the least qualified person in the world to 
consider what the average user will do with a false positive.  It's 
your *job* to read the things.

First rule of end-user false positives.  You don't call them false 
positives.  The end user has no clue what that means.  We call it 
"misidentified email", and I don't even like that.  We don't talk 
about spam (or, God forbid, "ham"!).  There's mail that was blocked, 
and mail that was approved.

I just got off the phone with my father last night.  I was getting 
his feedback on some new forms for dealing with misidentified email. 
He's one of our beta testers because he definitely fits into the 
"it's all magic to me" category. It took a while to explain the form 
because it turned out that he had gotten so complacent about the junk 
folder that he had stopped checking it at all.  He just deleted them. 
This had all been explained many times.  But this *isn't* his job. 
It's an annoyance.  And finding false positives was not something he 
had to do every day, but just occasionally, so he forgot.  And that's 
the real world.

>similar).  Send each user, according to whatever schedule they may 
>choose, a single email containing dates, froms and subject lines of 
>mail that's been filtered. Give them the opportunity (via a link to 
>your quarantine server) to view or discard the blocked emails.  Or 
>even provide a mechanism for selecting automatic forward (ie: based 
>on from) without having to adjust the front-end server-wide 
>filtering.

That is *exactly* what PureMessaging does.  Sending the spam through 
flagged is an option, but the normal behavior is to leave the mail on 
the server and send you a periodic summary.  You can have messages 
sent through to you, or you can 
whitelist/blacklist/unsubscribe/report-to-abuse--as appropriate for 
the given message.  It doesn't solve the problem.  They glance at the 
mail and delete it.

Now you can tell me that people are being stupid.  But that's kind of 
pointless.  You design a system for the users.  They know what they 
know.  Fundamentally when you are designing systems like this you are 
designing a user interface.  And like all good UI design, it needs to 
take into account how real users behave.  As people intimately 
involved in email systems for most of our lives, we are supremely 
unqualified to make that determination by examining our own behavior.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society