A new virus is spreading like wildfire today. I've gotten well over
400 e-mail messages generated by the damn thing, and seeing as they
all have binary attachments, they're *big*! Twice, I got notices
that I was over my ISP's e-mail quota, and had better clear stuff
out before I started losing e-mail.

(I don't have stuff e-mailed directly to my box. First, I occasionally
take the box offline for hardware maintenance, and don't want to risk
losing e-mail during those periods. Second, it saves me the trouble of
securing sendmail, or configuring and securing a replacement: I can
just firewall off port 25, and use it purely for local operations.)

Well, if I were using Windows, then I'd probably be moving my legit
e-mail to another account. But I'm not, so I'm not! Turns out the
box already has fetchmail installed... the tricky part was coming up
with a well-constructed .fetchmailrc, which was *not* do-able from
the man page, I'm afraid. I'm sure fetchmailconf would do a fine
job, but I haven't got it installed at the moment.

So I google a bit, experiment a bit, and after a few tries, hit upon
the magical combination:

set daemon 900
poll <pop3-server.isp.com> with proto POP3 and options timeout 300
user <username> there with pass <password> is <local-user> here

Then I kick it off with 'fetchmail' and it works! Okay, so using
Balsa is now slightly less convenient, but this is still *way*
preferable to just suffering the flood unassisted.

For those of you who are also being flooded, here are some rules for
your spam filter that will catch almost 100% of the junk:

From: contains "Microsoft"
body contains "Cumulative Update"
body contains "Undeliverable to"
body contains "Undeliverable mail to"
body contains "Undeliverable message to"
body contains "Undelivered to"
body contains "Undelivered mail to"
body contains "Undelivered message to"

(Even elrav1 users can use this! Translate these rules into procmail
format and add them to your .procmailrc file, above the elrav1-generated
stuff. This saves you from sending RAVs to the almost-certainly-forged
From: addresses.)

Ed Murphy <emurphy42@socal.rr.com> wrote:
It's going to be bad tonight when I get home...
Very bad.

I noticed it last night when I'd got 128 e-mails in the space of 3 hours...
So, I told fetchmail to download them, and deleted them, and by the time
it'd finished, I ran it again, and there were 30 more. There were another 7
waiting for me when I downloaded a third time, so, judging by this, I think
I'll be better off risking the loss of a mail or two and hitting

when I get home, cos I think there'll be 1500 waiting. (if that doesn't
exceed my mailbox size)

Ed Murphy <emurphy42@socal.rr.com> wrote:
So far, I've been catching 100% of them with this procmail recipe:

:0 B :
* the latest version of security update
in_fake_security_updates


That "security update" line seems to be in all of them, even though
the rest of the text changes.

So far, I've got over 40M of these things. I can't wait until I get
back to work from vacation. I think I'd better VPN in and add that rule
to my procmail there...


