RE: [Declude.JunkMail] OT - iMail 7.x and Windows 2003

2005-09-08 Thread Orin Wells
Actually, we have tried both but have not found the culprit(s) 
yet.  Although my partner believes he saw a spike in traffic coming in as a 
Telenet session from an unexpected origin - 
rrcs-74-39-200-122.nys.biz.rr.com which on searching with google appears 
not too uncommon - that is hacks, spam and spyware from users of biz.rr.com.


This has us planning to try to isolate which IP address(es) attacks may be 
coming in on and shut them down.


Regarding telnet - apparently there is a problem with windows 2003 and 
iMail.  If my source is correct one can telnet into a Windows 2003 system 
running iMail (pick a version) on port 25 and get by the 
authentication.  Again, my source told me that neither Micosoft nor 
Ipswitch has come up with a way to stop this.  It appears only to be a 
problem on Windows 2003, not Windows 2000.


At 04:05 PM 9/7/2005, Kevin Bilbee wrote:

Start with TCPView From sysinternals to view open ports on the server find
the ports and programs that should not be running and kill then remove them
from the system.

Also use Process Explorer from sysinternals and look at all the running
processes. If you find one that does not belong then kill and remove it.


Kevin Bilbee



---
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] SPFPass - good or bad?

2005-09-08 Thread Kornitz, David
I use SPFFail to add weight to test to a message, but like you I have
also seen spammers creating SPF records, which in turn allows them to
get lower score with SPFPass.  As a result, we no long find that SPFPass
is a useful in detecting spam.   

David Kornitz / Cornerstone Computer Solutions, Inc,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Dodell
Sent: Thursday, September 08, 2005 12:28 AM
To: declude.junkmail@declude.com
Subject: [Declude.JunkMail] SPFPass - good or bad?

I've noticed a bunch of spam with SPFPass grades that have negated the
spam databases (I have SPFPass at -5) ... is anyone finding that
SPFPass is working with spammers using legitimate ISP's?

david

-
Internet Dental Forum  www.internetdentalforum.org
Dentalcast Podcast www.dentalcast.net

---
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 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] SPFPass - good or bad?

2005-09-08 Thread Nick Hayer

Hi David -

I like the spfpass test - coupled with filters it does help aginst false 
positives.
[I prepend all my tests with the test type - thanks Kami! - it makes 
these filters easier to write -]

Here is my spfgood  filter - I score it with a  -12:
SKIPIFWEIGHT26
TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS
TESTSFAILEDENDCONTAINSIP4R.
TESTSFAILEDENDCONTAINSDNSBL.
TESTSFAILEDENDCONTAINSRHSBL.
TESTSFAILEDENDCONTAINSSNIFFER..
TESTSFAILEDENDCONTAINSEXTERNAL.
TESTSFAILEDENDCONTAINSIPFILE.HOSTS
TESTSFAILEDENDCONTAINSIPFILE.NETWORK
TESTSFAILEDENDCONTAINSIPFILE.SUSPICIOUS
#if it gets to here it is is clean
REMOTEIP0CONTAINS.

Here is my spfmaybe combo filter which I score with a -3:
SKIPIFWEIGHT26
TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS
TESTSFAILEDENDCONTAINS.SBL
TESTSFAILEDENDCONTAINS.XBL
TESTSFAILEDENDCONTAINS.CBL
TESTSFAILEDENDCONTAINS.MPL
#if it gets to here it is not listed in dnsbl's I trust
TESTSFAILED0CONTAINSIP4RW.  [whitelist ip4r tests]
TESTSFAILED0CONTAINSDNSBLW. [whitelist dnsbl tests]

-Nick

David Dodell wrote:


I've noticed a bunch of spam with SPFPass grades that have negated the
spam databases (I have SPFPass at -5) ... is anyone finding that
SPFPass is working with spammers using legitimate ISP's?

david

-
Internet Dental Forum  www.internetdentalforum.org
Dentalcast Podcast www.dentalcast.net

---
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 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] OT - iMail 7.x and Windows 2003

2005-09-08 Thread Dan Horne
Orin Wells  wrote on Thursday, September 08, 2005 1:15 AM:

 
 Regarding telnet - apparently there is a problem with windows 2003
 and iMail.  If my source is correct one can telnet into a Windows
 2003 system running iMail (pick a version) on port 25 and get by the
 authentication.  Again, my source told me that neither Micosoft nor
 Ipswitch has come up with a way to stop this.  It appears only to be
 a problem on Windows 2003, not Windows 2000. 

This is FUD and is patently false.  Telnetting on port 25 is not true
telnet which runs on port 23.  When you connect on port 25 you are
connecting to an SMTP session just like any other SMTP server.  It is
not possible to bypass Authentication in this manner.  If your source is
trying to do this from your network, and you have your network in the
relay mail for addresses list, then no authentication is necessary.
The proper way to test this would be to make the attempt from an outside
network.  If you have your relay settings set to anything other than No
mail relay or relay for addresses, then no authentication is
necessary from any network and you ARE an open relay.  Your source has
his facts wrong.  The OS (windows 2003/2000) has nothing to do with
Imail's SMTP service and whether it requires auth.

Dan Horne  
---
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] SPFPass - good or bad?

2005-09-08 Thread Darrell \([EMAIL PROTECTED])

David,

Since the start of SPF I have seen a steady adoption of SPF by spammers. 
Their really is nothing that stops them from using it.  My suggestion is not 
applying negative weight for SPFPASS.


Darrell
---
invURIBL - Intelligent URI Filtering.  Stops 85%+ SPAM with the default
configuration. Download a copy today - http://www.invariantsystems.com

- Original Message - 
From: David Dodell [EMAIL PROTECTED]

To: declude.junkmail@declude.com
Sent: Thursday, September 08, 2005 1:28 AM
Subject: [Declude.JunkMail] SPFPass - good or bad?



I've noticed a bunch of spam with SPFPass grades that have negated the
spam databases (I have SPFPass at -5) ... is anyone finding that
SPFPass is working with spammers using legitimate ISP's?

david

-
Internet Dental Forum  www.internetdentalforum.org
Dentalcast Podcast www.dentalcast.net

---
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 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] SPFPass - good or bad?

2005-09-08 Thread Darin Cox
Be careful of using spfpass.   Spammers can use SPF, too!

We do not give any credit for passing SPF, only a penalty for failing
which too many email admins set up but allow their networks to send email
from machines not listed in their SPF record :(.

Darin.


- Original Message - 
From: Nick Hayer [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 8:40 AM
Subject: Re: [Declude.JunkMail] SPFPass - good or bad?


Hi David -

I like the spfpass test - coupled with filters it does help aginst false
positives.
[I prepend all my tests with the test type - thanks Kami! - it makes
these filters easier to write -]
Here is my spfgood  filter - I score it with a  -12:
SKIPIFWEIGHT26
TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS
TESTSFAILEDENDCONTAINSIP4R.
TESTSFAILEDENDCONTAINSDNSBL.
TESTSFAILEDENDCONTAINSRHSBL.
TESTSFAILEDENDCONTAINSSNIFFER..
TESTSFAILEDENDCONTAINSEXTERNAL.
TESTSFAILEDENDCONTAINSIPFILE.HOSTS
TESTSFAILEDENDCONTAINSIPFILE.NETWORK
TESTSFAILEDENDCONTAINSIPFILE.SUSPICIOUS
#if it gets to here it is is clean
REMOTEIP0CONTAINS.

Here is my spfmaybe combo filter which I score with a -3:
SKIPIFWEIGHT26
TESTSFAILEDENDNOTCONTAINSTEST.SPFPASS
TESTSFAILEDENDCONTAINS.SBL
TESTSFAILEDENDCONTAINS.XBL
TESTSFAILEDENDCONTAINS.CBL
TESTSFAILEDENDCONTAINS.MPL
#if it gets to here it is not listed in dnsbl's I trust
TESTSFAILED0CONTAINSIP4RW.  [whitelist ip4r tests]
TESTSFAILED0CONTAINSDNSBLW. [whitelist dnsbl tests]

-Nick

David Dodell wrote:

I've noticed a bunch of spam with SPFPass grades that have negated the
spam databases (I have SPFPass at -5) ... is anyone finding that
SPFPass is working with spammers using legitimate ISP's?

david

-
Internet Dental Forum  www.internetdentalforum.org
Dentalcast Podcast www.dentalcast.net

---
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 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 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] SPFPass - good or bad?

2005-09-08 Thread Markus Gufler
Looking at the last 80.000 messages on our Mailserver SPFPASS has had a
positive result on 11% 
Following the final weight after all spam tests 7 from this 11% was right.
The other 4% was a wrong result.

SPFFAIL will only catch around 1% of all processed messages. Nearly all of
the catched right as spam. 
Only 0.12% has had a wrong result.

Markus


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of David Dodell
 Sent: Thursday, September 08, 2005 7:28 AM
 To: declude.junkmail@declude.com
 Subject: [Declude.JunkMail] SPFPass - good or bad?
 
 I've noticed a bunch of spam with SPFPass grades that have 
 negated the spam databases (I have SPFPass at -5) ... is 
 anyone finding that SPFPass is working with spammers using 
 legitimate ISP's?
 
 david
 
 -
 Internet Dental Forum  www.internetdentalforum.org
 Dentalcast Podcast www.dentalcast.net
 
 ---
 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 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] OT - iMail 7.x and Windows 2003

2005-09-08 Thread Matt




One other thing to add to this. Ipswitch in their brilliance, decided
to make a default password of "password" for any newly created account
including root. One must take great care to change these otherwise
they can become susceptible to AUTH hacking with a great deal of ease,
and you then become essentially an open relay even though you are
configured not to be.

Matt



Dan Horne wrote:

  Orin Wells  wrote on Thursday, September 08, 2005 1:15 AM:

 
  
  
Regarding telnet - apparently there is a problem with windows 2003
and iMail.  If my source is correct one can telnet into a Windows
2003 system running iMail (pick a version) on port 25 and get by the
authentication.  Again, my source told me that neither Micosoft nor
Ipswitch has come up with a way to stop this.  It appears only to be
a problem on Windows 2003, not Windows 2000. 

  
  
This is FUD and is patently false.  Telnetting on port 25 is not true
"telnet" which runs on port 23.  When you connect on port 25 you are
connecting to an SMTP session just like any other SMTP server.  It is
not possible to bypass Authentication in this manner.  If your source is
trying to do this from your network, and you have your network in the
"relay mail for addresses" list, then no authentication is necessary.
The proper way to test this would be to make the attempt from an outside
network.  If you have your relay settings set to anything other than "No
mail relay" or "relay for addresses", then no authentication is
necessary from any network and you ARE an open relay.  Your source has
his facts wrong.  The OS (windows 2003/2000) has nothing to do with
Imail's SMTP service and whether it requires auth.

Dan Horne  
---
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] OT - iMail 7.x and Windows 2003

2005-09-08 Thread Russ Lists

Orin Wells wrote:

OK, I see it.  The question is how do you KILL the stuff that has 
gotten into the server?  We shut down the IMAP yesterday primarily 
because we really don't have anyone we are aware of who does not use 
POP3.  But the problem persists and seems to avoid every attempt to 
find it.  I see a lot of code on the examples of how they are using 
the exploit.  I am afraid it does not mean a lot to me and my brain is 
too tired to try to make any sense of this and figure out how to catch 
it.  Surely someone has found a solution.


They *have* to connect to a network port.  If you can't find the port 
that shouldn't be open using something like Foundstone's Vision 
(http://www.foundstone.com/index.htm?subnav=resources/navigation.htmsubcontent=/resources/proddesc/vision.htm) 
... watch wrap .. Then the only option you have is to setup a packet 
capture like ethereal (http://www.ethereal.com/) and looking at the raw 
data. 

My guess is they have been able to plant something they are now using 
against us.  According to the tech if he disconnects the server from 
the network, the problem stops.  It is only when the cable is hooked 
up that it starts in again.


They've definitely installed a root kit.  Windows root kit's are become 
obscenely popular.  Your only option is to capture the raw data with 
ethereal if it's a good root kit.


I suppose if it is coming in on a specific IP address we could 
disconnect them all and then add them back one at a time until we find 
the one they are coming in on, but that sounds like a LOT of work.  Is 
there some other way to find this?  Right now we have a lot of unhappy 
clients.


If you block their IP, they will just come in on another IP.  You must 
find the program and get rid of it, or rebuild...


If I can be of any more assistance, let me know.

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

---
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] OT - iMail 7.x and Windows 2003

2005-09-08 Thread Darrell \([EMAIL PROTECTED])
I have seen some root kits be able to hide from tools like F-Port and such. 
As you have suggested using a packet capture tool usually always helps 
identify which port they are exploiting.  However, with that said the one 
thing that I keep as a golden rule is once a box has been comprimised is 
that its going to be scratched.  You just never know what else the left on 
the machine.


Darrell
---
DLAnalyzer - Comprehensive reporting on Declude Junkmail and Virus. Download 
it today - http://www.invariantsystems.com


- Original Message - 
From: Russ Lists [EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 9:24 AM
Subject: Re: [Declude.JunkMail] OT - iMail 7.x and Windows 2003



Orin Wells wrote:

OK, I see it.  The question is how do you KILL the stuff that has gotten 
into the server?  We shut down the IMAP yesterday primarily because we 
really don't have anyone we are aware of who does not use POP3.  But the 
problem persists and seems to avoid every attempt to find it.  I see a 
lot of code on the examples of how they are using the exploit.  I am 
afraid it does not mean a lot to me and my brain is too tired to try to 
make any sense of this and figure out how to catch it.  Surely someone 
has found a solution.


They *have* to connect to a network port.  If you can't find the port that 
shouldn't be open using something like Foundstone's Vision 
(http://www.foundstone.com/index.htm?subnav=resources/navigation.htmsubcontent=/resources/proddesc/vision.htm) 
... watch wrap .. Then the only option you have is to setup a packet 
capture like ethereal (http://www.ethereal.com/) and looking at the raw 
data.
My guess is they have been able to plant something they are now using 
against us.  According to the tech if he disconnects the server from the 
network, the problem stops.  It is only when the cable is hooked up that 
it starts in again.


They've definitely installed a root kit.  Windows root kit's are become 
obscenely popular.  Your only option is to capture the raw data with 
ethereal if it's a good root kit.


I suppose if it is coming in on a specific IP address we could disconnect 
them all and then add them back one at a time until we find the one they 
are coming in on, but that sounds like a LOT of work.  Is there some 
other way to find this?  Right now we have a lot of unhappy clients.


If you block their IP, they will just come in on another IP.  You must 
find the program and get rid of it, or rebuild...


If I can be of any more assistance, let me know.

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

---
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 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] SPFPass - good or bad?

2005-09-08 Thread Tyran Ormond

On 09:01 AM 9/8/2005 -0400, it would appear that Darin Cox wrote:

Be careful of using spfpass.   Spammers can use SPF, too!

We do not give any credit for passing SPF, only a penalty for failing
which too many email admins set up but allow their networks to send email
from machines not listed in their SPF record :(.

Darin.


Personally, I find SPF to be worthless in all cases.  To begin with, the 
only SPAM it could halt (in a perfect setup) is SPAM sent through 
unauthorized servers.  As already noted, SPAM can be sent legitimately from 
a server using SPF.  Also, current best practices break SPF.  The current 
wisdom is to block outgoing port 25 and force the clients to only send mail 
through the local mail server.  That sounds good on the surface but such a 
practice and SPF cannot live together.


Example:

Employer QRS.com has a beautiful SPF record, clean SPAM record and 
encourages their employees to telecommute.  John, a QRS.com employee, is 
working from home today and needs to send some updated information to one 
of QRS.com's customer.  John's ISP (ISPXYZ) blocks outbound 25 and forces 
its clients to send all email through the ISPXYZ mail server.  John, not 
wanting to confuse his customers by sending the information via his ISPXYZ 
account, uses SMTP Auth and sends his email using his @QRS.com address via 
the IXPXYZ server.  That message, which is completely legitimate AND which 
follows all current best practices, will fail any SPF test.  True, John 
could request that ISPXYZ be added to the QRS.com SPF record but do you 
really want to keep track of every mail server that your employees may have 
legitimate cause to use in sending mail from your domain?  I know I don't 
and we have only a small number of employees and would only have to deal 
with this while employees are out of town attending conferences or training.


The only way SPF could be used reliably is if A) port 25 were thrown wide 
open again and B) mail servers were reconfigured to ONLY send mail for 
their own domain.  Then in the above scenario, John sends his QRS.com mail 
from home via the QRS.com mail server and both QRS.com's and ISPXYZ's mail 
servers would refuse to send mail for any domain but their own.  Then all 
QRS.com's mail would pass SPF and all the mail that ISPXYZ's server sends 
would also pass SPF.



Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]

---
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] SPFPass - good or bad?

