Re: [Declude.JunkMail] MX pointing to localhost

2003-03-24 Thread R. Scott Perry

Got another one for you.  Check out the DNS for this spammer's 
domain:  e247.com

The MX points to localhost.  The MAILFROM test does not catch this yet, 
but probably should.
Good catch.  It was only detecting MX/A records that returned an IP of 
127.0.0.1, but in this case e247.com returns an MX record of localhost 
but doesn't include the corresponding A record pointing to 127.0.0.1.  The 
next release will cause this to fail the MAILFROM test.
   -Scott

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


[Declude.JunkMail] I know I'm doing some wroing but can't put my finger on it.

2003-03-24 Thread David Lewis-Waller
The answer is going to be obvious and simple but I can't spot it.

I have a filter file:

MAILFROMLISTfilter  d:\IMail\declude\mailfrom.txt
x   0   0

That contains the line (mailfrom.txt)

MAILFROM 30 CONTAINS @ideal.co.uk

(I've checked that there isn't a space at the end of the line)

Email from (info from headers)

From: [EMAIL PROTECTED] [EMAIL PROTECTED]

Doesn't get detected:

X-Note: SPAM tests failed:[HEUR10, SPAM-VLOW]


To help with organisation I have comment lines in mailfrom.txt e.g.

# POSITIVE WEIGHTS

Any help appreciated

David


---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


Re: [Declude.JunkMail] I know I'm doing some wroing but can'tput my finger on it.

2003-03-24 Thread R. Scott Perry

The answer is going to be obvious and simple but I can't spot it.
You're not the first to be fooled by this:

From: [EMAIL PROTECTED] [EMAIL PROTECTED]
The problem here is that the return address of the E-mail isn't 
[EMAIL PROTECTED] (nor is the From: address either, which is 
[EMAIL PROTECTED]).  Declude only looks at the return address, which can't be 
seen in this case (it is often different than the From: or Reply-To: 
addresses).  You can find the return address in the X-Declude-Sender: 
header, or the MAIL FROM: line in the IMail SMTP log file.
-Scott

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


RE: [Declude.JunkMail] I know I'm doing some wroing but can't put my finger on it.

2003-03-24 Thread Kami Razvan
David:

This is why we have created several filter files and one that also gives
weight to our Blacklist being found in the header.  We have a blacklist file
with Delete action and one that is filter based on the entries in the
blacklist.  So if any listing in the blacklist is found in the header the
email will be held.

Since we have this in a database we simply create different views of the
entries.  Such as blacklist found in body and header because we have also
noticed that our blacklist entries are at times using free emails but their
contact address is used in the body.  So if any blacklist email or address
is found in the body of the email the email will be held.

Hope that helps.

Regards,
Kami

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry
Sent: Monday, March 24, 2003 10:01 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] I know I'm doing some wroing but can't put
my finger on it.



The answer is going to be obvious and simple but I can't spot it.

You're not the first to be fooled by this:

 From: [EMAIL PROTECTED] [EMAIL PROTECTED]

The problem here is that the return address of the E-mail isn't 
[EMAIL PROTECTED] (nor is the From: address either, which is 
[EMAIL PROTECTED]).  Declude only looks at the return address, which can't be 
seen in this case (it is often different than the From: or Reply-To: 
addresses).  You can find the return address in the X-Declude-Sender: 
header, or the MAIL FROM: line in the IMail SMTP log file.
 -Scott

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To unsubscribe,
just send an E-mail to [EMAIL PROTECTED], and type unsubscribe
Declude.JunkMail.  The archives can be found at
http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


RE: [Declude.JunkMail] I know I'm doing some wroing but can't put my finger on it.

2003-03-24 Thread David Lewis-Waller
A - I thought the FROM address was the labelled From: not the return
address. Should have sussed that one.

Thanks v.much for pointing this out

David

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry
Sent: 24 March 2003 15:01
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] I know I'm doing some wroing but can't
put my finger on it.



The answer is going to be obvious and simple but I can't spot it.

You're not the first to be fooled by this:

 From: [EMAIL PROTECTED] [EMAIL PROTECTED]

The problem here is that the return address of the E-mail isn't 
[EMAIL PROTECTED] (nor is the From: address either, which is 
[EMAIL PROTECTED]).  Declude only looks at the return address, which can't
be 
seen in this case (it is often different than the From: or Reply-To: 
addresses).  You can find the return address in the X-Declude-Sender: 
header, or the MAIL FROM: line in the IMail SMTP log file.
 -Scott

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type
unsubscribe Declude.JunkMail.  The archives can be found at
http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