--
Jim Buchanan jbuchana@buchanan1.net
=================== http://www.buchanan1.net/ ==========================
"Lisp has all the visual appeal of oatmeal with fingernail clippings
thrown in. (Other than that, it's quite a nice language)" -Larry Wall
================= Visit: http://www.thehungersite.com ==================

On Fri, 19 Sep 2003 06:00:29 GMT, Ed Murphy
<emurphy42@socal.rr.com> wrote:
body contains "audio/x-midi"
body contains "application/x-msdownload"


--
Commander Spiral Pyjama Pseudo-Rhinocerous Feline Thingamajig Bill Marcum
(the First)
Ozy and Millie Name Generator http://heifong.phase.org/omname.php

On Fri, 19 Sep 2003 06:00:29 GMT, Ed Murphy <emurphy42@socal.rr.com> wrote:
Thanks for that, Ed. A good idea. I'll send this post out to folks.

For me, personally, I already send any mail from strangers over 20k to
/dev/null.

The problem is not with any user software in the case of dial-up
accounts like mine, it's with the fact that even when I use procmail
to delete mails on the SERVER that are over 20K, it is full again in
the same amount of time.

I've been looking over that virus, and if you were willing to kill any
mail containing mime or uuencode that wasn't from someone on your passlist,
then it would be pretty easy to eliminate them.

With procmail you could pipe all mail not from someone on your passlist
through a script that would would count the number consecutive lines with
no spaces ^[^ ][^ ]*[^ ]$ ( I think that regex would do it ) and if the
number was over, say, 50 ,then it's history.

Cheers,

Alan C

--

take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
spammers hate this program because they can't beat it

In article <UJCab.517420$YN5.343608@sccrnsc01>,
jbuchana@buchanan1.net writes:
My own custom procmail rules have were getting them all without any need
to reconfigure for this latest flood. What I'm concerned about myself is
that this flood is so huge it may put me over the daily bandwidth
allotment from my ISP (Cox), which is normally plenty big.

So, does anybody have any pointers to something that I can run before
using fetchmail to grab my mail that'll download headers and delete all
the messages that match some simple criterion? I've heard of such
programs for Windows or integrated into mail readers, but I don't know of
anything that'll work as a standalone tool that could be called before
fetchmail. Any pointers?

--
Rod Smith, rodsmith@rodsbooks.com
http://www.rodsbooks.com
Author of books on Linux, FreeBSD, and networking

On Fri, 19 Sep 2003 18:47:38 -0400, Rod Smith wrote:

telnet pop.cox.com 110
user rodsmith
pass password
list

+OK 1 messages
1 147152
dele 1

If the message is 145KB or so it is one of those MS crap things.

On Fri, 19 Sep 2003 18:47:38 -0400, Rod Smith <rodsmith@nessus.rodsbooks.com> wrote:
:0
* ^FROM.*MicroSoft
{ HOST }

That will delete any mails matching that recipe while it is still on
the server. Is that what you wanted?

I use fetchmail > formail > procmail > inbox

You must, I have been told (and do, but have not tested) put ~/.procmailrc
(or whatever procmailrc you use) on the commandline after procmail, and in
my case it goes into my .fetchmailrc:

and wants mda "/usr/bin/formail -ds /usr/bin/procmail ~/.procmailrc"

Alan C

--

take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
spammers hate this program because they can't beat it

On Fri, 19 Sep 2003 22:18:50 +0000, Alan Connor wrote:

I'd rather just killfile anything containing an attachment whose filename
ends in one of the following (case-insensitive):

..com
..exe
..bat
..pif
..scr

Someone posted (in another thread) a URL with a .procmailrc that
apparently does this. I'm making it my weekend project to figure
out and implement procmail. (Prior to this week's virus flood,
Balsa's built-in filtering system has been adequate to meet my
needs.) If it can kill the messages at the server (or if I can
combine it with your suggestion to make it do so), all the better!

I've got fetchmail grabbing mail every 15 minutes and I *still*
got three you-are-over-quota messages! I really hope that the
perpetrator of this stunt becomes the first contestant on a new
TV show called "Bake the Traitor"...

On Fri, 19 Sep 2003 17:48:01 -0400, Bill Marcum wrote:

Not bad. Indeed, this week's virus flood is taking advantage of the old
"naw, I'm not an executable, I'm just a harmless sound file!" security
hole in older versions of Outlook Express. I'd still rather filter on
the name of the attachment, though, rather than the claimed MIME type.

I also hear that it tries to disable several anti-virus programs, so a
fair number of viruses I've never heard of are also taking part in the
flood. (I wonder how much of the rapid spread is due to this particular
aspect of the virus? It's the computer equivalent of HIV! I hope the
popular media picks up that phrase and runs with it, so that this flood
will get the publicity it deserves.)

Dave Uhring <daveuhring@yahoo.com> wrote:
Well, yeah but... I've gotten roughly 5000 emails in the past
36 hours or so, and I just didn't see either download them or
manually deleting them as a potential way to spend the next week
or two!

I let it build up to something like 4500 message, and 600 Mb of
email by just shutting off fetchmail's access to the account
that is being hit. I was wondering if the ISP had a reasonable
limit, and apparently they don't!

Then I modified my fetchmailrc file to have these options turned
on: fetchall, expunge 10, nokeep, and limit 1200.

I then manually invoked "fetchmail -v -v" twice and let it show
me what it was doing. That allowed it to download every email
that was smaller than 1200 bytes in size. Then I invoked it
again as "fetchmail -v -v -F", and it proceeded to slowly but
surely delete, rather than download, 4500 email messages.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

On Fri, 19 Sep 2003 23:43:30 GMT, Ed Murphy <emurphy42@socal.rr.com> wrote:
hehe

The only problem I see with the above, Ed, is that no one could include
a URL with .com in it, although maybe that wouldn't matter with an
attachment?????

Did you catch Dave Uhring's telnet lesson above? Very cool. I new how
to use telnet to send mail through my ISP's smtp server, but not how
to read my mail and delete it too, before downloading. Not as useful
as the procmail trick, but nice to know.

By-the-way, a lot of elrav1 users pre-filter their mail to cut down
on useless RAVs. We just don't use any recipes that might catch mail
we want to get because there is only one destination in elrav1 for
rejected mail: /dev/null. In fact, /dev/null is the default procmail
'mailbox' DEFAULT=/dev/null. Mail has to prove itself or be rejected.
The door is normally-closed, so-to-speak, which is the opposite of
how the other UM strategy works.

Plus there's the fact that if I elrav1 receives a third mail from an
address that has failed to return an RAV twice in the past, all mail
from that address is sent to /dev/null from then on. So we are not
sending anywhere near the number of useless RAVs that some people
think...

Later,

Alan C

--

take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
spammers hate this program because they can't beat it

In article <DkMab.10357$BS5.2374@newsread4.news.pas.earthlink .net>,
Alan Connor <alanconnor@earthlink.net> writes:
In a procmail recipe, that runs them AFTER they've been downloaded from
my ISP's mail server (via fetchmail) to my local system. (They're still
on my LOCAL mail server, of course, but that won't help me keep the
latest worm from chewing up a substantial fraction -- or all -- of my
bandwidth allotment from Cox.) I was looking for a tool that would
download the headers only and delete the worst of the worms based on
header information alone, WITHOUT wasting my bandwidth getting the worms.