2005-09-08 Thread Andy Schmidt
 John, not wanting to confuse his customers by sending the information via
his ISPXYZ account, uses SMTP Auth and sends his email using his @QRS.com
address via the IXPXYZ server.  

That would not be wise.

Instead, he'll use SMTP AUTH on port 587 to send his mail using the @QRS.com
address via the QRS.com mail server.

Declude WHITELIST AUTH takes priority over SPF and Imail 8.2x is capable of
answering on more than one port (e.g., 587).

I've been an early adopter of SPF, running it for quick a long time and
don't have any problem with my own customers failing SPF.  

SPFPASS has to be used with care, I agree.  If spammers use SPFPASS then
their SPF record makes it easy for us to block all their permitted IP
addresses, since they are committing themselves to those.  
I think it's a good idea to first check the IP blacklists and NOT give
credit for SPFPASS unless the IP blacklists come back clean.  In essence,
you are giving SPFPASS credit only to counteract some other tests (such as
content and header checking).

(One could even go a step further and check multiple trusted blacklist
sources - if an IP is listed in several, the SPFPASS could be used to ADD
weight - but that's just a theory.)

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tyran Ormond
Sent: Thursday, September 08, 2005 09:59 AM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] SPFPass - good or bad?

On 09:01 AM 9/8/2005 -0400, it would appear that Darin Cox wrote:
Be careful of using spfpass.   Spammers can use SPF, too!

We do not give any credit for passing SPF, only a penalty for failing
which too many email admins set up but allow their networks to send 
email from machines not listed in their SPF record :(.

Darin.

Personally, I find SPF to be worthless in all cases.  To begin with, the
only SPAM it could halt (in a perfect setup) is SPAM sent through
unauthorized servers.  As already noted, SPAM can be sent legitimately from
a server using SPF.  Also, current best practices break SPF.  The current
wisdom is to block outgoing port 25 and force the clients to only send mail
through the local mail server.  That sounds good on the surface but such a
practice and SPF cannot live together.

Example:

Employer QRS.com has a beautiful SPF record, clean SPAM record and
encourages their employees to telecommute.  John, a QRS.com employee, is
working from home today and needs to send some updated information to one of
QRS.com's customer.  John's ISP (ISPXYZ) blocks outbound 25 and forces its
clients to send all email through the ISPXYZ mail server.  John, not wanting
to confuse his customers by sending the information via his ISPXYZ account,
uses SMTP Auth and sends his email using his @QRS.com address via the IXPXYZ
server.  That message, which is completely legitimate AND which follows all
current best practices, will fail any SPF test.  True, John could request
that ISPXYZ be added to the QRS.com SPF record but do you really want to
keep track of every mail server that your employees may have legitimate
cause to use in sending mail from your domain?  I know I don't and we have
only a small number of employees and would only have to deal with this while
employees are out of town attending conferences or training.

The only way SPF could be used reliably is if A) port 25 were thrown wide
open again and B) mail servers were reconfigured to ONLY send mail for their
own domain.  Then in the above scenario, John sends his QRS.com mail from
home via the QRS.com mail server and both QRS.com's and ISPXYZ's mail
servers would refuse to send mail for any domain but their own.  Then all
QRS.com's mail would pass SPF and all the mail that ISPXYZ's server sends
would also pass SPF.


Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility [EMAIL PROTECTED]

---
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 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] SPFPass - good or bad?

2005-09-08 Thread Darin Cox
Not true.  We find SPF to be extremely useful in stopping spoofing from
domains we host, and there really is no reason for anyone to fail SPF...
when it happens it's the result of poor management on the part of the mail
admins.

Regarding the situation you outlined, SPF can be easily configured to
specify the server that mail is forced through as the sending server.  SPF
records can also be designed to inherit other SPF records, so if an ISP has
SPF defined, then customers who manage their own SPF records can specify to
inherit the ISPs SPF record, thus avoiding having to know and specify all of
the ISPs sending servers.

So, the example you gave is incomplete and can easily be handled by SPF.

Darin.


- Original Message - 
From: Tyran Ormond [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 9:58 AM
Subject: Re: [Declude.JunkMail] SPFPass - good or bad?


On 09:01 AM 9/8/2005 -0400, it would appear that Darin Cox wrote:
Be careful of using spfpass.   Spammers can use SPF, too!

We do not give any credit for passing SPF, only a penalty for failing
which too many email admins set up but allow their networks to send email
from machines not listed in their SPF record :(.

Darin.

Personally, I find SPF to be worthless in all cases.  To begin with, the
only SPAM it could halt (in a perfect setup) is SPAM sent through
unauthorized servers.  As already noted, SPAM can be sent legitimately from
a server using SPF.  Also, current best practices break SPF.  The current
wisdom is to block outgoing port 25 and force the clients to only send mail
through the local mail server.  That sounds good on the surface but such a
practice and SPF cannot live together.

Example:

Employer QRS.com has a beautiful SPF record, clean SPAM record and
encourages their employees to telecommute.  John, a QRS.com employee, is
working from home today and needs to send some updated information to one
of QRS.com's customer.  John's ISP (ISPXYZ) blocks outbound 25 and forces
its clients to send all email through the ISPXYZ mail server.  John, not
wanting to confuse his customers by sending the information via his ISPXYZ
account, uses SMTP Auth and sends his email using his @QRS.com address via
the IXPXYZ server.  That message, which is completely legitimate AND which
follows all current best practices, will fail any SPF test.  True, John
could request that ISPXYZ be added to the QRS.com SPF record but do you
really want to keep track of every mail server that your employees may have
legitimate cause to use in sending mail from your domain?  I know I don't
and we have only a small number of employees and would only have to deal
with this while employees are out of town attending conferences or training.

The only way SPF could be used reliably is if A) port 25 were thrown wide
open again and B) mail servers were reconfigured to ONLY send mail for
their own domain.  Then in the above scenario, John sends his QRS.com mail
from home via the QRS.com mail server and both QRS.com's and ISPXYZ's mail
servers would refuse to send mail for any domain but their own.  Then all
QRS.com's mail would pass SPF and all the mail that ISPXYZ's server sends
would also pass SPF.


Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]

---
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 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] SPFPass - good or bad?

2005-09-08 Thread Tyran Ormond

On 10:32 AM 9/8/2005 -0400, it would appear that Darin Cox wrote:

Regarding the situation you outlined, SPF can be easily configured to
specify the server that mail is forced through as the sending server.  SPF
records can also be designed to inherit other SPF records, so if an ISP has
SPF defined, then customers who manage their own SPF records can specify to
inherit the ISPs SPF record, thus avoiding having to know and specify all of
the ISPs sending servers.


That still means that I have to setup includes for each of the possible 
sending domains, still unacceptable and reason enough for me to discard SPF 
completely.


Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]

---
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] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Timothy Bohen
Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I 
didnt change that path, is there any chance upgrading to 8.21 somehow changed 
it? 

So anyway, now that I downgraded already, should I go to 8.21 again or are 
there problems with declude? I'm not crazy about running a beta version of 
declude.

Thanks



-- Original Message --
From: R. Scott Perry [EMAIL PROTECTED]
Reply-To: Declude.JunkMail@declude.com
Date:  Wed, 07 Sep 2005 19:28:41 -0400

  I gave up and downgraded to 8.15 now I'm getting:
  09:07 15:08 SMTPD(CP) error 3 executing c:\imail\Declude.exe 
D:\IMAIL\spool\Q3ab90041008c0e76.SMD

It looks like you set up Declude to run in C:\IMail, but you run IMail 
on D:\IMail.  :)
   -Scott
---
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.

 

 
__ __ __ __
Sent via the CMS Internet Webmail system at mail1.cmsinter.net


 
   
---
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] SPFPass - good or bad?

2005-09-08 Thread Darin Cox
You have to set up an SPF record for each of the domains anyway, since the
SPF record resides in the DNS of the sending domain, so I don't see that
it's a big deal.

Bottom line: It's a useful tool.  Not as useful as originally intended, but
still useful.  Use it or don't at your discretion.

Darin.


- Original Message - 
From: Tyran Ormond [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 11:09 AM
Subject: Re: [Declude.JunkMail] SPFPass - good or bad?


On 10:32 AM 9/8/2005 -0400, it would appear that Darin Cox wrote:
Regarding the situation you outlined, SPF can be easily configured to
specify the server that mail is forced through as the sending server.  SPF
records can also be designed to inherit other SPF records, so if an ISP has
SPF defined, then customers who manage their own SPF records can specify to
inherit the ISPs SPF record, thus avoiding having to know and specify all
of
the ISPs sending servers.

That still means that I have to setup includes for each of the possible
sending domains, still unacceptable and reason enough for me to discard SPF
completely.

Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]

---
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 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] How to credit a domain

2005-09-08 Thread Goran Jovanovic
Hi all,

I get messages like this all the time and I am always in a dilemma on
what to do about them. This is a legit mail that scored 10 (where I
start tagging mail).


-
Received: from mx.dstsystems.com [204.167.177.68] by
mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07
Sep 2005 15:09:12 -0400

X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A
records [0301].

X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68]

X-Note: Reverse DNS:  Sent from dstsys-cp.dstsystems.com
([204.167.177.68]).

X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0],
SIZE-S [0]

-

So this mail came from domain dstsystems.com on the IP 204.167.177.68
but it is from domain ifdsgroup.com. Now my preferred method of dealing
with this type of problem is to credit based on REVDNS. Again in this
case there is a good REVDNS but it is not from the same domain as the
MAILFROM (if it was then I would have no problem in crediting the
REVDNS).

So is there a way to figure out if dstsystems.com is a e-mail hosting
company and then I would not want to credit the REVDNS as I do not know
what other domains they host. 

If I cannot figure out the link then I would not credit REVDNS and would
move to step 2. Credit HELO. HELOs can be spoofed but in this case the
HELO is basically the same as the REVDNS.

Next step is crediting MAILFROM. This I can do with the ifdsgroup.com
and lower the score for e-mail from this domain. Again it can be spoofed
but ...

I would prefer to credit REVDNS as that cannot be spoofed but I am leery
of crediting an unknown domain when it does not relate to the MAILFROM
address.

Any thoughts on how (if possible) to connect the two domains? Or do I
simply drop down to option 3 and credit MAILFROM? I suppose that I could
try and figure out the admin responsible for dstsystems.com and tell
them to fix the HELOBOGUS error in which case my problems would (mostly)
go away.

Any thoughts and comments are appreciated.

Thanks

 
 Goran Jovanovic
 The LAN Shoppe
---
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] SPF - Missing the Point

2005-09-08 Thread Andy Schmidt
 still unacceptable and reason enough for me to discard SPF completely. 

I think the discusson is missing the key point of SPF.  Sure, this list is
focused on INCOMING spam, and thus we restricting our discussions to
SPFFAIL/SPFPASS and how to use it in Declude.

However, that ignores what SPF is designed to do:

How many times have we received angry emails or hundreds of bounce messages
from other ISPs because some Spammer was sending mail with a fake email
sender - using OUR domain names?

If you define SPF for your own (and client) domain names, then the largest
ISPs won't accept the spam that has your email address faked, thus you and
your clients will no longer be bombarded with responses/complaints/bounces
to messages you never sent in the first place.

The effect of having SPF defined is, that FEWER spammers even bother trying
to abuse YOUR domain name, because they know that a lot of their spam would
never reach anyone.  Instead, they now use their own domain names and even
set up SPF for those.  To me - that ripple effect alone justifies SPF!

Thus, without question, SPF should be in place for all domains you control.
Specially for alias/vanity/web-only domains that never send any email.
Ideally, in addition, set up SMTP AUTH for your clients so that you can use
SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 

---
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] SPF - Missing the Point

2005-09-08 Thread Colbeck, Andrew
That's right on the money, Andy.

I agree 100%.


Andrew 8) 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt
 Sent: Thursday, September 08, 2005 8:48 AM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] SPF - Missing the Point
 
  still unacceptable and reason enough for me to discard SPF 
  completely. 
 
 I think the discusson is missing the key point of SPF.  Sure, 
 this list is focused on INCOMING spam, and thus we 
 restricting our discussions to SPFFAIL/SPFPASS and how to use 
 it in Declude.
 
 However, that ignores what SPF is designed to do:
 
 How many times have we received angry emails or hundreds of 
 bounce messages from other ISPs because some Spammer was 
 sending mail with a fake email sender - using OUR domain names?
 
 If you define SPF for your own (and client) domain names, 
 then the largest ISPs won't accept the spam that has your 
 email address faked, thus you and your clients will no longer 
 be bombarded with responses/complaints/bounces to messages 
 you never sent in the first place.
 
 The effect of having SPF defined is, that FEWER spammers even 
 bother trying to abuse YOUR domain name, because they know 
 that a lot of their spam would never reach anyone.  Instead, 
 they now use their own domain names and even set up SPF for 
 those.  To me - that ripple effect alone justifies SPF!
 
 Thus, without question, SPF should be in place for all 
 domains you control.
 Specially for alias/vanity/web-only domains that never send any email.
 Ideally, in addition, set up SMTP AUTH for your clients so 
 that you can use SPFFAIL for incoming mail and, if you 
 choose, ignore SPFPASS for now.
 
 Best Regards
 Andy Schmidt
 
 Phone:  +1 201 934-3414 x20 (Business)
 Fax:+1 201 934-9206 
 
 ---
 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 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] How to credit a domain

2005-09-08 Thread Colbeck, Andrew
Goran, I have consistently found that providers that handle mail for
other companies are reliable enough that I can merely counterweight
their IP.  I hardly ever trust their reverse DNS, and even less often
the HELO.

I have a last resort test where I have a mixed bag of counterweights.

Andrew 8)


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Goran Jovanovic
 Sent: Thursday, September 08, 2005 8:33 AM
 To: Declude.JunkMail@declude.com
 Subject: [Declude.JunkMail] How to credit a domain
 
 Hi all,
 
 I get messages like this all the time and I am always in a 
 dilemma on what to do about them. This is a legit mail that 
 scored 10 (where I start tagging mail).
 
 --
 --
 -
 Received: from mx.dstsystems.com [204.167.177.68] by 
 mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id 
 AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400
 
 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX 
 or A records [0301].
 
 X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68]
 
 X-Note: Reverse DNS:  Sent from dstsys-cp.dstsystems.com 
 ([204.167.177.68]).
 
 X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], 
 NOLEGITCONTENT [0], SIZE-S [0]
 --
 --
 -
 
 So this mail came from domain dstsystems.com on the IP 
 204.167.177.68 but it is from domain ifdsgroup.com. Now my 
 preferred method of dealing with this type of problem is to 
 credit based on REVDNS. Again in this case there is a good 
 REVDNS but it is not from the same domain as the MAILFROM (if 
 it was then I would have no problem in crediting the REVDNS).
 
 So is there a way to figure out if dstsystems.com is a e-mail 
 hosting company and then I would not want to credit the 
 REVDNS as I do not know what other domains they host. 
 
 If I cannot figure out the link then I would not credit 
 REVDNS and would move to step 2. Credit HELO. HELOs can be 
 spoofed but in this case the HELO is basically the same as the REVDNS.
 
 Next step is crediting MAILFROM. This I can do with the 
 ifdsgroup.com and lower the score for e-mail from this 
 domain. Again it can be spoofed but ...
 
 I would prefer to credit REVDNS as that cannot be spoofed but 
 I am leery of crediting an unknown domain when it does not 
 relate to the MAILFROM address.
 
 Any thoughts on how (if possible) to connect the two domains? 
 Or do I simply drop down to option 3 and credit MAILFROM? I 
 suppose that I could try and figure out the admin responsible 
 for dstsystems.com and tell them to fix the HELOBOGUS error 
 in which case my problems would (mostly) go away.
 
 Any thoughts and comments are appreciated.
 
 Thanks
 
  
  Goran Jovanovic
  The LAN Shoppe
 ---
 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 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] Server Running at 100%

2005-09-08 Thread Richard Farris



I was told to see if using AVAFTERJM would help on 
resources on my server...right now I almost dead in the water..my server is 
cralling to send mailhow do I use this command...exactly how does it go into 
the config..
Richard FarrisEthixs Online1.270.247. 
Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
Internet"

  - Original Message - 
  From: 
  Richard 
  Farris 
  To: Declude.JunkMail@declude.com 
  
  Sent: Thursday, August 04, 2005 11:21 
  AM
  Subject: [Declude.JunkMail] Spam 