[Declude.JunkMail] Interesting test results

2003-03-24 Thread brian

Hi Scott and all,

We added a test to SpamManager that has produced some really interesting
results.

What we are doing is to track the 2000 (user configurable) most recent spammer
IP addresses. The list is maintained as an MRU style list (sorted with the
most recent at the top). If incoming messages reach a user defined score, the
IP address of the spammer is added to the list.

As part of our testing procedure for our own lists, we validate the results of
our spam trap accounts and internal email accounts against most of the public
DNS lookup databases and the 3 we subscribe to mostly to determine their
weighting.

Prior to implementing this test, roughly 40% of spam we received also got hits
from one or more of the DNS lookup databases with SpamCop having the best
results (false positives ignored).

Here is what we found. After about 3 weeks of data collection, only about 1 in
400 incoming spams is identified by a DNS lookup, and NOT on the list of the
2000 most recent spammers. Also, of all the spams we receive on all accounts,
about 43% are on the recent spammer list, meaning that almost half of the
spams we receive are from senders that have spammed us before.

In analyzing this data, we found that spam trap accounts that were set up at
the same time, and use the same methods, have a totally different mailing list
distribution after a couple of months. This analysis supports our supposition
that a locally maintained list of spammers is going to be a lot more accurate
than some centrally maintained DNS lookup database. Also we routinely get lots
of spam reported to us that we have never seen, also indicating that spam
mailing lists evolve into lists that tend to be very unique, and that a few
originators are responsible for a majority of spam for each account.

I was thinking that it would probably be a relatively simple matter to add
such a test in a future version of declude. If an incoming message reached a
certain weight, it could be added to a recent spammer list. This list could be
checked along with other internal tests _before_ DNS tests are performed, and
this could push a weighting up high enough that external DNS lookups could be
skipped. 

The effect of this is that by using a individualized IP address scheme,
processing time per message could be greatly reduced resulting in less
resource problems, and faster delivery times.

Anyway, I thought this would make an interesting topic for discussion.

Brian Milburn

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


[Declude.JunkMail] Optimization Service

2003-03-24 Thread Trent M. Davenport
Scott,

We've been a Junkmail client for quite some time and although we love the
product, there is probably a whole lot more we could be doing to optimize
our system.  Being we have 2000 Cable modem clients and I am running the
department by myself, time to learn all the new features, take into
consideration the needs of all our clients (being an ISP) and implementing
the changes to maximize SPAM blocking while minimizing false positives is
just something I don't have time for.

If you or any of the readers of this forum are set up to ask the right
questions and provide the right answers to quickly keep our system optimized
with the least amount of time required on my part, please provide me a
quotation for this service.

The only external service we are subscribing to is Sortmonster's Message
Sniffer.

Trent
---
Trent M. Davenport - Systems Administrator
Northern Television Systems Ltd - WHTV
203-4103 4th Avenue, Whitehorse, YT Y1A 1H6
(867) 393-2225 X204, (867) 393-2224 FAX
www.whtvcable.com http://www.whtvcable.com  (
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  )

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


[Declude.JunkMail] Reverse DNS and mail issues

2003-03-24 Thread Donna Walsh
Hi all - I am having a set of problems that I am wondering if 
there is any relationship between as I know reverse reverse DNS 
can effect mail delivery. 

1.) We are failing to receive mail from some places; one being
verizon and some within our group are questioning if Declude is 
somehow preventing the mail from getting through. I do not think that
is the case.

2.) I got a note from ARIN that our name server for reverse DNS is
a lame name server.  I was able to verify this using www.DNSreport.com

I have looked into this and undertand that the primary name 
server for 194.242.199.in-adr.arpa  (dns.inet911.com) is not
answering authoritatiively.  I have checked the configuraton
and believe the delegation to be set up correctly. 

Is there something I'm missing in the zone file set up (see below)?
Any other ideas of where else to look.


Here is (part of) my zone file for reverse DNS
;
;  Zone file for Reverse DNS records, file 194.242.199.IN-ADDR.ARPA
;

$ORIGIN 194.242.199.IN-ADDR.ARPA.

;
; Authority record
;


@   IN  SOA dns.inet911.com. fred.inet911.com.
(
2003032301 ; serial
3600 ; refresh
7200 ; retry
1728000 ; expire
43200 ; default_ttl
)
;
; Name Server records
;

@   IN  NS  dns.inet911.com.
@   IN  NS  dns2.inet911.com.

;
; Address records
;

1   IN  PTR star.inet911.com.   
2   IN  PTR dns2.inet911.com.   
3   IN  PTR monitor.inet911.com.
truncated rest of address record

Donna Walsh
iNET911.com
www.inet911.com
617-787-5513 office
617-875-4496 mobile
[EMAIL PROTECTED]
 

---
[This E-mail scanned for viruses by Declude Virus]

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


Re: [Declude.JunkMail] Reverse DNS and mail issues

2003-03-24 Thread R. Scott Perry

1.) We are failing to receive mail from some places; one being
verizon and some within our group are questioning if Declude is
somehow preventing the mail from getting through. I do not think that
is the case.
This should be relatively easy to determine.

First, see if you can find the E-mail in the IMail SMTP log files.  If 
there are SMTPD lines for the E-mail, and one of them includes a spool file 
name, IMail accepted the E-mail.  If not, IMail did not accept the E-mail.

Then, you can check the Declude JunkMail log file to see what happened to 
the E-mail.

Finally, you can check the IMail SMTP log file for SMTP- or SMTP log 
file entries, which would indicate IMail attempting to deliver the E-mail.

2.) I got a note from ARIN that our name server for reverse DNS is
a lame name server.  I was able to verify this using www.DNSreport.com
I have looked into this and undertand that the primary name
server for 194.242.199.in-adr.arpa  (dns.inet911.com) is not
answering authoritatiively.  I have checked the configuraton
and believe the delegation to be set up correctly.
This can get very confusing, and depends on what type of DNS server you are 
using.

However, 
http://192.168.0.3/tools/lookup.ch?ip=70.194.242.199.in-addr.arpa.type=PTRserver=dns.inet911.com 
and 
http://192.168.0.3/tools/lookup.ch?ip=70.194.242.199.in-addr.arpa.type=PTRserver=dns2.inet911.com 
show that your DNS servers are reporting authoritatively for the reverse 
DNS for 199.242.194.70.
  -Scott

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


Re: [Declude.JunkMail] Interesting test results

2003-03-24 Thread R. Scott Perry

Here is what we found. After about 3 weeks of data collection, only about 1 in
400 incoming spams is identified by a DNS lookup, and NOT on the list of the
2000 most recent spammers.
That is quite impressive.

I was thinking that it would probably be a relatively simple matter to add
such a test in a future version of declude. If an incoming message reached a
certain weight, it could be added to a recent spammer list. This list could be
checked along with other internal tests _before_ DNS tests are performed, and
this could push a weighting up high enough that external DNS lookups could be
skipped.
The effect of this is that by using a individualized IP address scheme,
processing time per message could be greatly reduced resulting in less
resource problems, and faster delivery times.
That sounds like an excellent idea -- I'm going to investigate to see 
whether this may be possible or not.  Circumventing the DNS lookups would 
be very useful.
-Scott

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


RE: [Declude.JunkMail] Reverse DNS and mail issues

2003-03-24 Thread Donna Walsh
Murphy's Law  -- as soon as I write to the list, I find the DNS prob.

One of my PTR records had a typo -- was PRE instead of PTR and that did it..


Donna

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Donna Walsh
Sent: Monday, March 24, 2003 3:58 PM
To: [EMAIL PROTECTED]
Subject: [Declude.JunkMail] Reverse DNS and mail issues


Hi all - I am having a set of problems that I am wondering if
there is any relationship between as I know reverse reverse DNS
can effect mail delivery.

1.) We are failing to receive mail from some places; one being
verizon and some within our group are questioning if Declude is
somehow preventing the mail from getting through. I do not think that
is the case.

2.) I got a note from ARIN that our name server for reverse DNS is
a lame name server.  I was able to verify this using www.DNSreport.com

I have looked into this and undertand that the primary name
server for 194.242.199.in-adr.arpa  (dns.inet911.com) is not
answering authoritatiively.  I have checked the configuraton
and believe the delegation to be set up correctly.

Is there something I'm missing in the zone file set up (see below)?
Any other ideas of where else to look.


Here is (part of) my zone file for reverse DNS
;
;  Zone file for Reverse DNS records, file 194.242.199.IN-ADDR.ARPA
;

$ORIGIN 194.242.199.IN-ADDR.ARPA.

;
; Authority record
;


