Juno/hotmail/prodigy filtering


Rather than filter these services out as pure spam, I decided to make them
special-case filters - if the Message-ID doesn't contain the proper domain,
then the message is dumped as a spam:

This template is duplicated and modified as appropriate for each of the
individual domains:

# If the message appears to be FROM a Juno account, yet the Message-ID does
# not contain juno.com, it is forged (though, it might be someone sending
# a message as if from their juno account - but I don't much care).

:0
* ^From:.* <at> juno\.com
* ! ^Message-ID:.*juno\.com
{
	LOG="SPAM: forged juno$TWITVER"

	:0:
	|gzip -9fc>>$MAILDIR/twits.gz
}

I ran a bunch of my mail through this and it seems to catch
juno/hotmail/prodigy spam - leaving alone the handful of LEGIT messages I
have from users of these services.

Any recommendations for improvements?  How about sample headers from other
mail services similar to juno and hotmail?

---
(Continue reading)

Donald E. Hammond | 1 Jan 1998 09:54

forwarding list copies vs. subscribing twice

I am subscribed to a couple of mail lists and would like to
get copies at work.  (I collect mail once every 24 hours in
batch from home, and would like to continue doing so because
it gets archived there, but would like to see a lot of it
sooner.)  My question is what is the most resource friendly
way of doing this -- from the perspective of both the list
server and my ISP, and any appropriate trade-offs -- or if
it's even an issue.  

Would it be better to:

1.) modify my procmail filters to forward a copy of
    the desired messages
2.) execute  additional subscriptions from work
3.) none of the above
4.) doesn't matter

Thanks.

 - Don

era eriksson | 1 Jan 1998 11:54
Picon
Picon
Favicon

Re: Counting Content-Length ?

On Wed, 31 Dec 1997 10:27:46 +0200, jari.aalto <at> poboxes.com wrote:
 > Tue 97-12-30 Vikas Agnihotri <VikasA <at> att.com> list.procmail
 > | 4. Is the recipe 100% accurate that I can replace any existing
 > | Content-length headers with this score (after using HB to measure both head
 > | and body of course) and not have any MUA which relies completely on
 > | Content-Length: honk at me?
 > Yes. It's 100% accurate and fast.

A better solution would be this, unless you are running procmail -Y:

    :0fw
    | formail -A"Content-Length: 000000"

This will only add a Content-Length header if there isn't one in the
message already. You might still want to check whether there is a
Content-Length header from earlier, for performance purposes. Procmail
will notice the incorrect Content-Length and fix it before writing the
message. 

 > At least Emacs based MUA's don't rely on Content-Length
 > (VM,RMAIL,MH,GNUS..), but I have heeard that Sun's mailtool goes
 > beserk. Does anyone know what elm, pine or mutt etc thinks about
 > Content-Length ?

I believe Elm uses it, too. BTW, Emacs VM mode can read and generate
this format if you ask nicely.

/* era */

--

-- 
(Continue reading)

era eriksson | 1 Jan 1998 17:02
Picon
Picon
Favicon

Re: Counting Content-Length ?

On Thu, 1 Jan 1998 12:54:12 +0200 (EET), I wrote:
 >     | formail -A"Content-Length: 000000"
 > This will only add a Content-Length header if there isn't one in the
 > message already. 

Silly me: that's formail -a, not -A

/* era */

--

-- 
 Paparazzi of the Net: No matter what you do to protect your privacy,
  they'll hunt you down and spam you. <http://www.iki.fi/~era/spam/>

aoc | 2 Jan 1998 07:47
Picon
Favicon

Re: forwarding list copies vs. subscribing twice


you can just telnet in to your home box 
and access your mail through there. 

On Thu, 1 Jan 1998, Donald E. Hammond wrote:

> I am subscribed to a couple of mail lists and would like to
> get copies at work.  (I collect mail once every 24 hours in
> batch from home, and would like to continue doing so because
> it gets archived there, but would like to see a lot of it
> sooner.)  My question is what is the most resource friendly
> way of doing this -- from the perspective of both the list
> server and my ISP, and any appropriate trade-offs -- or if
> it's even an issue.  
> 
> Would it be better to:
> 
> 1.) modify my procmail filters to forward a copy of
>     the desired messages
> 2.) execute  additional subscriptions from work
> 3.) none of the above
> 4.) doesn't matter
> 
> Thanks.
> 
>  - Don
> 
> 

(Continue reading)

gsutter | 2 Jan 1998 04:37
Picon
Favicon

Re: Juno/hotmail/prodigy filtering

On Wed, 31 Dec 1997, Professional Software Engineering wrote:

>Rather than filter these services out as pure spam, I decided to make them
>special-case filters - if the Message-ID doesn't contain the proper domain,
>then the message is dumped as a spam:
>
>:0
>* ^From:.* <at> juno\.com
>* ! ^Message-ID:.*juno\.com

I use just that recipe:

# Forged mail from {hotmail, usa, juno}.
:0
* ^From:.* <at> ((hotmail|juno).com|usa.net)
* !^(Received|Message-Id):.*((hotmail|juno).com|usa.net)
{ SPAMMER="forged hotmail/usa/juno" }