box
  
  Is there a box I can put in front of my Imail 
  server that will help take some of the load off of the spam filtering that 
  Declude is doing
  Richard FarrisEthixs 
  Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads 
  to a Cleaner Internet"


Re: [Declude.JunkMail] Server Running at 100%

2005-09-08 Thread Darrell \([EMAIL PROTECTED])



It goes in the virus.cfg file and the option is 
"AVAFTERJM ON". Is your CPU running at 100% due to high load of incoming 
mail? Anything else you can tell us what is going on? Any patterns 
in the logs?

Darrell

---Check out http://www.invariantsystems.com for 
utilities for Declude And Imail. IMail Queue Monitoring, Declude Overflow 
Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log 
Parsers.

  - Original Message - 
  From: 
  Richard 
  Farris 
  To: Declude.JunkMail@declude.com 
  
  Sent: Thursday, September 08, 2005 11:55 
  AM
  Subject: [Declude.JunkMail] Server 
  Running at 100%
  
  I was told to see if using AVAFTERJM would help 
  on resources on my server...right now I almost dead in the water..my server is 
  cralling to send mailhow do I use this command...exactly how does it go 
  into the config..
  Richard FarrisEthixs Online1.270.247. 
  Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
  Internet"
  
- Original Message - 
From: 
Richard 
Farris 
To: Declude.JunkMail@declude.com 

Sent: Thursday, August 04, 2005 11:21 
AM
Subject: [Declude.JunkMail] Spam 
box

Is there a box I can put in front of my Imail 
server that will help take some of the load off of the spam filtering that 
Declude is doing
Richard FarrisEthixs 
Online1.270.247. Office1.800.548.3877 Tech 
Support"Crossroads to a Cleaner 
Internet"


RE: [Declude.JunkMail] Server Running at 100%

2005-09-08 Thread David Barker
In your virus.cfg file:
 
AVAFTERJM ON
 
Also ensure that you have the directive:
 
PRESCANON
 
David B
www.declude.com



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris
Sent: Thursday, September 08, 2005 11:56 AM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] Server Running at 100%
Importance: High


I was told to see if using AVAFTERJM would help on resources on my
server...right now I almost dead in the water..my server is cralling to send
mailhow do I use this command...exactly how does it go into the config..

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet


- Original Message - 
From: Richard Farris mailto:[EMAIL PROTECTED]  
To: Declude.JunkMail@declude.com 
Sent: Thursday, August 04, 2005 11:21 AM
Subject: [Declude.JunkMail] Spam box

Is there a box I can put in front of my Imail server that will help
take some of the load off of the spam filtering that Declude is doing

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet



---
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] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Darrell \([EMAIL PROTECTED])
So anyway, now that I downgraded already, should I go to 8.21 again or are 
there problems with declude? I'm not crazy about running a beta version 
of declude.


The beta seems decent, but their are some issues with multiprocessor 
machines right now.  Essentially it would go to sleep at the wrong times and 
due to sleeping so much it could never really keep up with my volume. 
However, in terms of stability it worked very well no issues with major 
functionality.


Darrell---
Check out http://www.invariantsystems.com for utilities for Declude And 
Imail.  IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI 
integration, MRTG Integration, and Log Parsers.





Thanks



-- Original Message --
From: R. Scott Perry [EMAIL PROTECTED]
Reply-To: Declude.JunkMail@declude.com
Date:  Wed, 07 Sep 2005 19:28:41 -0400


 I gave up and downgraded to 8.15 now I'm getting:
 09:07 15:08 SMTPD(CP) error 3 executing c:\imail\Declude.exe
D:\IMAIL\spool\Q3ab90041008c0e76.SMD

It looks like you set up Declude to run in C:\IMail, but you run IMail
on D:\IMail.  :)
  -Scott
---
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.





__ __ __ __
Sent via the CMS Internet Webmail system at mail1.cmsinter.net




---
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 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] Server Running at 100%

2005-09-08 Thread Colbeck, Andrew



Put:

AVAFTERJM ON

with a blank line after it in your 
virus.cfg

this has pros and cons that have been discussed over and 
over again on this list and the virus list, so the archives will be a rich vein 
to mine, no need to go over it all again.

However, Richard, I don't think you've answered WHAT 
process is taking your cpu time to 100%. Is it multiple instances of 
declude.exe, is it your antivirus program, or what?

Andrew 8)


  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Richard 
  FarrisSent: Thursday, September 08, 2005 8:56 AMTo: 
  Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server 
  Running at 100%Importance: High
  
  I was told to see if using AVAFTERJM would help 
  on resources on my server...right now I almost dead in the water..my server is 
  cralling to send mailhow do I use this command...exactly how does it go 
  into the config..
  Richard FarrisEthixs Online1.270.247. 
  Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
  Internet"
  
- Original Message - 
From: 
Richard 
Farris 
To: Declude.JunkMail@declude.com 

Sent: Thursday, August 04, 2005 11:21 
AM
Subject: [Declude.JunkMail] Spam 
box

Is there a box I can put in front of my Imail 
server that will help take some of the load off of the spam filtering that 
Declude is doing
Richard FarrisEthixs 
Online1.270.247. Office1.800.548.3877 Tech 
Support"Crossroads to a Cleaner 
Internet"


Re: [Declude.JunkMail] Server Running at 100%

2005-09-08 Thread Richard Farris

PRESCAN is not in the virus.cfg file...just put it in there?

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet

- Original Message - 
From: David Barker [EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 11:00 AM
Subject: RE: [Declude.JunkMail] Server Running at 100%



In your virus.cfg file:

AVAFTERJM ON

Also ensure that you have the directive:

PRESCANON

David B
www.declude.com



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris
Sent: Thursday, September 08, 2005 11:56 AM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] Server Running at 100%
Importance: High


I was told to see if using AVAFTERJM would help on resources on my
server...right now I almost dead in the water..my server is cralling to 
send
mailhow do I use this command...exactly how does it go into the 
config..


Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet


- Original Message - 
From: Richard Farris mailto:[EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, August 04, 2005 11:21 AM
Subject: [Declude.JunkMail] Spam box

Is there a box I can put in front of my Imail server that will help
take some of the load off of the spam filtering that Declude is doing

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet



---
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 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] Server Running at 100%

2005-09-08 Thread Darrell \([EMAIL PROTECTED])

Yes - but with the option ON.

PRESCAN ON

Darrell
---
Check out http://www.invariantsystems.com for utilities for Declude And 
Imail.  IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI 
integration, MRTG Integration, and Log Parsers.


- Original Message - 
From: Richard Farris [EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 12:08 PM
Subject: Re: [Declude.JunkMail] Server Running at 100%



PRESCAN is not in the virus.cfg file...just put it in there?

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet

- Original Message - 
From: David Barker [EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 11:00 AM
Subject: RE: [Declude.JunkMail] Server Running at 100%



In your virus.cfg file:

AVAFTERJM ON

Also ensure that you have the directive:

PRESCANON

David B
www.declude.com



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris
Sent: Thursday, September 08, 2005 11:56 AM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] Server Running at 100%
Importance: High


I was told to see if using AVAFTERJM would help on resources on my
server...right now I almost dead in the water..my server is cralling to 
send
mailhow do I use this command...exactly how does it go into the 
config..


Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet


- Original Message - 
From: Richard Farris mailto:[EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, August 04, 2005 11:21 AM
Subject: [Declude.JunkMail] Spam box

Is there a box I can put in front of my Imail server that will help
take some of the load off of the spam filtering that Declude is doing

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet



---
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 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 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] OT - iMail 7.x and Windows 2003

2005-09-08 Thread Don Brown
I don't see that as a big issue.

They can't Auth when 'Account Access Disabled' is checked in the user
gui.

If the user has a POP box, uncheck 'Account Access Disabled' and use
their unique password.

If the user is for forwarding, then make sure that 'Account Access
Disabled' is checked.  They can't Auth, so they can't send.


Thursday, September 8, 2005, 8:15:20 AM, Matt [EMAIL PROTECTED] wrote:
M
M  One other thing to add to this.  Ipswitch in their brilliance,
M decided to make a default password of password for any newly
M created account including root.  One must take great care to change
M these otherwise they can become susceptible to AUTH hacking with a
M great deal of ease, and you then become essentially an open relay
M even though you are configured not to be.
M  
M  Matt
M  
M  
M  
M  Dan Horne wrote: 
M   
M Orin Wells  wrote on Thursday, September 08, 2005 1:15 AM: 
M   
M   
M Regarding telnet - apparently there is a problem with windows 2003
M and iMail.  If my source is correct one can telnet into a Windows
M 2003 system running iMail (pick a version) on port 25 and get by the
M authentication.  Again, my source told me that neither Micosoft nor
M Ipswitch has come up with a way to stop this.  It appears only to be
M a problem on Windows 2003, not Windows 2000. 
M   
M   
M This is FUD and is patently false.  Telnetting on port 25 is not true
M telnet which runs on port 23.  When you connect on port 25 you are
M connecting to an SMTP session just like any other SMTP server.  It is
M not possible to bypass Authentication in this manner.  If your source is
M trying to do this from your network, and you have your network in the
M relay mail for addresses list, then no authentication is necessary.
M The proper way to test this would be to make the attempt from an outside
M network.  If you have your relay settings set to anything other than No
M mail relay or relay for addresses, then no authentication is
M necessary from any network and you ARE an open relay.  Your source has
M his facts wrong.  The OS (windows 2003/2000) has nothing to do with
M Imail's SMTP service and whether it requires auth.

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



Don Brown - Dallas, Texas USA Internet Concepts, Inc.
[EMAIL PROTECTED]   http://www.inetconcepts.net
(972) 788-2364Fax: (972) 788-5049


---
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] Server Running at 100%

2005-09-08 Thread Richard Farris



It looks like sniffer and fprot...when I turn off 
sniffer things look normal but thena lot of spam comes thru too...so I can 
not afford to do thatI think it is just the shear volume of spam hitting my 
server constantly and the server can't keep caught up..
Richard FarrisEthixs Online1.270.247. 
Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
Internet"

  - Original Message - 
  From: 
  Colbeck, 
  Andrew 
  To: Declude.JunkMail@declude.com 
  
  Sent: Thursday, September 08, 2005 11:03 
  AM
  Subject: RE: [Declude.JunkMail] Server 
  Running at 100%
  
  Put:
  
  AVAFTERJM ON
  
  with a blank line after it in your 
  virus.cfg
  
  this has pros and cons that have been discussed over and 
  over again on this list and the virus list, so the archives will be a rich 
  vein to mine, no need to go over it all again.
  
  However, Richard, I don't think you've answered WHAT 
  process is taking your cpu time to 100%. Is it multiple instances of 
  declude.exe, is it your antivirus program, or what?
  
  Andrew 8)
  
  


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Richard 
FarrisSent: Thursday, September 08, 2005 8:56 AMTo: 
Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server 
Running at 100%Importance: High

I was told to see if using AVAFTERJM would help 
on resources on my server...right now I almost dead in the water..my server 
is cralling to send mailhow do I use this command...exactly how does it 
go into the config..
Richard FarrisEthixs Online1.270.247. 
Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
Internet"

  - Original Message - 
  From: 
  Richard 
  Farris 
  To: Declude.JunkMail@declude.com 
  
  Sent: Thursday, August 04, 2005 11:21 
  AM
  Subject: [Declude.JunkMail] Spam 
  box
  
  Is there a box I can put in front of my Imail 
  server that will help take some of the load off of the spam filtering that 
  Declude is doing
  Richard FarrisEthixs 
  Online1.270.247. Office1.800.548.3877 Tech 
  Support"Crossroads to a Cleaner 
  Internet"


Re: [Declude.JunkMail] How to credit a domain

2005-09-08 Thread Scott Fisher
I've struggled also what I call the technical tests (helobogus, badheaders, 
cmdspace, spamheaders).
They indicate to me that something is technically wrong with an email, but 
really don't indicate that the email's content is spam. More likely to be 
spam yes. Solidly spam, no.
The bad news for me is they seem to tend to fire together in groups on 
poorly configured mail servers dragging tho weight of those emails up.

Over time, I've adjusted the scores of these tests downward.

helobogus: I  weight 10 on a subject tag at 100.  It is positive on 11% of 
my total email. It is a false positive on 6% of my total email. Wrong 6% of 
the time!
badheaders: I weight at 30 on a subject tag scale at 100. It is positive on 
14% of my total email. It is a false positive on 1% of my total email.
spamheaders: I weight at 40 on a subject tag scale at 100. It is positive on 
18% of my total email. It is a false positive on 2% of my total email.
cmdspace: I weight at 40 on a subject tag scale at 100. It is positive on 
28% of my total email. It is a false positive on 1% of my total email. This 
test is effective and I use this in combo with sniffer and uribl tests to 
drag middle weighted spam to a higher weight.


I've contemplated putting these together in a technical test filter where I 
could apply a maxweight.



- Original Message - 
From: Goran Jovanovic [EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 10:32 AM
Subject: [Declude.JunkMail] How to credit a domain


Hi all,

I get messages like this all the time and I am always in a dilemma on
what to do about them. This is a legit mail that scored 10 (where I
start tagging mail).


-
Received: from mx.dstsystems.com [204.167.177.68] by
mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07
Sep 2005 15:09:12 -0400

X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A
records [0301].

X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68]

X-Note: Reverse DNS:  Sent from dstsys-cp.dstsystems.com
([204.167.177.68]).

X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0],
SIZE-S [0]

-

So this mail came from domain dstsystems.com on the IP 204.167.177.68
but it is from domain ifdsgroup.com. Now my preferred method of dealing
with this type of problem is to credit based on REVDNS. Again in this
case there is a good REVDNS but it is not from the same domain as the
MAILFROM (if it was then I would have no problem in crediting the
REVDNS).

So is there a way to figure out if dstsystems.com is a e-mail hosting
company and then I would not want to credit the REVDNS as I do not know
what other domains they host.

If I cannot figure out the link then I would not credit REVDNS and would
move to step 2. Credit HELO. HELOs can be spoofed but in this case the
HELO is basically the same as the REVDNS.

Next step is crediting MAILFROM. This I can do with the ifdsgroup.com
and lower the score for e-mail from this domain. Again it can be spoofed
but ...

I would prefer to credit REVDNS as that cannot be spoofed but I am leery
of crediting an unknown domain when it does not relate to the MAILFROM
address.

Any thoughts on how (if possible) to connect the two domains? Or do I
simply drop down to option 3 and credit MAILFROM? I suppose that I could
try and figure out the admin responsible for dstsystems.com and tell
them to fix the HELOBOGUS error in which case my problems would (mostly)
go away.

Any thoughts and comments are appreciated.

Thanks


Goran Jovanovic
The LAN Shoppe
---
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 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] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Matt




IMail 8.20+ is only compatible with Declude 3+, but that software is
still in early beta and I wouldn't recommend it. This combination can
work, but it appears that the higher the volume you have, the more
likely you are to experience serious issues with E-mail backing up. I
have been using IMail 8.15 HF2 for many months without any new issues,
and it works very well with Declude 2.0.6.16 (the most recent interim
release) which also doesn't have any new issues. The newer Declude 3.0
that is in beta is basically the same in terms of functionality, but it
is changed to act as a service in order to resolve issues with the
changes in IMail 8.20+ and also increase performance slightly. This is
a big change for Declude, and building a service to handle E-mail
reliably isn't a small feat so I would suggest being patient in the
mean time.

Matt



Timothy Bohen wrote:

  Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? 

So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude.

Thanks



-- Original Message --
From: "R. Scott Perry" [EMAIL PROTECTED]
Reply-To: Declude.JunkMail@declude.com
Date:  Wed, 07 Sep 2005 19:28:41 -0400

  
  

  I gave up and downgraded to 8.15 now I'm getting:
09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" 
  

"D:\IMAIL\spool\Q3ab90041008c0e76.SMD"

It looks like you set up Declude to run in C:\IMail, but you run IMail 
on D:\IMail.  :)
  -Scott
---
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.


  
   

 
__ __ __ __
Sent via the CMS Internet Webmail system at mail1.cmsinter.net


 
   
---
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] Server Running at 100%

2005-09-08 Thread Erik
Yes, just put it in there.

I also think that it requires the PRO version to work ?

Erik


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris
Sent: Thursday, September 08, 2005 10:08 AM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Server Running at 100%


PRESCAN is not in the virus.cfg file...just put it in there?

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet

- Original Message - 
From: David Barker [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 11:00 AM
Subject: RE: [Declude.JunkMail] Server Running at 100%


 In your virus.cfg file:

 AVAFTERJM ON

 Also ensure that you have the directive:

 PRESCANON

 David B
 www.declude.com

 

 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Richard 
 Farris
 Sent: Thursday, September 08, 2005 11:56 AM
 To: Declude.JunkMail@declude.com
 Subject: [Declude.JunkMail] Server Running at 100%
 Importance: High


 I was told to see if using AVAFTERJM would help on resources on my 
 server...right now I almost dead in the water..my server is cralling 
 to send mailhow do I use this command...exactly how does it go 
 into the config..

 Richard Farris
 Ethixs Online
 1.270.247. Office
 1.800.548.3877 Tech Support
 Crossroads to a Cleaner Internet


 - Original Message -
 From: Richard Farris mailto:[EMAIL PROTECTED]
 To: Declude.JunkMail@declude.com
 Sent: Thursday, August 04, 2005 11:21 AM
 Subject: [Declude.JunkMail] Spam box

 Is there a box I can put in front of my Imail server that will help 
 take some of the load off of the spam filtering that Declude is 
 doing

 Richard Farris
 Ethixs Online
 1.270.247. Office
 1.800.548.3877 Tech Support
 Crossroads to a Cleaner Internet



 ---
 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 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 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] SPF - Missing the Point

2005-09-08 Thread Darin Cox
Excellent point, Andy.  Not just detecting spoofing, but changing behavior
to avoid future spoofing.

Darin.


- Original Message - 
From: Andy Schmidt [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 11:47 AM
Subject: RE: [Declude.JunkMail] SPF - Missing the Point


 still unacceptable and reason enough for me to discard SPF completely. 

I think the discusson is missing the key point of SPF.  Sure, this list is
focused on INCOMING spam, and thus we restricting our discussions to
SPFFAIL/SPFPASS and how to use it in Declude.

However, that ignores what SPF is designed to do:

How many times have we received angry emails or hundreds of bounce messages
from other ISPs because some Spammer was sending mail with a fake email
sender - using OUR domain names?

If you define SPF for your own (and client) domain names, then the largest
ISPs won't accept the spam that has your email address faked, thus you and
your clients will no longer be bombarded with responses/complaints/bounces
to messages you never sent in the first place.

The effect of having SPF defined is, that FEWER spammers even bother trying
to abuse YOUR domain name, because they know that a lot of their spam would
never reach anyone.  Instead, they now use their own domain names and even
set up SPF for those.  To me - that ripple effect alone justifies SPF!

Thus, without question, SPF should be in place for all domains you control.
Specially for alias/vanity/web-only domains that never send any email.
Ideally, in addition, set up SMTP AUTH for your clients so that you can use
SPFFAIL for incoming mail and, if you choose, ignore SPFPASS for now.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206

---
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 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] Server Running at 100%

2005-09-08 Thread Richard Farris



After doing this my server looks more normal...up 
and down instead of constant 100% then drop for a couple seconds then back to 
100%..I will check the archives and monitor to see if I am screwing up 
here..
Richard FarrisEthixs Online1.270.247. 
Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
Internet"

  - Original Message - 
  From: 
  Colbeck, 
  Andrew 
  To: Declude.JunkMail@declude.com 
  
  Sent: Thursday, September 08, 2005 11:03 
  AM
  Subject: RE: [Declude.JunkMail] Server 
  Running at 100%
  
  Put:
  
  AVAFTERJM ON
  
  with a blank line after it in your 
  virus.cfg
  
  this has pros and cons that have been discussed over and 
  over again on this list and the virus list, so the archives will be a rich 
  vein to mine, no need to go over it all again.
  
  However, Richard, I don't think you've answered WHAT 
  process is taking your cpu time to 100%. Is it multiple instances of 
  declude.exe, is it your antivirus program, or what?
  
  Andrew 8)
  
  


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Richard 
FarrisSent: Thursday, September 08, 2005 8:56 AMTo: 
Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server 
Running at 100%Importance: High

I was told to see if using AVAFTERJM would help 
on resources on my server...right now I almost dead in the water..my server 
is cralling to send mailhow do I use this command...exactly how does it 
go into the config..
Richard FarrisEthixs Online1.270.247. 
Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
Internet"

  - Original Message - 
  From: 
  Richard 
  Farris 
  To: Declude.JunkMail@declude.com 
  
  Sent: Thursday, August 04, 2005 11:21 
  AM
  Subject: [Declude.JunkMail] Spam 
  box
  
  Is there a box I can put in front of my Imail 
  server that will help take some of the load off of the spam filtering that 
  Declude is doing
  Richard FarrisEthixs 
  Online1.270.247. Office1.800.548.3877 Tech 
  Support"Crossroads to a Cleaner 
  Internet"


RE: [Declude.JunkMail] How to credit a domain

2005-09-08 Thread Goran Jovanovic
Andrew,

Why would you counterweight their IP and not the REVDNS? It seems that
it is basically the same thing?

 
 Goran Jovanovic
 The LAN Shoppe

 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
 [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
 Sent: Thursday, September 08, 2005 11:52 AM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] How to credit a domain
 
 Goran, I have consistently found that providers that handle mail for
 other companies are reliable enough that I can merely counterweight
 their IP.  I hardly ever trust their reverse DNS, and even less often
 the HELO.
 
 I have a last resort test where I have a mixed bag of counterweights.
 
 Andrew 8)
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of
  Goran Jovanovic
  Sent: Thursday, September 08, 2005 8:33 AM
  To: Declude.JunkMail@declude.com
  Subject: [Declude.JunkMail] How to credit a domain
 
  Hi all,
 
  I get messages like this all the time and I am always in a
  dilemma on what to do about them. This is a legit mail that
  scored 10 (where I start tagging mail).
 
  --
  --
  -
  Received: from mx.dstsystems.com [204.167.177.68] by
  mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id
  AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400
 
  X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX
  or A records [0301].
 
  X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68]
 
  X-Note: Reverse DNS:  Sent from dstsys-cp.dstsystems.com
  ([204.167.177.68]).
 
  X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5],
  NOLEGITCONTENT [0], SIZE-S [0]
  --
  --
  -
 
  So this mail came from domain dstsystems.com on the IP
  204.167.177.68 but it is from domain ifdsgroup.com. Now my
  preferred method of dealing with this type of problem is to
  credit based on REVDNS. Again in this case there is a good
  REVDNS but it is not from the same domain as the MAILFROM (if
  it was then I would have no problem in crediting the REVDNS).
 
  So is there a way to figure out if dstsystems.com is a e-mail
  hosting company and then I would not want to credit the
  REVDNS as I do not know what other domains they host.
 
  If I cannot figure out the link then I would not credit
  REVDNS and would move to step 2. Credit HELO. HELOs can be
  spoofed but in this case the HELO is basically the same as the
REVDNS.
 
  Next step is crediting MAILFROM. This I can do with the
  ifdsgroup.com and lower the score for e-mail from this
  domain. Again it can be spoofed but ...
 
  I would prefer to credit REVDNS as that cannot be spoofed but
  I am leery of crediting an unknown domain when it does not
  relate to the MAILFROM address.
 
  Any thoughts on how (if possible) to connect the two domains?
  Or do I simply drop down to option 3 and credit MAILFROM? I
  suppose that I could try and figure out the admin responsible
  for dstsystems.com and tell them to fix the HELOBOGUS error
  in which case my problems would (mostly) go away.
 
  Any thoughts and comments are appreciated.
 
  Thanks
 
 
   Goran Jovanovic
   The LAN Shoppe
  ---
  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 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 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] Server Running at 100%

2005-09-08 Thread Colbeck, Andrew



Did you get my reply in the Message Sniffer support list 
about rotating your log file?

Andrew 8)

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Richard 
  FarrisSent: Thursday, September 08, 2005 9:15 AMTo: 
  Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Server 
  Running at 100%
  
  It looks like sniffer and fprot...when I turn off 
  sniffer things look normal but thena lot of spam comes thru too...so I 
  can not afford to do thatI think it is just the shear volume of spam 
  hitting my server constantly and the server can't keep caught 
up..
  Richard FarrisEthixs Online1.270.247. 
  Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
  Internet"
  
- Original Message - 
From: 
Colbeck, 
Andrew 
To: Declude.JunkMail@declude.com 

Sent: Thursday, September 08, 2005 
11:03 AM
Subject: RE: [Declude.JunkMail] Server 
Running at 100%

Put:

AVAFTERJM ON

with a blank line after it in your 
virus.cfg

this has pros and cons that have been discussed over 
and over again on this list and the virus list, so the archives will be a 
rich vein to mine, no need to go over it all again.

However, Richard, I don't think you've answered WHAT 
process is taking your cpu time to 100%. Is it multiple instances of 
declude.exe, is it your antivirus program, or what?

Andrew 8)


  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Richard 
  FarrisSent: Thursday, September 08, 2005 8:56 AMTo: 
  Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Server 
  Running at 100%Importance: High
  
  I was told to see if using AVAFTERJM would 
  help on resources on my server...right now I almost dead in the water..my 
  server is cralling to send mailhow do I use this command...exactly how 
  does it go into the config..
  Richard FarrisEthixs Online1.270.247. 
  Office1.800.548.3877 Tech Support"Crossroads to a Cleaner 
  Internet"
  
- Original Message - 
From: 
Richard 
Farris 
To: Declude.JunkMail@declude.com 

Sent: Thursday, August 04, 2005 
11:21 AM
Subject: [Declude.JunkMail] Spam 
box

Is there a box I can put in front of my 
Imail server that will help take some of the load off of the spam 
filtering that Declude is doing
Richard FarrisEthixs 
Online1.270.247. Office1.800.548.3877 Tech 
Support"Crossroads to a Cleaner 
Internet"


Re: [Declude.JunkMail] How to credit a domain

2005-09-08 Thread Darin Cox
We maintain a filter file for many of the major tests, including REVDNS so
we can credit domains or addresses that fail a specific test.  This is a
much narrower way to credit than a whitelist, as it only credits if the
message failed the test to begin with.

Darin.


- Original Message - 
From: Goran Jovanovic [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 11:32 AM
Subject: [Declude.JunkMail] How to credit a domain


Hi all,

I get messages like this all the time and I am always in a dilemma on
what to do about them. This is a legit mail that scored 10 (where I
start tagging mail).


-
Received: from mx.dstsystems.com [204.167.177.68] by
mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id AAD8195300F2; Wed, 07
Sep 2005 15:09:12 -0400

X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A
records [0301].

X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68]

X-Note: Reverse DNS:  Sent from dstsys-cp.dstsystems.com
([204.167.177.68]).

X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT [0],
SIZE-S [0]

-

So this mail came from domain dstsystems.com on the IP 204.167.177.68
but it is from domain ifdsgroup.com. Now my preferred method of dealing
with this type of problem is to credit based on REVDNS. Again in this
case there is a good REVDNS but it is not from the same domain as the
MAILFROM (if it was then I would have no problem in crediting the
REVDNS).

So is there a way to figure out if dstsystems.com is a e-mail hosting
company and then I would not want to credit the REVDNS as I do not know
what other domains they host.

If I cannot figure out the link then I would not credit REVDNS and would
move to step 2. Credit HELO. HELOs can be spoofed but in this case the
HELO is basically the same as the REVDNS.

Next step is crediting MAILFROM. This I can do with the ifdsgroup.com
and lower the score for e-mail from this domain. Again it can be spoofed
but ...

I would prefer to credit REVDNS as that cannot be spoofed but I am leery
of crediting an unknown domain when it does not relate to the MAILFROM
address.

Any thoughts on how (if possible) to connect the two domains? Or do I
simply drop down to option 3 and credit MAILFROM? I suppose that I could
try and figure out the admin responsible for dstsystems.com and tell
them to fix the HELOBOGUS error in which case my problems would (mostly)
go away.

Any thoughts and comments are appreciated.

Thanks


 Goran Jovanovic
 The LAN Shoppe
---
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 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] SPFPass - good or bad?

2005-09-08 Thread Nick Hayer

Tyran Ormond wrote:

That still means that I have to setup includes for each of the 
possible sending domains, still unacceptable and reason enough for me 
to discard SPF completely.


Well be advised not all your mail will get delivered.  I have some 
insurance agencies whose mail will bounce if I did not have valid spf 
recs for their domains. I know this because its happened.  :)
[The setup is kake; some dns programs can even synthesize spf recs for 
local domains. SimpleDns for one will ]


-Nick



Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]

---
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 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] How to credit a domain

2005-09-08 Thread Darrell \([EMAIL PROTECTED])
One would suspect if they have PTR's setup for all their customer's IP's 
like other providers.


Example:
customer1-xx-xx-xx-xx.dtsystems.com

This way you may not get killed by a customer IP infected with a trojan 
since you are only reverse weighting the mail server IP.


Darrell
---
Check out http://www.invariantsystems.com for utilities for Declude And 
Imail.  IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI 
integration, MRTG Integration, and Log Parsers.


- Original Message - 
From: Goran Jovanovic [EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 12:21 PM
Subject: RE: [Declude.JunkMail] How to credit a domain


Andrew,

Why would you counterweight their IP and not the REVDNS? It seems that
it is basically the same thing?


Goran Jovanovic
The LAN Shoppe




-Original Message-
From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
Sent: Thursday, September 08, 2005 11:52 AM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] How to credit a domain

Goran, I have consistently found that providers that handle mail for
other companies are reliable enough that I can merely counterweight
their IP.  I hardly ever trust their reverse DNS, and even less often
the HELO.

I have a last resort test where I have a mixed bag of counterweights.

Andrew 8)


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 Goran Jovanovic
 Sent: Thursday, September 08, 2005 8:33 AM
 To: Declude.JunkMail@declude.com
 Subject: [Declude.JunkMail] How to credit a domain

 Hi all,

 I get messages like this all the time and I am always in a
 dilemma on what to do about them. This is a legit mail that
 scored 10 (where I start tagging mail).

 --
 --
 -
 Received: from mx.dstsystems.com [204.167.177.68] by
 mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id
 AAD8195300F2; Wed, 07 Sep 2005 15:09:12 -0400

 X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX
 or A records [0301].

 X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68]

 X-Note: Reverse DNS:  Sent from dstsys-cp.dstsystems.com
 ([204.167.177.68]).

 X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5],
 NOLEGITCONTENT [0], SIZE-S [0]
 --
 --
 -

 So this mail came from domain dstsystems.com on the IP
 204.167.177.68 but it is from domain ifdsgroup.com. Now my
 preferred method of dealing with this type of problem is to
 credit based on REVDNS. Again in this case there is a good
 REVDNS but it is not from the same domain as the MAILFROM (if
 it was then I would have no problem in crediting the REVDNS).

 So is there a way to figure out if dstsystems.com is a e-mail
 hosting company and then I would not want to credit the
 REVDNS as I do not know what other domains they host.

 If I cannot figure out the link then I would not credit
 REVDNS and would move to step 2. Credit HELO. HELOs can be
 spoofed but in this case the HELO is basically the same as the

REVDNS.


 Next step is crediting MAILFROM. This I can do with the
 ifdsgroup.com and lower the score for e-mail from this
 domain. Again it can be spoofed but ...

 I would prefer to credit REVDNS as that cannot be spoofed but
 I am leery of crediting an unknown domain when it does not
 relate to the MAILFROM address.

 Any thoughts on how (if possible) to connect the two domains?
 Or do I simply drop down to option 3 and credit MAILFROM? I
 suppose that I could try and figure out the admin responsible
 for dstsystems.com and tell them to fix the HELOBOGUS error
 in which case my problems would (mostly) go away.

 Any thoughts and comments are appreciated.

 Thanks


  Goran Jovanovic
  The LAN Shoppe
 ---
 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 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 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 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] How to credit a domain

2005-09-08 Thread Colbeck, Andrew
Hi, Goran.

I like to counterweight based on their IP for a couple of reasons.  The
first is that if their administration is not up to par (so that I have
to counterweight them), the odds are good that their revdns is flawed or
that their DNS is subject to timeouts.

I also find that, as a practical matter, a company is as likely to
change their IP as their revdns so neither is more stable than the
other.

Third, a lot of the companies with this kind of problem also fail REVDNS
anyway!

Last, larger companies can sometimes easily be spotted in SenderBase.org
as having all of their mailhosts on a small subnet and I can use a
REMOTEIP CIDR mask.

