JMKELSEY@delphi.com writes:
I just don't think I'd like Delphi to start filtering my e-mail without asking me for permission and instructions first.)
Likewise a number of AOL users don't like the idea of AOL deciding what they can and can't read. (By the way one of the good things about AOL is that they ignore all Usenet cancels.) AOL is promising to let its users filter their incoming mail the way they want to by the end of September.
Each user has a mail filter with a set of rules written either by or for that user. The mail filter does one of four things with each piece of e-mail it receives:
a. It lets the e-mail through immediately. (E-mail from friends, employers, employees, family members, etc. would probably be in this category.)
This should not be the default.
b. It discards the e-mail immediately. (E-mail from people you really didn't like, and from people who have spammed you in the past would probably be in this category.)
Or may from mailing lists submitted by known idiots.
c. It puts the e-mail on hold in some storage area.
This should be the default for unknown senders.
d. Send e-mail back to the sender, informing him of conditions under which the user is willing to accept this e-mail. This might be things like requiring anonymous users to provide some minimal kind of identity, or telling senders ``I'll read your e-mail for one dollar in digicash,'' or ``I'll read your e-mail if you carry out this computationally expensive calculation, or some other thing.
For e-mail in the third category, some kind of summary report is sometimes generated, to be sent to a server. The server collects these reports, and uses some kind of system (maybe rule-based, but probably involving scores to estimate probability of spam or other unwanted e-mail) to determine what is and is not spam, and with what probability. It then sends to each of its subscribers, every day or so, a report indicating scores for users' messages. (These should be individualized.)
One can simply choose to read the a) mail now and c) mail later. Consider this scenario: 10:00 Eve sends junk e-mail to Alice and Bob. 10:05 Alice reads her urgent e-mail; leaves non-urgent e-mail for later. 10:30 Alice reads non-urgent e-mail, discovers junk mail from Eve. 10:31 Alice posts a warning to a Usenet newsgroup about junk e-mail from Eve, specifying a pattern than matches Eve's junk mail, and perhaps an address for postmaster complaints. 10:40 Bob starts reading his e-mail. Before he begins, his e-mail reading program fetches new e-mail notices from the usenet newsgroup, finds the ones from the issuers Bob trusts, checks their PGP signatures, and adds their patterns to its database. It then junks Eve's letter (discards it or bounces it to the postmaster, whatever Bob chooses) Note that procmail can't do it - procmail would get Eve's junk mail at 10:00. We want to delay the processing of the incoming queue to get the latest available junk mail notices.
The junk e-mailers can try various countermeasures to this. The most obvious are:
a. Try to hit people who aren't using a good junk-mail filter. b. Try to make it against the law to use a junk-mail filter. (Perhaps this would be the case only for PSA spams?)
It's probably a bad idea for an ISP to impose such filters on users without letting them "opt out", as AOL tried to do.
c. Try to disguise their e-mail to make it not obviously junk e-mail, and simultaneously to alter each message to avoid detection by the servers, by making changes to each message, timestamp, and claimed sender ID.
That would an interesting technical challenge. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps