RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?

2004-09-18 Thread Avi Shatz
Well, in that case it might just be also the rDNS, but I've tested more
then once: 

telnet mailserver.localmta.org 25
ehlo blabla
[...]
Quit

Resulting header will show "blabla" other then workstation.localmta.org

-Original Message-
From: jdow [mailto:[EMAIL PROTECTED] 
Sent: Sunday, September 19, 2004 2:42 AM
To: users@spamassassin.apache.org
Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?

% host 66.111.4.30
30.4.111.66.in-addr.arpa domain name pointer
frontend1.messagingengine.com.

You coul dnot prove it by me that the name there is the HELO rather than
the rDNS lookup.

{^_^}
- Original Message - 
From: "Avi Shatz" <[EMAIL PROTECTED]>
> 
> Well, the way that Microsoft SMTP works here, is if the line is: 
> 
> Received: from frontend1.messagingengine.com ([66.111.4.30]) by
> localmta.org with
> Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
> 
> The EHLO is: "frontend1.messagingengine.com"
> The IP is: 66.111.4.30
> The accepting Server is: localmta.org
> 
> I've double checked this, that first string is not the rDNS, its
clearly
> the EHLO, and can be used..
> 
> Any ideas on how to solve this?
> 
> -Original Message-
> From: Avi Shatz 
> Sent: Sunday, September 19, 2004 2:18 AM
> To: 'Loren Wilton'
> Subject: RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?
> 
> Well, the way that Microsoft SMTP works here, is if the line is: 
> 
> Received: from frontend1.messagingengine.com ([66.111.4.30]) by
> localmta.org
> with
> Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
> 
> The EHLO is: "frontend1.messagingengine.com"
> The IP is: 66.111.4.30
> The accepting Server is: localmta.org
> 
> I've double checked this, that first string is not the rDNS, its
clearly
> the EHLO, and can be used..
> 
> Any ideas on how to solve this?
> 
> -Original Message-
> From: Loren Wilton [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, September 19, 2004 2:01 AM
> To: users@spamassassin.apache.org
> Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
> 
> > From some reason, SPF is always claiming the lack of HELO in the
> received
> headers, while they are clearly there.
> 
> Nope, they're not.
> 
> >I'm attaching an example message file which I try to pass via
> spamassassin,
> and get something like:
> 
> >debug: SPF: checking HELO (helo=, ip=66.111.4.30)
> >debug: SPF: trimmed HELO down to ''
> >debug: SPF: cannot get HELO, cannot use SPF
> 
> Received: from frontend1.messagingengine.com ([66.111.4.30]) by
> localmta.org
> with
> Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
> Received: from web4.messagingengine.com (web4.internal [10.202.2.213])
> by
> frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE
> for
> <[EMAIL PROTECTED]>; Sat, 18 Sep 2004 12:53:00 -0400 (EDT)
> 
> Those debug lines are pointing to the first received line above.  The
> HELO
> name would normally appear between the ( and the [ of the dotquad
> address.
> Nothing there.
> 
> The second received line does appear to have a HELO name on it.
> However,
> the address is in private space, so is not usable.
> 
> Loren



Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?

2004-09-18 Thread jdow
% host 66.111.4.30
30.4.111.66.in-addr.arpa domain name pointer frontend1.messagingengine.com.

You coul dnot prove it by me that the name there is the HELO rather than
the rDNS lookup.

{^_^}
- Original Message - 
From: "Avi Shatz" <[EMAIL PROTECTED]>
> 
> Well, the way that Microsoft SMTP works here, is if the line is: 
> 
> Received: from frontend1.messagingengine.com ([66.111.4.30]) by
> localmta.org with
> Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
> 
> The EHLO is: "frontend1.messagingengine.com"
> The IP is: 66.111.4.30
> The accepting Server is: localmta.org
> 
> I've double checked this, that first string is not the rDNS, its clearly
> the EHLO, and can be used..
> 
> Any ideas on how to solve this?
> 
> -Original Message-
> From: Avi Shatz 
> Sent: Sunday, September 19, 2004 2:18 AM
> To: 'Loren Wilton'
> Subject: RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?
> 
> Well, the way that Microsoft SMTP works here, is if the line is: 
> 
> Received: from frontend1.messagingengine.com ([66.111.4.30]) by
> localmta.org
> with
> Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
> 
> The EHLO is: "frontend1.messagingengine.com"
> The IP is: 66.111.4.30
> The accepting Server is: localmta.org
> 
> I've double checked this, that first string is not the rDNS, its clearly
> the EHLO, and can be used..
> 
> Any ideas on how to solve this?
> 
> -Original Message-
> From: Loren Wilton [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, September 19, 2004 2:01 AM
> To: users@spamassassin.apache.org
> Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
> 
> > From some reason, SPF is always claiming the lack of HELO in the
> received
> headers, while they are clearly there.
> 
> Nope, they're not.
> 
> >I'm attaching an example message file which I try to pass via
> spamassassin,
> and get something like:
> 
> >debug: SPF: checking HELO (helo=, ip=66.111.4.30)
> >debug: SPF: trimmed HELO down to ''
> >debug: SPF: cannot get HELO, cannot use SPF
> 
> Received: from frontend1.messagingengine.com ([66.111.4.30]) by
> localmta.org
> with
> Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
> Received: from web4.messagingengine.com (web4.internal [10.202.2.213])
> by
> frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE
> for
> <[EMAIL PROTECTED]>; Sat, 18 Sep 2004 12:53:00 -0400 (EDT)
> 
> Those debug lines are pointing to the first received line above.  The
> HELO
> name would normally appear between the ( and the [ of the dotquad
> address.
> Nothing there.
> 
> The second received line does appear to have a HELO name on it.
> However,
> the address is in private space, so is not usable.
> 
> Loren



RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?

2004-09-18 Thread Avi Shatz

Well, the way that Microsoft SMTP works here, is if the line is: 

Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300

The EHLO is: "frontend1.messagingengine.com"
The IP is: 66.111.4.30
The accepting Server is: localmta.org

I've double checked this, that first string is not the rDNS, its clearly
the EHLO, and can be used..

Any ideas on how to solve this?

-Original Message-
From: Avi Shatz 
Sent: Sunday, September 19, 2004 2:18 AM
To: 'Loren Wilton'
Subject: RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?

Well, the way that Microsoft SMTP works here, is if the line is: 

Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org
with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300

The EHLO is: "frontend1.messagingengine.com"
The IP is: 66.111.4.30
The accepting Server is: localmta.org

I've double checked this, that first string is not the rDNS, its clearly
the EHLO, and can be used..

Any ideas on how to solve this?

-Original Message-
From: Loren Wilton [mailto:[EMAIL PROTECTED] 
Sent: Sunday, September 19, 2004 2:01 AM
To: users@spamassassin.apache.org
Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?

> From some reason, SPF is always claiming the lack of HELO in the
received
headers, while they are clearly there.

Nope, they're not.

>I'm attaching an example message file which I try to pass via
spamassassin,
and get something like:

>debug: SPF: checking HELO (helo=, ip=66.111.4.30)
>debug: SPF: trimmed HELO down to ''
>debug: SPF: cannot get HELO, cannot use SPF

Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org
with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
Received: from web4.messagingengine.com (web4.internal [10.202.2.213])
by
frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE
for
<[EMAIL PROTECTED]>; Sat, 18 Sep 2004 12:53:00 -0400 (EDT)

Those debug lines are pointing to the first received line above.  The
HELO
name would normally appear between the ( and the [ of the dotquad
address.
Nothing there.

The second received line does appear to have a HELO name on it.
However,
the address is in private space, so is not usable.

Loren



Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?

2004-09-18 Thread Loren Wilton
> From some reason, SPF is always claiming the lack of HELO in the received
headers, while they are clearly there.

Nope, they're not.

>I'm attaching an example message file which I try to pass via spamassassin,
and get something like:

>debug: SPF: checking HELO (helo=, ip=66.111.4.30)
>debug: SPF: trimmed HELO down to ''
>debug: SPF: cannot get HELO, cannot use SPF

Received: from frontend1.messagingengine.com ([66.111.4.30]) by localmta.org
with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
Received: from web4.messagingengine.com (web4.internal [10.202.2.213]) by
frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE for
<[EMAIL PROTECTED]>; Sat, 18 Sep 2004 12:53:00 -0400 (EDT)

Those debug lines are pointing to the first received line above.  The HELO
name would normally appear between the ( and the [ of the dotquad address.
Nothing there.

The second received line does appear to have a HELO name on it.  However,
the address is in private space, so is not usable.

Loren



Two logs for each daemon?

2004-09-18 Thread Ed Kasky
I just upgraded to 3.0.7-1 and noticed an slight oddity in the logs now beig 
created.  In my smb.conf I have:

log level = 2
log file = /var/log/samba/%m.log

Since upgrading I now get two logs for smbd and two for nmbd...

 114676 Sep 18 07:19 /var/log/samba/log.nmbd
 100728 Sep 18 15:35 /var/log/samba/nmbd.log
4656 Sep 18 06:34 /var/log/samba/log.smbd
  55035 Sep 18 06:34 /var/log/samba/smbd.log

I have not seen this with previous versions and was wondering if I might have 
done something in the upgrade to cause this.

Ed Kasky
. . . . . . . . . . . . . . .
Randomly generated quote:
Success usually comes to those who are too busy to be looking for it.
- Henry David Thoreau, naturalist and author (1817-1862)


SPF Fails on SA 3.0rc5 because of lack of HELO ?

2004-09-18 Thread Avi Shatz








Hello
there,

 

Recently
I've tried installing SA 3.0rc5, and I wanted to try out its SPF support on
windows.

From
some reason, SPF is always claiming the lack of HELO in the received headers,
while they are clearly there.

 

I'm
attaching an example message file which I try to pass via spamassassin, and get
something like:

 

debug:
SPF: checking HELO (helo=, ip=66.111.4.30)

debug:
SPF: trimmed HELO down to ''

debug:
SPF: cannot get HELO, cannot use SPF

 

 

Any
help would be appreciated J

 

Yours,

Avi

 








test.msg.txt
Description: test.msg.txt


Re: stripping SA headers for reporting? (spamcop, etc.)

2004-09-18 Thread Ryan Thompson
Andre Nicholson wrote to users@spamassassin.apache.org:
John Owens wrote:
I'd like to send as original a message as I can to
SpamCop and other places since they don't like munged reports. Currently 
I'm doing this manually,
which is annoying. I note that sa-learn knows how to remove all SA-specific 
annotations from a message
(unwraps MIME, removes headers, etc.). Is that functionality available in 
any other way?
spamassassin -d < MESSAGEFILE > NEWFILE
Or to also report it afterward
spamassassin -d < MESSAGEFILE > NEWFILE && spamassassin -r < NEWFILE
RTFM, folks. :-)
SPAMASSASSIN(1):
   -r, --report
   Report this message as manually-verified spam.  This will submit
   the mail message read from STDIN to various spam-blocker databases.
   [...]
   If the message contains SpamAssassin markup, the markup will be
   stripped out automatically before submission.
This does the same thing as -d before submission. If it doesn't do what
you want, then your upstream probably isn't adding SA markup. (i.e.,
they're wrapping it themselves using MIMEDefang or something).
- Ryan
--
  Ryan Thompson <[EMAIL PROTECTED]>
  SaskNow Technologies - http://www.sasknow.com
  901-1st Avenue North - Saskatoon, SK - S7K 1Y4
Tel: 306-664-3600   Fax: 306-244-7037   Saskatoon
  Toll-Free: 877-727-5669 (877-SASKNOW) North America


Re: spam w/ special characters

2004-09-18 Thread Raymond Dijkxhoorn
Hi!
in the last week or two, we have been getting some
spam that spamassassin doesn't seem to recognize.
A common feature of all these messages seems to be
that they contain lots of special characters
(~, ^, `, and others) mixed into the text.
I put some examples up at http://marie.vtl.ee/spam.txt
Would a rule to calculate some kind of "special chars" vs
"total chars" ratio be useful?
Does anybody have that kind of rule already?
Start using SURBL, as far as i can see in your samples all would have been 
tagged.

Bye,
Raymond.


Re: stripping SA headers for reporting? (spamcop, etc.)

2004-09-18 Thread Andre Nicholson
John Owens wrote:
I'd like to send as original a message as I can to
SpamCop and other places since they don't like 
munged reports. Currently I'm doing this manually,
which is annoying. I note that sa-learn knows how 
to remove all SA-specific annotations from a message
(unwraps MIME, removes headers, etc.). Is that 
functionality available in any other way?
spamassassin -d < MESSAGEFILE > NEWFILE
Or to also report it afterward
spamassassin -d < MESSAGEFILE > NEWFILE && spamassassin -r < NEWFILE


Re: stripping SA headers for reporting? (spamcop, etc.)

2004-09-18 Thread Matt Kettler
At 03:32 PM 9/18/2004 +, John Owens wrote:
I'd like to send as original a message as I can to
SpamCop and other places since they don't like
munged reports. Currently I'm doing this manually,
which is annoying. I note that sa-learn knows how
to remove all SA-specific annotations from a message
(unwraps MIME, removes headers, etc.). Is that
functionality available in any other way?
Yes, it's directly available from the spamassassin command line tool.
man spamassassin:
-d, --remove-markup
Remove SpamAssassin markup (the ``SpamAssassin results'' report, 
X-Spam-Status headers, etc.) from the mail message. The resulting message, 
which will be more or less identical to the original, pre-SpamAssassin 
input, will be output to stdout.

(Note: the message will not be exactly identical; some headers will be 
reformatted due to some features of the Mail::Internet package, but the 
body text will be.)




stripping SA headers for reporting? (spamcop, etc.)

2004-09-18 Thread John Owens
I report spam to SpamCop among other places. 
I get mail from several upstream places (where I don't 
have control of the SA parameters), so when I get spam,
it's often wrapped in a variety of different ways 
(sometimes as a MIME attachment, sometimes with SA
results in the headers, etc.).

I'd like to send as original a message as I can to
SpamCop and other places since they don't like 
munged reports. Currently I'm doing this manually,
which is annoying. I note that sa-learn knows how 
to remove all SA-specific annotations from a message
(unwraps MIME, removes headers, etc.). Is that 
functionality available in any other way? What I'd like
to do is have a spam folder and just call a script 
that reads each message, scripts it, and then reports
each spam. What I don't have is the code that un-
SpamAssassins each message. Is that code available
anywhere (possibly as a standalone script, say
Python or something like that)?

JDO



Re: spam w/ special characters

2004-09-18 Thread Loren Wilton
> Would a rule to calculate some kind of "special chars" vs
> "total chars" ratio be useful?
> Does anybody have that kind of rule already?

Doing that as a ratio would require an eval, I suspect.  However, detecting
obfuscated things is pretty easy.  You need some new rules!  :-)  Hie thee
off to exit0 or rulesemporium or the like and get Matt's antidrug set, just
for a start.

Here are some results from the first few of your spam:

Content analysis details:   (27.1 points, 4.6 required)

 pts rule name  description
 -- 
--
 1.4 SARE_ALC   Some header matches /improve your/i
 0.6 RATWR10a_MESSIDMessage-ID has ratware pattern (HEXHEX.HEXHEX@)
 1.8 LOCAL_OBFU_CELEXA  BODY: Obfuscated 'CELEXA' in body
 1.8 LOCAL_OBFU_XANAX   BODY: Obfuscated 'XANAX' in body
 1.8 LOCAL_OBFU_LEVITRA BODY: Obfuscated 'LEVITRA' in body
 1.8 LOCAL_OBFU_PAXIL   BODY: Obfuscated 'PAXIL' in body
 1.8 LOCAL_OBFU_VIAGRA  BODY: Obfuscated 'VIAGRA' in body
 1.0 SARE_OBFUGIRLS BODY: masked spam word(s)
 1.8 LOCAL_OBFU_MERIDIA BODY: Obfuscated 'MERIDIA' in body
 0.1 TW_OC  BODY: Odd Letter Triples with OC
 1.8 LOCAL_OBFU_CIALIS  BODY: Obfuscated 'CIALIS' in body
 1.8 LOCAL_OBFU_XENICAL BODY: Obfuscated 'XENICAL' in body
 1.5 DRUGS_ERECTILE_OBFUObfuscated reference to an erectile drug
 1.0 DRUGS_ANXIETY_OBFU Obfuscated reference to an anxiety control drug
 1.0 DRUGS_ERECTILE Refers to an erectile drug
 0.0 DRUGS_ANXIETY  Refers to an anxiety control drug
 0.0 DRUGS_DEPRESSION   Refers to an antidepressant
 0.0 DRUGS_DIET Refers to a diet drug
 1.0 DRUGS_DEPR_ERECRefers to both an erectile and an antidepressant
 1.0 DRUGS_ANXIETY_EREC Refers to both an erectile and an anxiety drug
 1.0 DRUGS_DIET_ERECRefers to both an erectile and a diet drug
 1.0 DRUGS_MANYKINDSRefers to at least four kinds of drugs

Content analysis details:   (31.0 points, 4.6 required)

 pts rule name  description
 -- 
--
 1.8 LOCAL_OBFU_XANAX   BODY: Obfuscated 'XANAX' in body
 1.8 LOCAL_OBFU_ZOLOFT  BODY: Obfuscated 'ZOLOFT' in body
 1.8 LOCAL_OBFU_LEVITRA BODY: Obfuscated 'LEVITRA' in body
 1.8 LOCAL_OBFU_CELEBREXBODY: Obfuscated 'CELEBREX' in body
 1.8 LOCAL_OBFU_PAXIL   BODY: Obfuscated 'PAXIL' in body
 2.8 LOCAL_OBFU_VICODIN BODY: Obfuscated 'VICODIN' in body
 1.8 LOCAL_OBFU_VIAGRA  BODY: Obfuscated 'VIAGRA' in body
 1.8 LOCAL_OBFU_MERIDIA BODY: Obfuscated 'MERIDIA' in body
 1.8 LOCAL_OBFU_VIOXX   BODY: Obfuscated 'VIOXX' in body
 1.8 LOCAL_OBFU_XENICAL BODY: Obfuscated 'XENICAL' in body
-0.0 BAYES_44   BODY: Bayesian spam probability is 44 to 50%
[score: 0.4966]
 1.5 DRUGS_ERECTILE_OBFUObfuscated reference to an erectile drug
 1.0 DRUGS_ANXIETY_OBFU Obfuscated reference to an anxiety control drug
 1.0 DRUGS_ERECTILE Refers to an erectile drug
 0.0 DRUGS_ANXIETY  Refers to an anxiety control drug
 1.0 DRUGS_PAIN_OBFUObfuscated reference to a pain relief drug
 0.0 DRUGS_DEPRESSION   Refers to an antidepressant
 0.0 DRUGS_PAIN Refers to a pain relief drug
 0.0 DRUGS_DIET Refers to a diet drug
 1.0 DRUGS_DEPR_ERECRefers to both an erectile and an antidepressant
 1.0 DRUGS_ANXIETY_EREC Refers to both an erectile and an anxiety drug
 1.0 DRUGS_PAIN_ERECRefers to both an erectile and a painkiller
 0.5 DRUGS_DIET_PAINRefers to both a diet drug and a pain drug
 1.0 DRUGS_DIET_ERECRefers to both an erectile and a diet drug
 1.0 DRUGS_MANYKINDSRefers to at least four kinds of drugs

Content analysis details:   (9.3 points, 4.6 required)

 pts rule name  description
 -- 
--
 0.6 RATWR10a_MESSIDMessage-ID has ratware pattern (HEXHEX.HEXHEX@)
 3.3 SARE_SUB_ONLINE_OB subject has obfuscated spammer topic
 1.7 BAYES_80   BODY: Bayesian spam probability is 80 to 90%
[score: 0.8257]
 1.7 SARE_SPEC_ANUMAURI: Domain with ALPHAs NUMBERs APLHAs



Re: spam w/ special characters

2004-09-18 Thread Matt Kettler
At 06:21 PM 9/18/2004 +0300, Marie Fischer wrote:
Hello,
in the last week or two, we have been getting some
spam that spamassassin doesn't seem to recognize.
A common feature of all these messages seems to be
that they contain lots of special characters
(~, ^, `, and others) mixed into the text.
I put some examples up at http://marie.vtl.ee/spam.txt
Would a rule to calculate some kind of "special chars" vs
"total chars" ratio be useful?
Does anybody have that kind of rule already?
I don't have any rules that count ratios, however most of example spams are 
EXACTLY why antidrug.cf was created. It has special rules which detect 
obfuscated forms of common spam drugs and it will penalize the obfuscations 
quite heavily.

http://mywebpages.comcast.net/mkettler/sa/antidrug.cf
Disclaimer: I am the author of antidrug, thus I do have a bias. I'd suggest 
checking the mass-check results for this ruleset that are posted on the 
spamassasin wiki:

http://wiki.apache.org/spamassassin/CustomRulesets


spam w/ special characters

2004-09-18 Thread Marie Fischer
Hello,

in the last week or two, we have been getting some 
spam that spamassassin doesn't seem to recognize.
A common feature of all these messages seems to be 
that they contain lots of special characters 
(~, ^, `, and others) mixed into the text.
I put some examples up at http://marie.vtl.ee/spam.txt

Would a rule to calculate some kind of "special chars" vs 
"total chars" ratio be useful?
Does anybody have that kind of rule already?

TIA,

-- 
marie



Re: very basic IP address question

2004-09-18 Thread lee





Thanks,

I've now sent their abuse department the details, although I understand
that spammers can appear to be on a certain ISP even if they're not.

lee


jdow wrote:

  
A simple "whois" query indicates this is a set of addresses "owned"
by Comindico in Oz. If you don't have "whois" handy visit the
http://www.dnsstuff.com/ site and play there. Whois is on the left.
{^_^}
  

-- 









From lee - Have a PC,
broadband connection and Yahoo ID? Want to hear my FREE selection
of five decades of hit music and modern dance? Then
VISIT
HERE
and click on Lee's station




scanned by lee's virus software. outbound message found to be clean.






Re: very basic IP address question

2004-09-18 Thread jdow
From: "lee" <[EMAIL PROTECTED]>

> hello everyone,
> 
> With IP addresses, do the blocks of numbers have any specific meaning or 
> location-specific detail?
> 
> For eg, lots of spam I'm getting sent to one of my domain's addresses 
> with netsky attachments always shows 203.221 as the first two IP blocks 
> when I look at the received header. The actual apparent sender address 
> is always different but often @hotmail.com
> 
> I don't know if such knowledge would then allow me to (safely) set a 
> filter or rule somewhere in my cpanel or spam assassin to just discard 
> any mail from that person(s).
> Ideally, I would like to set a filter(s) in my cpanel 9 hosting to just 
> discard based on one or more rules, but the email filtering seems quite 
> inflexible and basic.
> 
> I do have avast! virus scanning on my pc which always picks up and warns 
> of the incoming nasty, but I'm trying to avoid such emails getting 
> through my domain in the first place, even if I was to manage 
> configuring spam assassin to flag them as SPAM.
> 
> Thanks a lot,
> lee

A simple "whois" query indicates this is a set of addresses "owned"
by Comindico in Oz. If you don't have "whois" handy visit the
http://www.dnsstuff.com/ site and play there. Whois is on the left.
{^_^}



very basic IP address question

2004-09-18 Thread lee





hello everyone,

With IP addresses, do the blocks of numbers have any specific meaning
or location-specific detail?

For eg, lots of spam I'm getting sent to one of my domain's addresses
with netsky attachments always shows 203.221 as the first two IP blocks
when I look at the received header. The actual apparent sender address
is always different but often @hotmail.com

I don't know if such knowledge would then allow me to (safely) set a
filter or rule somewhere in my cpanel or spam assassin to just discard
any mail from that person(s).
Ideally, I would like to set a filter(s) in my cpanel 9 hosting to just
discard based on one or more rules, but the email filtering seems quite
inflexible and basic.

I do have avast! virus scanning on my pc which always picks up and
warns of the incoming nasty, but I'm trying to avoid such emails
getting through my domain in the first place, even if I was to manage
configuring spam assassin to flag them as SPAM.

Thanks a lot,
lee




scanned by lee's virus software. outbound message found to be clean.






Re: New spammer trick?

2004-09-18 Thread Robert Menschel
Hello Andy,

Friday, September 17, 2004, 3:23:15 AM, you wrote:

AS> Hi, I just got a nigerian spam with a huge Reply-To: line! Never seen
AS> that trick before, but I suppose it works with quite a few of the
AS> recipients.  Should we create a new rule for that?  I can't think of
AS> a legitimate reason to have more than one address in the Reply-To
AS> line, right?

Rule I created and tested:

headerRM_hrt_multireplyReply-To =~ /[EMAIL PROTECTED]@.+\@/
describe  RM_hrt_multireplyhas multiple reply to addresses
score RM_hrt_multireply0.100
#hist RM_hrt_multireplyCreated by Bob Menschel, Sep 17 2004
#hist RM_hrt_multireplyidea from Andy Spiegl, SA-Users
#counts   RM_hrt_multireply1s/0h of 66060 corpus (40104s/25956h RM) 
09/17/04

Yes, that's only one hit out of 40k spam, but at least the one hit was
spam.

Bob Menschel





Re[2]: Memory usage question

2004-09-18 Thread Robert Menschel
Hello Chr.,

Friday, September 17, 2004, 7:58:11 AM, Stucki (Christoph von Stuckrad)
wrote: 

CvS> On Fri, Sep 17, 2004 at 10:42:20AM -0400, Matt Kettler wrote:
>> Since your box has 256mb of physical ram, I'd limit it to maximum of 
>> 256mb/15mb = 17 spamd's at the highest. I'd really suggest using something
>> much lower like 10 unless you add some ram.

CvS> So a system with 1G Memory (+2GSwap) DualPentium4 simply stopped
CvS> completely just by crowding its space with max 32 copies of spamd
CvS> (each forking with near 50M). The system was to slow to reboot
CvS> correctly and had to be 'reset' and fsck-ed.

CvS> So you have to watch closely, if the system is as small as the
CvS> above. Better invest in lots of memory...

However, for a system that gets only
RB>> At one point we hit 60 emails in a span of 5 minutes.
-m of 4 or 5 is probably adequate, in which case 256 Meg may be
sufficient, if slow.

(Me, I use a 1 Gig Windows machine just for word processing, web page
editing, and the occasional mass-check. Norton Utilities normally reports
50% in use, no matter what I do.)

Bob Menschel





Re: Additional URIBL phish/fraud list

2004-09-18 Thread Jeff Chan
On Friday, September 17, 2004, 4:24:37 PM, Bill Landry wrote:
> This is a list that MailPolice hosts and I have been running it for a few
> hours and it has already flagged some phish and fraud e-mails.  Here is some
> info about the list:  http://rhs.mailpolice.com/#rhsfraud

> This is my configuration for SA 2.64 with the SpamCopURI plug-in:

> uri  MP_URI_RBL
> eval:check_spamcop_uri_rbl('fraud.rhs.mailpolice.com','127.0.0.2')
> describe MP_URI_RBL URI's domain appears in MailPolice fraud list
> tflags   MP_URI_RBL net
> scoreMP_URI_RBL 2.0

> And for SA 3.0 with the URIDNSBL plug-in:

> urirhsbl URIBL_MP fraud.rhs.mailpolice.com.   A
> header   URIBL_MP eval:check_uridnsbl('URIBL_MP')
> describe URIBL_MP URI's domain appears in MailPolice fraud list
> tflags   URIBL_MP net
> scoreURIBL_MP 2.0

> Bill

Thanks for finding that additional phishing data Bill!

It may be worth noting that we're working on including these
into PH inside multi.surbl.org, and that we have 15 times more
name servers than mailpolice.com does.  ;-)

Jeff C.
-- 
Jeff Chan
mailto:[EMAIL PROTECTED]
http://www.surbl.org/