Andrew 8)



 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Goran Jovanovic
 Sent: Thursday, September 08, 2005 9:22 AM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] How to credit a domain
 
 Andrew,
 
 Why would you counterweight their IP and not the REVDNS? It 
 seems that it is basically the same thing?
 
  
  Goran Jovanovic
  The LAN Shoppe
 
  
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- 
  [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
  Sent: Thursday, September 08, 2005 11:52 AM
  To: Declude.JunkMail@declude.com
  Subject: RE: [Declude.JunkMail] How to credit a domain
  
  Goran, I have consistently found that providers that handle 
 mail for 
  other companies are reliable enough that I can merely counterweight 
  their IP.  I hardly ever trust their reverse DNS, and even 
 less often 
  the HELO.
  
  I have a last resort test where I have a mixed bag of 
 counterweights.
  
  Andrew 8)
  
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of Goran 
   Jovanovic
   Sent: Thursday, September 08, 2005 8:33 AM
   To: Declude.JunkMail@declude.com
   Subject: [Declude.JunkMail] How to credit a domain
  
   Hi all,
  
   I get messages like this all the time and I am always in 
 a dilemma 
   on what to do about them. This is a legit mail that 
 scored 10 (where 
   I start tagging mail).
  
   --
   --
   -
   Received: from mx.dstsystems.com [204.167.177.68] by 
   mail1.gonetworks.net with ESMTP (SMTPD32-8.13) id 
 AAD8195300F2; Wed, 
   07 Sep 2005 15:09:12 -0400
  
   X-RBL-Warning: HELOBOGUS: Domain mx.dstsystems.com has no MX or A 
   records [0301].
  
   X-Declude-Sender: [EMAIL PROTECTED] [204.167.177.68]
  
   X-Note: Reverse DNS:  Sent from dstsys-cp.dstsystems.com 
   ([204.167.177.68]).
  
   X-Note: Tests Failed: CMDSPACE [8], HELOBOGUS [5], NOLEGITCONTENT 
   [0], SIZE-S [0]
   --
   --
   -
  
   So this mail came from domain dstsystems.com on the IP
   204.167.177.68 but it is from domain ifdsgroup.com. Now 
 my preferred 
   method of dealing with this type of problem is to credit based on 
   REVDNS. Again in this case there is a good REVDNS but it 
 is not from 
   the same domain as the MAILFROM (if it was then I would have no 
   problem in crediting the REVDNS).
  
   So is there a way to figure out if dstsystems.com is a e-mail 
   hosting company and then I would not want to credit the 
 REVDNS as I 
   do not know what other domains they host.
  
   If I cannot figure out the link then I would not credit 
 REVDNS and 
   would move to step 2. Credit HELO. HELOs can be spoofed 
 but in this 
   case the HELO is basically the same as the
 REVDNS.
  
   Next step is crediting MAILFROM. This I can do with the 
   ifdsgroup.com and lower the score for e-mail from this 
 domain. Again 
   it can be spoofed but ...
  
   I would prefer to credit REVDNS as that cannot be spoofed 
 but I am 
   leery of crediting an unknown domain when it does not relate to 
   the MAILFROM address.
  
   Any thoughts on how (if possible) to connect the two domains?
   Or do I simply drop down to option 3 and credit MAILFROM? 
 I suppose 
   that I could try and figure out the admin responsible for 
   dstsystems.com and tell them to fix the HELOBOGUS error in which 
   case my problems would (mostly) go away.
  
   Any thoughts and comments are appreciated.
  
   Thanks
  
  
Goran Jovanovic
The LAN Shoppe
   ---
   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 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 came from the Declude.JunkMail mailing list.  To 
 unsubscribe, just send an E-mail to [EMAIL PROTECTED], and 
 type unsubscribe Declude.JunkMail.  The archives 

RE: [Declude.JunkMail] SPF - Missing the Point

2005-09-08 Thread Tyran Ormond

On 11:47 AM 9/8/2005 -0400, it would appear that Andy Schmidt wrote:

 still unacceptable and reason enough for me to discard SPF completely. 

I think the discusson is missing the key point of SPF.  Sure, this list is
focused on INCOMING spam, and thus we restricting our discussions to
SPFFAIL/SPFPASS and how to use it in Declude..


[snip]


If you define SPF for your own (and client) domain names, then the largest
ISPs won't accept the spam that has your email address faked, thus you and
your clients will no longer be bombarded with responses/complaints/bounces
to messages you never sent in the first place.

The effect of having SPF defined is, that FEWER spammers even bother trying
to abuse YOUR domain name.


No, the effect is that if I define SPF (which I don't and won't as I'll 
explain) then I am forced to either write includes for Netzero, Xmission, 
Connect2 and every other ISP that my users (employees) use at home where 
they also write emails that legitimately use @cvwrf.org.  If I use SPF and 
*don't* write those includes then I am forcing a FAIL when those users send 
mail through their home ISP using @cvwrf.org.  If, however, I don't have 
any SPF record (which I don't) then at worst an SPF test is required to 
return a NONE/NEUTRAL.  Some ISPs do reject on FAIL but I have yet to find 
one that rejects on a NONE/NEUTRAL because the RFC specifies that 
NONE/NEUTRAL should not be rejected out of hand.  For example, SPFFAIL is 
*not* triggered if a domain has no SPF record.


From the Junkmail manual:
Note that it will not be triggered for E-mail that has other problems (no 
SPF record, unknown results from the SPF record, etc.). So any E-mail 
failing the SPFFAIL test is E-mail that is not authorized per the 
administrator of the domain the E-mail is being sent from.



In short, I better ensure my that my users can send mail regardless of 
their location by not having any SPF record.  That also means that I do no 
SPF checks on incoming mail, in my view it is simply too 
unreliable.  Besides, my other Declude tests are already catching 97% of 
the SPAM we receive with only 0.03% of those messages caught being false 
positives.


As to using port 587 as you suggested early Andy, we may do that eventually 
but currently 587 usage is still not widespread enough on the client 
side.  Sure, I can *make* 587 work for nearly any client out there but that 
will break port 25 usage on many of those clients.  Example:  Any Eudora 
client older than 17 June 2005 can use *either* port 25 or port 587 for 
sending.  Besides, I *really* don't want to make 73 house calls to get my 
users over to port 587. ;)



Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]

---
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] SPF - Missing the Point

2005-09-08 Thread Darin Cox
Well, it's entirely up to you:  Tell your users to send out through your
server instead of their ISP(over port 587 if the ISP is blocking 25) or use
the SPF neutral response instead of pass or fail.

Yes, it requires a little work, but for us it has proven useful.  I don't
think anyone is saying it's perfect, but it can be implemented in a useful
fashion.

Darin.


- Original Message - 
From: Tyran Ormond [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 12:39 PM
Subject: RE: [Declude.JunkMail] SPF - Missing the Point


On 11:47 AM 9/8/2005 -0400, it would appear that Andy Schmidt wrote:
  still unacceptable and reason enough for me to discard SPF completely.


I think the discusson is missing the key point of SPF.  Sure, this list is
focused on INCOMING spam, and thus we restricting our discussions to
SPFFAIL/SPFPASS and how to use it in Declude..

[snip]

If you define SPF for your own (and client) domain names, then the largest
ISPs won't accept the spam that has your email address faked, thus you and
your clients will no longer be bombarded with responses/complaints/bounces
to messages you never sent in the first place.

The effect of having SPF defined is, that FEWER spammers even bother trying
to abuse YOUR domain name.

No, the effect is that if I define SPF (which I don't and won't as I'll
explain) then I am forced to either write includes for Netzero, Xmission,
Connect2 and every other ISP that my users (employees) use at home where
they also write emails that legitimately use @cvwrf.org.  If I use SPF and
*don't* write those includes then I am forcing a FAIL when those users send
mail through their home ISP using @cvwrf.org.  If, however, I don't have
any SPF record (which I don't) then at worst an SPF test is required to
return a NONE/NEUTRAL.  Some ISPs do reject on FAIL but I have yet to find
one that rejects on a NONE/NEUTRAL because the RFC specifies that
NONE/NEUTRAL should not be rejected out of hand.  For example, SPFFAIL is
*not* triggered if a domain has no SPF record.

 From the Junkmail manual:
Note that it will not be triggered for E-mail that has other problems (no
SPF record, unknown results from the SPF record, etc.). So any E-mail
failing the SPFFAIL test is E-mail that is not authorized per the
administrator of the domain the E-mail is being sent from.


In short, I better ensure my that my users can send mail regardless of
their location by not having any SPF record.  That also means that I do no
SPF checks on incoming mail, in my view it is simply too
unreliable.  Besides, my other Declude tests are already catching 97% of
the SPAM we receive with only 0.03% of those messages caught being false
positives.

As to using port 587 as you suggested early Andy, we may do that eventually
but currently 587 usage is still not widespread enough on the client
side.  Sure, I can *make* 587 work for nearly any client out there but that
will break port 25 usage on many of those clients.  Example:  Any Eudora
client older than 17 June 2005 can use *either* port 25 or port 587 for
sending.  Besides, I *really* don't want to make 73 house calls to get my
users over to port 587. ;)


Tyran Ormond
Programmer/LAN Administrator
Central Valley Water Reclamation Facility
[EMAIL PROTECTED]

---
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 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] How to credit a domain

2005-09-08 Thread Darin Cox
Good point.  I wasn't thinking about the domain in question, only the
practice, and didn't go so far as to mention that for ISP domains like this,
we prefer to counterweight by MAILFROM on the exact email address rather
than REVDNS.

It's all about being as narrow as possible where there's room for abuse...

Darin.


- Original Message - 
From: Colbeck, Andrew [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 12:58 PM
Subject: RE: [Declude.JunkMail] How to credit a domain


Danger, Will Robinson! Danger!

Darin, thank you pointing out that qualifying a domain name with a
prepended period is a solid best practice, and I'll add that it is
mandatory to get the expected results when one uses a SPAMDOMAINS test.

However, this ComCast example is NOT a recommended action, as it will
still have the flaw I cited earlier, i.e. that you would be
counterweighting their mailhosts all right, but also all of the zombies
on their highly infested cable subscriber network.

Andrew 8)


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox
 Sent: Thursday, September 08, 2005 9:46 AM
 To: Declude.JunkMail@declude.com
 Subject: Re: [Declude.JunkMail] How to credit a domain

 Might want to make it

 REVDNS -100 ENDSWITH .ComCast.net

 instead of

 REVDNS -100 ENDSWITH ComCast.net

 (note the period before comcast.net)

 That way spamcomcast.net won't match when you don't want it to.

 Darin.


 - Original Message -
 From: Colbeck, Andrew [EMAIL PROTECTED]
 To: Declude.JunkMail@declude.com
 Sent: Thursday, September 08, 2005 12:37 PM
 Subject: RE: [Declude.JunkMail] How to credit a domain


 Oop, there was one other thing.

 I try to avoid the temptation of counterweighting a fragment of their
 reverse DNS.

 For example, if there were a ComCast.net mailhost problem
 that I wanted
 to counterweight, it would be tempting to add:

 REVDNS -100 ENDSWITH ComCast.net

 Which would accomplish the goal, but that the same time as
 letting in a
 tidal wave of spam from zombies on their cable subscriber network!

 That all being said, I also have a very few Declude PRO filter text
 files that accomplish counterweighting for problematic
 domains that need
 help to get their mail through my setup, but whose complexity to keep
 the spam out preclude it from going in my mixed bag of counterweights.

 Andrew 8)


  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of
  Colbeck, Andrew
  Sent: Thursday, September 08, 2005 9:31 AM
  To: Declude.JunkMail@declude.com
  Subject: RE: [Declude.JunkMail] How to credit a domain
 
  Hi, Goran.
 
  I like to counterweight based on their IP for a couple of
  reasons.  The first is that if their administration is not up
  to par (so that I have to counterweight them), the odds are
  good that their revdns is flawed or that their DNS is subject
  to timeouts.
 
  I also find that, as a practical matter, a company is as
  likely to change their IP as their revdns so neither is more
  stable than the other.
 
  Third, a lot of the companies with this kind of problem also
  fail REVDNS anyway!
 
  Last, larger companies can sometimes easily be spotted in
  SenderBase.org as having all of their mailhosts on a small
  subnet and I can use a REMOTEIP CIDR mask.
 
  Andrew 8)
 
 
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of Goran
   Jovanovic
   Sent: Thursday, September 08, 2005 9:22 AM
   To: Declude.JunkMail@declude.com
   Subject: RE: [Declude.JunkMail] How to credit a domain
  
   Andrew,
  
   Why would you counterweight their IP and not the REVDNS? It
  seems that
   it is basically the same thing?
  
  
Goran Jovanovic
The LAN Shoppe
  
  
  
-Original Message-
From: [EMAIL PROTECTED]
  [mailto:Declude.JunkMail-
[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
Sent: Thursday, September 08, 2005 11:52 AM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] How to credit a domain
   
Goran, I have consistently found that providers that handle
   mail for
other companies are reliable enough that I can merely
  counterweight
their IP.  I hardly ever trust their reverse DNS, and even
   less often
the HELO.
   
I have a last resort test where I have a mixed bag of
   counterweights.
   
Andrew 8)
   
   
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf
 Of Goran
 Jovanovic
 Sent: Thursday, September 08, 2005 8:33 AM
 To: Declude.JunkMail@declude.com
 Subject: [Declude.JunkMail] How to credit a domain

 Hi all,

 I get messages like this all the time and I am always in
   a dilemma
 on what to do about them. This is a legit mail that
   scored 10 (where
 I start tagging mail).

 

Re: [Declude.JunkMail] SPF - Missing the Point

2005-09-08 Thread Matt




But isn't this utopian? The majority of situations have exceptions as
they apply to SPF, and in a world where there are open relays on every
corner, many servers without proper reverse DNS records, etc., would
you really want to trust others to maintain SPF records accurately?

I use a custom filter for tagging local domains in incoming E-mail.
Since all of my customers' servers are whitelisted, and hosted clients
are also whitelisted through AUTH, I can add a couple of points for
anything with a Mail From that matches something that I handle. This
does have false positives, many in fact due to mailers that forge such
as greeting cards or feedback forms, devices that send out
notifications with their own SMTP engine, people that are port 25
blocked or proxied, configured to use their own ISP's SMTP server, Web
applications, etc. SPF isn't required to do this. I don't trust how
well some random admin manages their own SPF records, and if I had my
own SPF records, I wouldn't trust how some random admin treated a
failure among my own customers. At least they aren't going to be
tagged for sending E-mail from someplace that they didn't know not to
send from, and is otherwise perfectly acceptable. I am obviously not
going to give any credit to anyone for passing SPF either. Passing SPF
is a better indication of spam than of legitimate E-mail these days for
incoming traffic.

I have never been a big fan of SPF because of what I saw as an
impractical and unreliable implementation in the real world. It really
isn't any better than Habeas once you get down to it, but people ate
that up for a while as well. We have many tools available to us these
days that are quite effective and much more accurate. Forging spam
almost never leaks through my system, and it's not something that I
care to focus on at all these days. It's things like Advance Fee
Fraud, Phishing, Niche Spam, and First Run Static Spam that concern me.

Matt





Colbeck, Andrew wrote:

  That's right on the money, Andy.

I agree 100%.


Andrew 8) 

  
  
-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt
Sent: Thursday, September 08, 2005 8:48 AM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] SPF - Missing the Point



  
still unacceptable and reason enough for me to discard SPF 
completely. 

  

I think the discusson is missing the key point of SPF.  Sure, 
this list is focused on INCOMING spam, and thus we 
restricting our discussions to SPFFAIL/SPFPASS and how to use 
it in Declude.

However, that ignores what SPF is designed to do:

How many times have we received angry emails or hundreds of 
bounce messages from other ISPs because some Spammer was 
sending mail with a fake email sender - using OUR domain names?

If you define SPF for your own (and client) domain names, 
then the largest ISPs won't accept the spam that has your 
email address faked, thus you and your clients will no longer 
be bombarded with responses/complaints/bounces to messages 
you never sent in the first place.

The effect of having SPF defined is, that FEWER spammers even 
bother trying to abuse YOUR domain name, because they know 
that a lot of their spam would never reach anyone.  Instead, 
they now use their own domain names and even set up SPF for 
those.  To me - that ripple effect alone justifies SPF!

Thus, without question, SPF should be in place for all 
domains you control.
Specially for alias/vanity/web-only domains that never send any email.
Ideally, in addition, set up SMTP AUTH for your clients so 
that you can use SPFFAIL for incoming mail and, if you 
choose, ignore SPFPASS for now.

Best Regards
Andy Schmidt

Phone:  +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206 

---
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 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] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Dan Horne



Yes, we justtoday reverted back to 1.82 because our 
single-processor machine backed up. At the worst there was an hour delay 
in delivery. I specifically denoted it was a single-processor machine just 
to indicate that our problems would not be related to the multi-processor sleep 
problems. It just doesn't seem able to handle the load that 1.82 
does. And yes, we have increased our THREADS to 25. 


