I've had enough.
Mark Shaw
Of UCE, that is. What I have in mind is a series of procmail
recipes which will work something like the following:
Recipe Group 1: There are a small number of pests whose
mail I never want to see. Any mail originating from those
addresses is filed to /dev/null. (My current .procmail
already has these recipes.)
Recipe Group 2: There are a number of people I currently
correspond with, and whose mail I wish to continue to re-
ceive. Any mail originating from those addresses is filed
to my inbox.
Recipe Group 3: Any mail which does not satisfy the cri-
teria for groups 1 or 2, but which includes a particular
string in the subject line (say, "not UCE") is filed to my
inbox.
Recipe Group 4: Any mail which does not satisfy any of the
above criteria is returned to the sender along with a polite
note apologizing for the bounce, and explaining that the mail
will be accepted if it is not UCE and is resent with "not UCE"
in the subject line. I'll also stick an abbreviated form of
this message in my sig.
What I'm assuming, of course, is that most bulk emailers will not
bother to tailor their junk to my Group 3 specifications, so it'll
never get to me. And after reading a Group 3 message, I can add
the sender's address to the Group 2 list and they won't have to
bother with the "not UCE" string in further messages.
What I'm afraid of, however, is something along the lines of the
possibility of getting into a ping-pong match between my bot and
some bot that's continually mailing me, thus tying up resources
and making people unhappy.
Anybody have any observations? Thanks in advance.
---
Mark Shaw
My opinions only
PGP public key available at ftp.netcom.com:/pub/ms/mshaw
Lance Purple
Mark Shaw <ms...@asic.sc.ti.com> proposes recipes to handle mail from:
>
> 1. sender on list of known spammers: dump to dev/null unread
> 2. sender on list of known friends: keep in in-box
> 3. unknown but contains magic string: keep in in-box
> 4. unknown and lacks any magic string: return mail, with a note
> about magic strings to use.
>Anybody have any observations? Thanks in advance.
It'd take spammers a week, tops, to learn to use "not UCE".
Instead of a fixed magic string, I'd pick a random password
(from /usr/lib/dict), and convert to ascii-art using Figlet.
This would be much harder for an automated script to handle.
Example:
"Hi. I see you are e-mailing <user@site> for the first time.
In order to give your e-mail priority over automated "junk",
they ask you to please reply to this message, using the
following simple password as your Subject: .
+---. +---+ +-+ +-+
| |) ) | __| | | | |
| < | | | | | |
| |) ) | ""| | '"| | '"|
+---' +---+ +---+ +---+
"Once you have replied with this password, your e-mails to
<user@site> will be given top priority. Thank you.
Plus, to prevent endless loops when -you- send e-mail,
you need a 5th class: people whom you've sent email to
recently, who are replying with one of the above forms.
There probably be ought to be an X-header for them...
Other than that, it is a good plan. Can any procmail
gurus suggest how to implement the above?
------------------------------
L. Purple (lpu...@netcom.com)
Greg Limes
ms...@asic.sc.ti.com (Mark Shaw) writes:
|
| Of UCE, that is. What I have in mind is a series of procmail
| recipes which will work something like the following:
|
| Recipe Group 1: [known trash to /dev/null]
| Recipe Group 2: [known friends to inbox]
| Recipe Group 3: [trapdoor subject to inbox]
| Recipe Group 4: [bounce everything else]
I've been doing something similar, but a bit simpler. I
don't like to bounce mail back -- UCE often would bounce
to an innocent third party, and sometimes mail from
friends does not bounce "correctly".
I use this kind of filter:
Group A: mail from friends goes into the inbox.
Group B: anything not matching Group A, which passed
through the SGI firewall (I'm inside it), gets tossed
into a holding pen.
Group C: anything else (SGI internal) goes into inbox.
Every night, the holding pen is dumped into a mail folder
which I can look at when I have time.
This means that if I get mail from a friend using an
internet address that I've never seen, it can take a
few days before I see it ... but I do get to see it,
and can toss their information into my pass-list.
--
Greg Limes limes at sgi.com SGI DSD Core I/O Software
limes at netcom.com [personal mail -- NO JUNK]
ASSERT(!speakfor(SGI,me)); ASSERT(!speakfor(me,SGI));
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
Mark Shaw
In article 0...@library.airnews.net, elcab...@aol.com (The Gentleman) writes:
> How about a 'X-Magic-Word:' header on mail? For enabled clients (that
>don't exist yet, I'm being purely theoretical here), this could simplify
>things quite a bit. Imagine a mail client that could associate a magic word
>with a particular address.
>
> Say that I send a mail to a poster to a group I read. His filter bounces
>the mail, telling me that the magic word is 'Please'. I associate that word
>with his address, and from then on, all mail I send to that address includes a
>'X-Magic-Word:Please' header. Except for the very first time I send him mail,
>I never have to worry about bouncing mail again.
Sounds pretty good, on the face of it. If the bounce messages were standard,
though, I can see UCE mailbots simply sending their junk in two passes.
Tom Betz
Quoth pedw...@valhalla.cs.wright.edu.NOSPAM (Phil Edwards)
in <55ta1o$3...@alpha.wright.edu>:
|
|To be truly evil, you might add an EXITCODE line if you haven't
|already, as in
|
| :0
| * whatever criteria
| * you use here
| {
| EXITCODE=77
|
| :0
| /dev/null
| }
|
|Try testing that first, if the line from /usr/include/sysexits.h
|doesn't make it obvious. Good for amusement value. :-)
|
Refresh our memories... what exactly does that EXITCODE do?
--
|We have tried ignorance | Tom Betz (914) 375-1510 |
|for a very long time, and | Want to send me email? First, read this page: |
|it's time we tried education. | <http://www.panix.com/~tbetz/mailterms.shtml> |
|<http://www.pobox.com/~tbetz> | I mock up my reactive mind twice daily. |
Nathan Tenny
In article <55qrg8$l...@spock.asic.sc.ti.com>,
Mark Shaw <ms...@asic.sc.ti.com> wrote:
>Of UCE, that is. What I have in mind is a series of procmail
>recipes which will work something like the following:
I'm doing something similar, but I don't feel at liberty to use a "magic word"
system because of the constraints of maintaining a FAQ (I get a lot of legit
mail from relative newbies, and I don't want to make them jump through hoops).
Instead, I've cobbled together a content filter that attempts to identify
legitimate mail---e.g., anything that contains my name or mentions snakes (but
not "snake oil"!) is deemed to be OK, and so on. Only about one piece of
UCE per month gets past the filter, which is good enough performance to keep
me happy. And it's trivial to implement in procmail:
:0B
* !a-keyword
* !another-keyword
* !yet-another-keyword
* !and-so-on
.
.
.
{
# some sort of bounce recipe
}
>What I'm afraid of, however, is something along the lines of the
>possibility of getting into a ping-pong match between my bot and
>some bot that's continually mailing me, thus tying up resources
>and making people unhappy.
Adding an X-Loop: header should short-circuit most of these problems. If the
bot on the other end doesn't preserve headers when replying, of course, it
won't help, but IMHO any autoreplying bot should preserve at least X-Loop:!
You just add that header to all your bounces, and then change your filters
so that anything with the right X-Loop: header doesn't get bounced. (I use
"X-Loop: while (1) ;", which is probably just too cutesy...)
Of course, if you do your bouncing by setting EXITCODE instead of formulating
a reply, loops shouldn't happen. A bot that autoreplies to a mailer bounce
message is definitely broken.
NT
--
Nathan Tenny nte...@qualcomm.com
Qualcomm, Inc., San Diego, CA http://www.qualcomm.com/~ntenny/
The rec.pets.herp FAQ lives at http://www.qualcomm.com/~ntenny/herps/FAQ.html
Lorrie Wood
In article <55tb05$i...@panix3.panix.com>,
Tom Betz <Read_the_Mailterms_URL@Bottom_of_my_Post.Please> wrote:
>
>Refresh our memories... what exactly does that EXITCODE do?
From the referenced header file:
#define EX_NOPERM 77 /* permission denied */
-- Lorrie
--
<*> -- Lorrie Wood -- <*> -- lor...@mellers1.ppsych.berkeley.edu -- <*>
I believe in everything; nothing is sacred.
I believe in nothing; everything is sacred.
-- Tom Robbins, _Even_Cowgirls_Get_the-Blues_
Eli The Bearded
Mark Shaw <ms...@asic.sc.ti.com> proposes recipes to handle mail from:
: 1. sender on list of known spammers: dump to dev/null unread
: 2. sender on list of known friends: keep in in-box
: 3. unknown but contains magic string: keep in in-box
: 4. unknown and lacks any magic string: return mail, with a note
: about magic strings to use.
: Anybody have any observations? Thanks in advance.
Lance Purple <lpurple@netcom> wrote:
>It'd take spammers a week, tops, to learn to use "not UCE".
And they might accidentally hit it while lying about the
content of the mail.
>Instead of a fixed magic string, I'd pick a random password
>(from /usr/lib/dict), and convert to ascii-art using Figlet.
>This would be much harder for an automated script to handle.
Yup. Much harder too when some clueless newbie takes you too
litterally and cuts&pastes the five line BUAF word into the
subject line.
>Other than that, it is a good plan.
I'd disagree. I get a fair amount of mail from people writing
to me for a first time in response to a usenet post or webpage
of mine. When they are not trying to sell me anything or get
me to add a link to point to their webpages, I don't mind the
mail. Any cookie code in the headers will be a problem for many
of those people. I do not want to discriminate against people
who do not notice this weeks variation on the "How to send Eli
mail rules." All I want to discriminate against is "Sell It"
mail.
Similarly mucking with the "From" header is going to cause
needless headache for a bunch of people who have done nothing
wrong.
Also I don't think this would be any good against UCErs who
manage to get through protections on mailing lists. Under
this plan, mailing lists would have to be automatically
accepted because you cannot require everyone on the list to
modify subject lines just for you.
Last week I posted my new experimental "Acceptable Email
Policy" that defines what I consider acceptable email. My
usenet posts since then have all had X-header references
to it. I have revised the text since I posted it last week,
now I include a statement saying what kind of email it
was formulated to protect against.
At first it may seem illegal to force everyone sending me
email to conform to this policy since many obviously have
no idea they are being bound to it. That would be true if
it were a contract, but it is not. It defines mail that is
harassing and attempts to define bulk and commercial email.
Harassing communication including email is already illegal
in the US, bulk and commercial may be illegal under the
fax law. I explain in the policy that I will seek legal
redress for illegal email. On top of this I forward notices
to offenders telling them their email is being archived for
legal use when they violate it.
It is not likely the best solution but I think it better
than others proposed.
Elijah
------
considering installing an autoresponder to mail it out as well
Matt McLeod
On 6 Nov 1996 20:12:56 GMT, Mark Shaw <ms...@asic.sc.ti.com> wrote:
>Of UCE, that is. What I have in mind is a series of procmail
>recipes which will work something like the following:
<scheme snipped>
I'm doing something similar. Mail from known spam addresses gets chucked
straight away. Mail with suspicious characteristics (e.g., words like
"money" or "$$$$" used more than x times) gets replied to with a polite note
telling the sender that the message looks like spam, so it's being sent back
to them (so I don't lose any non-spam mail).
Naturally, mailing-lists are sorted out before any of this, and the recipe
checks for loops.
This approach has some advantages and disadvantages when compared to yours:
Pro:
* Don't cause any hassle for most non-spammers trying to mail me, even
without my knowing about them prior to receiving their mail
Con:
* Doesn't catch all spam - only stuff that smells like spam gets caught.
* Potentially legit mail will get returned. This hasn't happened yet
though.
--
Matt McLeod "Si tacuisses, philosophus mansisses."
System Administrator - Sir Humphrey Appleby
Hunter Network Association KDE: http://www.zws.com/kde/
Joe D
Lance Purple (lpurple@netcom) wrote:
: Mark Shaw <ms...@asic.sc.ti.com> proposes recipes to handle mail from:
: >
: > 1. sender on list of known spammers: dump to dev/null unread
: > 2. sender on list of known friends: keep in in-box
: > 3. unknown but contains magic string: keep in in-box
: > 4. unknown and lacks any magic string: return mail, with a note
: > about magic strings to use.
:
: >Anybody have any observations? Thanks in advance.
: [password scheme snipped]
I'm doing something a little different.
Rules 1 and 2 I've got. If the mail doesn't meet those criteria, then I run
it through a spam detector. It looks for key phrases like 'amazing
opportunity' 'financial success' 'shipping and handling' etc, etc, etc,
which tend to appear in UCE, and then rates the message. The higher the
rating, the more likely it is to be spam. Anything with a rating of 10 or
higher gets sent to a special folder. Everything else gets sent to my
inbox. Then I can review the suspected spam and feed it to my nastygram
generator if I want to.
I used to have it send nastygrams automatically, but I had misspelled the
name of the mailing list in my 'allowed addresses' file, and had a message
trigger it, so I decided to play it safe.
No, it's not perfect, but I'd say it's about 95% accurate. There's a chance
that some spam will make it through, and a chance that some legitimate email
will get diverted, but I don't have to worry about passwords or making my
friends learn the secret handshake.
I got the idea from John Harvey (johnbob @ io.com). He did something
similar, but it was in Perl, which I don't speak yet. I wanted to play with
the concept, so I rewrote the major parts in C. John's Perl scripts are
available at http://www.io.com/~johnbob/jm/index.html.
Joe D
--
Question of etiquette:
Is it OK to have sex before dinner?
Yes, as long as the restaurant isn't crowded.
Ronald sez: Reply To This Address Only If You Are A Stupid E-mail Spammer. So Sayeth Guilmette
In article <55qrg8$l...@spock.asic.sc.ti.com>,
Mark Shaw <ms...@asic.sc.ti.com> wrote:
>Of UCE, that is. What I have in mind is a series of procmail
>recipes which will work something like the following:
>
> mail I never want to see. Any mail originating from those
> addresses is filed to /dev/null. (My current .procmail
> already has these recipes.)
>
> Recipe Group 2: There are a number of people I currently
> correspond with, and whose mail I wish to continue to re-
> ceive. Any mail originating from those addresses is filed
> to my inbox.
>
> Recipe Group 3: Any mail which does not satisfy the cri-
> teria for groups 1 or 2, but which includes a particular
> string in the subject line (say, "not UCE") is filed to my
> inbox.
>
> Recipe Group 4: Any mail which does not satisfy any of the
> above criteria is returned to the sender along with a polite
> note apologizing for the bounce, and explaining that the mail
> will be accepted if it is not UCE and is resent with "not UCE"
> in the subject line. I'll also stick an abbreviated form of
> this message in my sig.
>
>What I'm assuming, of course, is that most bulk emailers will not
>bother to tailor their junk to my Group 3 specifications, so it'll
>never get to me. And after reading a Group 3 message, I can add
>the sender's address to the Group 2 list and they won't have to
>bother with the "not UCE" string in further messages.
>
>possibility of getting into a ping-pong match between my bot and
>some bot that's continually mailing me, thus tying up resources
>and making people unhappy.
>
The idea of having a registration process for all of your E-mail
correspondants (i.e. all that you don't already pre-register yourself)
is a good one and has been discussed here before. It _should_
effectively block essentially 100% of UBE.
As regards to the ``infinite mirrors'' effect of having your auto-
responder responding to someone else's autoresponder... well... there
are known (and simple) solutions for that problem also. I won't
describe them here because I believe they are already well documented
elsewhere.
--
-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg @ monkeys . com -------------------------------------------
------ Copyright (c) 1996 by Ronald F. Guilmette; All rights reserved. -----
Ronald sez: Reply To This Address Only If You Are A Stupid E-mail Spammer. So Sayeth Guilmette
In article <lpurpleE...@netcom.com>, Lance Purple <lpurple@netcom> wrote:
>Mark Shaw <ms...@asic.sc.ti.com> proposes recipes to handle mail from:
>>
>> 1. sender on list of known spammers: dump to dev/null unread
>> 2. sender on list of known friends: keep in in-box
>> 3. unknown but contains magic string: keep in in-box
>> 4. unknown and lacks any magic string: return mail, with a note
>> about magic strings to use.
>
>
You are assuming that they will spend the time necessary to do that.
They won't.
As someone else noted, that would not fit with their minimum-cost
business model.