@   IN  SOA dns.inet911.com. fred.inet911.com.
(
2003032301 ; serial
3600 ; refresh
7200 ; retry
1728000 ; expire
43200 ; default_ttl
)
;
; Name Server records
;

@   IN  NS  dns.inet911.com.
@   IN  NS  dns2.inet911.com.

;
; Address records
;

1   IN  PTR star.inet911.com.
2   IN  PTR dns2.inet911.com.
3   IN  PTR monitor.inet911.com.
truncated rest of address record

Donna Walsh
iNET911.com
www.inet911.com
617-787-5513 office
617-875-4496 mobile
[EMAIL PROTECTED]


---
[This E-mail scanned for viruses by Declude Virus]

---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.
---
[This E-mail scanned for viruses by Declude Virus]


---
[This E-mail scanned for viruses by Declude Virus]

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


[Declude.JunkMail] Parsing Email Header

2003-03-24 Thread Keith Johnson
Title: Parsing Email Header






I wanted to see if anyone had any luck with a recommended tool (i.e. Perl Script, etc) to parse out email headers on the fly (i.e. Program alias) and adding the address into a block list that Declude Junkmail could guard against the next time. We are wanting to automate a 'HoneyPot' type of scenario. Thanks for the suggestions.


___


Keith Johnson, MCP

Network Engineer

Network Advocates, Inc.

Tel: 502.412.1050

Fax: 502.412.1058

Email: [EMAIL PROTECTED]


Good pings come in small packets






RE: [Declude.JunkMail] Reverse DNS and mail issues

2003-03-24 Thread John Tolmachoff
 Murphy's Law  -- as soon as I write to the list, I find the DNS prob.
 
 One of my PTR records had a typo -- was PRE instead of PTR and that did
it..

At least it is fixed. :))

John Tolmachoff MCSE, CSSA
IT Manager, Network Engineer
RelianceSoft, Inc.
Fullerton, CA  92835
www.reliancesoft.com




---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


Re: [Declude.JunkMail] Parsing Email Header

2003-03-24 Thread Smart Business Lists
Keith,

Monday, March 24, 2003 you wrote:
KJ I wanted to see if anyone had any luck with a recommended tool (i.e.
KJ Perl Script, etc) to parse out email headers on the fly (i.e. Program
KJ alias) and adding the address into a block list that Declude Junkmail
KJ could guard against the next time.  We are wanting to automate a
KJ 'HoneyPot' type of scenario.  Thanks for the suggestions.

You can do it with Perl but you have to teach yourself a lot of stuff.
There are several helpful packages, namely: Mail::Internet;
MIME::Parser; MIME::Tools; HTML::TreeBuilder; MIME::Base64;
MIME::QuotedPrint.

However it is much much easier to buy yourself a copy of Gammadyne
mailer, http://www.gammadyne.com/ , and set up a project for
processing incoming e-mails.


Terry Fritts

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


RE: [Declude.JunkMail] Interesting test results

2003-03-24 Thread Colbeck, Andrew
I was thinking that it would probably be a relatively simple matter to add
such a test in a future version of declude. If an incoming message reached
a
certain weight, it could be added to a recent spammer list. This list
could be
checked along with other internal tests _before_ DNS tests are performed,
and
this could push a weighting up high enough that external DNS lookups could
be
skipped.

The effect of this is that by using a individualized IP address scheme,
processing time per message could be greatly reduced resulting in less
resource problems, and faster delivery times.

SPThat sounds like an excellent idea -- I'm going to investigate to see 
SPwhether this may be possible or not.  Circumventing the DNS lookups would

SPbe very useful.
SP -Scott

Mr. Obvious here... the same technique could be used in the negative to pass
through frequent mail from *low* scoring servers.

That may mean that a server from which we receive a lot of mail, which
suddenly finds itself or its subnet on numerous RBLs, may still deliver its
mail successfully to us, based on it's previous good behaviour.

Andrew.
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


RE: [Declude.JunkMail] Interesting test results

2003-03-24 Thread R. Scott Perry

SPThat sounds like an excellent idea -- I'm going to investigate to see
SPwhether this may be possible or not.  Circumventing the DNS lookups would
SPbe very useful.
Mr. Obvious here... the same technique could be used in the negative to pass
through frequent mail from *low* scoring servers.
That may mean that a server from which we receive a lot of mail, which
suddenly finds itself or its subnet on numerous RBLs, may still deliver its
mail successfully to us, based on it's previous good behaviour.
That sounds like it would work very well as well.  :)
-Scott
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.