Also, they claim to have fixed a problem with leftover 
files, but after swapping out the Declude executable with 1.82 and leaving the 
Decludeproc service running, 24 files are still stranded in the 
"spool\proc\work" directory and there are 9 *.vir directories still in there 
(they are truly stranded, even the 24 files comprise 12 paired q and d files 
they are not being delivered for several hours with the Decludeproc service 
still running. I am going to have to move them back into the spool 
directory manually). The Decludeproc service has NOT stopped running at 
all in theseveral days it has been running, so I don't know why the files 
are stranded. I just tried restarting it to see if I could "wake it up", 
but it didn't give me any love. Looking at the dates, I see one q/d pair 
from Sep 2, several from Sep 7 and the2 pairfrom today. Each 
one of these represents a "lost" email. I opened afew and didn't 
find any of them to be spam. The one thing I can't abide is "lost" email, 
so I had to stop our beta test.






From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
MattSent: Thursday, September 08, 2005 12:11 PMTo: 
Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Is there 
any hope running Declude with imail8.21???
IMail 8.20+ is only compatible with Declude 3+, but that software is 
still in early beta and I wouldn't recommend it. This combination can 
work, but it appears that the higher the volume you have, the more likely you 
are to experience serious issues with E-mail backing up. I have been using 
IMail 8.15 HF2 for many months without any new issues, and it works very well 
with Declude 2.0.6.16 (the most recent interim release) which also doesn't have 
any new issues. The newer Declude 3.0 that is in beta is basically the 
same in terms of functionality, but it is changed to act as a service in order 
to resolve issues with the changes in IMail 8.20+ and also increase performance 
slightly. This is a big change for Declude, and building a service to 
handle E-mail reliably isn't a small feat so I would suggest being patient in 
the mean time.MattTimothy Bohen wrote: 
Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? 

So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude.

Thanks



-- Original Message --
From: "R. Scott Perry" [EMAIL PROTECTED]
Reply-To: Declude.JunkMail@declude.com
Date:  Wed, 07 Sep 2005 19:28:41 -0400

  
  
I gave up and downgraded to 8.15 now I'm getting:
09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" 
  "D:\IMAIL\spool\Q3ab90041008c0e76.SMD"

It looks like you set up Declude to run in C:\IMail, but you run IMail 
on D:\IMail.  :)
  -Scott
---
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.

 

 
__ __ __ __
Sent via the CMS Internet Webmail system at mail1.cmsinter.net


 
   
---
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] Is there any hope running Declude with imail8.21???

2005-09-08 Thread David Barker



Dan,

What version for Declude Beta were you running? As we have 
not seen the behavior you are referring to.
David B
www.declude.com


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Dan 
HorneSent: Thursday, September 08, 2005 1:58 PMTo: 
Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] Is there 
any hope running Declude with imail8.21???

Yes, we justtoday reverted back to 1.82 because our 
single-processor machine backed up. At the worst there was an hour delay 
in delivery. I specifically denoted it was a single-processor machine just 
to indicate that our problems would not be related to the multi-processor sleep 
problems. It just doesn't seem able to handle the load that 1.82 
does. And yes, we have increased our THREADS to 25. 


Also, they claim to have fixed a problem with leftover 
files, but after swapping out the Declude executable with 1.82 and leaving the 
Decludeproc service running, 24 files are still stranded in the 
"spool\proc\work" directory and there are 9 *.vir directories still in there 
(they are truly stranded, even the 24 files comprise 12 paired q and d files 
they are not being delivered for several hours with the Decludeproc service 
still running. I am going to have to move them back into the spool 
directory manually). The Decludeproc service has NOT stopped running at 
all in theseveral days it has been running, so I don't know why the files 
are stranded. I just tried restarting it to see if I could "wake it up", 
but it didn't give me any love. Looking at the dates, I see one q/d pair 
from Sep 2, several from Sep 7 and the2 pairfrom today. Each 
one of these represents a "lost" email. I opened afew and didn't 
find any of them to be spam. The one thing I can't abide is "lost" email, 
so I had to stop our beta test.






From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
MattSent: Thursday, September 08, 2005 12:11 PMTo: 
Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Is there 
any hope running Declude with imail8.21???
IMail 8.20+ is only compatible with Declude 3+, but that software is 
still in early beta and I wouldn't recommend it. This combination can 
work, but it appears that the higher the volume you have, the more likely you 
are to experience serious issues with E-mail backing up. I have been using 
IMail 8.15 HF2 for many months without any new issues, and it works very well 
with Declude 2.0.6.16 (the most recent interim release) which also doesn't have 
any new issues. The newer Declude 3.0 that is in beta is basically the 
same in terms of functionality, but it is changed to act as a service in order 
to resolve issues with the changes in IMail 8.20+ and also increase performance 
slightly. This is a big change for Declude, and building a service to 
handle E-mail reliably isn't a small feat so I would suggest being patient in 
the mean time.MattTimothy Bohen wrote: 
Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? 

So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude.

Thanks



-- Original Message --
From: "R. Scott Perry" [EMAIL PROTECTED]
Reply-To: Declude.JunkMail@declude.com
Date:  Wed, 07 Sep 2005 19:28:41 -0400

  
  
I gave up and downgraded to 8.15 now I'm getting:
09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" 
  "D:\IMAIL\spool\Q3ab90041008c0e76.SMD"

It looks like you set up Declude to run in C:\IMail, but you run IMail 
on D:\IMail.  :)
  -Scott
---
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.

 

 
__ __ __ __
Sent via the CMS Internet Webmail system at mail1.cmsinter.net


 
   
---
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] SPF - Missing the Point

2005-09-08 Thread Andy Schmidt



Hi Matt:

I read your posting (because you are always insightful), 
but I'm not sure that your message actually applies to what I had said(and 
to which Andrew had commented on) or if youmay beanswering to a 
different part of the conversation. Certainly nothing Utopian in what I wrote? 


a) It isplain fact that the largest providers do 
check SPF, which in turn means that Joe-Jobs have a drastically lower impact on 
the spoofed domain's owner.
b) It is also a fact, that spammers are very SPF aware (to 
the point that they create SPF records.) 
c) Based on my personal, admittedly anecdotal, experience 
(supported bycommon sense) it further appears to me that 
SPF protected domainswould beless likely to get picked for Joe-Jobs 
than unprotected domains.

Here is what I had written:

  How many times have we 
  received angry emails or hundreds of bounce messages from other ISPs 
  because some Spammer was sending mail with a fake email sender - using OUR 
  domain names?If you define SPF for your own (and client) domain names, 
  then the largest ISPs won't accept the spam that has your email 
  address faked, thus you and your clients will no longer be bombarded with 
  responses/complaints/bounces to messages you never sent in the first 
  place.The effect of having SPF defined is, that FEWER spammers even 
  bother trying to abuse YOUR domain name, because they know that a lot 
  of their spam would never reach anyone. Instead, they now use their 
  own domain names and even set up SPF for those. To me - that ripple 
  effect alone justifies SPF!
Best 
RegardsAndy SchmidtPhone: +1 201 934-3414 x20 
(Business)Fax: +1 201 934-9206 



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
MattSent: Thursday, September 08, 2005 01:55 PMTo: 
Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] SPF - 
Missing the Point
But isn't this utopian? The majority of situations have 
exceptions as they apply to SPF, and in a world where there are open relays on 
every corner, many servers without proper reverse DNS records, etc., would you 
really want to trust others to maintain SPF records accurately?I use a 
custom filter for tagging local domains in incoming E-mail. Since all of 
my customers' servers are whitelisted, and hosted clients are also whitelisted 
through AUTH, I can add a couple of points for anything with a Mail From that 
matches something that I handle. This does have false positives, many in 
fact due to mailers that forge such as greeting cards or feedback forms, devices 
that send out notifications with their own SMTP engine, people that are port 25 
blocked or proxied, configured to use their own ISP's SMTP server, Web 
applications, etc. SPF isn't required to do this. I don't trust how 
well some random admin manages their own SPF records, and if I had my own SPF 
records, I wouldn't trust how some random admin treated a failure among my own 
customers. At least they aren't going to be tagged for sending E-mail from 
someplace that they didn't know not to send from, and is otherwise perfectly 
acceptable. I am obviously not going to give any credit to anyone for 
passing SPF either. Passing SPF is a better indication of spam than of 
legitimate E-mail these days for incoming traffic.I have never been a 
big fan of SPF because of what I saw as an impractical and unreliable 
implementation in the real world. It really isn't any better than Habeas 
once you get down to it, but people ate that up for a while as well. We 
have many tools available to us these days that are quite effective and much 
more accurate. Forging spam almost never leaks through my system, and it's 
not something that I care to focus on at all these days. It's things like 
Advance Fee Fraud, Phishing, Niche Spam, and First Run Static Spam that concern 
me.MattColbeck, Andrew wrote: 
That's right on the money, Andy.

I agree 100%.


Andrew 8) 

  
  -Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt
Sent: Thursday, September 08, 2005 8:48 AM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] SPF - Missing the Point



  still unacceptable and reason enough for me to discard SPF 
completely. 
I think the discusson is missing the key point of SPF.  Sure, 
this list is focused on INCOMING spam, and thus we 
restricting our discussions to SPFFAIL/SPFPASS and how to use 
it in Declude.

However, that ignores what SPF is designed to do:

How many times have we received angry emails or hundreds of 
bounce messages from other ISPs because some Spammer was 
sending mail with a fake email sender - using OUR domain names?

If you define SPF for your own (and client) domain names, 
then the largest ISPs won't accept the spam that has your 
email address faked, thus you and your clients will no longer 
be bombarded with responses/complaints/bounces to messages 
you never sent in the first place.

The effect of having SPF defined 

RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Dan Horne



3.0.3. Mail has backed up repeatedly since installing 
this version. We originally installed 3.0 when it was released, but 
quickly backed off that when the service stopped on its own, leaving multiple 
files in the proc directory. After waiting a while, we got an email about 
3.0.3 being released which seemed to specifically target the problems we had, so 
we again immediately installed that version (on Sep 2). The results were 
OK until the weekend when mail piled up for an unknown reason. We just 
waited that one out, and the next one which occurred Monday afternoon. The 
one from yesterday though caused an hour-long delay in email delivery. 
Today the decision was made to cease the beta test and revert back to 
1.82. The change was made this morning at around 9:00 AM EST, and the 
files I noted are still in thework directorynow, 5 hours 
later.

I just want to note that the same server never backs up 
running 1.82. I notice that there is now a version 3.0.3.4, but we of 
course haven't tried that version. FWIW, we are using all three Declude 
products including Hijack.


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of David 
BarkerSent: Thursday, September 08, 2005 2:04 PMTo: 
Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] Is there 
any hope running Declude with imail8.21???

Dan,

What version for Declude Beta were you running? As we have 
not seen the behavior you are referring to.
David B
www.declude.com


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Dan 
HorneSent: Thursday, September 08, 2005 1:58 PMTo: 
Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] Is there 
any hope running Declude with imail8.21???

Yes, we justtoday reverted back to 1.82 because our 
single-processor machine backed up. At the worst there was an hour delay 
in delivery. I specifically denoted it was a single-processor machine just 
to indicate that our problems would not be related to the multi-processor sleep 
problems. It just doesn't seem able to handle the load that 1.82 
does. And yes, we have increased our THREADS to 25. 


Also, they claim to have fixed a problem with leftover 
files, but after swapping out the Declude executable with 1.82 and leaving the 
Decludeproc service running, 24 files are still stranded in the 
"spool\proc\work" directory and there are 9 *.vir directories still in there 
(they are truly stranded, even the 24 files comprise 12 paired q and d files 
they are not being delivered for several hours with the Decludeproc service 
still running. I am going to have to move them back into the spool 
directory manually). The Decludeproc service has NOT stopped running at 
all in theseveral days it has been running, so I don't know why the files 
are stranded. I just tried restarting it to see if I could "wake it up", 
but it didn't give me any love. Looking at the dates, I see one q/d pair 
from Sep 2, several from Sep 7 and the2 pairfrom today. Each 
one of these represents a "lost" email. I opened afew and didn't 
find any of them to be spam. The one thing I can't abide is "lost" email, 
so I had to stop our beta test.






From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
MattSent: Thursday, September 08, 2005 12:11 PMTo: 
Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Is there 
any hope running Declude with imail8.21???
IMail 8.20+ is only compatible with Declude 3+, but that software is 
still in early beta and I wouldn't recommend it. This combination can 
work, but it appears that the higher the volume you have, the more likely you 
are to experience serious issues with E-mail backing up. I have been using 
IMail 8.15 HF2 for many months without any new issues, and it works very well 
with Declude 2.0.6.16 (the most recent interim release) which also doesn't have 
any new issues. The newer Declude 3.0 that is in beta is basically the 
same in terms of functionality, but it is changed to act as a service in order 
to resolve issues with the changes in IMail 8.20+ and also increase performance 
slightly. This is a big change for Declude, and building a service to 
handle E-mail reliably isn't a small feat so I would suggest being patient in 
the mean time.MattTimothy Bohen wrote: 
Oh ouch, thats embarrising, you could have sent this off list!!! :) I KNOW I didnt change that path, is there any chance upgrading to 8.21 somehow changed it? 

So anyway, now that I downgraded already, should I go to 8.21 again or are there problems with declude? I'm not crazy about running a beta version of declude.

Thanks



-- Original Message --
From: "R. Scott Perry" [EMAIL PROTECTED]
Reply-To: Declude.JunkMail@declude.com
Date:  Wed, 07 Sep 2005 19:28:41 -0400

  
  
I gave up and downgraded to 8.15 now I'm getting:
09:07 15:08 SMTPD(CP) error 3 executing "c:\imail\Declude.exe" 
  "D:\IMAIL\spool\Q3ab90041008c0e76.SMD"

It looks like you set up Declude to run in C:\IMail, but 

RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???

2005-09-08 Thread David Barker
Dan,
 
1. 3.0.3 in our testing has been considerably quicker than that of earlier
versions of Declude.
2. We have never seen an long delay in the processing of email and no one
else has reported this.
3. As mentioned on the Beta page there are still issues with orphan files
due to Hijack, but this is because the hijack is moving the email to the
HOLD2 folder and leaving files behind, these email should not be legitimate.
4. The only other reasons we are aware of for orphan files is - if the files
already exist in the location (eg Spam folder) then the files cannot be
moved from the \work directory to that location.
5. In order to find the cause please send us your log files / copy of an
orphaned email / config files for us to look at the situation ?
6. In addition to the lists, in future it would be a good idea to email us
at [EMAIL PROTECTED] with issues you are experiencing so we can deal with
them promptly.

Thanks
David B
www.declude.com
 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
Sent: Thursday, September 08, 2005 2:26 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running Declude with
imail8.21???


3.0.3.  Mail has backed up repeatedly since installing this version.  We
originally installed 3.0 when it was released, but quickly backed off that
when the service stopped on its own, leaving multiple files in the proc
directory.  After waiting a while, we got an email about 3.0.3 being
released which seemed to specifically target the problems we had, so we
again immediately installed that version (on Sep 2).  The results were OK
until the weekend when mail piled up for an unknown reason.  We just waited
that one out, and the next one which occurred Monday afternoon.  The one
from yesterday though caused an hour-long delay in email delivery.  Today
the decision was made to cease the beta test and revert back to 1.82.  The
change was made this morning at around 9:00 AM EST, and the files I noted
are still in the work directory now, 5 hours later.
 
I just want to note that the same server never backs up running 1.82.  I
notice that there is now a version 3.0.3.4, but we of course haven't tried
that version.  FWIW, we are using all three Declude products including
Hijack.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Barker
Sent: Thursday, September 08, 2005 2:04 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running Declude with
imail8.21???


Dan,
 
What version for Declude Beta were you running? As we have not seen the
behavior you are referring to.

David B
www.declude.com



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
Sent: Thursday, September 08, 2005 1:58 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running Declude with
imail8.21???


Yes, we just today reverted back to 1.82 because our single-processor
machine backed up.  At the worst there was an hour delay in delivery.  I
specifically denoted it was a single-processor machine just to indicate that
our problems would not be related to the multi-processor sleep problems.  It
just doesn't seem able to handle the load that 1.82 does.  And yes, we have
increased our THREADS to 25.  
 