>Any recommendations for improvements?  How about sample headers from other
>mail services similar to juno and hotmail?

It works for usa.net as well.  I'm not sure of any others.

This also works fairly well:

:0
* ^Received:.*((hotmail|juno|bigfoot|rocketmail).com|usa.net).*uu.net
{ SPAMMER="forged bigfoot/hotmail/juno/rocketmail/usa" }

It handles Received: headers which report as:
(Continue reading)

Walter Dnes | 2 Jan 1998 06:55
Picon

Re: Juno/hotmail/prodigy filtering

Professional Software Engineering wrote:
> if the Message-ID doesn't contain the proper domain,
> then the message is dumped as a spam:
> 
> This template is duplicated and modified as appropriate for
> each of the individual domains:
> 
> If the message appears to be FROM a Juno account, yet the
> Message-ID does > not contain juno.com, it is forged (though,
> it might be someone sending a message as if from their juno
> account - but I don't much care).

> Any recommendations for improvements?  How about sample
> headers from other mail services similar to juno and hotmail?

  My recommendation... rather than umpteen variants to handle
umpteen different mail services, how about one generalized
version.  I'm still hazy about $MATCH, but here's a possible
algorithm...
  1) match the first whole-word (including punctuation) after
the " <at> " on the "From: " header.  E.g. from
"From: someone <at> some.isp.com (someone)" extract "some.isp.com"
  2) look for MATCH ("some.isp.com") in *BOTH* the message ID
and the "Received: " headers.  If not found in both, it's
probably junk.

  I don't know how to capture the "some.isp.com" portion, but
if it's do-able, then...

########################################################
(Continue reading)

Christopher P. Lindsey | 2 Jan 1998 09:47
Favicon

Re: Juno/hotmail/prodigy filtering

> > if the Message-ID doesn't contain the proper domain,
> > then the message is dumped as a spam:
> > 
> > Any recommendations for improvements?  How about sample
> > headers from other mail services similar to juno and hotmail?
> 
>   My recommendation... rather than umpteen variants to handle
> umpteen different mail services, how about one generalized
> version.  I'm still hazy about $MATCH, but here's a possible
> algorithm...

I agree -- making this more extensible would be a Good Thing.  Here's
a possibility using $MATCH:

   :0:
   * ^From: [^ <at> ]+ <at> \/[^ ]+[ ]+
   * !^(Received|Message-Id):.*$MATCH
   couldbespam

>   I don't know how to capture the "some.isp.com" portion, but
> if it's do-able, then...

What procmail does it take whatever is to the right of "\/" in the
regular expression and set it to $MATCH.  So in the above recipe,
it pulls everything that's to the right of the first  <at>  sign up
to the next space, which ends up being the hostname/domain name.

Unfortunately, this matches on way too much stuff for me right now,
so I'll have to do some fine-tuning...

(Continue reading)

Re: Juno/hotmail/prodigy filtering

At 02:47 AM 1/2/98 -0600, Christopher P. Lindsey wrote:

>>   My recommendation... rather than umpteen variants to handle
>> umpteen different mail services, how about one generalized
>> version.  I'm still hazy about $MATCH, but here's a possible
>> algorithm...

(note: I have yet to see this particular message followup via the list,
though I hope to see it soon)

There are many mail services - but only a handful of them have a track
record of being WIDELY used for spam.

I should also note that someone else had posted to this list some time back
about matching from domains to message-id domain portions - but there
were/are too many technical issues with that - here, I mentioned the
application of this for Juno-type mail specifically because of the known
spam problems being FORGED from that domain.

>I agree -- making this more extensible would be a Good Thing.  Here's
>a possibility using $MATCH:
>
>   :0:
>   * ^From: [^ <at> ]+ <at> \/[^ ]+[ ]+
>   * !^(Received|Message-Id):.*$MATCH
>   couldbespam

As you noted below, this From match is too generic - this sort of rule
would suspect too many messages as potential spam (for instance, many
people with virtual domain services - their FROM contains their registered
(Continue reading)

W. Wesley Groleau x4923 | 2 Jan 1998 14:11
Picon

Re: Juno/hotmail/prodigy filtering

> Any recommendations for improvements?  How about sample headers from other
> mail services similar to juno and hotmail?

I won't guarantee this is an _improvement_ but it is different and may
give you an idea or two:

# THE NOBOUNCE FILE
#    This is a file of addresses of friends and others I 
#    want to get mail from, even if they are at spam haven
#    domains/systems.
:0
* ? fgrep -i -f nobounce
{
 :0fhw
 |$MAILDIR/Prioritize_Subject   # adds a priority tag to the subject line

 :0
 $DEFAULT
}

# Stop loops right here - save them long enough to know they happened
:0
* ^X-Loop: noloops_<personalized_unique_string>
loops

# forgeries (based on an idea by RFG)

FORGED_DOMAIN = compuserve.com
INCLUDERC     = forgery.rc

(Continue reading)


Gmane