--
Rod Smith, rodsmith@rodsbooks.com
http://www.rodsbooks.com
Author of books on Linux, FreeBSD, and networking

In article <pan.2003.09.19.23.18.56.77568@yahoo.com>,
Dave Uhring <daveuhring@yahoo.com> writes:
Well, probably, but I'm not going to do that manually for hundreds or
thousands of copies of this worm. I was hoping for something that would:

- Do this automatically
- Be a bit smarter than just looking at the e-mail size (I do receive
vital e-mails with attachments that are roughly this size)

It's not really a terribly complex programming task, true, but I was
hoping to avoid re-inventing this particular wheel, if at all possible.
(Besides, by the time I got around to it, this particular flood would
probably be over.)

--
Rod Smith, rodsmith@rodsbooks.com
http://www.rodsbooks.com
Author of books on Linux, FreeBSD, and networking

Oops! rodsmith@nessus.rodsbooks.com (Rod Smith) was seen spray-painting on a wall:
fetchmail has the "-l --limit" option which _might_ do the trick;
that defers messages larger than the specified size.

You would then go back and "fetchmail -F" or "fetchmail --flush" to
delete the "already seen" messages, which would be the ones that were
too big.

Unfortunately, if your MTA isn't running right, this can throw away
messages. The risk may be worthwhile. I'll be experimenting with
this...
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://www.ntlug.org/~cbbrowne/
"take USABLE from UNSTABLE and you get NT"

Oops! "Ed Murphy" <emurphy42@socal.rr.com> was seen spray-painting on a wall:
I had to drop timing down to 10 seconds between attempts. In joyous
times like these, there honestly is a continual stream of mail going
through, and there's honestly no sense in sleeping afterwards.
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/
Donny: Are these the Nazis, Walter?
Walter: No, Donny, these men are nihilists. There's nothing to be
afraid of. -- The Big Lebowski

Christopher Browne <cbbrowne@acm.org> wrote:
It works pretty good, at least for a manual method to clear the
server off while this particular escapade is going on. You
certainly would not want to run it on a normal basis out of
cron or anything like that! Sure as heck, whatever you set
the limit to will be just smaller than the size of that file
full of pictures of the kids that your favorite inlaw sends
the next day... :-)

The trick is to invoke fetchmail manually a couple times as
"fetchmail -v -v", after setting "nokeep", "fetchall" and "limit
xxxx" in your ~/.fetchmailrc file, where the "xxxx" is some size
you think will filter things well enough.

Then after that has been run, "fetchmail -v -v -F" will
delete what is left without downloading it. It takes a bit
less than one second per message, so a few hundred takes
a short time and a few thousand take a while.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

On Fri, 19 Sep 2003 20:14:06 -0400, Rod Smith <rodsmith@nessus.rodsbooks.com> wrote:
Yet this is what the log says:

From gi.nocco@tiscalinet.it Fri Sep 19 10:38:03 2003
SUBJECT: Current Security Upgrade
Folder: 0


But I tested it and you are right. These two times represent the same
mail (within a few kilobytes) being killed with the above recipe
and being sent to /dev/null. Darn.

real 0m32.715s
user 0m0.010s
sys 0m0.010s

real 0m31.248s
user 0m0.020s
sys 0m0.000s



Not sure what you mean. Run fetchmail -c and you will see that there is nothing
left on your POP server after you run that recipe, and nothing in your
mailbox.


, but that won't help me keep the
Have a look at Floyd Davidson's fetchmail recipes above.

Alan C

--

take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
spammers hate this program because they can't beat it

On 19 Sep 2003 15:59:12 -0800, Floyd Davidson <floyd@barrow.com> wrote:

Well! I thought *I* had the hot tip of the day, but you sure aced me good,
Floyd.

I just followed your directions and they worked like the proverbial charm.

Many thanks.

Oh...I ran fetchmail -c 20 seconds after I had emptied the POP account
and there were alread 2 more 150kb mails there!

5 minutes later there were 60!

Gonna have to script this, Floyd.


Alan C

--

take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
spammers hate this program because they can't beat it

Bill Marcum wrote:

Almost 100% is still no good. My simple way is to readjust the DNS entry for
my e-mail server so that it will completely reject (not filters) 100% of
these junk e-mails.

BTW, as I recalled this e-mail floods also happened a couple of weeks ago
and noticed that my other e-mail accounts on MSN/HotMail/Yahoo (usually got
lots of junk e-mails on a daily basis) seemed to be idling (no junk
e-mails) until a couple days ago. I believe others also had that kind of
experience. If so, I can conclude that most of the spammers who used to
send out spammed e-mails got his/her computers invested with this type of
virus and they were having some big times to get rid off the virus instead
of sending out spammed e-mails.

--
NO_SPAMMERS