Also, they claim to have fixed a problem with leftover files, but after
swapping out the Declude executable with 1.82 and leaving the Decludeproc
service running, 24 files are still stranded in the spool\proc\work
directory and there are 9 *.vir directories still in there (they are truly
stranded, even the 24 files comprise 12 paired q and d files they are not
being delivered for several hours with the Decludeproc service still
running.  I am going to have to move them back into the spool directory
manually).  The Decludeproc service has NOT stopped running at all in the
several days it has been running, so I don't know why the files are
stranded.  I just tried restarting it to see if I could wake it up, but it
didn't give me any love.  Looking at the dates, I see one q/d pair from Sep
2, several from Sep 7 and the 2 pair from today.  Each one of these
represents a lost email.  I opened a few and didn't find any of them to be
spam.  The one thing I can't abide is lost email, so I had to stop our
beta test.
 
 
 
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Thursday, September 08, 2005 12:11 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Is there any hope running Declude with
imail8.21???


IMail 8.20+ is only compatible with Declude 3+, but that software is still
in early beta and I wouldn't recommend it.  This combination can work, but
it appears that the higher the volume you have, the more likely you are to
experience serious issues with E-mail backing up.  I have been using IMail

RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Colbeck, Andrew
DB 1. 3.0.3 in our testing has been considerably quicker than that of
earlier versions of Declude.

Dave, at the top of my suggested list for new code in declude.exe has
been to do robust MIME decoding so that Declude PRO text filters no
longer grind the raw layer of attachments for spammy text.  That alone
would make Declude orders of magnitude faster, more accurate, and
lighter on RAM.

Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a
great stopgap for me.  If anybody out there is wondering what the heck
I'm talking about, check the archive for my posting of my SKIPATTACH
test.

Andrew 8)


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
 Sent: Thursday, September 08, 2005 11:54 AM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with imail8.21???
 
 Dan,
  
 1. 3.0.3 in our testing has been considerably quicker than 
 that of earlier versions of Declude.
 
 2. We have never seen an long delay in the processing of 
 email and no one else has reported this.
 
 3. As mentioned on the Beta page there are still issues with 
 orphan files due to Hijack, but this is because the hijack is 
 moving the email to the HOLD2 folder and leaving files 
 behind, these email should not be legitimate.
 
 4. The only other reasons we are aware of for orphan files is 
 - if the files already exist in the location (eg Spam folder) 
 then the files cannot be moved from the \work directory to 
 that location.
 
 5. In order to find the cause please send us your log files / 
 copy of an orphaned email / config files for us to look at 
 the situation ?
 
 6. In addition to the lists, in future it would be a good 
 idea to email us at [EMAIL PROTECTED] with issues you are 
 experiencing so we can deal with them promptly.
 
 Thanks
 David B
 www.declude.com
  
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
 Sent: Thursday, September 08, 2005 2:26 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with imail8.21???
 
 
 3.0.3.  Mail has backed up repeatedly since installing this 
 version.  We originally installed 3.0 when it was released, 
 but quickly backed off that when the service stopped on its 
 own, leaving multiple files in the proc directory.  After 
 waiting a while, we got an email about 3.0.3 being released 
 which seemed to specifically target the problems we had, so 
 we again immediately installed that version (on Sep 2).  The 
 results were OK until the weekend when mail piled up for an 
 unknown reason.  We just waited that one out, and the next 
 one which occurred Monday afternoon.  The one from yesterday 
 though caused an hour-long delay in email delivery.  Today 
 the decision was made to cease the beta test and revert back 
 to 1.82.  The change was made this morning at around 9:00 AM 
 EST, and the files I noted are still in the work directory 
 now, 5 hours later.
  
 I just want to note that the same server never backs up 
 running 1.82.  I notice that there is now a version 3.0.3.4, 
 but we of course haven't tried that version.  FWIW, we are 
 using all three Declude products including Hijack.
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
 Sent: Thursday, September 08, 2005 2:04 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with imail8.21???
 
 
 Dan,
  
 What version for Declude Beta were you running? As we have 
 not seen the behavior you are referring to.
 
 David B
 www.declude.com
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
 Sent: Thursday, September 08, 2005 1:58 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with imail8.21???
 
 
 Yes, we just today reverted back to 1.82 because our 
 single-processor machine backed up.  At the worst there was 
 an hour delay in delivery.  I specifically denoted it was a 
 single-processor machine just to indicate that our problems 
 would not be related to the multi-processor sleep problems.  
 It just doesn't seem able to handle the load that 1.82 does.  
 And yes, we have increased our THREADS to 25.  
  
 Also, they claim to have fixed a problem with leftover files, 
 but after swapping out the Declude executable with 1.82 and 
 leaving the Decludeproc service running, 24 files are still 
 stranded in the spool\proc\work
 directory and there are 9 *.vir directories still in there 
 (they are truly stranded, even the 24 files comprise 12 
 paired q and d files they are not being delivered for several 
 hours with the Decludeproc service still running.  I am going 
 to have to move them back into the spool directory manually). 
  The Decludeproc service has 

RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???

2005-09-08 Thread David Barker
Andrew,

Thanks for the suggestion. I have passed it on to our developers to look
into.

David B
www.declude.com 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
Sent: Thursday, September 08, 2005 3:03 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running Declude with
imail8.21???

DB 1. 3.0.3 in our testing has been considerably quicker than that of
earlier versions of Declude.

Dave, at the top of my suggested list for new code in declude.exe has been
to do robust MIME decoding so that Declude PRO text filters no longer grind
the raw layer of attachments for spammy text.  That alone would make Declude
orders of magnitude faster, more accurate, and lighter on RAM.

Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a great
stopgap for me.  If anybody out there is wondering what the heck I'm talking
about, check the archive for my posting of my SKIPATTACH test.

Andrew 8)


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
 Sent: Thursday, September 08, 2005 11:54 AM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???
 
 Dan,
  
 1. 3.0.3 in our testing has been considerably quicker than that of 
 earlier versions of Declude.
 
 2. We have never seen an long delay in the processing of email and no 
 one else has reported this.
 
 3. As mentioned on the Beta page there are still issues with orphan 
 files due to Hijack, but this is because the hijack is moving the 
 email to the HOLD2 folder and leaving files behind, these email should 
 not be legitimate.
 
 4. The only other reasons we are aware of for orphan files is
 - if the files already exist in the location (eg Spam folder) then the 
 files cannot be moved from the \work directory to that location.
 
 5. In order to find the cause please send us your log files / copy of 
 an orphaned email / config files for us to look at the situation ?
 
 6. In addition to the lists, in future it would be a good idea to 
 email us at [EMAIL PROTECTED] with issues you are experiencing so we 
 can deal with them promptly.
 
 Thanks
 David B
 www.declude.com
  
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
 Sent: Thursday, September 08, 2005 2:26 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???
 
 
 3.0.3.  Mail has backed up repeatedly since installing this version.  
 We originally installed 3.0 when it was released, but quickly backed 
 off that when the service stopped on its own, leaving multiple files 
 in the proc directory.  After waiting a while, we got an email about 
 3.0.3 being released which seemed to specifically target the problems 
 we had, so we again immediately installed that version (on Sep 2).  
 The results were OK until the weekend when mail piled up for an 
 unknown reason.  We just waited that one out, and the next one which 
 occurred Monday afternoon.  The one from yesterday though caused an 
 hour-long delay in email delivery.  Today the decision was made to 
 cease the beta test and revert back to 1.82.  The change was made this 
 morning at around 9:00 AM EST, and the files I noted are still in the 
 work directory now, 5 hours later.
  
 I just want to note that the same server never backs up running 1.82.  
 I notice that there is now a version 3.0.3.4, but we of course haven't 
 tried that version.  FWIW, we are using all three Declude products 
 including Hijack.
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
 Sent: Thursday, September 08, 2005 2:04 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???
 
 
 Dan,
  
 What version for Declude Beta were you running? As we have not seen 
 the behavior you are referring to.
 
 David B
 www.declude.com
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
 Sent: Thursday, September 08, 2005 1:58 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???
 
 
 Yes, we just today reverted back to 1.82 because our single-processor 
 machine backed up.  At the worst there was an hour delay in delivery.  
 I specifically denoted it was a single-processor machine just to 
 indicate that our problems would not be related to the multi-processor 
 sleep problems.
 It just doesn't seem able to handle the load that 1.82 does.  
 And yes, we have increased our THREADS to 25.  
  
 Also, they claim to have fixed a problem with leftover files, but 
 after swapping out the Declude executable with 1.82 and leaving the 
 Decludeproc service running, 24 files are still 

Re: [Declude.JunkMail] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Scott Fisher

Yeah, throw us Pro users a couple of bones!

- Original Message - 
From: Colbeck, Andrew [EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 2:02 PM
Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
imail8.21???



DB 1. 3.0.3 in our testing has been considerably quicker than that of
earlier versions of Declude.

Dave, at the top of my suggested list for new code in declude.exe has
been to do robust MIME decoding so that Declude PRO text filters no
longer grind the raw layer of attachments for spammy text.  That alone
would make Declude orders of magnitude faster, more accurate, and
lighter on RAM.

Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a
great stopgap for me.  If anybody out there is wondering what the heck
I'm talking about, check the archive for my posting of my SKIPATTACH
test.

Andrew 8)



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Barker
Sent: Thursday, September 08, 2005 11:54 AM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running
Declude with imail8.21???

Dan,

1. 3.0.3 in our testing has been considerably quicker than
that of earlier versions of Declude.

2. We have never seen an long delay in the processing of
email and no one else has reported this.

3. As mentioned on the Beta page there are still issues with
orphan files due to Hijack, but this is because the hijack is
moving the email to the HOLD2 folder and leaving files
behind, these email should not be legitimate.

4. The only other reasons we are aware of for orphan files is
- if the files already exist in the location (eg Spam folder)
then the files cannot be moved from the \work directory to
that location.

5. In order to find the cause please send us your log files /
copy of an orphaned email / config files for us to look at
the situation ?

6. In addition to the lists, in future it would be a good
idea to email us at [EMAIL PROTECTED] with issues you are
experiencing so we can deal with them promptly.

Thanks
David B
www.declude.com



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
Sent: Thursday, September 08, 2005 2:26 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running
Declude with imail8.21???


3.0.3.  Mail has backed up repeatedly since installing this
version.  We originally installed 3.0 when it was released,
but quickly backed off that when the service stopped on its
own, leaving multiple files in the proc directory.  After
waiting a while, we got an email about 3.0.3 being released
which seemed to specifically target the problems we had, so
we again immediately installed that version (on Sep 2).  The
results were OK until the weekend when mail piled up for an
unknown reason.  We just waited that one out, and the next
one which occurred Monday afternoon.  The one from yesterday
though caused an hour-long delay in email delivery.  Today
the decision was made to cease the beta test and revert back
to 1.82.  The change was made this morning at around 9:00 AM
EST, and the files I noted are still in the work directory
now, 5 hours later.

I just want to note that the same server never backs up
running 1.82.  I notice that there is now a version 3.0.3.4,
but we of course haven't tried that version.  FWIW, we are
using all three Declude products including Hijack.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Barker
Sent: Thursday, September 08, 2005 2:04 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running
Declude with imail8.21???


Dan,

What version for Declude Beta were you running? As we have
not seen the behavior you are referring to.

David B
www.declude.com



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
Sent: Thursday, September 08, 2005 1:58 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Is there any hope running
Declude with imail8.21???


Yes, we just today reverted back to 1.82 because our
single-processor machine backed up.  At the worst there was
an hour delay in delivery.  I specifically denoted it was a
single-processor machine just to indicate that our problems
would not be related to the multi-processor sleep problems.
It just doesn't seem able to handle the load that 1.82 does.
And yes, we have increased our THREADS to 25.

Also, they claim to have fixed a problem with leftover files,
but after swapping out the Declude executable with 1.82 and
leaving the Decludeproc service running, 24 files are still
stranded in the spool\proc\work
directory and there are 9 *.vir directories still in there
(they are truly stranded, even the 24 files comprise 12
paired q and d files they are not being delivered for several
hours with the Decludeproc service still 

RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???

2005-09-08 Thread David Barker
Scott,

We are very happy with the suggestions Declude users have made regarding
tests and improvements of Declude, as soon as we are done with the Declude
3.0 release the focus will be on these additions wrt to functionality.

David B
www.declude.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Fisher
Sent: Thursday, September 08, 2005 3:20 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Is there any hope running Declude with
imail8.21???

Yeah, throw us Pro users a couple of bones!

- Original Message -
From: Colbeck, Andrew [EMAIL PROTECTED]
To: Declude.JunkMail@declude.com
Sent: Thursday, September 08, 2005 2:02 PM
Subject: RE: [Declude.JunkMail] Is there any hope running Declude with
imail8.21???


DB 1. 3.0.3 in our testing has been considerably quicker than that of
earlier versions of Declude.

Dave, at the top of my suggested list for new code in declude.exe has been
to do robust MIME decoding so that Declude PRO text filters no longer grind
the raw layer of attachments for spammy text.  That alone would make Declude
orders of magnitude faster, more accurate, and lighter on RAM.

Meanwhile, Matt's SizeOf.vbs and Scott's compiled version have been a great
stopgap for me.  If anybody out there is wondering what the heck I'm talking
about, check the archive for my posting of my SKIPATTACH test.

Andrew 8)


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
 Sent: Thursday, September 08, 2005 11:54 AM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???

 Dan,

 1. 3.0.3 in our testing has been considerably quicker than that of 
 earlier versions of Declude.

 2. We have never seen an long delay in the processing of email and no 
 one else has reported this.

 3. As mentioned on the Beta page there are still issues with orphan 
 files due to Hijack, but this is because the hijack is moving the 
 email to the HOLD2 folder and leaving files behind, these email should 
 not be legitimate.

 4. The only other reasons we are aware of for orphan files is
 - if the files already exist in the location (eg Spam folder) then the 
 files cannot be moved from the \work directory to that location.

 5. In order to find the cause please send us your log files / copy of 
 an orphaned email / config files for us to look at the situation ?

 6. In addition to the lists, in future it would be a good idea to 
 email us at [EMAIL PROTECTED] with issues you are experiencing so we 
 can deal with them promptly.

 Thanks
 David B
 www.declude.com

 

 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
 Sent: Thursday, September 08, 2005 2:26 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???


 3.0.3.  Mail has backed up repeatedly since installing this version.  
 We originally installed 3.0 when it was released, but quickly backed 
 off that when the service stopped on its own, leaving multiple files 
 in the proc directory.  After waiting a while, we got an email about 
 3.0.3 being released which seemed to specifically target the problems 
 we had, so we again immediately installed that version (on Sep 2).  
 The results were OK until the weekend when mail piled up for an 
 unknown reason.  We just waited that one out, and the next one which 
 occurred Monday afternoon.  The one from yesterday though caused an 
 hour-long delay in email delivery.  Today the decision was made to 
 cease the beta test and revert back to 1.82.  The change was made this 
 morning at around 9:00 AM EST, and the files I noted are still in the 
 work directory now, 5 hours later.

 I just want to note that the same server never backs up running 1.82.  
 I notice that there is now a version 3.0.3.4, but we of course haven't 
 tried that version.  FWIW, we are using all three Declude products 
 including Hijack.

 

 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
 Sent: Thursday, September 08, 2005 2:04 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???


 Dan,

 What version for Declude Beta were you running? As we have not seen 
 the behavior you are referring to.

 David B
 www.declude.com

 

 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
 Sent: Thursday, September 08, 2005 1:58 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running Declude with 
 imail8.21???


 Yes, we just today reverted back to 1.82 because our single-processor 
 machine backed up.  At the worst there was an hour delay in delivery.  
 I specifically denoted it was a single-processor machine just to 
 indicate that 

Re: [Declude.JunkMail] SPF - Missing the Point

2005-09-08 Thread Matt




Andy,

Thanks for the kind words. My answer was more so an indirect response
instead of a direct one.

As far as your points go, please allow me to piece them out.

a) It isplain fact that the largest providers do check SPF,
which in turn means that Joe-Jobs have a drastically lower impact on
the spoofed domain's owner. 

It depends on the joe-job. Most of them target random domains and not
necessarily the largest providers. If providers are rejecting on
SPF-FAIL alone, then that is actually even more reason for me to not
implement SPF on my own domains and advise customers to skip this as
well. There are just too many legitimate exceptions to this that would
cause an SPF-FAIL on a strictly defined record. If I was to define the
records less specifically, it doesn't have much practical use since
this would be like saying it can come from anywhere...and in fact it
can. The worst joe-job bounce issues that I see are where the open
relay itself is what is bouncing the majority of messages. Open relays
are not likely to support SPF. Other servers that bounce the joe-jobs
are ones that accept all E-mail without authenticating, which is a huge
mistake in this day and age, and I wouldn't expect for them to use SPF
either since they can't seem to figure out how to validate addresses
which is 100 times more important.

