Thwarting UCE address culling programs.
D. J. Bernstein
In article <5bmdhr$5...@tracy.nacs.net>, Steven Sobol <sjs...@nacs.net> wrote:
> It's not free. Period.
It's so close to free _for them_ that it might as well be free.
You're accepting messages from random people around the Internet. You
are not charging them for your reading time, or even a tiny fraction of
your reading time.
You are therefore _gambling_ that the messages will be worthwhile.
Some of the random people are spammers taking advantage of your gamble.
You lose.
As an MTA implementor I'm sick of listening to the fantasy that we can
automatically identify which random people are spammers. This is doomed
to failure. As soon as an automated mechanism becomes popular, spammers
will subvert it. Time wasted and nothing to show for it. Security
through obscurity, without the obscurity.
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
David Richards
In article <1997Jan1820...@koobera.math.uic.edu>,
D. J. Bernstein <d...@koobera.math.uic.edu> wrote:
>As an MTA implementor I'm sick of listening to the fantasy that we can
>automatically identify which random people are spammers. This is doomed
>to failure. As soon as an automated mechanism becomes popular, spammers
>will subvert it. Time wasted and nothing to show for it. Security
>through obscurity, without the obscurity.
One idea I've been too busy to implement right now is a (procmail based)
filter that keeps two lists of mail addresses:
1. Addresses you NEVER want to accept mail from, may include
regular expressions. Mail with these addresses ANYWHERE in the
headers is discarded.
2. Addresses you ARE willing to accept mail from.
(Mail that matches this list is automatically accepted)
Here's the automated part- When a message is received from an address that
doesn't match either list, the message is bounced back to the sender,
with a checksum encoded in the message, and a note that it was automatically
returned, and will be accepted if they bounce it back to you.
When they resend the message (with the checksum) their address is appended
to the second list, so this and all subsequent messages are accepted
automatically.
Since most spam mail is sent without valid reply addresses and spammers
seldom use the same address twice, this should catch all automated junk mail.
Everybody you want to correspond with will only have to resend their
message once, after which their address is on the second list.
The one big opening this leaves is when you are on a mailing list and
add it to the list of 'acceptable' addresses- if a spammer attacks the
mailing list, his messages will get through.
Comments?
--
David Richards Ripco, since Nineteen-Eighty-Three
My opinions are my own, Public Access in Chicago
But they are available for rental Shell/SLIP/PPP/UUCP/ISDN/Leased
d...@ripco.com (312) 665-0065 !Free Usenet/E-Mail!
Rahul Dhesi
In <1997Jan1820...@koobera.math.uic.edu>
d...@koobera.math.uic.edu (D. J. Bernstein) writes:
>As an MTA implementor I'm sick of listening to the fantasy that we can
>automatically identify which random people are spammers. This is doomed
>to failure. As soon as an automated mechanism becomes popular, spammers
>will subvert it.
I use unpopular automated mechanisms.
This is the old arms race which was documented way back by Jules Verne:
They make bigger cannons, I make stronger sheilds. All I want to do is
be a step ahead of them, so they go and bother somebody else.
See http://www.iq-internet.com/ to see who is unhappy that I'm
a step ahead.
--
Rahul Dhesi <dh...@spams.r.us.com>
a2i communications, a quality ISP with sophisticated anti-junkmail features
For various anti-junk-email lists, follow links in:
http://www.rahul.net/dhesi/
Simon Karpen
d...@ripco.com (David Richards) writes:
> In article <1997Jan1820...@koobera.math.uic.edu>,
> D. J. Bernstein <d...@koobera.math.uic.edu> wrote:
> >automatically identify which random people are spammers. This is doomed
> >to failure. As soon as an automated mechanism becomes popular, spammers
> >through obscurity, without the obscurity.
>
> One idea I've been too busy to implement right now is a (procmail based)
> filter that keeps two lists of mail addresses:
[snip]
> Here's the automated part- When a message is received from an address that
> doesn't match either list, the message is bounced back to the sender,
> with a checksum encoded in the message, and a note that it was automatically
> returned, and will be accepted if they bounce it back to you.
>
> When they resend the message (with the checksum) their address is appended
> to the second list, so this and all subsequent messages are accepted
> automatically.
>
> Since most spam mail is sent without valid reply addresses and spammers
> seldom use the same address twice, this should catch all automated junk mail.
This is the kind of thing that will work as long as it is unpopular.
If it becomes popular, it would be trivial to modify spam software
and servers to have a valid reply address for the mail that sends
back a copy of whatever you send to it. It isn't hard to do.
Basically, the only way we'll ever get rid of the stuff would be to
a) outlaw it internationally or b) it will become unprofitable
because of the tiny cost of advertizing and the fact that
much of the stuff advertized hasn't got a hope with any other
form of delivery, a) would probably have to happen before
anything significant is done about it.
However, in the mean time, *original* methods of getting rid of spam,
so that methods vary person by person (i.e. customized procmail,
.qmail, using qmail to stop relaying, etc) will cut down on a large
amount of the spam.
--
Simon Karpen
kar...@rpi.edu, s...@acm.rpi.edu, s...@karpes.stu.rpi.edu
When you say "I wrote a program that crashed Windows", people just stare at
you blankly and say "Hey, I got those with the system, *for free*"
--Linus Torvalds
Julian Byrne
David Richards wrote:
> [Description of spam block scheme]
I've been using a similar email spam block 'bot experimentally for
months.
It must be good; I've received hate mail from spammers concerning it.
:-)
How it works:
- Addresses on a `blocked' list are bounced with a rude message.
- Addresses on a `go' list are delivered as usual.
- Any `unknown' address is bounced with a note saying that the sender
needs to put a code in the `Subject' heading and their email will
get through.
- If a message is received with a valid code the corresponding address
is put on the `go' list.
- Any address I send to is automatically placed on the `go' list so
that anybody who replies to me never sees the 'bot.
- Bounces and double bounces must be handled very carefully.
Upside:
- *Zero* espam.
- Much reduced thoughtless throwaway email as people get a second
chance to decide not to send me an email message.
- No maintenance, invisible to me and my regular correspondents.
- Doesn't matter what fake domains, IP addresses and relays
spammers use.
- Email addresses I correspond with are verified.
- Once installed easy for a naive user to understand and use.
Several of my correspondents have asked for a copy.
- Doesn't require the whole net cooperating to work.
Downside:
- People contacting me for the first time have to put a code in the
subject heading.
- People who use multiple email addresses get aggravated. I suspect
Rahul would hate it :-)
- A pain for postmasters, support people, mailing list maintainers etc.
who deal with large volumes of email to one-off correspondents.
Can anybody think of a long term solution to this?
- Complicated to install - inbound, outbound, bounce and double bounce
messages must all be handled.
- Doesn't eliminate the machine overhead of the spam email.
I believe a development of this could be one medium term solution to the
email spam problem. Currently the 'bot asks for a code that a spammer
could automatically deal with but by replacing the code with arbitrary
question[s] for each user (eg. `What color do red and yellow paints
mixed together give? Put it in the subject heading') then I can't see
any way that a spammer could automatically handle it. It depends on
the fact that a human being will always be able to ask and answer a
question that an AI can't, for the near future anyway...
If you were a spammer could you beat it?
I'm not releasing the 'bot code at this stage as I still regard it as
mostly experimental. It's written mainly in C/gdbm and runs under
unix with qmail.
Incidently, Dan is right about fully automatic filters:
they are only a stopgap. That's why I stress AUP's and other
non-filter based solutions on my web page. When enough people
start filtering the spammers will simply change their forgeries
more often. If need be they can even change it on the fly during
a single spam run.
Julian Byrne <http://kryten.eng.monash.edu.au/gspam.html>
Stefan Monnier
Simon Karpen <s...@karpes.stu.rpi.edu> writes:
> Basically, the only way we'll ever get rid of the stuff would be to
> a) outlaw it internationally or b) it will become unprofitable
> because of the tiny cost of advertizing and the fact that
What about the imaginable time when cryptographic software such as PGP
is widely used: you could have a "no-spam" signing service which would only
sign keys of people which have agreed to never spam, you could then check
the author's key and only accept the mail if the author has signed such a
no-spam agreement. Of course this is very far in the future...
Stefan
Wiz
On 18 Jan 1997 21:56:27 GMT, Rahul Dhesi <c.c....@13.usenet.us.com>
wrote:
>See http://www.iq-internet.com/ to see who is unhappy that I'm
>a step ahead.
Well, aren't /you/ the bad-ass.... :)
"Restriction of interstate commerce", indeed. Like it's their right
to annoy us. The shoe on the other foot must be a bit tight, though;
it obviously pinches... <g>
--
* Any unsolicited commercial e-mail and/or the inclusion of my user-id
in any mailing list without my express prior written approval,
including the receipt of a mass e-mail message and/or the unauthorized
reselling of this user-id to mailing list vendors, will be met with a
complaint to your internet provider.
--=+=+=+=+=+=+=+=+=+=+=+=+=+= Wiz is =+=+=+=+=+=+=+=+=+=+=+=+=+=--
mcraig[at]webaccess[dot]net (reply-to must be modified)
"Don't need no charge card; just give me a Die Hard...."
Ronald sez: Please use the <> bracketed Reply-To: address below. So Sayeth Guilmette
>> It's not free. Period.
>
>It's so close to free _for them_ that it might as well be free.
>
>You're accepting messages from random people around the Internet. You
>are not charging them for your reading time, or even a tiny fraction of
>your reading time.
>
>You are therefore _gambling_ that the messages will be worthwhile.
>
>Some of the random people are spammers taking advantage of your gamble.
>You lose.
>
>automatically identify which random people are spammers. This is doomed
>to failure.
Well, if you are speaking of news spam, then I would have to agree.
E-mail spam is very different however, and you _can_ very easily ``cull''
the identities (or at least the alleged identities) of E-mail spammers.
The process is quite simple.
Assuming that you are a UNIX sysadmin, just edit your /etc/aliases file
so as to create say three or four dummy addresses in your domain, all
alises to some dummy account which only exists so that there will be
a mail drop file for the three or four aliases you have created. Now,
once a week, make three or four forged posts from these ``pseudo-accounts''
on your system to alt.spam... or to some other randomly selected newsgroup.
Then just sit back and wait. After a short while, you will begin to get
sets of three or four duplicate E-mails in the drop box. (If you had a
smart program to do the work you wouldn't even have to manually/visually
check for the duplicates yourself.) Each set of duplicates which arrives
at the drop box will have an envelope from addresses which indicate the
current (most probably forged, but hopefully at least unique) identity
of your latest E-mail spammer.
>As soon as an automated mechanism becomes popular, spammers
>will subvert it. Time wasted and nothing to show for it. Security
>through obscurity, without the obscurity.
I agree that spammers will _eventually_ subvert any and all _filtering_
that you might try to apply to their ouput. (The keyword there is
``eventually'.) However E-mail spammers, at least, will just never
be able to escape the kind of _detection_ I have described above
unless they simply give up what they are doing.
So the real problem... for junk E-mail at least... is just keeping the
filters actually one step ahead of the spammers at most sites and at
most times. (Right now, the filters that various people use are almost
always one step _behind_ the latest forged identities that the spammers
are using today.)
The obvious solution is to run a fully automated detector such as the
one I have described, and then have it broadcast any new identities it
collects _immediately_ (or at least very quickly) to filters operating
at a substantial percentage of the hosts comprising the rest of the
Internet, thereby effectively ``locking out'' further email messages
from the same source to those other sites before most of the additional
spam E-mail messages in question even start arriving at those other sites.
If such a system were put in place, the E-mail spammers would eventually
see that for every 100,000 messages they put out, they get 99,000 bounces
back. After that, it would just be a matter of time before they all would
just dry up and blow away... like so many autumn leaves.
--
-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg(at)monkeys(dot)com ----------------------------------------
------ Copyright (c) 1997 by Ronald F. Guilmette; All rights reserved. -----
Tim Smith
D. J. Bernstein <d...@koobera.math.uic.edu> wrote:
>As an MTA implementor I'm sick of listening to the fantasy that we can
>automatically identify which random people are spammers. This is doomed
>will subvert it. Time wasted and nothing to show for it. Security
>through obscurity, without the obscurity.
We can automatically identify spammers who won't put their money where their
mailer is, although it does require a lot of cooperation among non-spam
sites to bootstrap:
1. Non-spam sites form an association, and this organization registers a
certification mark that can be applied to postings and email originating
from sites that meet the associations anti-spam/anti-UCE standards.
2. Member sites impose a limit on outgoing email and postings. The limit
is large enough to not impact most "ordinary" net users. Users who need
to send more mail or post more messages are required to pay a deposit.
3. Each mailing or posting over the limit causes $.50 to be deducted from
the deposit. When nothing is left, no more mail or postings are allowed.
The user must put in more money to continue mailing, or wait for a credit
(see item #4, below).
4. One week after each email or posting goes out, the $.50 is credited back
to the user *if* there has been no complaints about spam/UCE. E.g., if I
send UCE to 10,000 people, $5,000 is taken from my deposit. If 5,000 of
the recipients complain, and 5000 say nothing, I get $2,500 back one week
later, and $2,5000 is permanently gone.
5. Mail and posting from member sites includes the certification mark in
the header. Non-member sites that put it in the header get sued.
Users who don't want UCE put in mail filters that drop everything that is
not from someone they know unless it has the certification mark in the
header. They might still receive UCE, but then they can complain and
know that they just hit the sender for $.50.
--Tim Smith
D. J. Bernstein
Guilmette wrote:
> The obvious solution is to run a fully automated detector such as the
> one I have described, and then have it broadcast any new identities
``Identities''? Get real.
> If such a system were put in place, the E-mail spammers would eventually
> see that for every 100,000 messages they put out, they get 99,000 bounces
> back.
No. They'd start generating messages from random sender addresses.
Whoops, looks like the detector got a message from r...@monkeys.com!
Let's bounce all messages from that address. Brilliant.
Alec Muffett
d...@ripco.com (David Richards) writes:
> One idea I've been too busy to implement right now is a (procmail based)
> filter that keeps two lists of mail addresses:
>
> 1. Addresses you NEVER want to accept mail from, may include
> regular expressions. Mail with these addresses ANYWHERE in the
> headers is discarded.
>
> 2. Addresses you ARE willing to accept mail from.
> (Mail that matches this list is automatically accepted)
...
> Comments?
I must admit I implemented something similar to this in the package I
wrote to remove spam from my homebound mail feed (why waste the
bandwidth with endless MMF postings and similar junk?)
I must admit to being quite pleased; the s/n ratio is back to, ooh,
1991 levels - maybe 1992.
In short: the method works.
- alec
(ps: if anyone wants to take a look at it, it's called "SnarfNews" and
is at the site below; not just another "slurp" clone, it also does
article relaying, general spam filtering, batching/unbatching and
transmission via e-mail, encrypted batch transmission (via PGP),
mail<->news gatewaying, etc... http://www.users.dircon.co.uk/~crypto/ )
--
# If you e-mail a reply to this message, please modify the "To:" address.
# alec muffett, oxford, uk - http://www.users.dircon.co.uk/~crypto/
# below: password cracker in one line of perl; echo guess | perl [args]
perl -nle 'setpwent;crypt($_,$c)eq$c&&print"$u=$_"while($u,$c)=getpwent'
Frederick D. Kass
Mike Cohen (dje...@sprynet.REMOVE_TO_REPLY.com) wrote:
> This is one of the best anti-spam sites I know of - it has a very useful
> form which lets you do a dig, traceroute, whois, and use other tools for
> identifying spammers & figuring out who to complain to. Everyone should be
> grateful to Julian (btw, I ran into his filter when I tried to thank him
> via email ;-).
This idea reminds me of those phone devices which require you to have a
passcode inorder for your call to go through to the phone number.
At first glance this seems like a good idea. However, I can't think of a
week I haven't gotten a call from someone I don't ussually talk to, who I
was glad they called (i.e. old lost friends, Police dept., someone offering
me a job, etc.). This same idea goes for e-mail, most of us get a
lot of old friends, security updates (even nice letters from people you
don't know :) and such from people that would not otherwise know your code.
You could stop spammers by not getting an e-mail account too! The best
UNIX security is not to own a UNIX box...
Stop spammers, don't stop open communications...
-Fred
Seth Breidbart
In article <5brgub$f...@samba.rahul.net>,
Rahul Dhesi <c.c....@13.usenet.us.com> wrote:
>This is the old arms race which was documented way back by Jules Verne:
>They make bigger cannons, I make stronger sheilds. All I want to do is
>be a step ahead of them, so they go and bother somebody else.
>
>See http://www.iq-internet.com/ to see who is unhappy that I'm
>a step ahead.
They seem to be claiming that you're committing various felonies
(including piracy; I didn't know rahul.net was on a boat). That seems
actionable to me (at least in some states, accusation of a felony is
libel per se and entitles the victime to damages). You could make
yourself very popular by suing them out of business.
Seth
Douglas G. Henke
In article <1997Jan1820...@koobera.math.uic.edu>
> automatically identify which random people are spammers. This is doomed
> to failure. As soon as an automated mechanism becomes popular, spammers
> will subvert it.
I agree with you, wrt to the receiving side of things. (However, I've
enjoyed some success by making sure everyone has to do at least one thing
manually before sending me mail. Hypothetical machine intelligence aside,
this should be hard to subvert on a large scale.)
What about the sending end? If I were an ISP, I would make sure of the
following:
1) I don't relay mail which is neither from nor to one of my
customers.
2) I don't relay multiple messages with largely the same content
from any of my customers.
3) I don't route packets from my customers to the SMTP port of
anything.
Unless I am missing something, that should go a long way toward keeping
my site from being a source of UCE, even if one or more of my customers
is a spammer. (Depending on the implementation details of (2), there may
be room for subversion. There is also the question of how to handle mailing
lists, which are in essence *solicited* mail spams.) Would doing the above
break anything useful?
If enough big providers started doing something like that, it would cut
down on the number of UCEs we get from people who are either just clueless
enough to not know better or are moving from one disposable account to
the next.
Providers who didn't would become known as safe harbors for UCE, and
could be dealt with much the same as they are now (i.e. don't pass their
packets, or use tcp-wrapper to hand them to something that spews
gibberish when they try to connect to your SMTP port).
--
Headers munger to avoid email spam. Mail to henke at phoenix dot net.
D. J. Bernstein
In article <5bu3gq$l0$1...@brokaw.wa.com>, Tim Smith <t...@coho.halcyon.com> wrote:
> Users who need
> to send more mail or post more messages are required to pay a deposit.
Yup, the situation changes dramatically when you demand prepayment.
You can eliminate the need for central coordination in this solution by
reducing the threshold to 0. Then the rule is simply ``you prepay the
recipient, and he decides how much to refund to you,'' for each message.
Roger Books
It really looks to me like the only way to deal with this is on the
ISP side, not the recipient side. The ISP needs to not allow e-mail
from inside->outside their firewall except through their server. Most
of the ISP's customers use them as a smart forwarder anyway, you just
force everyone to use them as a smart forwarder. At this point the
ISP checks for excessive e-mail coming from the individual.
If we all did this most of the mass UCE's would go away. Only those
sites that did UCE's as a main business would not, and they could easily
be blocked.
Obviously you would need to be able to exempt certain users, for instance
people hosting large mailing lists. You would also need to have written
policy so that the UCE-ers wouldn't have a legal leg to stand on.
Roger
Scott Norwood
In article <oau3ocj...@ayesha.krall.org>,
Douglas G. Henke <he...@ayesha.krall.org> wrote:
>
>What about the sending end? If I were an ISP, I would make sure of the
>following:
> anything.
>
#3 probably would. If I set up my own mail server (which I probably would,
partly because I'm a bit of a geek, and partly because I have a perverse
fondness for /etc/sendmail.cf, then it would be totally useless if I
couldn't send mail anywhere except locally. Also, you're preventing
folks from telnetting to port 25 in order to issue a 'VRFY'/'EXPN',
which are both legitimate uses for connecting to the sendmail port.
--
<html><head><title>Down with HTML news postings!</title></head><body>
<h1><blink>If this line blinks, then it's time to get a newsreader that
doesn't encourage HTML news posting! There are many that are better
than Netscape or IE; try trn!</blink></h1></body></html>
Julian Byrne
Frederick D. Kass wrote:
>
> Mike Cohen (dje...@sprynet.REMOVE_TO_REPLY.com) wrote:
> > This is one of the best anti-spam sites I know of - it has a very useful
> > form which lets you do a dig, traceroute, whois, and use other tools for
> > identifying spammers & figuring out who to complain to. Everyone should be
> > grateful to Julian (btw, I ran into his filter when I tried to thank him
> > via email ;-).
You're welcome. ;-)
> This idea reminds me of those phone devices which require you to have a
> passcode inorder for your call to go through to the phone number.
>
> At first glance this seems like a good idea. However, I can't think of a
> week I haven't gotten a call from someone I don't ussually talk to, who I
> was glad they called (i.e. old lost friends, Police dept., someone offering
> me a job, etc.). This same idea goes for e-mail, most of us get a
> lot of old friends, security updates (even nice letters from people you
> don't know :) and such from people that would not otherwise know your code.
Um, this isn't equivalent at all. The equivalent would be if, when
somebody
rang your phone for the first time (as determined by caller ID), they
got
verbal instructions to dial a code (an extension?), thus blocking
computer
generated telemarketting calls but allowing a real live person to
trivially
get through.
> You could stop spammers by not getting an e-mail account too! The best
> UNIX security is not to own a UNIX box...
Yes, the most secure Unix box is a pet rock. It's a bear to get
X-windows
going on it though. ;-)
I think you're seriously overestimating how much the 'bot inconveniences
a person trying to contact me for the first time. In practice it's just
not that big a deal. Philosophically I think it's appropriate that the
first communication a person makes with somebody should be a little
more difficult than regular correspondence and if it means the net can
be made espam free with no legislation then I'm all for it.
> Stop spammers, don't stop open communications...
*YES!* That is one reason why I dislike conventional filtering,
because if it makes a mistake, and it will, mail could be lost. The
'bot will only lose email if the mail system is broken and in addition
minimizes the noise (spam and throwaway email) that reduces the value
of communication.
Conventional filtering is a short term stop gap and it's time people
stopped wasting time on it, for the reasons Dan has already mentioned
in his usual inimitable style ;-). The way I'd put it is to say that
when you publish your email address on the net you're allowing
any one of millions of people, including a subset of spammers and
kooks, to contact you. They all have equivalent technical resources.
*Anything* an average netizen can do a spammer can do better, because
they have a financial incentive to do so. It's only when you start
`charging' them something, in this case person time/contact, will the
spammer lose that financial incentive.
Julian Byrne <http://kryten.eng.monash.edu.au/gspam.html>
(Apologies for the delayed reply - the US-Australian newsfeed is slooow)
Douglas G. Henke
In article <5c6buk$o...@nyx10.cs.du.edu> snor...@nyx10.cs.du.edu
(Scott Norwood) writes:
>> [ Douglas Henke's proposal that ISPs not route packets from their customers
>> to SMTP ports in the outside world as part of a larger policy to stop
>> UCE at the point of origin. Would this break anything useful? ]
>
> #3 probably would. If I set up my own mail server (which I probably would,
> partly because I'm a bit of a geek, and partly because I have a perverse
> fondness for /etc/sendmail.cf, then it would be totally useless if I
> couldn't send mail anywhere except locally.
1) Not so; configure your MTA to relay all non-local outbound mail through
a mailhost at your ISP (whose SMTP port you *can* see, but where the
anti-mailspam gremlins live and would getcha if you tried to be evil).
That's the whole point.
2) I run my own mail server too, for largely the same reasons.
3) Look at the newsgroup to which you are posting. If we weren't all "a
bit of a geek" we wouldn't be here.
4) Re: sendmail: you poor bastard. Get qmail now and prepare to GRAB YOUR
HEAD like a STUNNED MONKEY because of how much more sense it makes.
> Also, you're preventing folks from telnetting to port 25 in order to
> issue a 'VRFY'/'EXPN', which are both legitimate uses for connecting to
> the sendmail port.
Here, you have a point. Perhaps run a proxy that would allow connection
to SMTP ports in the outside world, but would disallow certain commands
(like DATA). You sometimes need RCPT because there are brain-damaged
mailers where VRFY and EXPN are broken but RCPT gives you an immediate
indication of whether an address is righteous or bogus.
--
Headers munged to avoid email spam. Mail to henke at phoenix dot net.
Roger Books
Scott Norwood (snor...@nyx10.cs.du.edu) wrote:
: In article <oau3ocj...@ayesha.krall.org>,
: Douglas G. Henke <he...@ayesha.krall.org> wrote:
: >
: >What about the sending end? If I were an ISP, I would make sure of the
: >following:
: > 3) I don't route packets from my customers to the SMTP port of
: > anything.
: >
:
: #3 probably would. If I set up my own mail server (which I probably would,
: partly because I'm a bit of a geek, and partly because I have a perverse
: fondness for /etc/sendmail.cf, then it would be totally useless if I
: folks from telnetting to port 25 in order to issue a 'VRFY'/'EXPN',
: which are both legitimate uses for connecting to the sendmail port.
VRFY/EXPN is rapidly becoming worthless as it is disabled on so many servers.
As for the other part, well, oh well.
This is just a stopgap measure anyway. When comcast is running cable modems
to all of Tallahassee do you really think they are going to be able to
force everyone to use the same forwarder? And that's Tallahassee, I hate
to think what NYC is going to be like.
Roger
Ian Leicht
Greetings. I too have developed a spam filter. It can be found at my Netizens
Against Gratuitous Spamming site (http://axxis.com/~ian/nags).
I took a different approach because I feel that while this method will be
virtually spam proof, the price that must be paid for it is too high. Spam costs
us in two ways: online time/storage and inconvenience. A spam filter that
creates inconvenience to anyone new who emails you may not be that much better
than the problem.
I've been talking with someone else who has developed a filter
(http://www.io.com/~johnbob) and he seems to have done some interesting things.
He looks at a number of things that indicate but do not "prove" that a piece of
email is spam. If there are enough indications that an "unknown" piece of mail
is spam (i.e. it passes a certain score threshold) then it is marked as spam and
rejected.
Right now, my tactic is to maintain a list of spamming sites and then have an
exceptions list for your friends at that site. This does requrie people to add
their friends in which is an inconvenience. I do like the idea of automagically
adding the email addresses of anyone you send mail to to some sort of an okay
list.. but HOW COULD THIS BE DONE?.... I use POP to get to my mail...
>How it works:
>- Addresses on a `go' list are delivered as usual.
>- Any `unknown' address is bounced with a note saying that the sender
> needs to put a code in the `Subject' heading and their email will
> get through.
>- Any address I send to is automatically placed on the `go' list so
> that anybody who replies to me never sees the 'bot.
>Downside:
>
>- People contacting me for the first time have to put a code in the
> subject heading.
-------------------------+--------------------------------------
Ian Leicht | Netizens Against Gratuitous Spamming
Personal: i...@axxis.com | URL: http://axxis.com/~ian/nags/
| Evolution: love it or leave it
Clifton T. Sharp, Jr.
>
> "Restriction of interstate commerce", indeed. Like it's their right
> to annoy us. The shoe on the other foot must be a bit tight, though;
> it obviously pinches... <g>
A look at the page a few minutes ago shows that the reference to rahul.net
is gone. Nothing there but a notice that the page is under construction.
--
+----------------------------------------------------------------------------+
| Cliff Sharp | If tin whistles are made of tin, what do they make |
| WA9PDM | foghorns out of? --Lonnie Donnegan |
+----------------------------------------------------------------------------+
Gyorgy Barna
There could be defense against high volume E-mail spam.
The problems:
1) Spammers can send E-mail which has legitimate `From:' address
and it can be different in every letter.
2) They can send different text in each letter. (Like making two
versions of every sentence thus automatically generating 2^n
messages.) But the _patterns_ in the text could be identified.
One can rely on the cooperation of:
Yes: some other sites.
No: all other sites.
No: most users/senders.
Versions for defense I know:
A) Automatically identifying spam letters as spam, based solely on
content. Can block legitimate mail, can allow spam to get through.
B) Filtering on sender. Should be used, but far not enough.
C) Checking the identity (validity) of the sender. Generally does
not work, _and_ can be cheated (see (1) above).
D) Requiring every new sender (new to _this_ site) to include a given ID
to the `Subject:' line and resend; outgoing `To:' addresses are
automatically appended to the `allowed-through' list. Perfect solution
on one site, unacceptable on the other. (What if I send request to
in...@zizi.com and got reply from Some...@zizi.com? They'll hardly
try the second time.) (From D. J. Bernstein <d...@koobera.math.uic.edu>
in <1997Jan1820...@koobera.math.uic.edu>.)
E) Requiring _every_ site to validate the sender if the E-mail comes from
their domain, and to do forwarding only for trusted hosts. This could
work on an ideal world, but there could be broken/ignorant sites and
the spam gets through. (Steve Watt <{root,steve}@Watt.COM> in
<E4D9A...@Watt.COM> thinks so too.) (A modification of this is that
for every outgoing E-mail the ISP requires a small amount of deposit,
and gives it back if no complaint arrives within a week. From Tim
Smith <t...@coho.halcyon.com> in <5bu3gq$l0$1...@brokaw.wa.com>.)
F) Spamtrap. Setting up fake (but legitimate looking accounts) and using
them when posting (otherwise real) news articles; giving out them
through `identd' when surfing the net; requesting `sendmail' to give
out them through `VRFY' and `EXPN'; etc. If an E-mail arrives to a
fake address, that _could_ be a spam. (This one comes from Ron
Guilmette, <rfg(at)monkeys(dot)com)> in
<5bt3in$bal$1...@coredump.monkeys.com>. I mean the idea, not a spam :-)
From the above (B) should be used -- it's `cheap' --, (E) should be
enforced -- but it'll always have holes --, but only (F) could be used
transparently, automatically and reliably.
The plan:
i) Participating sites setup spamtrap accounts, and take the trouble
to spread their E-mail addresses throughout the Internet. (They
should do it in a low volume like 1:1000 ratio -- still enough to
trap the spams, and in general they should not cause more problems
than they try to solve.)
ii) Some of the sites get E-mail on a spamtrap account. They send them
to a central authority (CA).
iii) CA recognizes that some of them are very similar to each other (or
to an earlier human-identified spam) thus identifying them as spam.
(Should make special care for mailing lists, etc.?)
iv) CA sends out an auto-alert with samples/algorithms/statistics.
Sites automatically set up the new filters.
The weak points are (iii) and (iv). What METHOD recognizes automatically
that two messages are similar (essentially the same), and how to do the
filtering on every site?
The METHOD. (I'm not suggesting this, just show that it can be done.)
In an article (in BYTE? in the 1980's?) they proposed an algorithm for
searching in text databases. A text can be split into 3-letter sequences,
like "my home" into "my ", "y h", " ho", "hom", "ome". The statistics
of the more frequently used triplets can be characteristic to the topic,
maybe even more characteristic to the text itself. (Words like "the",
"in" should be removed first.)
Spammers new line of attack could only be:
a) Doing more sophisticated automatic generation of the text so the
METHOD can be fooled. But if CA has a good METHOD and enough sample
letters to extract the common features, it _has_ an edge.
b) Creating more versions of the original letter, and/or lowering the
volume. Above (below) a certain level it is not a spam any more.
c) Spammers might flood the net with fake spams (yes), so CA sends out
too many alerts so sites disable it. Probably, something could be done
against this. (Now, if someone hacks CA and thus installs completely
blocking filters in every sites...wooo.)
d) How about multimedia mail, putting the text into pictures with random
background? Then one can start using OCR...
e) I can't think anything else, can you?
George
Blain Nelson
Michael Booye wrote:
>
> uce-de...@monkeys.com (Ronald sez: Please use the <> bracketed Reply-To:
> address below. So Sayeth Guilmette) wrote:
>
> }Now, once a week, make three or four forged posts from these
> }``pseudo-accounts''on your system to alt.spam... or to some other
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Who will, of course, be ever so thrilled when every mail-hosting domain in
> the world starts dropping their little bot-baits all over USEnet.
>
Yeah, but that can be adjusted slightly -- make legitimate posts under
the fake names to groups you would be posting to anyhow. No additional
bandwidth spent, and the folks in the group just get used to you posting
with different names (one userid per group wouldn't be difficult).
Take care,
Blain
Tsu Do Nimh
ba...@sunserv.kfki.hu (Gyorgy Barna) wrote:
>There could be defense against high volume E-mail spam.
>The METHOD. (I'm not suggesting this, just show that it can be done.)
>In an article (in BYTE? in the 1980's?) they proposed an algorithm for
>searching in text databases. A text can be split into 3-letter sequences,
>like "my home" into "my ", "y h", " ho", "hom", "ome". The statistics
>of the more frequently used triplets can be characteristic to the topic,
>maybe even more characteristic to the text itself. (Words like "the",
>"in" should be removed first.)
There are existing text analysis programs being used to
identify manuscripts of dubious origin: they take a known work by
the author in question, analyse the "style" and compare it to the
manuscript in question for points of similarity.
Compared to literary works, UCE should be a piece of cake. The
first indicator is the number of e-mails with the same origin.
The presence of the same address or contact e-mail address, or
phone number (or very close variations), and words about the site
or product being promoted: "downline", "income", "financial
security", "free" ... all a tipoff. You could create weighting
scale -
>Spammers new line of attack could only be:
>a) Doing more sophisticated automatic generation of the text so the
> METHOD can be fooled. But if CA has a good METHOD and enough sample
> letters to extract the common features, it _has_ an edge.
They still have to produce a readable, coherent letter, and
there are limits to the number of synonyms for "get rich" that
the recipients will understand. This would require a lot of
work, custom-crafting every UCE in multiple versions of using
a "babbleizer" on certain words would still leave identifiable
chunks.
>b) Creating more versions of the original letter, and/or lowering the
> volume. Above (below) a certain level it is not a spam any more.
But it's still UCE: unsolicited commercial e-mail, regardless
of the number.
>c) Spammers might flood the net with fake spams (yes), so CA sends out
> too many alerts so sites disable it. Probably, something could be done
> against this. (Now, if someone hacks CA and thus installs completely
> blocking filters in every sites...wooo.)
A flood of "fake spams?" A flood is a spam.
>d) How about multimedia mail, putting the text into pictures with random
> background?
Would be too damn big to read! And would slow the sender down
too much ... they would increase their sending time way too much.
Have to raise their prices.
Callie
Cal...@writepage.com | http://www.writepage.com
(the real place to e-mail)| Genre Fiction Publicity
Ian Stirling
Douglas G. Henke (he...@ayesha.krall.org) wrote:
: In article <1997Jan1820...@koobera.math.uic.edu>
: d...@koobera.math.uic.edu (D. J. Bernstein) writes:
: > As an MTA implementor I'm sick of listening to the fantasy that we can
: > automatically identify which random people are spammers. This is doomed
: > to failure. As soon as an automated mechanism becomes popular, spammers
: > will subvert it.
: I agree with you, wrt to the receiving side of things. (However, I've
: enjoyed some success by making sure everyone has to do at least one thing
: manually before sending me mail. Hypothetical machine intelligence aside,
: this should be hard to subvert on a large scale.)
: What about the sending end? If I were an ISP, I would make sure of the
: following:
: 2) I don't relay multiple messages with largely the same content
: from any of my customers.
Ohhh, I'm a spammer, I'd Lurve to see you do this one.
I simply setup a quick program to pick from n alternatives to each
scentance/word, and put that in the body, same idea in the subject.
Now, let's take a mail system handling a decent amount of mail, say
500K messages a day.
To get this to work, you need to store a users outgoing mail for x days,
run a non-trivial program over all the mail you have in the x day buffer.
How much will this increase load, twice, more?
: Providers who didn't would become known as safe harbors for UCE, and
: could be dealt with much the same as they are now (i.e. don't pass their
: packets, or use tcp-wrapper to hand them to something that spews
: gibberish when they try to connect to your SMTP port).
Ok, let's take my ISP, the only services that are officially supported
are the ability of the modems to pick up the phone, the boxes they are
connected to to gateway you'r packets onto the internet, and also email.
I'm currently running linux, outgoing mail being smarthosted by my ISP,
but i'm about to change that to attempt direct delivery first.
Basically, each of 80000 customers has there own internet node, along
with IP#, postmaster, 5Mb webspace, on a virtual host. They are connected
by everything from 2400 modem, to 128K leased line and up.
The vast majority of these sites would not send UCE, as most of them are
one user per site.
: --
: Headers munger to avoid email spam. Mail to henke at phoenix dot net.
Ian Leicht
On Wed, 22 Jan 1997 19:08:52 +1100, Julian Byrne
<Julian...@eng.monash.edu.au.DELETE_THIS> wrote:
>I think you're seriously overestimating how much the 'bot inconveniences
>a person trying to contact me for the first time. In practice it's just
>not that big a deal. Philosophically I think it's appropriate that the
When my mail filter rejects someone's mail, it sends them a message
explaining why their mail was rejected and includes instructions on how
to get a piece of mail through to me (basically they just need to
use a phrase in the subject) -- even though this is pretty straightforward,
it still seems to confuse people quite a bit.
>*YES!* That is one reason why I dislike conventional filtering,
>because if it makes a mistake, and it will, mail could be lost. The
My solution to this is to put all rejected mail into a junkmail folder and keep
logs of all the filters activity. If I see any mail that was rejected that
doesn't seem like junk mail (ie from the subject or sender) I usually
take a look at it
>kooks, to contact you. They all have equivalent technical resources.
>*Anything* an average netizen can do a spammer can do better, because
>they have a financial incentive to do so. It's only when you start
>`charging' them something, in this case person time/contact, will the
>spammer lose that financial incentive.
I disagree with this. Most of the spammers don't know much about the internet at
all. They have purchased some sort of spam generating product sold by some of
the few people that are competent. Right now at least, we can evolve
considerably faster than the spammers.
A strategy that I think would be very effective in overcoming spamming without
using the "caller ID" approach is to establish a "trust web". Since it takes a
finite amount of time for spam to propgate through across the net, if someone in
the first 10,000 is able to file an alert at a trust node, this could
automagically alert the other members mail filters to reject the mail when it
comes to them. Suggestions? Comments?
>
>Julian Byrne <http://kryten.eng.monash.edu.au/gspam.html>
>
>(Apologies for the delayed reply - the US-Australian newsfeed is slooow)
-------------------------+--------------------------------------
Robert E. Maas
<<A strategy that I think would be very effective in overcoming
spamming without using the "caller ID" approach is to establish a
"trust web". Since it takes a finite amount of time for spam to
propgate through across the net, if someone in the first 10,000 is able
to file an alert at a trust node, this could automagically alert the
other members mail filters to reject the mail when it comes to them.>>
I proposed something like this last Summer. My idea was to catch
mass-mailing, so each incoming message would automatically generate a
brief report to the master trust node giving some sort of hash or other
characteristic of the e-mail, and if the master trust node gets a whole
bunch of reports of the same exact hash then it's marked as
mass-mailing and all the nodes that reported it already are then
notified to reject it as fast as possible after the mass-mail threshold
has been reached, and any node that reports it later is immediately
notified to reject it. In this way the threshold would be
content-independent, just like BI-based Usenet cancellation, and fully
automatic, nobody need ever manually read mass-mail and decide it's
bad, except the very first few who happen to check their mail before
the threshold is reached.
Douglas G. Henke
In article <1997012613...@mauve.demon.co.uk> Ian Stirling
<ro...@mauve.demon.co.uk> writes:
> [ my suggestion, which included among other things: ]
> : 2) I don't relay multiple messages with largely the same content
> : from any of my customers.
>
> Ohhh, I'm a spammer, I'd Lurve to see you do this one.
Sigh. Let's see how many people take that literally and out of context,
and end up flaming you as a result.
> I simply setup a quick program to pick from n alternatives to each
> scentance/word, and put that in the body, same idea in the subject.
They already do that. There are a number of good ways to detect that,
starting with Markov-chain analysis with words equivalenced through an
online thesaurus.
For your simple scheme, just identifying the parts of speech and looking
for patterns there would be sufficient.
As a previous poster has already pointed out, there are programs already
written whose purpose is to identify the authors of unknown text based on
samples of known-author text. This is a much harder problem than identifying
UCE.
Why don't you go ask clewis about the same problem wrt Usenet spam?
Anyway, the point is not total elimination of the possibility of spam.
Getting rid of half the UCE is a worthwhile goal, too. It's like the locks
on your doors; you don't have to be impossible to break in to, you just have
to be more secure than your neighbor.
> Now, let's take a mail system handling a decent amount of mail, say
> 500K messages a day. To get this to work, you need to store a users
> outgoing mail for x days, run a non-trivial program over all the mail
> you have in the x day buffer.
Wrong, but thanks for playing.
1) Let's say for the purpose of argument that my window is 90 days. The
only accounts I even need to watch are those which send a *lot* of
messages within the window. (More than 500?) For a typical ISP, that
should be a small fraction of the customers.
2) Of those who are over the threshold, how many are mailing lists (which
I've already noted need to be excepted) or autoresponders, which could
be detected (they only send out mail to people who send mail in) and
skipped?
3) If I get 45M messages in the 90-day window, I don't have to do 45M ^ 2
comparisons. I only have to compare messages originating from the same
account with one another. (Yes, this means if the detection threshold
were N, a spammer could get M accounts and send M(N-1) messages without
getting automatically detected. He's still out on his ass the minute
I get complaints, and he's spent M times as much to get out fewer spams
than he would have ordinarily using one account.)
> How much will this increase load, twice, more?
Only if it's the same guy who's sending those 500K messages each day. If
that is true, what are the odds he is a spammer? What are the odds that he
bears watching? For the latter, unity.
Anyway, yes, this would cost. It would cost disk space and CPU and
time for administrators to maintain it. And it would be hard to
justify this cost to the people who pay the bills, as the short-term
the direct benefit is to the net as a whole, not to the particular ISP
who does it.
On the other hand, spam is a real problem and IMHO, anything that can
make a dent in it without making life harder for Joe User is worth
some amount of cost.
> Ok, let's take my ISP, the only services that are officially supported
> are the ability of the modems to pick up the phone, the boxes they are
> connected to to gateway you'r[sic] packets onto the internet, and also
> email.
Sounds pretty much like a decent model for an ANSI standard ISP, insofar
as how to cut UCE is concerned. (Some ISPs offer stuff like web space,
but that is tangential to the topic at hand, yes?)
> I'm currently running linux, outgoing mail being smarthosted by my ISP,
> but i'm about to change that to attempt direct delivery first.
Same here. Try qmail, I've had very good luck with it (and it does direct
delivery if you want). What does this have to do with the topic at hand?
> Basically, each of 80000 customers has there own internet node, along
> with IP#, postmaster, 5Mb webspace, on a virtual host. They are connected
> by everything from 2400 modem, to 128K leased line and up.
>
> The vast majority of these sites would not send UCE, as most of them are
> one user per site.
Gnus flash: most of the UCE I get is from individual morons running some
kind of canned spam-bot on a 'doze box, hooked up per the above. A few of
the rest are running their spam-bot on a shell account. Few of the big
corporate sites are dumb enough to play the UCE game.
----------------
Idea: I think UCE senders are gathering "live" addresses by watching who
sends them "remove" requests. Every time I get spam, I note the address and
keyword for so-called "removal." I then forge remove requests from everybody
who has sent me spam in the past. Ditto twice over for "send more information"
addresses. Let them spam-bomb one another into oblivion. Fuckards.
P.S. Give 'em one anothers' snail mail, voice phone and FAX info, too.
--
Headers munged to avoid email spam. Mail to henke at phoenix dot net.
Roger Books
Ian Stirling (ro...@mauve.demon.co.uk) wrote:
: Ohhh, I'm a spammer, I'd Lurve to see you do this one.
: I simply setup a quick program to pick from n alternatives to each
: scentance/word, and put that in the body, same idea in the subject.
: Now, let's take a mail system handling a decent amount of mail, say
: 500K messages a day.
: To get this to work, you need to store a users outgoing mail for x days,
: run a non-trivial program over all the mail you have in the x day buffer.
: How much will this increase load, twice, more?
OK Spammer (I realize you aren't, just replying as if). I am an ISP that
you want to get hooked up with. I set my firewall so ONLY my mailserver
may deliver mail. You will not be allowed to hook up to anyones port
25 other than mine. (That's step one.)
Step 2, before I allow you to hook up you have to sign a contract. As
part of this contract you will be informed that any UCE's sent through
my server will be billed at a rate of $5 per recipient. I also inform
you that any e-mail coming from a specific individual at a rate of more
than X (say 30?) messages per hour will potentially be checked for UCE
content. If you refuse to pay than we go the way everything else works,
See-You in court for my (you sent out 10K messages) $50,000USD.
: I'm currently running linux, outgoing mail being smarthosted by my ISP,
: but i'm about to change that to attempt direct delivery first.
:
: Basically, each of 80000 customers has there own internet node, along
: with IP#, postmaster, 5Mb webspace, on a virtual host. They are connected
: by everything from 2400 modem, to 128K leased line and up.
Not relevant. If my firewall only allows port 25 connects to and from
one (or specific) host then connections only go to and from that (or those)
host(s). I don't care if there are 80K customers or 8 behind my firewall.
If you want other connectivity, well, that is a different contract.
Roger (Money Talks) Books
David Gerard
On 26 Jan 1997 20:26:21 -0800, Robert E. Maas <r...@one-o.com> wrote:
:[someone]
:<<A strategy that I think would be very effective in overcoming
This would also catch legitimate mailing lists.
I would have problems with all mailing lists requiring central registry
before being able to operate. I bet the lists would too.
--
http://www.suburbia.net/~fun/scn -- email me if it doesn't work for you
http://wpxx02.toxi.uni-wuerzburg.de/~gerard/ (European mirror)
mailto: f...@suburbia.net f...@tertius.net.au
Ian Stirling
Gyorgy Barna (ba...@sunserv.kfki.hu) wrote:
: There could be defense against high volume E-mail spam.
: The problems:
: 1) Spammers can send E-mail which has legitimate `From:' address
: and it can be different in every letter.
3) Spammer joins all mailing lists they can find, listens for a couple of
weeks, extracting user-ID's, then forges mail to the users, purportedly
from the listserver.
: George
Julian Byrne
Robert E. Maas wrote:
> [Spam block proposal based on trap sites and duplicate
identification]
An improvement on current methods but only a delaying tactic.
See this espam I got in my mailbox yesterday :-(
------------------------------------------------------------------
WELCOME TO ALL NEW EZSPAM (tm) v2.1 (Patent pending) !!!!!!!!!!!!
A another fine product from SPAM2000 Enterprises.
All the features of all those other bulk emailing programs *AND*!
- Personalised messages (patent pending) !!!!!
Our email address database includes the context where the address
was harvested from. This can be used to `personalise' your message
eg. Addresses harvested from news posting can include the Subject
heading and if from web pages the web reference. Peoples' full names
obtained from search services. Your message can be phrased so that
ISP's think it is solicited. We even provide data matching services
with conventional media mailing services. eg. Subject: Re: Your
posting in comp.admin.net-abuse.misc.
- Word permute (patent pending) !!!!!
Get past those pesky sites that use automatic recognition of
duplicate email messages to reject your valuable sales message.
*Every* email message you send is different. EZSPAM (tm) uses a
thesaurus to substitute words in your message with the same or
similar meaning. 9 out of 10 messages guaranteed to be meaningful.
eg. Innovative, clever product = New, intelligent must-have.
- Sentence permute (patent pending) !!!!!
Like word permute this advanced feature allows you to have lists of
sentences that are substitutes for each other. eg. We are New World
Inc. -> Millenium 2000 Pty. Ltd was established in 1970.
- Layout permute (patent pending) !!!!!
An advanced algorithm to insert spaces and other extraneous
characters to rearrange the format of your sales message while
leaving the meaning unchanged. eg. A cool new product -> A c001
neew Product!!!
- Phone number permute (patent pending) !!!!!
In combination with call forwarding you can use this advanced
feature to have different phone numbers that are also rearranged
with various combinations of spaces, dashes and brackets making it
impossible to block your important message. eg. +1-800-2468-123 ->
(904) 1 234x333
- Address permute (patent pending) !!!!!
Like phone number permute EZSPAM (tm) can rearrange your postal
address and with forwarding post office boxes can be a valuable
adjunct in your fight to have your important sales message heard!
eg. PO Box 123, Melbourne, Florida -> P.O. 1 23 - Palm Bay, FL
- Header permute (patent pending) !!!!!
Get past those Un-American (tm) sites that reject email messages
from free speech domains. Every email message you send will have a
different source domain and username, selected either from lists
you specify or synthetically generated by EZSPAM (tm) and our
name server from a dictionary on the fly. An added bonus is that
anti-free speech complaints about your valuable sales message will
be distributed all over the net, dispersing the heat.
eg. From: JSmi...@beezlebub.com
- Dynamic relays (patent pending) !!!!!
EZSPAM(tm) dynamically searches for sites on the net that relay
email messages and can use thousands of them in a single run.
Particularly targets all those useful sites that don't verify
incoming email messages.
- Trusted sender (patent pending) !!!!!
Every valuable sales message you send has a `From' address that was
harvested from the same area that the email message is being sent
to. eg. If sending to an address that was harvested in
comp.admin.net-abuse.misc the `From' address will also be an address
harvested from the same news group. eg. From: fk...@mtholyoke.edu
(Frederick D. Kass), To: i...@axxis.com (Ian Leicht)
- ASCII art (patent pending) !!!!!
Avoid filters that do key word search by replacing key words in
your message with ASCII art. eg. "Free Sex!" becomes:
+-- +- +-- +-- -- +-- \ / |
| | | | | | | \ / |
+- +- +- +- -- +- X |
| |\ | | | | / \
| | \ +-- +-- -- +-- / \ *
Many fonts and character combinations available.
- Graphics art (patent pending) !!!!! (Gold edition only)
Give your sales message impact! Avoid key word filter based filters
by sending GIF's and WAV's instead of text. Most net users are now
running MIME compatible email readers and this will make you stand
out in the crowd. Many non-OCR'able fonts and graphics available.
Warning: this may cause slightly higher network overhead.
- IP address spoofing (patent pending) !!!!! (Gold edition only)
The net uses an internal networking protocol call "IP addresses"
that net savvy people can use to track down where you sent your
valuable sales message from. With this feature activated only net
administrators with access to net router logs can track down where
your message came from, making it impossible for the average net
user or ISP to make a complaint to your real ISP without going
through a chain of backbone administrators, even if it's logged,
and it usually isn't. Who'd bother tracking you down? And even
if they do you're long gone!
- Teasers (patent pending) !!!!!! (Gold edition only)
A catalog of one hundred carefully crafted email messages
designed to look like personal email but convincing the
reader to access your web site or autoresponder. Use them
or make your own!
- ISP diversity (patent pending) !!!!! (Gold edition only)
Prefer to avoid the complaints of ISP's? EZSPAM(tm) will
send to only a selected number of addresses per ISP, thus
minimizing the the impact and likelyhood of complaint at
any one ISP.
A wonderful mailing program like this deserves a bullet proof drop
box; and we have just the ISP for you! ezspamiswonderfulisntit.com
- We're based in selected third world sites around the globe.
Low labour rates and no government interference!
- Our WHOIS entries have nothing meaningful in them.
- Our machines are configured so that every traceroute and ping to
our site gives a different result.
- We are set up so we look like we are an ISP of an ISP of an ISP of
an ISP to the outside world.
- All complaints from silly un-american anti-free-speech people
cheerfully acknowledged with a bounce message and ignored.
- If they do eventually work out what's going on we'll just say that
your message wasn't sent from our site so it's not our concern!
You keep your web page and the complainer goes on our hit list!
- Remove requests (if you want them) accepted and ignored or
catalogued.
- Don't want your web page seen by certain sites? Want different
web pages seen by different sites? Let your customers see a sales
message, complainers (we have a list) see something innocuous and
our/your ISP's see something harmless and deceptive.
- Our FINGER operates the same way!
- InfiniteAlias (tm). So your email message can have a different
web page name and email contact address in every message our domain
name, web and mail servers can supply millions of automatically
synthesised aliases for the same site. You can also use this
feature for filter bypassing and customer tracking.
- ComplaintBlock (tm). Complaints from known complainer domains
bounced with an irritating sales message!
- Got a bit of heat on Tuesday? Let us give you a brand new
`net identity' on Wednesday! Millions of domain names and
user names available. Bulk use discount.
- We're set up to bounce mail bombs and `ping of death'. You never
see them! We vigorously pursue SYN and router attacks.
- We are actively looking for MLM'ers. Be close to the head
of a pyramid of thousands of resellers. Contact us today!
SPAM2000 Enterprises is a complete service! We represent the interests
of bulk emailers in all major forums. We create false but plausible
`net identities' to sow dissention among anti-bulk email campaigners.
We send out random meaningless complaints to administrators on the net
so they get sick of it. We talk about free speech and other irrelevant
issues to muddy the waters. 10% of our revenue goes into research
and development to find new and improved methods of advertising your
business!
We pursue all legal avenues to get your valuable sales message heard!
EZSPAM (tm) only $299.95 (standard) or $399.95 (gold).
See http://www.ez137spam.com/ for further information.
Get your EZSPAM (tm) (patent pending) today!
---------------------------------------------------------------------
For the humor impaired: this is a *satire*. It is *not* real (yet).
Unlikely though? I think not. :-( Exaggerated? Not by much. Some
of these things (`personalised messages', `layout permute', `teasers'
and `ISP diversity') are already being used by spammers. Computer
viruses already have full permutation engines. Also, look at the
level of sophistication that conventional advertising is operating
at.
Not much in this post is difficult to do, particularly once
organized crime gets involved. Some people may be unhappy that
I'm advertising these options to spammers. Sorry, but they
know about most of them already. Security through obscurity is
rarely a good idea long term.
The only reason it hasn't happened yet is that only a vanishingly
small percentage of net sites are/were filtering until AOL started
recently. It just wasn't worth a spammer's trouble. Just give it
time. All it takes in one person in the whole world to write
EZSPAM and all of the thousands of conventional filtering
setups that netizens have developed will be for naught.
Conventional filtering is just going to become less and less
effective, make more and more mistakes leading to lost email and
poor communication and eventually sink into the noise. Only full
human level AI, a secretary if you like, can work out where any
particular email message is on the spectrum between junk and
valuable. Even then mistakes are made. Filtering works, but in
the long term only when the sender is cooperating.
The advantage of the challenge-response anti-spam 'bot (CRAB ;-))
is that it places the onus on the sender to have human level AI,
not the recipient and email is not lost or misplaced. CRAB's have
problems but they'll work medium term and the overhead (first time
contact slightly messier) is minimal. Sure I'd like to go back
to when the net was young, netizens could be trusted and anybody
could email anybody with no worries about foolish filters losing
email, delaying email or letting unsolicited junk through and
idiotic CRAB's wasting their time. Those days are gone.
Julian Byrne <http://kryten.eng.monash.edu.au/gspam.html>
Julian Byrne
Ian Leicht wrote:
>
> When my mail filter rejects someone's mail, it sends them a message
> explaining why their mail was rejected and includes instructions on how
> to get a piece of mail through to me (basically they just need to
> use a phrase in the subject) --
Sounds like you're doing pretty much what I'm doing, except you're
emphasising the pre-filtering side of it and I'm emphasising the
challenge-response side of it.
> even though this is pretty straightforward,
> it still seems to confuse people quite a bit.
I haven't had that experience. Perhaps you need to reword your
bounce message?
> >*YES!* That is one reason why I dislike conventional filtering,
> >because if it makes a mistake, and it will, mail could be lost. The
>
> My solution to this is to put all rejected mail into a junkmail folder and keep
> logs of all the filters activity. If I see any mail that was rejected that
> doesn't seem like junk mail (ie from the subject or sender) I usually
> take a look at it
That'll work more or less for now but more and more junk email is
being `personalised'. It won't work long term and the fact that you've
looked at their email message at all, even if delayed, means that
they succeeded.
> I disagree with this. Most of the spammers don't know much about the internet at
> all. They have purchased some sort of spam generating product sold by some of
> the few people that are competent. Right now at least, we can evolve
> considerably faster than the spammers.
Yes and know; I suspect some of the worst current spammers
(eg. Larson) are getting past almost everybody's filters and the
filters they are not getting past are rejecting valid email.
> A strategy that I think would be very effective in overcoming spamming without
> using the "caller ID" approach is to establish a "trust web". Since it takes a
> finite amount of time for spam to propgate through across the net, if someone in
> the first 10,000 is able to file an alert at a trust node, this could
> automagically alert the other members mail filters to reject the mail when it
> comes to them. Suggestions? Comments?
No go. See my next post `SPAMSPEW'.
Julian Byrne <http://kryten.eng.monash.edu.au/gspam.html>
Ronald sez: Please use the <> bracketed Reply-To: address below. So Sayeth Guilmette
In article <32ea194b...@news.planet.net>,
Michael Booye <mbo...@planet.net> wrote:
>uce-de...@monkeys.com (Ronald sez: Please use the <> bracketed Reply-To:
>address below. So Sayeth Guilmette) wrote:
>
>
>}Now, once a week, make three or four forged posts from these
>}``pseudo-accounts''on your system to alt.spam... or to some other
>}randomly selected newsgroup. ^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Who will, of course, be ever so thrilled when every mail-hosting domain in
>the world starts dropping their little bot-baits all over USEnet.
>
>wade through is okay by you, so long as it enables you to keep
>address-collecting UCE out of your domain. A lot more garbage is a
>desirable state so long as a lot more domains can filter UCE.
>
>That about sum it up?
>
>A pox on your house.
I believe that you have seriously misconstrued what I had intended to
say. I'm not sure if you did that deliberately or just due to my own
unfortunate choice of words, but in either case, it appears that you
have chosen to infer the worst possible (and least charitable) inter-
pretation of what I had intended to say.
What I had _intended_ to say was `... randomly selected INACTIVE news-
groups in the alt.* hierarchy.'' (I would have hoped that what I meant
to say would have been obvious to all right-thinking persons, but
apparently the great influx of new people to the net over the past
several years now forces me to be more obvious and explicit when
speaking, rather than taking for granted any given level of under-
standing on the part of the readership of this, or any other news-
group.)
Anyway, from where I sit (and perhaps from where you sit too) there
are TONS of basically unused and long-since abandoned newsgroups
under the alt.* hierarchy... newsgroups which, while still existing
and still propagated, are currently read by no one.
Of course, if the common wisdom of the net indicated that even these
could not or should not be exploited for the advancement of other
utilitarian, useful, and noble goals of the net community, then it
would be just as feasible for me, or you, or _anybody_ to create some
brand new newsgroups (under the alt.* hierarchy) to house the kinds
of UCE troll messages that I suggested could form the basis for an
automated UCE detector. In either case, the fundamental point remains,
i.e. that an automated UCE detector, engineered along the lines I have
previously dscribed, _could_ in fact be built, and that its operation
need not have any noticable negative impact upon any actual human
readers of USENET news.
I certainly hope that this clears up what seems to have been a simple
misunderstanding about how I would propose to design and operate a
fully automated UCE detector... assuming that I was in fact planning to
build and/or operate such a thing. I am not. I have no need of such
a thing. I am getting gobs and gobs of UCE on a daily basis now even
_without_ any intentional trolling for it, thank you.
P.S. A part of your apparent objection to even the idea of intentional
(and perhaps even automated) trolling in newsgroups for UCE seems to
have been that such trolling, if initiated from innumerable separate
Internet sites, would create a rather prodigious amount of `junk'
troll messages in various newsgroups... as indeed it would in such
trolling were initiated from lots of separate sites. The solution
to that problem should be obvious. Only one or a few sites should
be doing this sort of thing, on behalf of the entire Internet. That
site (or those few sites) could and should then make their results
available publically, to the net at large (and preferably in real-time).
This is essentially the NoCEM-for-Email idea that was discussed here
briefly some months ago.
--
-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg(at)monkeys(dot)com ----------------------------------------
------ Copyright (c) 1997 by Ronald F. Guilmette; All rights reserved. -----
Ronald F. Guilmette
In article <1997012719...@mauve.demon.co.uk>,
That is still (and also) a case of forgery. It can be detected, either
by humans or by programs.
Ronald F. Guilmette
In article <32e49...@nomad2.HCSys.com>,
Roger Books <970805022...@mail.state.fl.us> wrote:
>It really looks to me like the only way to deal with this is on the
>ISP side, not the recipient side.
I used to think so too. I have changed my mind. Or rather I should say
that the exponential growth in the numbers of incompetent and/or
malevolent system administrators on the Internet (and scattered all
over the world) has changed my mind for me. No amount of effort,
regardless of how large, will ever get all Internet site adminstrators
to act responsibly. It just ain't gonna happen.
>The ISP needs to not allow e-mail
>from inside->outside their firewall except through their server. Most
>of the ISP's customers use them as a smart forwarder anyway, you just
>force everyone to use them as a smart forwarder. At this point the
>ISP checks for excessive e-mail coming from the individual.
I proposed this in n.a.n-a.m a couple of months ago. It is still a
completely valid and useful technique that _responsible_ system ad-
ministrators may find useful for controling users against whom the
administrators in question have little or no recourse (e.g. like
firing them or throwing them out of school).
But you should have been here when I proposed ``firewalling in'' admin's
_own_ user bases! There were some people who screamed rather irrationally
about meaningless performance issues. And anyway, the bottom line is
that this idea still doesn't do swuat about the most serious part of
the UCE problem... i.e. the vast and growing numbers of _irresponsible_
site administrators (and backbone providers) on the Internet. This
latter (bigger) problem will never go away, and sadly, it forces the
responsibility for a solution to the UCE problem back onto the receiving
end.
Ronald F. Guilmette
In article <5cd3nr$f...@sunserv.kfki.hu>,
Gyorgy Barna <ba...@sunserv.kfki.hu> wrote:
>There could be defense against high volume E-mail spam.
>
>The problems:
>1) Spammers can send E-mail which has legitimate `From:' address
> and it can be different in every letter.
Right, so you must instead try to concentrate on the few things that
the UCEers can vary only slowly and with some difficulty, i.e. the
domain names and IP addresses of the machines which they send out
their crap from. Fortunately, one or both of these useful tidbits
of information is usually/often shown in the Received: headers.
>2) They can send different text in each letter. (Like making two
> versions of every sentence thus automatically generating 2^n
> messages.) But the _patterns_ in the text could be identified.
>
>One can rely on the cooperation of:
>Yes: some other sites.
>No: all other sites.
>No: most users/senders.
>
>Versions for defense I know:
>A) Automatically identifying spam letters as spam, based solely on
> content. Can block legitimate mail, can allow spam to get through.
>B) Filtering on sender. Should be used, but far not enough.
>C) Checking the identity (validity) of the sender. Generally does
> not work, _and_ can be cheated (see (1) above).
>D) Requiring every new sender (new to _this_ site) to include a given ID
> to the `Subject:' line and resend; outgoing `To:' addresses are
> automatically appended to the `allowed-through' list. Perfect solution
> on one site, unacceptable on the other. (What if I send request to
> in...@zizi.com and got reply from Some...@zizi.com? They'll hardly
> try the second time.) (From D. J. Bernstein <d...@koobera.math.uic.edu>
> in <1997Jan1820...@koobera.math.uic.edu>.)
>E) Requiring _every_ site to validate the sender if the E-mail comes from
> their domain, and to do forwarding only for trusted hosts.
Any major site which is _still_ doing mail forwarding for _any_ Tom,
Dick, and Spammy that happens to show up at their port 25 is being run
by blithering idiots. I know. I know. We still _do_ have some major
sites (e.g. Earthlink) which are being run by blithering idiots. What
can we do about these? I have a plan A and a plan B. Plan A is to
just shoot all of the admins at these sites and put them out of our
misery. Given that plan A may be infeasible for technical reasons,
I'll probably go with plan B. Unfortunately, I can't talk about plan
B just yet, but please do believe me when I say that it is vastly
more benign and non-confrontational, and it involves software (but no
guns, knives, axes, or other implements of destruction). It also does
not involve anything that _anyone_ (except UCEers) would take exception
to.
> This could
> work on an ideal world, but there could be broken/ignorant sites and
> the spam gets through. (Steve Watt <{root,steve}@Watt.COM> in
> <E4D9A...@Watt.COM> thinks so too.) (A modification of this is that
> for every outgoing E-mail the ISP requires a small amount of deposit,
> and gives it back if no complaint arrives within a week. From Tim
> Smith <t...@coho.halcyon.com> in <5bu3gq$l0$1...@brokaw.wa.com>.)
>F) Spamtrap. Setting up fake (but legitimate looking accounts) and using
> them when posting (otherwise real) news articles; giving out them
> through `identd' when surfing the net; requesting `sendmail' to give
> out them through `VRFY' and `EXPN'; etc. If an E-mail arrives to a
> fake address, that _could_ be a spam. (This one comes from Ron
> Guilmette, <rfg(at)monkeys(dot)com)> in
> <5bt3in$bal$1...@coredump.monkeys.com>. I mean the idea, not a spam :-)
>
>From the above (B) should be used -- it's `cheap' --, (E) should be
>enforced -- but it'll always have holes --, but only (F) could be used
>transparently, automatically and reliably.
Initially at least, approach (A) and (B) can be used together. Approach
(F) is the ultimate in protection, and as the problem worsens (which I'm
quite sure it will) someone _will_ implement approach (F).
>The plan:
>i) Participating sites setup spamtrap accounts, and take the trouble
> to spread their E-mail addresses throughout the Internet. (They
> should do it in a low volume like 1:1000 ratio -- still enough to
> trap the spams, and in general they should not cause more problems
> than they try to solve.)
It seems that this may not be altogether necessary. Apparently, as a
result of my often vocal opposition to UCE, one or more members of the
loyal opposition (i.e. the UCEers) have taken it upon themselves to
make forged postings, using my _real_ E-mail address, to numerous
newsgroups, especially ones which are frequented by MLMers and those
trying to sell long distance phone services. Thus, my _real_ E-mail
address is already proving to be an invaluable UCE magnet and I have
been getting veritable floods of the stuff for some time now. Unless
someone else wishes to volunteer their services also, I can now declare
that <r...@monkeys.com> is ready to serve as the official spamtrap for
the entire Internet. (1/2 :-)
>ii) Some of the sites get E-mail on a spamtrap account. They send them
> to a central authority (CA).
>iii) CA recognizes that some of them are very similar to each other (or
> to an earlier human-identified spam) thus identifying them as spam.
> (Should make special care for mailing lists, etc.?)
>iv) CA sends out an auto-alert with samples/algorithms/statistics.
> Sites automatically set up the new filters.
I have two disagreements with the above three parts of the plan.
First, there are very few things on the Internet which realy on the ex-
istance of a single Central Authority. Domain names and IP addresses
are certainly the exceptions that prove the rule. The bottom line is
that I see no reason why there should be a single Central Authority,
other than by virtue of the fact that (perhaps) only one volunteer
can be found. If that situation DOES NOT apply however, then I think
that there could be (and perhaps should be) many many Authorities with
respect to junk E-mail... and each site should be free to choose what
Authority or Authorities they wish to rely on. (I believe that the
NoCEM system for junk news is structured essentially the same way.
There may perhaps only be one person or organization actually putting
out NoCEM notifications at the present time, however I believe that
there is nothing inherent in the system which prevents other Authorities
from showing up and offering _their_ advice on what to keep, and what to
discard.)
Second, I have a more technical objection to point (iv) above. I see no
reason to use up bandwidth by performing `push' broadcasting of your so-
called `alerts' to various sites which already have good Internet con-
nectivity. Those sites (at least) can `pull' the alert information from
the Authority Site(s) on a real-time and as-needed basis. Other sites,
e.g. sites served only by UUCP, could also `pull' the alerts from their
chosen Authority Site(s), but they would need to do so via some auto-
responder mail protocol which, unfortunately, would not operate in real-
time... not that the Internet does either anymore these days. (1/2 :-)
>The weak points are (iii) and (iv). What METHOD recognizes automatically
>that two messages are similar (essentially the same), and how to do the
>filtering on every site?
Given that any Authority Site would potentially have a profound influence
on the mail of innumerable other sites, I personally would not trust
_any_ completely automated mechanism to be reliable and fool-proof
enough to completely dictate the judgements of the Authority Site.
Rather, I would expect that any truly trsutworthy Authority Site
would necessarily have a human operator making the decisions as to
what is, and what is not UCE. This is certainly labor intensive
(and therefore sub-optimal) but when you consider that one reliable
human being, doing a good and reliable job of sorting out UCE from
non-UCE could serve as the Authority for ten thousand or a hundred
thousand Internet sites (and perhaps millions of individual users)
it seems a reasonable expanse to pay. If one person spending a few
hours a week, could effectively prevent a million other people from
having to waste time wading through junk E-mail, then it would certainly
be worth it to the net to have that one person around.
>The METHOD. (I'm not suggesting this, just show that it can be done.)
>In an article (in BYTE? in the 1980's?) they proposed an algorithm for
>searching in text databases. A text can be split into 3-letter sequences...
This is a good idea for an automated ``duplicates detector''. Such a
detector would definitely be a nice thing to have, but personally, I
think that just having one intelligent human on duty should be more
than ample as a mechanism for spotting junk UCE. The real problem is
how to get that person's judgements propagated out both quickly and
automatically so that they can be used in automated filters at many
many sites before the judgements themselves become irrelevant and
obsolete.
I don't really want to tip my hand too much here, but let me just say
that I am working on the problem, and hope to have something of value
to share with the net community at some point in the future.
The problem with UCE is not that it is difficult to spot. Indeed,
innumerable people are spotting more and more UCE (in their own
inboxes) every damn day! The real problem is that (at present)
a million or so people may each be individually _forced_ to spot
one particular UCE, over and over again, in each of their respec-
tive inboxes. The way to solve _that_ problem is to improve communi-
cation. Like I said, I have a plan, and I'm working on it.
Ronald sez: Please use the <> bracketed Reply-To: address below. So Sayeth Guilmette
In article <1997Jan2009...@koobera.math.uic.edu>,
D. J. Bernstein <d...@koobera.math.uic.edu> wrote:
>Guilmette wrote:
>> The obvious solution is to run a fully automated detector such as the
>> one I have described, and then have it broadcast any new identities
>
>``Identities''? Get real.
>
>> If such a system were put in place, the E-mail spammers would eventually
>> see that for every 100,000 messages they put out, they get 99,000 bounces
>> back.
>
>No. They'd start generating messages from random sender addresses.
>
>Whoops, looks like the detector got a message from r...@monkeys.com!
>Let's bounce all messages from that address. Brilliant.
Obviously, you have never read a Received: header. If you had, you would
know that obvious forgeries can be easily detected as such... automatically
in fact.
In those cases where the From: address, the Reply-To: address, the Errors-To:
address or even the envelope from address bear no obvious relationship to
the apparent path which was taken by the message on its way to you (and,
in particular, to its apparent starting point) then it is altogether
obvious that the strategy must be different, and that the bounce and/or
complaint messages must be directed either to a suitable sender address
gleened from the Received headers (where possible) or else to postmasters
of sites mentioned in the Received headers, or else they must simply be
dropped on the floor.
Anyway, even in lieu of such intelligence on the part of the filtering
agent, it doesn't really matter much. You just wont get either the
satisfaction of, or the benefits from having been able to clog up the
_real_ sender's mailbox (as he attempted to do to yours). Instead,
he will have just effectively (and indirectly) mailbombed someone else
(assuming that his forgeries point to some other real, deliverable address),
but he could just as well have done that via any one of the innumerable
autoresponders on the net these days anyway. (If some hapless victim
is third-party mailbombed in this way... i.e. by bouncing stuff off of
_any_ sort of auto-responding agent... then it is that victim's responsi-
bility to take up that issue/problem with the actual instigator, and I
would hope that all people who get this done to them would in fact do
that.) Note that adding just one more type of auto-responding E-mail
handler to the net does not really create this problem anew. Various
people already get indirectly mailbombed (either maliciously or inad-
vertantly) due to the presence of, and misuse of other auto-responding
agents which already exist on the net.
Anyway, bottom line is that there is a finite and non-zero percentage of
junk E-mailers who (surprising as it may seem) DO NOT forge their return
addresses. My research indicates that these cases may, in general, be
automatically differentiated from other (forged) cases on the basis of
the information in Received headers, and that bounce messages could
therefore be returned to the original junk sender in many cases.
I will have more to say about this later on.
John C. Randolph
r...@monkeys.com (Ronald F. Guilmette) writes:
>Any major site which is _still_ doing mail forwarding for _any_ Tom,
>Dick, and Spammy that happens to show up at their port 25 is being run
>by blithering idiots. I know. I know. We still _do_ have some major
>sites (e.g. Earthlink) which are being run by blithering idiots.
I just have to throw in a comment here re: earthlink. You should realize
that earthlink is run by Scientologists, who have a definite hostile intent
towards the rest of the internet. I don't take *any* traffic from earthlink,
and I would advise other sysops to do likewise.
Now, Much as I may impugn the mental faculties of anyone taken in by the
criminal cult of $ientology, they're not actually *bilthering* idiots. They
have the mental capacity to mount deliberate, coordinated denial-of-service
attacks against their critics, or the ISP's of their critics, or anyone
who takes alt.religion.scientology in their newsfeed.
For an example of an ISP run by blithering idiots, you have to go to
AOL ;-).
-jcr
Ian Leicht
I wrote:
>:<<A strategy that I think would be very effective in overcoming
>:spamming without using the "caller ID" approach is to establish a
>:"trust web". Since it takes a finite amount of time for spam to
>:propgate through across the net, if someone in the first 10,000 is able
>:to file an alert at a trust node, this could automagically alert the
>:other members mail filters to reject the mail when it comes to them.>>
David Wrote:
>This would also catch legitimate mailing lists.
>
>I would have problems with all mailing lists requiring central registry
>before being able to operate. I bet the lists would too.
Another problem with this sort of a web is that it involves being able to
construct a hash and requries potentially signficant amounts of net.traffic.
My proposal was to have allow people (or perhaps only certain "trusted"
individuals") to be able to submit UCE reports. These might consist of an email
address, subject, or perhaps a site name (thought should be given to possible
counter tactics the spammers would have available to them). These UCE reports
would then go into a central repository perhaps with an associated expiration
time. If a new piece of mail arrives and it has been say an hour since the last
time the central registry was checked, the software would then contact the
registry and download the latest spammers listing.
Bruce J. Bell
On 29 Jan 1997 09:07:22 -0800, John C. Randolph <j...@idiom.com> wrote:
>r...@monkeys.com (Ronald F. Guilmette) writes:
>
>>Dick, and Spammy that happens to show up at their port 25 is being run
>>by blithering idiots. I know. I know. We still _do_ have some major
>>sites (e.g. Earthlink) which are being run by blithering idiots.
>
>that earthlink is run by Scientologists, who have a definite hostile intent
>towards the rest of the internet. I don't take *any* traffic from earthlink,
>and I would advise other sysops to do likewise.
Much as I dislike Scientology, and much as I think Earthlink is poorly
run both as an access provider and as a company, I have to say that there
is not a firm link between the two.
The head honcho at Earthlink is a dyed-in-the-wool Scientologist, and
you have to wonder who his silent partners are, but AFAIK the company
has come by its blithering-idiot-hood independently...
Bruce
--
You are the lens of the world:
the lens through which the world may become aware of itself.
The world, on the other hand, is the only lens in which you can see yourself.
It is both lenses together that make vision. (--R. A. MacAvoy)
Seth Breidbart
In article <5covrb$j...@news.orst.edu>,
John Stanley <sta...@skyking.OCE.ORST.EDU> wrote:
>In article <5cn964$fn1$1...@coredump.monkeys.com>,
>Ronald sez: Please use the <> bracketed Reply-To: address below. So Sayeth Guilmette <970904052...@monkeys.com> wrote:
>>What I had _intended_ to say was `... randomly selected INACTIVE news-
>>groups in the alt.* hierarchy.''
>
OK, newgroup alt.spamtrap, with a charter that says articles are only
posted there so that spammers will be foolish enough to extract their
headers. Then those autoposted articles are, by definition, on-topic.
Seth
John Lundgren
Frederick D. Kass (fk...@mtholyoke.edu) wrote:
: Mike Cohen (dje...@sprynet.REMOVE_TO_REPLY.com) wrote:
: > This is one of the best anti-spam sites I know of - it has a very useful
: > form which lets you do a dig, traceroute, whois, and use other tools for
: > identifying spammers & figuring out who to complain to. Everyone should be
: > grateful to Julian (btw, I ran into his filter when I tried to thank him
: > via email ;-).
: This idea reminds me of those phone devices which require you to have a
: passcode inorder for your call to go through to the phone number.
: At first glance this seems like a good idea. However, I can't think of a
: week I haven't gotten a call from someone I don't ussually talk to, who I
: was glad they called (i.e. old lost friends, Police dept., someone offering
: me a job, etc.). This same idea goes for e-mail, most of us get a
: lot of old friends, security updates (even nice letters from people you
: don't know :) and such from people that would not otherwise know your code.
: You could stop spammers by not getting an e-mail account too! The best
: UNIX security is not to own a UNIX box...
: Stop spammers, don't stop open communications...
: -Fred
Yeah, tell that to Microtimes magazine. They used to have a free
magazine rack on every major street, and it was easy to get their latest
issue. Then some homeless ne'er-do-wells started grabbing most of the
magazines for recycling. So the magazine yanked most of the racks off
the street.
So the moral of this story is that the price of free magazines is abuse by
some lowlife.
A few years ago, I think it was Prodigy, used to have no limit on the
number of messages (emails) that could be sent out. Then the word got out
that much of the volume of the messages was from a small percentage of
users. They were using the free messages as, well, you guessed it. So
Prodigy clamped down and put a cap on free messages. Something like 25
messages a month with every message over that charged a fee. What a
fuss the users put up! They couldn't stop complaining about it. But it
took care of the problem.
Maybe ISPs should consider this as an option. When a spammer sends out
hundreds or thousands of emails, he uses much more resources than the
average user. So there is a way to get some compensation from the high
users and put a heavier burden on those wasting other peoples time. As
long as there are unscrupulous people out there that hype their UCE
spamming services as giving amazing results, and then send some thousands
of emails for _free_ to get only a handful of prospects, then there will
be spammers that abuse the free services of their providers.
The UCE used to be an annoyance, until the number of spammers rose
dramatically. They look at us and think 'why is this guy complaining?'
Well, the problem has gone far beyond annoyance. Every spammer is
flooding our mailboxes with UCE and I would say that well over half of my
email is spam. And that's the price of free communication? That's the
price of free one-way junk email communication. Leave the average users
to communicate for free, and charge the junk emailers a fee for their spam.
--
#===================================================================#
| John Lundgren - Elec Tech - Info Tech Svcs. | jlundgre@ |
| Rancho Santiago Community College District | deltanet.com |
| 17th St at Bristol \ Santa Ana, CA 92706 | http://www.rancho|
| My opinions are my own, and not my employer's. | .cc.ca.us |
| Most FAQs are available through Thomas Fine's WWW FAQ archive: |
| http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html |
| "Babe Ruth struck out 1,330 times... keep on swinging." |
| says the lid on the jar of Laredo & Lefty's Picante Salsa |
! You MAY NOT use my email address for unsolicited Email or lists! !
#======P=G=P==k=e=y==a=v=a=i=l=a=b=l=e==u=p=o=n==r=e=q=u=e=s=t======#
Seth Breidbart
In article <5cv9uo$qm6$1...@coredump.monkeys.com>,
Ronald F. Guilmette <r...@monkeys.com> wrote:
>In article <5cqs4u$5...@panix3.panix.com>,
>Seth Breidbart <se...@panix.com> wrote:
>>OK, newgroup alt.spamtrap, with a charter that says articles are only
>>posted there so that spammers will be foolish enough to extract their
>>headers. Then those autoposted articles are, by definition, on-topic.
>As I understand it, there is some reluctance (in some quarters) to have
>brand new second-level hierarchies created under `alt', so the name
>`alt.spamtrap' might not be the absolutely best choice. The good news
>however is that a new group like `alt.stop.spamming.troll' (with a charter
>exactly like what you proposed) would work equally well, I think.
I like alt.mlm.spamtrap myself. Of course, there's no reason not to
have several of these.
Seth
John Todd
A simple and naive question.
I understand, I think, that in the "real" world, advertisers are concerned
with passing their brand across your retina / eardrum in the hope that
something will stick.
How is it that spammers think it is worthwhile spamming, when the amount of
hate mail it generates indicates that it might be counter-productive?
I personally go out of my way to *not* use products marketed to me in in
ways I find offensive: similarly, I wouldn't even *consider* using whatever
product or service was spammed at me.
Therefore:
What possible purpose can there be to spam, aside from it's nuisance value,
if the recipents not only ignore it, but actively reject the product which
is advertised? I can only think that the spam for product "A" is paid for
by the producers of competing product "B".
Hmm?
JT
--
I start to spin the tale / you complain of my diction / you give me / friction.
Television, 'Friction' | Anti-bot address: john@diploma demon co uk
Ian Stirling
Seth Breidbart (se...@panix.com) wrote:
: In article <5cv9uo$qm6$1...@coredump.monkeys.com>,
And news.announce.net-abuse.spamtrap Of course.
: have several of these.
: Seth
Seth Breidbart
In article <854790...@diploma.demon.co.uk>,
John Todd <John@diploma demon co uk> wrote:
>How is it that spammers think it is worthwhile spamming, when the amount of
>hate mail it generates indicates that it might be counter-productive?
>What possible purpose can there be to spam, aside from it's nuisance value,
>if the recipents not only ignore it, but actively reject the product which
>is advertised? I can only think that the spam for product "A" is paid for
>by the producers of competing product "B".
The spammers lie to companies, telling them that spamming is good
advertising, so the suckers pay the spammers to spam. The suckers
then find out that spamming is such a bad idea, but the spammers
already have their money and the suckers generally don't sue.
Seth
David Bromage
John Todd (Jo...@diploma.demon.co.uk) wrote:
>A simple and naive question.
>
>I understand, I think, that in the "real" world, advertisers are concerned
>with passing their brand across your retina / eardrum in the hope that
>something will stick.
>
>hate mail it generates indicates that it might be counter-productive?
>
>ways I find offensive: similarly, I wouldn't even *consider* using whatever
>product or service was spammed at me.
Make sure the advertisers know this. It has only just recently become
apparent that getting to the advertisers is hurting the spammers. Note the
recent threats of legal action for lost revenue against people who
complain, or the threats of legal action "if you interfere with our
business" actually included in the spams.
Cheers
David
Robert E. Maas
<<... the vast and growing numbers of _irresponsible_ site
administrators (and backbone providers) on the Internet. This latter
(bigger) problem will never go away, and sadly, it forces the
responsibility for a solution to the UCE problem back onto the
receiving end.>>
As soon as I learn how to use procmail, I plan to block entire address
blocks as follows:
If anyone whatsoever mails to r...@one-o.com i.e. r...@jericho.one-o.com,
it bounces with a request to re-mail to grue.one-o.com (which has IP
address logging), and with a warning of $500 penalty if the re-sent
message is a commercial advertisement or solicitation or announcement.
If any e-mail is directly to r...@grue.one-o.com from a blocked address
block, it bounces with no recourse, but with an explanation why the
address block. (Hmm, ambiguous jargon here. 'address block' means a
blockage of e-mail, but it also means a consecutive set of addresses.
Maybe I'll call this my address-block block!)
When I complain about UCE, I use Reply-To: field to tell the sysadmin
to send to rem%grue.one-o.com@someOtherHost, which will be the ONLY way
to get from the banned address block through my block so I'll see the
sysadmin message. (There are a whole slew of other hosts which allow
the user%host@relayHost syntax and which do logging of IP numbers so I
know where the message really came from even via the relay, so this is
no problem providing the relay hosts don't complain that I'm stealing a
few milliseconds of computer time from them. To prevent forgery, I'll
use a different relay host for each blocked-sysadmin I want to hear
from.)
Does anybody have "for a dummy" instructions how to do what I want:
I want all e-mail that doesn't have a
Received: from ... by grue.one-o.com
line to be bounced with a text preface from a file I've provided on my
disk. I want all e-mail that DOES have that Received: from ... by
grue.one-o.com line to be checked for the IP number that sent it to
grue, and bounced with a different text file preface for each
particular address block I've specified to be blocked. But in special
cases where the message went from a particular blocked address block
to a particular relay host to grue, I want to accept that, because
it's from the sysadmin responding to my UCE complaint, and I want that
sysadmin-about-abuse message to go in a special file instead of my
regular e-mail inbox.
Anybody have 'for dummies' cookbook instructions for how to do all
that? For a starter: Just how to bounce anything that didn't go
through grue, with my text file instead of the usual bounce preface?
For example:
I'm sorry, but e-mail addressed to r...@one-o.com is no longer being
accepted. Instead you must mail to r...@grue.one-o.com, and your e-mail
absolutely must NOT be any sort of commercial message such as an
advertisement. (Any violation of that rule will be considered felony
harassment, and will be prosecuted to the fullest extent of both
criminal law and civil tort law.)
Brad Knowles
In article <jcr.85...@idiom.com>, j...@idiom.com (John C. Randolph) wrote:
> For an example of an ISP run by blithering idiots, you have to go to
> AOL ;-).
Blithering idiots? Do you want your comp.mail.sendmail FAQ or not?
--
Brad Knowles, MIME/PGP: br...@his.com
comp.mail.sendmail FAQ Maintainer <http://www.his.com/~brad/>
finger br...@his.com for my PGP Public Keys and Geek Code
The comp.mail.sendmail FAQ is at <http://www.his.com/~brad/sendmail/>
Brad Knowles
In article <5cndkg$g7e$1...@coredump.monkeys.com>, r...@monkeys.com (Ronald F.
Guilmette) wrote:
> In article <32e49...@nomad2.HCSys.com>,
> Roger Books <970805022...@mail.state.fl.us> wrote:
> >It really looks to me like the only way to deal with this is on the
> >ISP side, not the recipient side.
>
> I used to think so too. I have changed my mind. Or rather I should say
> that the exponential growth in the numbers of incompetent and/or
> malevolent system administrators on the Internet (and scattered all
> over the world) has changed my mind for me. No amount of effort,
> regardless of how large, will ever get all Internet site adminstrators
> to act responsibly. It just ain't gonna happen.
If they're being used as open mail relays for UCE, and more and more
sites start implementing certain specific types of
anti-junkmail/anti-bogus domain features, then they're going to be left
with a mailqueue of several million messages (which they probably can't
bounce any better than anyone else) and a dead mail system. That will be
their incentive to fix things.
What will make a real difference is when we can get the big sites to
implement these sorts of controls, and get them built in as defaults (or
at least very easily enabled features) in various common SMTP MTAs.
Maurizio Codogno
Ronald F. Guilmette <r...@monkeys.com> states:
% I have talked to a couple of the anti-spam guys at earthlink, and they
% seemed normal and ordinary enough. But one of them confessed to me
% that he _knew_ damn well that their open SMTP port is acting like a
% big magnet for all of the _outside_ UCEers on the planet who have
% managed to grow enough brain cells to understand bouncing.
Or that have found a cookbook which explains how to do it :-(
Anyway, I just block everything which come from eartlink.{com,net}. Not
really impressive, but still better than nothing.
.mau.
Chris Lewis
In article <5cv9bu$qjd$1...@coredump.monkeys.com>,>In article <5crm8m$f...@news05.deltanet.com>,
>John Lundgren <jlun...@delta1.deltanet.com> wrote:
>>A few years ago, I think it was Prodigy, used to have no limit on the
>>number of messages (emails) that could be sent out. Then the word got out
>>that much of the volume of the messages was from a small percentage of
>>users. They were using the free messages as, well, you guessed it. So
>>Prodigy clamped down and put a cap on free messages. Something like 25
>>messages a month with every message over that charged a fee. What a
>>fuss the users put up! They couldn't stop complaining about it. But it
>>took care of the problem.
>No actually, it didn't.
>Included below are two VERY FRESH junk UCEs that I have received from
>Plodigy just within the past few days.
>But hey! Chris Lewis is great pals with the folks at Plodigy and the
>way he tells it, this crap that they keep on spewing out is all just in
>my imagination. Yea. Right Chris. Whatever you say.
Ever the master of the irrelevant cheap shot eh?
It's a sign of your immaturity and inability to properly deal with email
spam that you (a) blame Prodigy's spam on me, and (b) think that _two_
mail spams makes Prodigy a spam haven. No ISP, no matter how good they
are, can make email spamming impossible. Until you understand that,
you will always be on the loony fringe, getting in the way of both the
anti-spammers trying to control spam, and alienating the ISPs that are
seriously trying to fix things.
I guess the fact that Prodigy sued Cyberpromo means that they're spammer
friendly, eh Ronnie? Or that I helped Prodigy in gathering evidence
for the lawsuit means I do nothing about email spam.
Did you bother to check the IP addresses Ronnie? Could it be Cyberpromo
or some other spammer forging Prodigy system addresses again?
>I guess that as long as you are drinking buddies with Chris Lewis,
I've never met any Prodigy employee, let alone had drinks with one - bogus
as the rest of your infantile whining.
--
For more information on spam, including countermeasures and resources,
see the Internet Spam Boycott, at <URL:http://www.vix.com/spam/>.
Chris Lewis: _Una confibula non sat est_
Matthew Ward
Follower of the Clawed Albino wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In article <5d0brr$q...@panix3.panix.com>,
> se...@panix.com (Seth Breidbart) carved on the cave wall:
> > In article <5cv9uo$qm6$1...@coredump.monkeys.com>,
> > >Seth Breidbart <se...@panix.com> wrote:
> >
> > >>OK, newgroup alt.spamtrap, with a charter that says articles are only
> > >>posted there so that spammers will be foolish enough to extract their
> > >>headers. Then those autoposted articles are, by definition, on-topic.
> > >As I understand it, there is some reluctance (in some quarters) to have
> > >brand new second-level hierarchies created under `alt', so the name
> > >`alt.spamtrap' might not be the absolutely best choice. The good news
> > >however is that a new group like `alt.stop.spamming.troll' (with a charter
> > >exactly like what you proposed) would work equally well, I think.
> >
> > I like alt.mlm.spamtrap myself. Of course, there's no reason not to
>
> Agreed.
>
> I'd dare say that a few towards the front of the alt.* hierarchy might
> not be a bad idea--two groups I read (alt.barney.dinosaur.die.die.die and
> alt.comics.2000ad) towards the front of alt.* seem to get spammed worse
> than other groups towards the middle or end of alt.*.
>
> If anyone wants, I'll be more than happy to propose alt.binaries.a-spamtrap
> and alt.comics.cancel, if folks think it'd be a good idea.
No! No! It HAS to be in one of the *.binaries.* hierarchies! That
way you'll be sure to attract LOADS of spammers.
>
> (Of course, one major problem is making sure spamtrap groups get good
> propogation. Propogation for new alt.* groups has gone right to the
> sheissepot thanks to folks like Tom Servo et al. :P)
>
> - --
> - -Windigo The Feral (NYAR!)
> For more information on spam, including countermeasures and resources,
> see the Internet Spam Boycott, at <URL:http://www.vix.com/spam/>.
> "Whack him on the modem till his UARTs comm off." - M. Scheidell
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3a
> Charset: cp850
>
> iQCVAwUBMvUQ0d7EjaI0ArxhAQFQLwQAoQQ4X35IzypsCBru26wkhVxftmEsw98s
> HlJP8CrMEsLDmNbXK1jRcDVzOvrFU0rEHLYmvTs5xYQLMCOt/ViyXnAJi/ocQnHZ
> SHr0Oru//cZ41UZgdnNai5oW/sZ8f4GRhl4dWeKM2sCBEPsa7xK7hngE/Vh8xFdA
> 4IYu6CaCJgI=
> =qFLn
> -----END PGP SIGNATURE-----
--
"One will not have needed the Future Perfect in one's entire life" -
William Safire. /\/\ a tt == mw...@gte.net == Alpha Geek
Follower of the Clawed Albino
-----BEGIN PGP SIGNED MESSAGE-----
In article <5d0brr$q...@panix3.panix.com>,
se...@panix.com (Seth Breidbart) carved on the cave wall:
> In article <5cv9uo$qm6$1...@coredump.monkeys.com>,
> Ronald F. Guilmette <r...@monkeys.com> wrote:
> >In article <5cqs4u$5...@panix3.panix.com>,
> >Seth Breidbart <se...@panix.com> wrote:
>
> >>OK, newgroup alt.spamtrap, with a charter that says articles are only
> >>posted there so that spammers will be foolish enough to extract their
> >>headers. Then those autoposted articles are, by definition, on-topic.
> >As I understand it, there is some reluctance (in some quarters) to have
> >brand new second-level hierarchies created under `alt', so the name
> >`alt.spamtrap' might not be the absolutely best choice. The good news
> >however is that a new group like `alt.stop.spamming.troll' (with a charter
> >exactly like what you proposed) would work equally well, I think.
>
> I like alt.mlm.spamtrap myself. Of course, there's no reason not to
> have several of these.
Agreed.
I'd dare say that a few towards the front of the alt.* hierarchy might
not be a bad idea--two groups I read (alt.barney.dinosaur.die.die.die and
alt.comics.2000ad) towards the front of alt.* seem to get spammed worse
than other groups towards the middle or end of alt.*.
If anyone wants, I'll be more than happy to propose alt.binaries.a-spamtrap
and alt.comics.cancel, if folks think it'd be a good idea.
(Of course, one major problem is making sure spamtrap groups get good
Mark Hughes
Seth Breidbart (se...@panix.com) wrote:
: Ronald F. Guilmette <r...@monkeys.com> wrote:
: > Seth Breidbart <se...@panix.com> wrote:
: > > OK, newgroup alt.spamtrap, ...
: > ... a new group like `alt.stop.spamming.troll'
: I like alt.mlm.spamtrap myself. Of course, there's no reason not to
: have several of these.
Just how much trouble do you suppose it would be for spammers to avoid
such groups? Answer: not much.
What is really needed is for people with the ability to set up multiple
accounts and change them easily (e.g. admins and AOL subscribers) to use
their normal usenet posts as spam traps.
--
To reply by email to this message, remove "-bluenco" from my return
address. This is an attempt to foil email spammers who gather addresses
from news postings. This extension is random. Any resemblance to a
name, real word or another email address is coincidental.
Mark
Seth Breidbart
In article <28...@pms104.pms.ford-bluenco.com>,
Mark Hughes <mhu...@pms104.pms.ford-bluenco.com> wrote:
>Seth Breidbart (se...@panix.com) wrote:
>: Ronald F. Guilmette <r...@monkeys.com> wrote:
>: > Seth Breidbart <se...@panix.com> wrote:
>: > > OK, newgroup alt.spamtrap, ...
>: > ... a new group like `alt.stop.spamming.troll'
>
>: I like alt.mlm.spamtrap myself. Of course, there's no reason not to
>: have several of these.
>
>Just how much trouble do you suppose it would be for spammers to avoid
>such groups? Answer: not much.
However, it's just a little more trouble than most spammers are going
to go too.
Seth
Ronald F. Guilmette
In article <E4zx4...@ferret.ocunix.on.ca>,
Chris Lewis <cle...@ferret.ocunix.on.ca> wrote:
>In article <5cv9bu$qjd$1...@coredump.monkeys.com>,
>>John Lundgren <jlun...@delta1.deltanet.com> wrote:
>
>>>A few years ago, I think it was Prodigy, used to have no limit on the
>>>number of messages (emails) that could be sent out. Then the word got out
>>>that much of the volume of the messages was from a small percentage of
>>>users. They were using the free messages as, well, you guessed it. So
>>>Prodigy clamped down and put a cap on free messages. Something like 25
>>>messages a month with every message over that charged a fee. What a
>>>fuss the users put up! They couldn't stop complaining about it. But it
>>>took care of the problem.
>
>>No actually, it didn't.
>
>>Included below are two VERY FRESH junk UCEs that I have received from
>>Plodigy just within the past few days.
>
>>But hey! Chris Lewis is great pals with the folks at Plodigy and the
>>way he tells it, this crap that they keep on spewing out is all just in
>>my imagination. Yea. Right Chris. Whatever you say.
>
>Ever the master of the irrelevant cheap shot eh?
Nope. That's you department. I try to leave that to you.
>It's a sign of your immaturity and inability to properly deal with email
>spam that you (a) blame Prodigy's spam on me, and (b) think that _two_
>mail spams makes Prodigy a spam haven.
I blame you for exactly what you are guilty of... being part of the problem,
rather than part of the solution.
You already came to the defense of the morons at Prodigy, here, in public,
so don't try to deny that now. You defend them even though it becomes
more and more apparent, that it is slowly becoming another safe haven for
the UCEers.
You are already on record as saying the every spammer and UCEer should be
given not one, but TWO opportunities to spam from each of their throw-away
accounts, so don't bother trying to deny that either.
>No ISP, no matter how good they are, can make email spamming impossible.
That is utter bullshit and you know it. The methods for accomplishing
this have been discussed here on more than one occasion, and in some
detail. ISPs can force all outgoing mail to be routed through THEIR
OWN Mail Trnasfer Agent... at least in the first instance, and that
can provide a ``choke point'' where the outbound flow can be limited...
*if* anyone care to do it, and there have been reports here that *some*
ISPs have in fact done just that.
But can your pals at Plodigy manage this simple technology?? Noooooooo.
And you, Chris Lewis, ever the apologist for his pals at the ISPs, says
``No, it can't be done''. Why? Maybe it can't be done (according the
gospel of Chris Lewis) because your pals at the ISPs have told you that
they just don't feel like spending the time or the money to do it. After
all... who is all of this crap UCE bothering anyway? Just a few casual
complainers and that one annoying Guilmette fellow. But our pal Chris
can take care of him. Yea.
>Until you understand that, you will always be on the loony fringe...
Oh I _do_ understand exactly what _you_ would like to pain me as. I _do_
fully understand your vested interests in trying to make everyone continue
to be lulled into a false sense of security because ``Chris Lewis is on
the job!''
Well, I've already made this point, but I guess that I'm going to have to
do the old broken record routine and just keep on making it until you
sulk away sliently to rejoin your pals among the ISP owners...
You haven't solved the problem of UCE. Period. End of story. If you
solve it tomorrow then _I_ and my methods... to which you take such
exception... will _also_ disappear tomorrow. I promise.
But instead of actually doing something about the problem, you seem to
be too busy kissing the asses of the various ISPs you are in bed with
and telling everybody what a swell job they are doing. And you alternate
_that_ futile and pointless activity with attacking me, because _I_ am
trying to _do something_ about the problem.
Prodigy is a perfect case in point. I describe _exactly_ what I was told
by a Prodigy representative on the phone... i.e. they Prodigy has NO POLICY
WHATSOEVER againts mass junk E-mail. So what you do you? What do your
pals at Plodigy do? Do you (or they) investigate?? NOOOOOOOOOOOO! That
would take work, effort. Somebody might actually have to DO SOMETHING,
like fer instance TRAIN the people who answer Prodigy's phones. Instead
you think that you can kill the turth, and the message, just by bad-mouthing
the messenger. Well, you can forget it. I am going to speak the truth
about Prodigy and other lame ISPs no matter how much you try to shut me
up.
>getting in the way of both the
>anti-spammers trying to control spam, and alienating the ISPs that are
>seriously trying to fix things.
Yea. Right. Like as if _you_ knew who is really trying to fix things and
who is just shamming you.
Look Chris, it seems that you are not getting my message. So you are
forcing me to repeat myself. You haven't solved the problem. Neither
have the carefully cultivate pals that you brag about having at various
ISPs. You stand up for and defend the likes of Prodigy. Then they and
their customers send me and everybody else yet another new ration of crap
UCE. Does this have _any_ effect on your thinking about them? None what-
soever. Ron must be making this all up you say to yourself. This UCE
problem doesn't even really exist... either at Prodigy or anywhere else.
Yea. Right. Whatever you say Chris.
Wake up and smell the coffee Chris.
>I guess the fact that Prodigy sued Cyberpromo means that they're spammer
>friendly, eh Ronnie? Or that I helped Prodigy in gathering evidence
>for the lawsuit means I do nothing about email spam.
If Prodigy is so goddamn sensitive about the junk E-mail issue then why,
oh why, Lord Lewis, are their customers still sending me this crap????????
OH! I GET IT! Plodigy's policy is that it is better to give than to
receive! How charitable! They take great exception to *their own*
customers getting slimed, but they don't even have a policy against
their customers sliming other people! Swell. Just swell.
>Did you bother to check the IP addresses Ronnie? Could it be Cyberpromo
>or some other spammer forging Prodigy system addresses again?
Did you look at the headers Sir Christopher? Did you even bother to
_ask_ your alleged great pals over at Plodigy if the account from
which those UCEs obviously came exists or not, and whether they had
had any other complaints about it? Noooooooo. Because they would
require some work, some effort, effort which might take you away from
what you seem to have made your main job in life, i.e. disagreeing
with me and trashing me in public.
>>I guess that as long as you are drinking buddies with Chris Lewis,
>
>I've never met any Prodigy employee, let alone had drinks with one - bogus
>as the rest of your infantile whining.
Did you not say that you had ``contacts'' at Prodigy??
If so, they please do enlighten me oh Wise One... Have you asked them
about the UCEs that I posted, and/or about what (if anything) they are
doing about them? Have you ever tried calling the _normal_ Prodigy 800
number yourself to complain about a UCE that you got?? No. Silly me.
Of course not. You don't have to use the front door, like most of us
peons who are getting slimed by Prodigy. You have the _special_ and
secret number that allows you to talk directly with the sysadmins at
Prodigy.
Get off your high horse and stop calling me a liar until you can produce
some evidence. All I see if a bunch of hot air from someone who has a
vested interest in maintaining the status quo... the status quo which
is delivering ever more crap UCE to my inbox on a daily basis.
It must be very comfy for you to be able to deal in inuendo and slander
against me, rather than trying to establish some _facts_ for a change,
but inuendo and slander won't keep you going forever.
--
-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: r...@monkeys.com -----------------------------------------------
Ronald F. Guilmette
In article <5d1m16$k4q$1...@gruvel.une.edu.au>,
Such threats are _not_ by any means a new or recent phenomenon. These kinds
of hollow and silly threats have been around as long as the spammers and
UCEers have been around.
But I do agree that such threats do tend to indicate that we are getting
to them on occasion.
I frequently remember a scene from the movie ``The String'' with Paul
Neuman and Robert Redford:
``How did it go kid?''
``Fine. They threatened to kill me.''
``Hell kid! If they don't do that, you know you're not getting
to them!''
Roger Books
Seth Breidbart (se...@panix.com) wrote:
: >
: >: I like alt.mlm.spamtrap myself. Of course, there's no reason not to
: >: have several of these.
: >
: >Just how much trouble do you suppose it would be for spammers to avoid
: >such groups? Answer: not much.
:
: However, it's just a little more trouble than most spammers are going
: to go too.
Oh come on, avoiding specific groups is trivial. And before you go
into the "any effort is too much" remember, these people are pulling their
lists out of a usenet feed. Not horribly difficult, but it does take
some effort and a little knowledge.
Roger
Mark Hughes
Seth Breidbart (se...@panix.com) wrote:
: Mark Hughes <mhu...@pms104.pms.ford-bluenco.com> wrote:
: >Just how much trouble do you suppose it would be for spammers to avoid
: >such groups? Answer: not much.
: However, it's just a little more trouble than most spammers are going
: to go too.
Most spammers use someone else's software to do their harvesting (I'm
guessing). If the author of, say, Lightning Bolt makes a few trivial
changes, all the spammers who use that piece of chu'ta' benefit with no
trouble at all.
--
To reply by email to this message, remove "-effer" from my return
Tye McQueen
) > Roger Books <970805022...@mail.state.fl.us> wrote:
) > >It really looks to me like the only way to deal with this is on the
) > >ISP side, not the recipient side.
) r...@monkeys.com (Ronald F. Guilmette) wrote:
) > I used to think so too. I have changed my mind. Or rather I should say
) > that the exponential growth in the numbers of incompetent and/or
) > malevolent system administrators on the Internet (and scattered all
) > over the world) has changed my mind for me.
I think one of the best improvements lies in the _receiving_ ISPs.
The one intrinsic characteristic of UCEs is that it is sent to
tons of people. If an ISP allowed users to register from which
mailing lists they expect messages destined for multiple users,
then the ISP could filter any nearly identical messages sent to
more than 2% of their users, much like the Usenet spam cancellers
do. Then only relatively "slow" UCE could get through. Such
"slow" UCEs can be choked off by other methods discussed.
br...@his.com (Brad Knowles) writes:
) If they're being used as open mail relays for UCE, and more and more
) sites start implementing certain specific types of
) anti-junkmail/anti-bogus domain features, then they're going to be left
) with a mailqueue of several million messages (which they probably can't
) bounce any better than anyone else) and a dead mail system. That will be
) their incentive to fix things.
I agree that these forces will continue to educate sites into not
being UCE havens (and the education will start happening faster
as you point out). However, there will always be some new start-up
ISP that hasn't been educated yet that will allow one huge UCE
out the door (and for the next while, there will continue to be
_plenty_ of new start-up ISPs that aren't educated).
So combine this with some receive-side filtering. And the
per-user filtering won't hurt either. But I think allowing groups
of users to filter based on whether many of them got the "same"
message has even more potential.
Sorry if this is an old idea but I haven't seen it proposed in the
sampling of articles I've read.
P.S. I think AOL's filtering solution would be easy to get around
and it is being poorly implemented so that too much non-UCE e-mail
is getting thrown away.
--
Tye McQueen t...@metronet.com || t...@thingy.usu.edu
Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)
Dave Ratcliffe
On 2 Feb 1997 09:16:22 GMT, dbro...@metz.une.edu.au (David Bromage) wrote:
>John Todd (Jo...@diploma.demon.co.uk) wrote:
>>I personally go out of my way to *not* use products marketed to me in in
>>ways I find offensive: similarly, I wouldn't even *consider* using whatever
>>product or service was spammed at me.
>
>Make sure the advertisers know this. It has only just recently become
>apparent that getting to the advertisers is hurting the spammers. Note the
>recent threats of legal action for lost revenue against people who
>complain, or the threats of legal action "if you interfere with our
>business" actually included in the spams.
People who are subject to these threats need to be made aware that such
threats have no basis in law and are used only as a scare tactic on the part
of the spammers. They [spammers] have no legal leg to stand on and many may
actually have something to worry about with regard to misrepresentation to
their clients.
--
Dave Ratcliffe
da...@frackit.com
Ronald F. Guilmette
Excuse me for following up on my own posting, but I said something which
someone inquired about via private E-mail, and it seemed like something
which was worth elaborating upon, so with his permission, I am posting
my response to his query.
This _does_ relate quite directly to security, to sendmail, and to the
topic of junk E-mail and how to counter it.
First, here is an excerpt from my prior posting...
In article <5d6ti6$5pu$1...@coredump.monkeys.com>,
Ronald F. Guilmette <r...@monkeys.com> wrote:
>In article <E4zx4...@ferret.ocunix.on.ca>,
>Chris Lewis <cle...@ferret.ocunix.on.ca> wrote:
>
>>No ISP, no matter how good they are, can make email spamming impossible.
>
>That is utter bullshit and you know it. The methods for accomplishing
>this have been discussed here on more than one occasion, and in some
>detail. ISPs can force all outgoing mail to be routed through THEIR
>OWN Mail Trnasfer Agent... at least in the first instance, and that
>can provide a ``choke point'' where the outbound flow can be limited...
>*if* anyone care to do it, and there have been reports here that *some*
>ISPs have in fact done just that.
Now, here is my response to a recent E-mail inquiry about this from
Dave Kochan <da...@n1.net>:
In message <Pine.SOL.3.93.97020...@natasha.n1.net>, you wrote:
>
>Hi, Ron:
>
>In one of your posts in comp.unix.security (Re: Prodigy sucks... )
>you alluded to a method by which I as an ISP can funnel all
>outgoing SMTP mail through my mail hub.
>
>Where can I obtain details on this? I would love to get a
>handle on what is going on with E-mail traffic from my
>customers. I have had enough of this spam nonsense and am
>willing do to whatever I can to stop any of this crap
>originating at my site.
There are no written documents to describe this rather rudimentary idea...
at least none that I know of. And in any case, the actual implementation
will be highly dependent upon the exact type of hardware and software
that you are running.
Basically, the idea is that somewhere between your site and the rest of
the Internet you probably already have either a router or a firewall or
both. Either one of these _should_ be configurable so as to allow you
to absolutely block essentially all outgoing TCP connections from any
of your internal (non-firewall) machines to port 25 on any machine which
is outside of your domain.
What you have then is a situation where your internal users are all forced
to send mail through your central MTA (Mail Transfer Agent... usually the
sendmail program) running on your firewall machine, and then _this agent_
is the only agent which actually has the power to connect out of your
domain to other people's machines on port 25.
This is the way many sites operate _normally_ anyway.... i.e. having all
``normal'' mail go through a local ``mail hub'' machine... which is often
the same machine as the local firewall machine.
This is a fairly common way to run a site, and it keeps most ordinary
users in line. But the problem is that unless you also block _direct_
outbound TCP access to port 25 of other machines outside of your domain,
the really unscruplous end users (i.e. the mass junk E-mailers) can
easily do an ``end run'' around your central mail server/forwarder.
Just by forcing them to _always_ go through your own central mail server
(rather than playing these custey games that some of the UCEers are playing
these days by writing their own mass junk E-mailing programs that directly
connect out on port 25) you get certain advantages. For one thing, you
slow them down... and they don't like that, so the astute UCEers... which
are the most dangerous ones... will go find another place to blast their
junk E-mail from, rather than using your system to do it. Also, and
very importantly, you can easily configure your central mail server MTA
to *log* each and every mail transaction. This allows you to *know*
who among your user base is pulling this kind of crap. And knowing
exactly who is doing it... and having the concrete, unforgable evidence
to prove that... is half of the battle.
Also however, once you have forced all outbound mail from your site to
pass through one central choke-point, it become at least theoretically
possible to have the MTA on your central mail server actively limit
the amount of outbound traffic from any given individual user account
to some ``reasonable'' level. Of course, ``reasonable'' probably must
be a configurable value which can be adjusted separately for different
classes of users. For ordinary users, 50 or 100 messages per 24 hour
period seems pretty reasonably to me, but _any_ limit... even something
like 500 per day... is better than nothing! For the special people
at your site who run mailing lists, the limit must obviously be much
higher, and perhaps completely unlimited. (If you really really trust
the people involved, then you might as well make there be no limit for
them. These are the special ``really trusted'' users. Obviously, `root'
falls into the category also.)
Now I _do_ admit that as of today, no one has made the necessary extensions
to sendmail to track and/or enforce such limits publically available. How-
ever it is my opinion that the necessary extensions are not exceptionally
difficult to make, and that they could be done in about a man-month (or
less) by a competent systems programmer.
Obviously, all that is needed is a set of counters within sendmail, one
for each local user, that is incremented by one each time a local user
sends an outbound mail message. The counters could all be reset to zero
again at (say) 3 AM each day. Additionally, of course, you would need
to have a small data base which would indicate the per-day outbound mail
limits for each local user, respectively. (A zero value in this data
base could be used to indicate no limit.) You would also need something
roughly analogous to the /etc/aliases file (and also some separate program
which would be roughly analogous to the `newaliases' program) through
which the local system administrator could adjust the limits for individual
users.... let's just call them the /etc/maillimits file and the `newlimits'
program.
Anyway, the whole point is that each time the sendmail on the mail hub is
asked to send out a mail message for a local user, it first checks to
see if that user has already hit or exceeded his daily limit. If so,
the new mail message is _not_ sent, but is instead bounced back to the
original (local) sender.
I would have implemented this whole thing myself during January... and made
all of the code publically available... except for the fact that I gave up
on the notion that the _people_ at the sites where this crap comes from
are universally responsible enough to even _want_ to stop this stuff at
the origination point. Many do not. Thus, I have spent the entire month
of January working instead on implementing new code for the receiving
end which I hope will make life much much harder on the mass junk E-mailers
once it is released for general use.
But ideally, we should have tools to block this stuff at _both_ the re-
ceiving end _and_ at the sending end. The former could be used by anybody,
while that latter would only be used by _responsible_ local system admini-
strators (such as yourself) who actually _do_ care if their own user bases
are screwing up the rest of the Internet.
In other words, although I am currently quite preoccupied with implementing
something new for the receiving end, I do sincerly hope that _someone_ will
take up the (modest) challenge of implementing some effective, non-circum-
ventable controls for the sending end also. Lord knows that we can certainly
use all of the help we can get in fighting this new scourge.
Wolfgang Schelongowski
[Distribution: inet deleted]
In <5cv9kl$qkr$1...@coredump.monkeys.com>
r...@monkeys.com (Ronald F. Guilmette) writes:
>UCE trolling postings could also be posted to various *.test newsgroups,
>including the alt.test newsgroup (with the keyword `IGNORE' included of
>course).
From my experience spammers do not seem fish addresses from *.test groups.
--
Wolfgang Schelongowski Check _all_ headers for sending email.
Teifi, Teifi, Sakradie, do geht er dahin!
-- EAV, Alpenrap
Ronald F. Guilmette
In article <28...@pms104.pms.ford-bluenco.com>,
Mark Hughes <mhu...@pms104.pms.ford-bluenco.com> wrote:
>Seth Breidbart (se...@panix.com) wrote:
>: Ronald F. Guilmette <r...@monkeys.com> wrote:
>: > Seth Breidbart <se...@panix.com> wrote:
>: > > OK, newgroup alt.spamtrap, ...
>: > ... a new group like `alt.stop.spamming.troll'
>
>: have several of these.
>
>such groups? Answer: not much.
Just how many brain cells do spammers have to have in order to _know_
that they should avoid such groups? Answer: At least two.
Many spammers do not qualify. In fact studies show that most do not.
Ronald F. Guilmette
In article <5d7pat$d...@xivic.ruhr.de>,
Wolfgang Schelongowski <skar...@localhost.ruhr.de> wrote:
>[Distribution: inet deleted]
>
>In <5cv9kl$qkr$1...@coredump.monkeys.com>
> r...@monkeys.com (Ronald F. Guilmette) writes:
>
>>UCE trolling postings could also be posted to various *.test newsgroups,
>>including the alt.test newsgroup (with the keyword `IGNORE' included of
>>course).
>
>From my experience spammers do not seem fish addresses from *.test groups.
I'll take that bet!
I got twenty bucks (US) here right now that says that I could make a
posting _today_ to alt.test, forged with some du...@monkeys.com
address and that within 72 hours, it would get UCE'd.
Any takers?
Ronald F. Guilmette
In article <32f72...@nomad2.HCSys.com>,>: >: I like alt.mlm.spamtrap myself. Of course, there's no reason not to
>: >: have several of these.
>: >
>: >Just how much trouble do you suppose it would be for spammers to avoid
>: >such groups? Answer: not much.
>: to go too.
>
>into the "any effort is too much" remember, these people are pulling their
>lists out of a usenet feed. Not horribly difficult, but it does take
>some effort and a little knowledge.
Actually, I'll give odds right now that many of the UCEers have _zero_
technical knowledge whatsoever, and that they are just buying culling
programs from other people.
But I agreed that _eventually_ even the clueless catch on, which is why
any long term program of automated UCE detection would have to find (or
create) a new ``junk'' group under the alt.* hierarchy to use for the
trolls every so often. Probably once every two months would be more
than sufficient.
lam...@nospam.washington.edu
bo...@no.spam.here (Roger Books) writes:
>Oh come on, avoiding specific groups is trivial. And before you go
>into the "any effort is too much" remember, these people are pulling their
>lists out of a usenet feed. Not horribly difficult, but it does take
>some effort and a little knowledge.
I get UCE from an e-mail address which I haven't used on the net in probably
3 years (the machine is dead now, but i still get forwarded e-mail). It
appears on no searches (e.g. altavista web/news, dejanews, even metacrawler)
and i've never used it on a single web page. I don't know how it got "out"
there, but I'm convinced that it is on a list of e-mail addresses which is
being sold. I got three UCEs to this address this past Sunday.
I would dearly like to nail the ass of whoever is selling it to the wall...
(after all, they're facilitating the use of government resources -- my
e-mail account -- for the private gains of the customers who are spamming
me... i can't believe that would be legal...)
But, since all I *ever* receive through this e-mail address is UCE, i'm
instead going to just write an auto-reply to everything in the UCE
that looks like an e-mail address or site, along with a 'whois' lookup...
--
Lamont Granquist (lamontg at u dot washington dot edu) ->note spamfilter<-
"First consider a spherical chicken..." ICBM: 47 39'23"N 122 18'19"W
unsolicited commercial e-mail->contacting your ISP to remove your net.access
Brad Knowles
In article <5d6ti6$5pu$1...@coredump.monkeys.com>, r...@monkeys.com (Ronald F.
Guilmette) wrote:
> >Ever the master of the irrelevant cheap shot eh?
>
> Nope. That's you department. I try to leave that to you.
C'mon guys, both of you -- calm down.
Prodigy certainly isn't 100% blameless when it comes to being a source
for junkmail, but then for that matter, neither is AOL. If they've got
another credit card (God knows, there are something like 2 Billion credit
cards in the U.S., for some 250 Million people, so *somebody* has to have
a huge stash of these things) and another AOL disk, they're back on the
air in minutes. That's true for both AOL and Prodigy (at least, I'm sure
it's true for AOL, and I assume the same is true for everyone else,
including Prodigy).
Unfortunately, junkmail just isn't going away, not any time soon. No
matter what I do (and I've got a few ideas of my own), no matter what you
do, no matter what anyone else does. Even if the SMTP protocol changed
overnight so that no one could ever fake a domain or a return address,
they could always register hundreds and hundreds more, and probably
register them faster than you can shut them down (at beast, you'd be only
a few minutes to a few hours behind them, but then that gives them enough
time to send off a few million mail messages and the damage is already
done).
Even legal decisions against bozos like CyberPromo (I'm speaking of
the Concentric settlement, the Prodigy decision, and the CompuServe
decision) isn't going to stop it. Even passing new laws to make junkmail
illegal (extending the anti-junkfax law that was passed to explictly deal
with one Sanford Wallace) won't solve the problem, because they'll just
move overseas.
Sure, we can come up with ways to refuse to accept stuff that is
coming from IP addresses or domains that are known to harbor junkmailers,
sure we come up with way to filter stuff once it gets here and throw away
what we believe to be dreckage and bletchery.
But the only way we'll ever actually get rid of junkmail is if every
single person who ever gets junkmail complains not only to all the
associated postmasters and domain administrators, but also actively
contacts each and every advertiser that uses that junkmailer to tell them
just how negatively they are viewed by the entire community.
Once the advertisers start wising up, and once the default action for
all standard MTAs is to refuse to be a mail relay for any non-local
domains, we'll start seeing this stuff just dry up and blow away on it's
own. But, we've got to aggressively start going after the money source
for these junkmailers, otherwise we'll never be rid of it.
gregory byshenk
Ronald F. Guilmette <r...@monkeys.com> wrote:
> In article <E4zx4...@ferret.ocunix.on.ca>,
> Chris Lewis <cle...@ferret.ocunix.on.ca> wrote:
> >No ISP, no matter how good they are, can make email spamming impossible.
> That is utter bullshit and you know it. The methods for accomplishing
> this have been discussed here on more than one occasion, and in some
> detail.
Just wanted to point out that this response doesn't quite follow.
While I'm no expert on this sort of thing, I think that your
discussion of spam-prevention on the outbound end is accurate.
But... such preventive measures do _not_ make email spamming
impossible. Yes, they make email spamming difficult, and large-
scale email spamming nearly impossible, but that isn't quite
the same thing.
--
gregory byshenk No one I know is sensible enough
gbys...@tezcat.com to allow me to speak for them -
gbys...@prairienet.org wise though such a thing might
chicago, illinois, usa be...
Wolfgang Rupprecht
lam...@nospam.washington.edu writes:
>I get UCE from an e-mail address which I haven't used on the net in probably
>3 years (the machine is dead now, but i still get forwarded e-mail). It
>appears on no searches (e.g. altavista web/news, dejanews, even metacrawler)
>and i've never used it on a single web page. I don't know how it got "out"
>there, but I'm convinced that it is on a list of e-mail addresses which is
>being sold. I got three UCEs to this address this past Sunday.
I got something to an explicitly routed address that I used for a
month approx 4 years ago while I was getting UUNET to switch my MX so
that I could use domain address again. These maggots must have some
vintage names database from that era.
Received: from default (port7.alam.prodigy.net [204.237.176.7]) by hoflink.com (8.7.6/8.6.12) with SMTP id GAA24255; Fri, 31 Jan 1997 06:56:59 -0500 (EST)
Message-Id: <1997013111...@hoflink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: <Ci...@Rollens.net>
To: "wolf...@aol.com" <wolf...@aol.com>
Subject: Hey babe..........
Date: Fri, 31 Jan 1997 06:56:59 -0500 (EST)
!!!!!! R E A L G I R L F R I E N D S !!!!!!
Want to see what your neighbors wife looks like under that hot bikini?
Welcome to my spam filter aol.com, prodigy.net, hoflink.com and rollens.net.
Anyone know whats up with the "To: " address? It looks like some
tagged value ("wolfga" split(1) group "el" ???). Could they be
running split over their database and making files/phoney recepients
with these strange names?
-wolfgang
--
Wolfgang Rupprecht <wolf...@wsrcc.com> <http://www.wsrcc.com/>
Harrison Bergeron
>: >such groups? Answer: not much.
>
>: However, it's just a little more trouble than most spammers are going
>: to go too.
>
>guessing). If the author of, say, Lightning Bolt makes a few trivial
>changes, all the spammers who use that piece of chu'ta' benefit with no
>trouble at all.
>
One could simply add and rmgroups (at least from the alt spool)
then cancel every single message posted under the assumption
that 1) it's a spammer, 2) it's a dolt that has probably indis-
criminantly crossposted to the world and some ephemeral group
can hardly exist long enough to gain a group of fervent posters.
--
dav...@davids.psyberlink.net
Seth Breidbart
In article <25...@pms104.pms.ford-effer.com>,
Mark Hughes <mhu...@pms104.pms.ford-effer.com> wrote:
>Seth Breidbart (se...@panix.com) wrote:
>: Mark Hughes <mhu...@pms104.pms.ford-bluenco.com> wrote:
>: >Just how much trouble do you suppose it would be for spammers to avoid
>: >such groups? Answer: not much.
>
>: However, it's just a little more trouble than most spammers are going
>: to go too.
>
>Most spammers use someone else's software to do their harvesting (I'm
>guessing). If the author of, say, Lightning Bolt makes a few trivial
>changes, all the spammers who use that piece of chu'ta' benefit with no
>trouble at all.
We can create bogus alt groups (spot the redundancy) a lot faster than
Lightning Bolt can get new versions out to its customers^Wsuckers.
Seth
Ian Stirling
Seth Breidbart (se...@panix.com) wrote:
: In article <25...@pms104.pms.ford-effer.com>,
Uhuh, does not work this way, if this gets to be a problem, they don't
bother with the futile task of trying to maintain a list, they simply
list the non-spamtrap groups.
: Seth
--
Ian Stirling. Currently designing a new PDA, see homepage.
Homepage: http://www.mauve.demon.co.uk/
Money is a powerfull aphrodisiac, but flowers work almost as well.
Robert A Heinlein
Curt Sampson
In article <5d8eb4$8ah$1...@coredump.monkeys.com>,
Ronald F. Guilmette <r...@monkeys.com> wrote:
>...block essentially all outgoing TCP connections from any
>of your internal (non-firewall) machines to port 25 on any machine which
>is outside of your domain.
This is very nice, except that you've now created a large technical
problem for ISPs that support roaming users. Where once a user
could simply select a number off a list, dial in, and work as
normal, now the user must somehow find out the SMTP mail server
address for that particular ISP and know how to reconfigure his
MUA to use that. This may be trivially easy for you, but it's not
for the vast majority of people out there, and they will simply
choose another ISP to give their roaming dollars to rather than
deal with the hassle.
>Also however, once you have forced all outbound mail from your site to
>pass through one central choke-point, it become at least theoretically
>possible to have the MTA on your central mail server actively limit
>the amount of outbound traffic from any given individual user account
>to some ``reasonable'' level.
In practice it's the modifications you'd need to make to sendmail
seem to me to be less than trivial. The only way you can find out
what user is sending mail is to look up who is currently using that
particular IP address. There is no standard method of doing this.
I would be interested to hear how you had planned to implement
this.
cjs
--
Curt Sampson c...@portal.ca Info at http://www.portal.ca/
Internet Portal Services, Inc. Through infinite myst, software reverberates
Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.
Roger Books
Curt Sampson (c...@cynic.portal.ca) wrote:
: In article <5d8eb4$8ah$1...@coredump.monkeys.com>,:
: >...block essentially all outgoing TCP connections from any
: >of your internal (non-firewall) machines to port 25 on any machine which
: >is outside of your domain.
: This is very nice, except that you've now created a large technical
: problem for ISPs that support roaming users. Where once a user
: could simply select a number off a list, dial in, and work as
: address for that particular ISP and know how to reconfigure his
: MUA to use that. This may be trivially easy for you, but it's not
: for the vast majority of people out there, and they will simply
: choose another ISP to give their roaming dollars to rather than
: deal with the hassle.
This ones easy. You can allow connects from within each of the ISP's
domains to 25 on the other end of the ISP's domains. Not a problem.
: In practice it's the modifications you'd need to make to sendmail
: seem to me to be less than trivial. The only way you can find out
: what user is sending mail is to look up who is currently using that
: particular IP address. There is no standard method of doing this.
: I would be interested to hear how you had planned to implement
: this.
Then don't use sendmail. I can do this easily from exim and I would
guess qmail would allow it also. However, assuming you need sendmail,
it is fairly trivial to determine excess mail from a particular IP
(if they want to hang up and connect again to get a new IP the volume
drops to trivial) and cut it off. Then you can go back and figure out
who the individual was later. If you can't map your use...@some.time
to the actual user you have a significant problem, you have also left
yourself open to some major legal problems because you have just left
yourself with no way to pass the buck when one of your users does
something illegal.
Roger
Curt Sampson
In article <32fef...@nomad2.HCSys.com>,
Roger Books <970805022...@mail.state.fl.us> wrote:
> > [re: roaming]
>
>This ones easy. You can allow connects from within each of the ISP's
>domains to 25 on the other end of the ISP's domains. Not a problem.
Um...I don't even know all the ISPs (of which there are several
thousand) that I share I-pass roaming with. There is a list, but
there's no list of IP addresses, and there are several score changes
on it every month. Your suggestion is entirely impractical.
> > [re: finding out which user is sending mail]
>
>it is fairly trivial to determine excess mail from a particular IP
>(if they want to hang up and connect again to get a new IP the volume
>drops to trivial) and cut it off.
Yes, but what about the person who gets that IP address fifteen
seconds later and wants to send out a message? There has to be a
real-time link into your terminal server authentication system.
Ronald F. Guilmette
In article <5dlsdg$7...@cynic.portal.ca>,
Curt Sampson <c...@cynic.portal.ca> wrote:
>In article <5d8eb4$8ah$1...@coredump.monkeys.com>,>>...block essentially all outgoing TCP connections from any
>>of your internal (non-firewall) machines to port 25 on any machine which
>>is outside of your domain.
>
>problem for ISPs that support roaming users. Where once a user
>could simply select a number off a list, dial in, and work as
>address for that particular ISP and know how to reconfigure his
>MUA to use that.
Is this hard???
>This may be trivially easy for you, but it's not
>for the vast majority of people out there...
Please do elaborate.
>>Also however, once you have forced all outbound mail from your site to
>>pass through one central choke-point, it become at least theoretically
>>possible to have the MTA on your central mail server actively limit
>>the amount of outbound traffic from any given individual user account
>>to some ``reasonable'' level.
>
>In practice it's the modifications you'd need to make to sendmail
>seem to me to be less than trivial. The only way you can find out
>what user is sending mail is to look up who is currently using that
>particular IP address.
Yea. So?
>There is no standard method of doing this.
Maybe not, but I'll lay odds right now that it is a piece of cake for most
ISPs.
Hell! The ISP _have_ to be able to determind who is using what line at
all time. If they couldn't, then how would they do billing???
>I would be interested to hear how you had planned to implement this.
Moi? Who said that _I_ was going to implement it?
Like I said, I'm working on the problem from the receiving end, and I'm
tied up with that. I can only hope that someone else tackels the sending
side of the problem.
Brad Knowles
In article <32fef...@nomad2.HCSys.com>,
970805022...@mail.state.fl.us wrote:
> Then don't use sendmail. I can do this easily from exim and I would
> guess qmail would allow it also. However, assuming you need sendmail,
> it is fairly trivial to determine excess mail from a particular IP
> (if they want to hang up and connect again to get a new IP the volume
> drops to trivial) and cut it off.
The particular MTA being used is not relevant -- the same problem
exists for all of them. In essence, how do you know, a priori, what user
is attached to what IP address, so that you can *prevent* them from
generating junkmail?
It's one thing to know that you can find out who they are later and
then bill them for it, but by the time you do that, the damage has already
been done -- the junkmail is already out. Besides, your odds of actually
collecting from junkmail generators like this is virtually nil --
remember, there are something like 2 billion credit cards in the U.S.
alone, for about 250 million people. That means there are a lot of credit
cards out there in the hands of some pretty shady people, and they already
have this credit card fraud thing down pat.
Sure, you can set arbitrary limits for all users, but then you have
created a different problem -- how do you allow people who legitimately
generate large quantities of mail to do so? And how do you distinguish
between them and the potential junkmailers, especially since they're all
probably going to have dynamically assigned IP address (assigned by a
router or a terminal server, not likely to be some program that can be
hacked to modify the in-addr.arpa tables to update who owns what on a
per-millisecond basis, especially not if it then has to be pushed out to
other nameservers and replace data they may already have in their cache).
If you're a regional ISP that has only one or two POPs, you don't
really have a problem. In fact, most users are probably already using
your mail machine as their outbound relay, and most of them probably would
not be significantly encumbered if you filtered all outbound port 25
connections to force that on them. Nor are the large ISPs that have VPNs,
because no matter where you are, you are supposedly "inside" their
network, and they can hack their nameservers so that they always return to
you the "local" mail server closest to you as your outbound mail relay.
Where you really get hurt is if you try to cross ISP/NSP/OSP
boundaries -- suddenly, you can't use one local ISP to send mail through
another one (as is becoming more and more common, from listening to the
Usenet newsgroups local to the ISP I use). Suddenly, all these products
that let you centralize all your accounts into just one place (Eudora Pro,
Claris Em@iler, etc...) can't be used to serve their primary
centralization function, because in the process of tightening the outbound
port 25 connections, you've surely also tightened down "relaying" of
non-local mail to non-local users.
Unfortunately for all of us, junkmail is something that fundamentally
*must* be stopped cold while it is in-process (or before). Trying to bill
someone for it after-the-fact, or anything else that is not done in "real
time" is simply not going to solve the problem -- you may catch
0.00000001%, but they'll route around you as quickly (or faster) than you
can adapt.
The *only* time they really get hurt is if you catch them before they
actually launch a junkmail attack (preventing them from using their
favourite tactics), or while they are in the early stages of an ongoing
attack. If your defenses are automatic and fast enough, they'll have a
*very* hard time getting through. And that means they'll go somewhere
else, and keep going somewhere else as more and more places get harder to
abuse, until such time as it's simply not worth the effort to go anywhere.
Fortunately, many of the automatic defenses will force them to fall
back to techniques that are much more likely to wind up with their carcass
in court for trademark infringement, and once they get all future wages
for the next ten thousand years garnisheed, maybe they'll start to wake
up.
brian moore
In article <5dno3b$n...@cynic.portal.ca>,
c...@cynic.portal.ca (Curt Sampson) writes:
> In article <32fef...@nomad2.HCSys.com>,
> Roger Books <970805022...@mail.state.fl.us> wrote:
>
>>(if they want to hang up and connect again to get a new IP the volume
>>drops to trivial) and cut it off.
>
> seconds later and wants to send out a message? There has to be a
> real-time link into your terminal server authentication system.
Doable with RADIUS (at least Livingston's, and all PM owners can
have the source code to that for free to hack around with). In fact
for part of our anti-spam efforts here, I got such a beastie working
tonight: in acct.c where it logs the start and stop records, have it
update the database of IP->username.
Stored as a (db/dbm/ndbm/gdbm/etc) file, sendmail can grok it and
insert an X-Authenticated-User: line on the mail to make sure people
are responsible for what they write.
If it becomes a problem, port 25 filters may have to go in place,
but hopefully more people will secure their mail ports against
relaying and this won't be an issue.
Source code to my hacks will be available once I'm done playing
with it. It's about 20 lines tops.
--
Brian Moore The opinions expressed above are my own, not
Sysadmin, C/Perl Hacker necesarily my employers'.
Curt Sampson
In article <5dohkj$303$1...@monkeys.com>,
Ronald F. Guilmette <r...@monkeys.com> wrote:
>In article <5dlsdg$7...@cynic.portal.ca>,
>Curt Sampson <c...@cynic.portal.ca> wrote:
>>...now the user must somehow find out the SMTP mail server
>>address for that particular ISP and know how to reconfigure his
>>MUA to use that.
>
>Is this hard???
Yes, this is very hard for most users.
>>This may be trivially easy for you, but it's not
>>for the vast majority of people out there...
>
>Please do elaborate.
You've obviously never worked at a technical support desk. You know
those stories you hear about people who don't know how to use a
scroll bar, and telephone technical support to ask why so many web
pages are cut off at the bottom? Well those stories are *true*.
>Hell! The ISP _have_ to be able to determind who is using what line at
>all time. If they couldn't, then how would they do billing???
ISPs don't have to bill in real time.
>>I would be interested to hear how you had planned to implement this.
>
>Moi? Who said that _I_ was going to implement it?
Well, you said it was simple. You must have had some thought of how
to impelement it simply, no?
Roger Books
Curt Sampson (c...@cynic.portal.ca) wrote:
: >
: >it is fairly trivial to determine excess mail from a particular IP
: >(if they want to hang up and connect again to get a new IP the volume
: >drops to trivial) and cut it off.
:
: Yes, but what about the person who gets that IP address fifteen
: seconds later and wants to send out a message? There has to be a
: real-time link into your terminal server authentication system.
Nope, when user x logs out the tacacs authentication informs my server
immediately.
Before you say "YOU CAN'T" you should learn a bit about tacacs, radius,
and SNMP. I have the same granularity with my users coming in through
the dialup as I would if they were actually able to log into my unix
tacacs server.
If I didn't have tacacs (although how I would manage authentication
without it I'm not sure) I could do the same thing with SNMP traps.
New user logs in my Cisco 5200 sends a trap with the info. User
logs out Cisco sends another trap.
Roger
Roger Books
Brad Knowles (br...@his.com) wrote:
> The particular MTA being used is not relevant -- the same problem
> exists for all of them. In essence, how do you know, a priori, what user
> is attached to what IP address, so that you can *prevent* them from
> generating junkmail?
The answer is I don't really care. The only thing I really need to deal
with is mailing lists, and I can run those on my server. Simplest case
I just make sure they don't send more than X amount of mail.
In actuallity it should not be beyond the capability of any competant
SA to map IP->Users. They have to log into the server, if you are a
big outfit you are use tacacs or something similar and you log the ins
and outs. Automatically going through the log to find who is which is
no big deal, and sendmail proxies are fairly easy to write.
> It's one thing to know that you can find out who they are later and
> then bill them for it, but by the time you do that, the damage has already
> been done -- the junkmail is already out. Besides, your odds of actually
> collecting from junkmail generators like this is virtually nil --
> remember, there are something like 2 billion credit cards in the U.S.
> alone, for about 250 million people. That means there are a lot of credit
> cards out there in the hands of some pretty shady people, and they already
> have this credit card fraud thing down pat.
We stop it before it reaches these limits.
> Sure, you can set arbitrary limits for all users, but then you have
> created a different problem -- how do you allow people who legitimately
> generate large quantities of mail to do so? And how do you distinguish
> between them and the potential junkmailers, especially since they're all
> probably going to have dynamically assigned IP address (assigned by a
> router or a terminal server, not likely to be some program that can be
> hacked to modify the in-addr.arpa tables to update who owns what on a
> per-millisecond basis, especially not if it then has to be pushed out to
> other nameservers and replace data they may already have in their cache).
If you can't figure out who is logged into what IP address at any time you
have a problem. I can, you really need to go out and learn a bit about
SNMP. This is a trivial problem. Going through logs is also a fairly
trivial problem.
> Where you really get hurt is if you try to cross ISP/NSP/OSP
> boundaries -- suddenly, you can't use one local ISP to send mail through
> another one (as is becoming more and more common, from listening to the
> Usenet newsgroups local to the ISP I use). Suddenly, all these products
> that let you centralize all your accounts into just one place (Eudora Pro,
> Claris Em@iler, etc...) can't be used to serve their primary
> centralization function, because in the process of tightening the outbound
> port 25 connections, you've surely also tightened down "relaying" of
> non-local mail to non-local users.
Basic rule of thumb that should be fairly obvious, the more you tighten
security the more difficult the system becomes to use. And yes, relaying
of non-local-mail->non-local-users should probably go away. There is no
real reason for it. reply-to's and forwards work fine.
> Unfortunately for all of us, junkmail is something that fundamentally
> *must* be stopped cold while it is in-process (or before). Trying to bill
> someone for it after-the-fact, or anything else that is not done in "real
> time" is simply not going to solve the problem -- you may catch
> 0.00000001%, but they'll route around you as quickly (or faster) than you
> can adapt.
If they can't go out on 25 and are forced to go through the ISP who has
a quota system they can't "go around" me. And I can easily stop 99% while
have 99.5% of my users never notice a thing, especially if they are warned
ahead of time "this is a non-UCE supporting site, if more than X mail
messages are sent within X minutes the mail will be held for examination
for UCE's by the sysadmins".
To be completely honest you don't have to stop 100% of the UCE'ers. You
only need to make it so difficult that it is not econimically feasable.
Stopping things on the ISP side is doable. Unfortunately a dedicated
UCE'er could get his own connection. He runs sendmail in outgoing mode
only. Until we can add him to the list of UCE generators he is free and
clear. What we need to be able to do is get him on that list before he
is able to recover the cost of the new site. Is that do-able? I don't
know. Cable-Modems and ADSL may make this impractical.
Roger
Roger Books
Curt Sampson (c...@cynic.portal.ca) wrote:
: In article <5dohkj$303$1...@monkeys.com>,: >In article <5dlsdg$7...@cynic.portal.ca>,
: >Curt Sampson <c...@cynic.portal.ca> wrote:
: >>...now the user must somehow find out the SMTP mail server
: >>address for that particular ISP and know how to reconfigure his
: >>MUA to use that.
: >
: >Is this hard???
:
: Yes, this is very hard for most users.
Hard? The only people that don't do this are the smtp competant ones.
Most users already set the smart mail forwarder in netscape or whatever
machine they happen to be using. It's trivial even for the barely
computer literate.
:
: >>This may be trivially easy for you, but it's not
: >>for the vast majority of people out there...
: >
: >Please do elaborate.
:
: You've obviously never worked at a technical support desk. You know
: those stories you hear about people who don't know how to use a
: scroll bar, and telephone technical support to ask why so many web
: pages are cut off at the bottom? Well those stories are *true*.
I do tech support all the time. If a user can switch phone-numbers
when he goes roaming he can switch his smart-mail-forwarder setting.
:
: >Hell! The ISP _have_ to be able to determind who is using what line at
: >all time. If they couldn't, then how would they do billing???
:
: ISPs don't have to bill in real time.
If I am providing a connection to the internet and somebody comes through
me and hacks another system, I could very well be liable. If I don't have
a way to map IP's back to who was on when, I've just left my rear hanging
in the wind. If you aren't doing that at Portal how are you going to deal
with the litigation when you can't pass the buck to the perpetrator? What
are you going to do when ONE OF YOUR OWN USERS decides to SYN attack you
because he didn't like the way you talked to him?
: >>I would be interested to hear how you had planned to implement this.
: >
: >Moi? Who said that _I_ was going to implement it?
:
: Well, you said it was simple. You must have had some thought of how
: to impelement it simply, no?
:
Yes, it is simple. Why am I not implimenting it? Because my workers are
state workers, a UCE from them doesn't just get their hands slapped, it
could get them fired or even prosecuted under Florida Laws. It currently
isn't a big deal for me. Also, if I did it I would probably do it as
a filter for exim, so it might not do everyone out there a ton of good.
Hmmm, I do have a few users who can't figure out how to set their "who
I am" string in netscape. That sounds like a good project, tack that
on. As soon as I finish my current Java/C/tcl project I'll start on that.
Roger
Steve Tupy
So like, b...@news.cmc.net (brian moore) was 'splainin' :
>In article <5dno3b$n...@cynic.portal.ca>,
> c...@cynic.portal.ca (Curt Sampson) writes:
>Doable with RADIUS (at least Livingston's, and all PM owners can
>have the source code to that for free to hack around with). In fact
>for part of our anti-spam efforts here, I got such a beastie working
>tonight: in acct.c where it logs the start and stop records, have it
>update the database of IP->username.
That's what we use here with our PM-3's and we love it. We also use
the choicenet features and enjoy them as well. Radius cannot interact
with sendmail, though. Also, knowing what actual address they were on
in the pool does not really help in stopping unwanted email traffic,
at least that is what we have found.
>Stored as a (db/dbm/ndbm/gdbm/etc) file, sendmail can grok it and
>insert an X-Authenticated-User: line on the mail to make sure people
>are responsible for what they write.
Now you are cooking with oil! This is *the* solution for us. It is
reliable, not caring about IP's, per say, but rather usernames. Our
policy is to bill according to traffic used. A certain amount is
assumed as part of a standard account and the extra traffic is billed
accordingly. I feel that as an ISP, it is not my concern to be all
users 'police' department. I am more concerned with illegalities and
my ability to provide local authorities with any and all pertinent
info in aiding them to prosecute(if that is what becomes required of
me as an ISP) the offending user. Certain privacy must be afforded the
end user, essentially tying your hands to become any much more
involved in the process. Just my opinion, of course... :)
Take care!
***********************************************************
Steve Tupy
CompuData Systems
Home of Base Runner, Userstat, The Enforcer, SpotChek etc...
brian moore
In article <5dqu2c$n...@waldo.whisp.com>,
>>insert an X-Authenticated-User: line on the mail to make sure people
>>are responsible for what they write.
>
> Now you are cooking with oil! This is *the* solution for us. It is
> reliable, not caring about IP's, per say, but rather usernames.
Exactly: dynamic IP's mean nothing to anyone without /var/adm/radactt/*
files and grep..... but X-Authenticated-User: means much. :)
> Our
> policy is to bill according to traffic used. A certain amount is
> assumed as part of a standard account and the extra traffic is billed
> accordingly. I feel that as an ISP, it is not my concern to be all
> users 'police' department.
As long as I don't get complaints from other sites, I don't care what
our users do. They can look at naughty web pix all day, or download
MIDI Bach files. They pay for access and as long as they respect other
people's systems they can do whatever they want. From looking at the
bandwidth patterns, god only knows what they're doing (some nights there
are tons of people logged in at our POPs and they don't seem to do
ANYTHING), but hey, if we're just there to keep their line busy, that's
cool. Seems sorta strange, but to each his own. :)
> I am more concerned with illegalities and
> my ability to provide local authorities with any and all pertinent
> info in aiding them to prosecute(if that is what becomes required of
> me as an ISP) the offending user. Certain privacy must be afforded the
> end user, essentially tying your hands to become any much more
> involved in the process. Just my opinion, of course... :)
They have all the privacy they want: they just can't pretend to be
someone else without leaving little trails that keep me mostly out
of the loop. :) If they want to use my mailserver, the username they
authenticated with will be stamped on the letter. In 99.99999% of
legit users it will mean precisely nothing: it will just match the
From: line.
The rare troublemaker will have a nice trail left pointing at him
not my server. :)
[A side advantage is this is a nice security increase in knowing exactly
who has what IP: 3 lines of Perl and I can grok their username when they
hit our change-password page, which means the only account they can even
TRY to change passwords on is the one they logged in with. :)]
Now that RADIUS is mostly hacked (silly PM's allow spaces in the usernames
so we have users with accounts like "john" authenticated as "john smith"....
I need to fix that. :)), it's time to figure out how to generate headers
in sendmail based not on mailer flags, but on whether a db lookup
succeeds.
Ronald F. Guilmette
In article <5dp60l$oim$2...@news.cmc.net>, brian moore <b...@news.cmc.net> wrote:
>Stored as a (db/dbm/ndbm/gdbm/etc) file, sendmail can grok it and
>insert an X-Authenticated-User: line on the mail to make sure people
>are responsible for what they write.
>
>but hopefully more people will secure their mail ports against
>relaying and this won't be an issue.
>
>Source code to my hacks will be available once I'm done playing
>with it. It's about 20 lines tops.
You're a good man. We need more like you.
Curt Sampson
In article <5dqu2c$n...@waldo.whisp.com>, Steve Tupy <st...@whisp.com> wrote:
>So like, b...@news.cmc.net (brian moore) was 'splainin' :
>
>> c...@cynic.portal.ca (Curt Sampson) writes:
>>Doable with RADIUS (at least Livingston's, and all PM owners can
>>have the source code to that for free to hack around with). In fact
Please note that I did not write any of the above, although it
could be interepreted from this that I did. Be a bit more careful
with editing your inclusions, folks.
Curt Sampson
In article <3300b...@nomad2.HCSys.com>,
Roger Books <970805022...@mail.state.fl.us> wrote:
>Hard? The only people that don't do this are the smtp competant ones.
>Most users already set the smart mail forwarder in netscape or whatever
>machine they happen to be using. It's trivial even for the barely
>computer literate.
Never mind. You obviously have no clue about the cost and effort
needed for technical support. By `hard' I mean that the vast majority
of users will have to call in for support for this. I can't afford
to pay for that.
>If I am providing a connection to the internet and somebody comes through
>me and hacks another system, I could very well be liable. If I don't have
>a way to map IP's back to who was on when, I've just left my rear hanging
>in the wind. If you aren't doing that at Portal how are you going to deal
>with the litigation when you can't pass the buck to the perpetrator?
Where on earth did you ever get the idea that I can't map IP
addresses to names? Please re-read the thread.
>Yes, it is simple.
So explain how to implement it, then, rather than going around in
circles. If you don't have a clue how to implement it, you can't
know whether it's simple or not, can you?
Roger Books
Curt Sampson (c...@cynic.portal.ca) wrote:
: In article <3300b...@nomad2.HCSys.com>,
: Roger Books <970805022...@mail.state.fl.us> wrote:
:
: >Hard? The only people that don't do this are the smtp competant ones.
: >Most users already set the smart mail forwarder in netscape or whatever
: >machine they happen to be using. It's trivial even for the barely
: >computer literate.
:
: Never mind. You obviously have no clue about the cost and effort
: needed for technical support. By `hard' I mean that the vast majority
: of users will have to call in for support for this. I can't afford
: to pay for that.
Do your users have to, or do they not have to, change there phone number
when they roam? And yes, I do have a clue, lately that's what I spend
most of my time doing.
:
: >If I am providing a connection to the internet and somebody comes through
: >me and hacks another system, I could very well be liable. If I don't have
: >a way to map IP's back to who was on when, I've just left my rear hanging
: >in the wind. If you aren't doing that at Portal how are you going to deal
: >with the litigation when you can't pass the buck to the perpetrator?
:
: Where on earth did you ever get the idea that I can't map IP
: addresses to names? Please re-read the thread.
That one should be obvious, you keep talking about how difficult it
is to know who is sending e-mail because they come in on different IP's.
I believe you were asking "what if a user comes on 15 seconds after the
spammer? You'll deny her e-mail" or words to that affect.
:
: >Yes, it is simple.
:
: So explain how to implement it, then, rather than going around in
: circles. If you don't have a clue how to implement it, you can't
: know whether it's simple or not, can you?
Arggh, before I start calling YOUR competancy into account I will back
off from this arguement. And I am going to impliment it as an X-header.
I'm tired of people having <> as their return address and then sending
stuff off to invalid sites or places that refuse connections. The
garbage sits in my queue and I want to easily be able to tell who sent
it so I can e-mail them as to how to fix their PC. Of course, my
solution will probably be specific to my setup. (Cisco 5200's running
SNMP, exim as my mail package.) Maybe I'll do it in Java just because
doing it in scotty would be too trivial. Well see.
Roger
Steve Sobol
Just pointing out something:
Ronald F. Guilmette (r...@monkeys.com) wrote:
: >>No ISP, no matter how good they are, can make email spamming impossible.
: >
: >That is utter bullshit and you know it. The methods for accomplishing
: >this have been discussed here on more than one occasion, and in some
: >detail. ISPs can force all outgoing mail to be routed through THEIR
: >OWN Mail Trnasfer Agent... at least in the first instance, and that
: >can provide a ``choke point'' where the outbound flow can be limited...
: >*if* anyone care to do it, and there have been reports here that *some*
: >ISPs have in fact done just that.
Aren't you talking about preventing yourself being used as a relay? That
in fact is very easy to do. It seems to me that possibly Chris was talking
about incoming mail to your users too. You can protect yourself partially
from that kind of thing, but not completely.
: Basically, the idea is that somewhere between your site and the rest of
: the Internet you probably already have either a router or a firewall or
: both. Either one of these _should_ be configurable so as to allow you
: to absolutely block essentially all outgoing TCP connections from any
: of your internal (non-firewall) machines to port 25 on any machine which
: is outside of your domain.
:
: What you have then is a situation where your internal users are all forced
: to send mail through your central MTA (Mail Transfer Agent... usually the
: sendmail program) running on your firewall machine, and then _this agent_
: is the only agent which actually has the power to connect out of your
: domain to other people's machines on port 25.
:
: This is the way many sites operate _normally_ anyway.... i.e. having all
: ``normal'' mail go through a local ``mail hub'' machine... which is often
: the same machine as the local firewall machine.
:
: This is a fairly common way to run a site, and it keeps most ordinary
: users in line. But the problem is that unless you also block _direct_
: outbound TCP access to port 25 of other machines outside of your domain,
: the really unscruplous end users (i.e. the mass junk E-mailers) can
: easily do an ``end run'' around your central mail server/forwarder.
:
: Just by forcing them to _always_ go through your own central mail server
: (rather than playing these custey games that some of the UCEers are playing
: these days by writing their own mass junk E-mailing programs that directly
: connect out on port 25) you get certain advantages. For one thing, you
: slow them down... and they don't like that, so the astute UCEers... which
*This* is a good idea. I LIKE it. Shouldn't be too hard to implement either.
I'm going to bounce it around here... see what people say about it.
: the origination point. Many do not. Thus, I have spent the entire month
: of January working instead on implementing new code for the receiving
: end which I hope will make life much much harder on the mass junk E-mailers
: once it is released for general use.
Would you possibly want to get paid for licensing that code?
I've FINALLY got my compiler re-installed under NT and I am FINALLY starting
work on the package I said I wanted to start so many months ago.
: something new for the receiving end, I do sincerly hope that _someone_ will
: take up the (modest) challenge of implementing some effective, non-circum-
: ventable controls for the sending end also. Lord knows that we can certainly
: use all of the help we can get in fighting this new scourge.
I think there may be more ISP's willing to work with you than you might
think.
--
Steve Sobol, | Tech Support, New Age Consulting [ sjs...@nacs.net ]
Professional | Also doing Website Design and Windows/UNIX Programming:
Internet | E-mail North Shore Technologies [ sjs...@nstc.com ]
Guru | Report UCE/Usenet abuse to me at [ ab...@nacs.net ]
Ronald F. Guilmette
In article <5dpf2j$d...@cynic.portal.ca>,
Curt Sampson <c...@cynic.portal.ca> wrote:
>In article <5dohkj$303$1...@monkeys.com>,
>Ronald F. Guilmette <r...@monkeys.com> wrote:
>>Moi? Who said that _I_ was going to implement it?
>
>Well, you said it was simple. You must have had some thought of how
>to impelement it simply, no?
I think that I already sketched the basic outline of what I was thinking
about.
I don't have any more than that.
Basically, for ordinary dial-up users, you force all of their outgoing
mail through your onw certral ``choke point'' MTA. You then arrange to
have this MTA actually know the identity of each ``local'' user who sent
it mail. (This is the part which has been discussed most elaborately
here already I think, and I have nothing of value to add to that part
of the discussion.) Then you just have the MTA keep counts for number
of outgoing messages for each user during the current 24 hour period.
(All counters should be reset to zero at say, 3 AM.)
For each specific user, there is a user-specific count limit imposed
by the MTA... say no more than 100 outgoing messages per 24 hour period
for an ordinary user. (For trusted local operators of mailing lists,
the limit would obviously have to be much higher.)
That's it. That the whole idea in a nutshell. If a user tries to send
more than his limit, the excess messages just start getting bounced back
to him by the local ``choke point'' MTA.
Curt Sampson
In article <33023...@nomad2.HCSys.com>,
Roger Books <970805022...@mail.state.fl.us> wrote:
>Curt Sampson (c...@cynic.portal.ca) wrote:
>:
>: Where on earth did you ever get the idea that I can't map IP
>: addresses to names? Please re-read the thread.
>
>That one should be obvious, you keep talking about how difficult it
>is to know who is sending e-mail because they come in on different IP's.
So in other words, you are of the firm belief that if I have the
ability to match IPs to users using log files on a system that's
completely separate from my mail server, I suddenly have the ability
to do real-time matching on my mail server as well?
Kenneth Herron
|> real-time link into your terminal server authentication system.
|
|Stored as a (db/dbm/ndbm/gdbm/etc) file, sendmail can grok it and
|insert an X-Authenticated-User: line on the mail to make sure people
|are responsible for what they write.
I'll bet your radius server is right next to your mail server, or maybe
they're even the same computer? Think bigger. We're using radius too,
but we have multiple authentication systems at multiple locations, and
multiple mail servers also at multiple locations. Accounting records
are brought together at 15-minute intervals for billing, but that's not
sufficient granularity for email stamping.
So for us, email authentication becomes a question of maintaining a
central database (or multiple distributed copies of that database) with
realtime updating and querying from remote sites. And don't forget
that Internet links go down from time to time, and that the servers in
the field should continue to operate autonomously during that time.
--
Kenneth Herron khe...@campus.mci.net +1 916 649 6142
No animals were harmed during the production of this message.
brian moore
In article <5e4sg3$6dl$1...@news.campus.mci.net>,
khe...@campus.mci.net (Kenneth Herron) writes:
> In article <5dp60l$oim$2...@news.cmc.net>, brian moore <b...@news.cmc.net> wrote:
>|> There has to be a
>|> real-time link into your terminal server authentication system.
>|
>|Doable with RADIUS...
>|Stored as a (db/dbm/ndbm/gdbm/etc) file, sendmail can grok it and
>|insert an X-Authenticated-User: line on the mail to make sure people
>|are responsible for what they write.
>
> I'll bet your radius server is right next to your mail server, or maybe
> they're even the same computer? Think bigger. We're using radius too,
> but we have multiple authentication systems at multiple locations, and
> multiple mail servers also at multiple locations. Accounting records
> are brought together at 15-minute intervals for billing, but that's not
> sufficient granularity for email stamping.
Are your mail servers in the same locations as your radius servers? As
for looking at radius logs: blech. No, thanks. radacct gets too big too
quick to use: hence why you hack radius to keep an updated ip->name
database. One record per IP beats 20 some lines for every connect/drop.
> So for us, email authentication becomes a question of maintaining a
> central database (or multiple distributed copies of that database) with
> realtime updating and querying from remote sites. And don't forget
> that Internet links go down from time to time, and that the servers in
> the field should continue to operate autonomously during that time.
Why a central database when you have remote SMTP servers and remote
RADIUS servers?
Gus
Curt Sampson (c...@cynic.portal.ca) wrote:
: In article <33023...@nomad2.HCSys.com>,
: Roger Books <970805022...@mail.state.fl.us> wrote:
: >
: >That one should be obvious, you keep talking about how difficult it
: >is to know who is sending e-mail because they come in on different IP's.
: So in other words, you are of the firm belief that if I have the
: ability to match IPs to users using log files on a system that's
: completely separate from my mail server, I suddenly have the ability
: to do real-time matching on my mail server as well?
It really doesn't sound that difficult, if I may say so. Perl, crond,
netpipes and a little experimentation should solve the problem pretty
sharpish.
Perhaps an RPC module, combined with TCP wrappers would enable the
identifying machine to serve that information on request to the mailhubs.
It really is high time that the tools for restricting bulk email abuse
were as common as bulk email abuse systems, and slightly embarrasing that
the community is so far behind.
just my 00.2
--
- an...@intasys.com -
= http://www.thepulse.co.uk/angus =
-= 82 AA 4D 7F D8 45 58 05 6D 1B 1A 72 1E DB 31 B5 =-
But what if there were no hypothetical situations ?
Roger Books
brian moore (b...@news.cmc.net) wrote:
: Are your mail servers in the same locations as your radius servers? As
: for looking at radius logs: blech. No, thanks. radacct gets too big too
: quick to use: hence why you hack radius to keep an updated ip->name
: database. One record per IP beats 20 some lines for every connect/drop.
What about SNMP? I can easily find out who is logged into which port on
my Cisco 5200's (and the 5100 which is really a USR product), and mapping
the IP's which are statically assigned to ports to the user is fairly
trivial. As a matter of fact I already have a Scotty script that pulls
out all users logged in, what port they are on, and what IP they have.
With a little effort I could easily turn this into something where I
feed the IP in and get the current user out. Of course, this does
depend on using static IP's for each port, but that was also something
fairly easy to impliment.
Roger
Roger Books
Curt Sampson (c...@cynic.portal.ca) wrote:
: >: Where on earth did you ever get the idea that I can't map IP
: >: addresses to names? Please re-read the thread.
: >
: >That one should be obvious, you keep talking about how difficult it
: >is to know who is sending e-mail because they come in on different IP's.
:
: So in other words, you are of the firm belief that if I have the
: ability to match IPs to users using log files on a system that's
: completely separate from my mail server, I suddenly have the ability
: to do real-time matching on my mail server as well?
:
I did not say that. YOU may not have the ability. One the requirements
(IMNSHO) of a decent sysadmin is the ability to do at least a minimal
amount of scripting. At least scripting in your favorite shell, and
realisticly TCL/TK or perl. Your choice. If you have competancy in
any of these areas, and have minimal proficiency with sendmail realtime
mapping of IP to username should be no big deal. For a high volume
setup I personally would recommend scotty and SNMP, but if you are a
shoestring operation who is constantly reacting to fires instead of
insuring they don't occur you may not have this option.
Roger