b) It is also a fact, that spammers are very SPF aware (to
the point that they create SPF records.) 

Static spammers (where they spam from their own servers) are aware of
SPF and abuse it. Zombie spammers can't make use of it and they are a
whole different class in terms of what they do. Forging is almost
exclusive to zombie spammers. They can be very sophisticated, but they
don't cleanse their databases of things like SPF, they just generally
rotate through either fake or known addresses as they attack servers
with millions of addresses that mostly don't exist in the first place.
I have also found that many of these guys cache the IP addresses
corresponding to MX records and they don't refresh this data for very
long periods of time if ever. I have changed MX records for domains
that are still being spammed on the original IP over a year and a half
later. This is why we always attempt to lock down our gateway
customer's servers, or at least try to get them to change IP's if that
isn't practical.

c) Based on my personal, admittedly anecdotal, experience
(supported bycommon sense) it further appears to me
that SPF protected domainswould beless likely to get picked for
Joe-Jobs than unprotected domains.

This kind of points to my reply to a). I don't think that the zombie
spammers care. They will attempt 1 million addresses on a domain with
a single valid user, they don't care if every attempt is accepted or
rejected, and they aren't even trying to capture the rejected addresses
so save themselves processing on future attacks. They aren't really
even dictionary attacks by definition, they are just brute-force spam
runs. While you might have experienced some anecdotal proof of them
caring about SPF, it doesn't make sense to me that they would ignore
bigger issues such as repeatedly hitting invalid addresses and not
bothering to update their IP cache of MX records. These guys are
social misfits, many of them with tens of thousands of zombies in their
bot networks, and they don't care to micro-manage things. Success to
them is not just spamming a particular site, but also causing a bounce,
overwhelming a server, or even just pissing you off. I think that you
might have the perception that these guys care. I don't think they do.

SPF just isn't anywhere near accurate enough for me to want to use on
my system for catching spam, and it would create some double-hit
problems with SPAMDOMAINS. I can control SPAMDOMAINS, but I can't
control what someone does for their own SPF records. Many domains,
especially the larger and more actively used ones, have many examples
of fully legitimate use that will fail SPF, and while I might be smart
enough to not block on that alone, there are others around here that
will most definitely at least hold a message if it hits SPF-FAIL, and
again I have no control over that except to either configure SPF
records for every address, or not configure it at all.

Since SPF has come out, forging spam has dramatically increased, and
dictionary attacks have become much more common and fierce. I tag this
stuff with much more reliable tests such as Sniffer, enhanced URIBL
functionality, DUL lists enhanced by my own data, technical heuristics
that find zombie spamware patterns, blacklists, and custom combo
filters that know that a combinations like a DUL hit, a Sniffer hit and
an XBL hit together is stronger than the three alone. It works
incredibly well on my system and I don't feel that I need any more
tools to block such things, though tweaking them can help of course.

My opinion remains that SPF, while well intentioned, lacks the ability
to be accurate enough to be used 

RE: [Declude.JunkMail] Is there any hope running Declude with imail8.21???

2005-09-08 Thread Colbeck, Andrew
I'm feeling the love.

Andrew 8)
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
 Sent: Thursday, September 08, 2005 12:34 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with imail8.21???
 
 Scott,
 
 We are very happy with the suggestions Declude users have 
 made regarding tests and improvements of Declude, as soon as 
 we are done with the Declude 3.0 release the focus will be on 
 these additions wrt to functionality.
 
 David B
 www.declude.com
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Scott Fisher
 Sent: Thursday, September 08, 2005 3:20 PM
 To: Declude.JunkMail@declude.com
 Subject: Re: [Declude.JunkMail] Is there any hope running 
 Declude with imail8.21???
 
 Yeah, throw us Pro users a couple of bones!
 
 - Original Message -
 From: Colbeck, Andrew [EMAIL PROTECTED]
 To: Declude.JunkMail@declude.com
 Sent: Thursday, September 08, 2005 2:02 PM
 Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with imail8.21???
 
 
 DB 1. 3.0.3 in our testing has been considerably quicker than that of
 earlier versions of Declude.
 
 Dave, at the top of my suggested list for new code in 
 declude.exe has been to do robust MIME decoding so that 
 Declude PRO text filters no longer grind the raw layer of 
 attachments for spammy text.  That alone would make Declude 
 orders of magnitude faster, more accurate, and lighter on RAM.
 
 Meanwhile, Matt's SizeOf.vbs and Scott's compiled version 
 have been a great stopgap for me.  If anybody out there is 
 wondering what the heck I'm talking about, check the archive 
 for my posting of my SKIPATTACH test.
 
 Andrew 8)
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of 
 David Barker
  Sent: Thursday, September 08, 2005 11:54 AM
  To: Declude.JunkMail@declude.com
  Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with 
  imail8.21???
 
  Dan,
 
  1. 3.0.3 in our testing has been considerably quicker than that of 
  earlier versions of Declude.
 
  2. We have never seen an long delay in the processing of 
 email and no 
  one else has reported this.
 
  3. As mentioned on the Beta page there are still issues with orphan 
  files due to Hijack, but this is because the hijack is moving the 
  email to the HOLD2 folder and leaving files behind, these 
 email should 
  not be legitimate.
 
  4. The only other reasons we are aware of for orphan files is
  - if the files already exist in the location (eg Spam 
 folder) then the 
  files cannot be moved from the \work directory to that location.
 
  5. In order to find the cause please send us your log files 
 / copy of 
  an orphaned email / config files for us to look at the situation ?
 
  6. In addition to the lists, in future it would be a good idea to 
  email us at [EMAIL PROTECTED] with issues you are experiencing so we 
  can deal with them promptly.
 
  Thanks
  David B
  www.declude.com
 
  
 
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne
  Sent: Thursday, September 08, 2005 2:26 PM
  To: Declude.JunkMail@declude.com
  Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with 
  imail8.21???
 
 
  3.0.3.  Mail has backed up repeatedly since installing this 
 version.  
  We originally installed 3.0 when it was released, but 
 quickly backed 
  off that when the service stopped on its own, leaving 
 multiple files 
  in the proc directory.  After waiting a while, we got an email about
  3.0.3 being released which seemed to specifically target 
 the problems 
  we had, so we again immediately installed that version (on Sep 2).
  The results were OK until the weekend when mail piled up for an 
  unknown reason.  We just waited that one out, and the next 
 one which 
  occurred Monday afternoon.  The one from yesterday though caused an 
  hour-long delay in email delivery.  Today the decision was made to 
  cease the beta test and revert back to 1.82.  The change 
 was made this 
  morning at around 9:00 AM EST, and the files I noted are 
 still in the 
  work directory now, 5 hours later.
 
  I just want to note that the same server never backs up 
 running 1.82.  
  I notice that there is now a version 3.0.3.4, but we of 
 course haven't 
  tried that version.  FWIW, we are using all three Declude products 
  including Hijack.
 
  
 
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of 
 David Barker
  Sent: Thursday, September 08, 2005 2:04 PM
  To: Declude.JunkMail@declude.com
  Subject: RE: [Declude.JunkMail] Is there any hope running 
 Declude with 
  imail8.21???
 
 
  Dan,
 
  What version for Declude Beta were you running? As we have not seen 
  the behavior you are referring to.
 
  David B
  www.declude.com
 
  

RE: [Declude.JunkMail] What Header does Whitelist file use?

2005-09-08 Thread Agid, Corby
Title: What Header does Whitelist file use?



I finally figured out the problem.stupid, stupid, 
stupid.I had fat-fingered the path to the whitelist fileNow everything 
works as expected!



  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Darin 
  CoxSent: Friday, September 02, 2005 12:30 PMTo: 
  Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] What 
  Header does Whitelist file use?
  
  Hi Corby,
  
  The best way to determine explicitly what it's 
  using is to add custom header to the email. There are several you may 
  find useful, but the one I'm referring to can be added by adding a line 
  like
  
  XINHEADERX-Note: FROM: 
  %MAILFROM%
  to your Global.cfg file. We add several 
  headers for diagnostic purposes...
  
  XINHEADERX-Note: Total spam weight of this 
  E-mail is %WEIGHT%.XINHEADERX-Note: Spam Tests Failed: 
  %TESTSFAILEDWITHWEIGHTS%XINHEADERX-Note: REMOTEIP: 
  %REMOTEIP%XINHEADERX-Note: REVDNS: 
  %REVDNS%XINHEADERX-Note: FROM: %MAILFROM%XINHEADERX-Note: 
  TO: %RECIPHOST%
  TheFROM address that will be reported there 
  is exactly what Declude woulduse when checking against your 
  whitelists.
  
  REVDNS is almost always a different domain than 
  the sending address, since most email domains are hosted on common 
  servers. While you may have reason to block or whitelist on REVDNS, 
  which would be a different test completely, the FROM whitelist would only need 
  the two entries you specify.
  
  BTW, though we've been calling it whitelisting, 
  it is generally recommended to use the "whitelists" as negative weights 
  instead of true whitelists. That way if something is really bad (i.e. 
  bad enough that your negative weight doesn't keep it from being tagged, held, 
  or deleted), then it is still detected. True whitelisting would let it 
  through no matter how bad it was.
  
  We hold on a weight of 100 and delete on 300, and 
  have three FROM "whitelists" defined like
  
  FROMWHITELIST_LOWfromfileC:\IMail\Declude\fromwhitelist_low.txtx-1000FROMWHITELIST_MEDfromfileC:\IMail\Declude\fromwhitelist_med.txtx-2000FROMWHITELIST_HIGHfromfileC:\IMail\Declude\fromwhitelist_high.txtx-5000
  We also have FROM blacklists, IP white and black 
  lists, content-based white and black lists, and test-specific counterweights 
  thatmatch againstMAILFROM and/or REVDNS. We favor adding to 
  the counterweight tests first, then FROM whitelists, and finally IP 
  whitelists, though you could argue the order of the last two.
  
  Just another list 
  member..been using IMail for 5 years or so, and Declude for about 3.5 years 
  now.
  
  Thanks, man.
  Darin.
  
  
  - Original Message - 
  From: Agid, 
  Corby 
  To: Declude.JunkMail@declude.com 
  
  Sent: Friday, September 02, 2005 3:03 PM
  Subject: RE: [Declude.JunkMail] What Header does Whitelist file 
  use?
  
  Darin,
  
  I'm still confused on what part of the message 
  converstation would be compared to the whitelist entry. A message 
  often has a different values for the From Header and the envelope (not 
  sure if I'm using the correct terms). The Reverse DNS is also different 
  from the other two. Using the format of .sub.domain.com and 
  @sub.domain.com, I would have to make six entries to cover all the bases, when 
  probably the correct two would take care of it.
  
  Suggestions?
  
  BTW, 
  are you with Declude or a helpful bystander?
  
  Thanks again for your help and hope you are feeling 
  better.
  
  Corby
  
  


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Darin 
CoxSent: Thursday, September 01, 2005 7:49 PMTo: 
Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] What 
Header does Whitelist file use?

Sorry, you're right... Sometimes when I'm under 
the weather I switch things around...

Have you checked the other suggestion... making 
sure the last line has a carriage return afterwards?
  
Darin.


- Original Message - 
From: Agid, 
Corby 
To: Declude.JunkMail@declude.com 

Sent: Thursday, September 01, 2005 6:26 PM
Subject: RE: [Declude.JunkMail] What Header does Whitelist file 
use?

Hi Darin,

I just checked the manual regarding 
theSWITCHRECIP ON. The description sounds like it 
affects who the message is addressed to rather than where it comes 
from. Am I missing something?

Corby

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Darin 
  CoxSent: Thursday, September 01, 2005 1:02 PMTo: 
  Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] 
  What Header does Whitelist file use?
  
  This may be an issue where the FROM listed in 
  the email is different from the MAILFROM address found in the 
  envelope.
  
  If so, putting SWITCHRECIP ONin your 
  Declude Global.cfg should fix it. You can 

RE: [Declude.JunkMail] Server Running at 100%

2005-09-08 Thread Gary Steiner
I'm confused.  The page in the Knowledge Base

http://support.declude.com/Customer/KBArticle.aspx?articleid=11

says to put it in the global.cfg file.  It also says nothing about adding the 
ON switch.  I even exchanged emails with Declude support back on Aug. 2 
stating that I was putting AVAFTERJM in my global.cfg file, and support never 
mentioned that I should have put it in the virus.cfg file, nor was anything 
said about PRESCAN.


  Original Message 
 From: David Barker [EMAIL PROTECTED]
 Sent: Thursday, September 08, 2005 12:01 PM
 To: Declude.JunkMail@declude.com
 Subject: RE: [Declude.JunkMail] Server Running at 100%
 
 In your virus.cfg file:
  
 AVAFTERJM ON
  
 Also ensure that you have the directive:
  
 PRESCANON
  
 David B
 www.declude.com
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris
 Sent: Thursday, September 08, 2005 11:56 AM
 To: Declude.JunkMail@declude.com
 Subject: [Declude.JunkMail] Server Running at 100%
 Importance: High
 
 
 I was told to see if using AVAFTERJM would help on resources on my
 server...right now I almost dead in the water..my server is cralling to send
 mailhow do I use this command...exactly how does it go into the config..
 
 Richard Farris
 Ethixs Online
 1.270.247. Office
 1.800.548.3877 Tech Support
 Crossroads to a Cleaner Internet
 
 
   - Original Message - 
   From: Richard Farris mailto:[EMAIL PROTECTED]  
   To: Declude.JunkMail@declude.com 
   Sent: Thursday, August 04, 2005 11:21 AM
   Subject: [Declude.JunkMail] Spam box
 
   Is there a box I can put in front of my Imail server that will help
 take some of the load off of the spam filtering that Declude is doing
   
   Richard Farris
   Ethixs Online
   1.270.247. Office
   1.800.548.3877 Tech Support
   Crossroads to a Cleaner Internet
   
 
 


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


---
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] Server Running at 100%

2005-09-08 Thread Darrell \([EMAIL PROTECTED])





I'm confused.  The page in the Knowledge Base
http://support.declude.com/Customer/KBArticle.aspx?articleid=11


Now I am too - I had no idea there was a knowledge base now :)


says to put it in the global.cfg file.  It also says nothing about adding 
the ON switch.  I even exchanged emails with Declude support back on 
Aug. 2 stating that I was putting AVAFTERJM in my global.cfg file, and 
support never mentioned that I should have put it in the virus.cfg file, 
nor was anything said about PRESCAN.


Placing it in your global.cfg is wrong.  It needs to be in your virus.cfg.

Prescan is a seperate feature that if it basically detects no attachments or 
harmful code it will skip scanning the message period.


Darrell
---
Check out http://www.invariantsystems.com for utilities for Declude And 
Imail.  IMail Queue Monitoring, Declude Overflow Queue Monitoring, SURBL/URI 
integration, MRTG Integration, and Log Parsers.




 Original Message 

From: David Barker [EMAIL PROTECTED]
Sent: Thursday, September 08, 2005 12:01 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Server Running at 100%

In your virus.cfg file:

AVAFTERJM ON

Also ensure that you have the directive:

PRESCANON

David B
www.declude.com



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Farris
Sent: Thursday, September 08, 2005 11:56 AM
To: Declude.JunkMail@declude.com
Subject: [Declude.JunkMail] Server Running at 100%
Importance: High


I was told to see if using AVAFTERJM would help on resources on my
server...right now I almost dead in the water..my server is cralling to 
send
mailhow do I use this command...exactly how does it go into the 
config..


Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet


- Original Message - 
From: Richard Farris mailto:[EMAIL PROTECTED]

To: Declude.JunkMail@declude.com
Sent: Thursday, August 04, 2005 11:21 AM
Subject: [Declude.JunkMail] Spam box

Is there a box I can put in front of my Imail server that will help
take some of the load off of the spam filtering that Declude is doing

Richard Farris
Ethixs Online
1.270.247. Office
1.800.548.3877 Tech Support
Crossroads to a Cleaner Internet






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


---
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 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] FBI: Hurricane relief Internet scams proliferate

2005-09-08 Thread Matt
It isn't a surprise to see that phishers are targeting donations for 
hurricane relief, but I found it promising that the FBI was apparently 
paying close attention to the scams.  I figure that the phishers are the 
same ones that target the banks and PayPal on a daily basis, but doing 
that they seem to have attracted little action by the Feds.  Maybe 
things will change now.  I don't see why these people can't be tracked 
down and jailed.


FBI: Hurricane relief Internet scams proliferate
http://www.cnn.com/2005/US/09/08/katrina.web.scams.ap/index.html

---
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.