Re: ARGH!!! Why the *#%^$* is this tagged ALL_TRUSTED???

2004-12-08 Thread Thomas Cameron 
On Tue, 2004-12-07 at 17:22 -0600, David B Funk wrote:
 On Tue, 7 Dec 2004, Thomas Cameron wrote:
 
  Hrm - that makes a lot of sense.  I am using spamass-milter (the latest
  from CVS as of about a week ago).
 
  I actually have the following at the bottom of my sendmail.mc:
 
  INPUT_MAIL_FILTER
  (`clmilter',`S=local:/var/run/clamav/clmilter.sock,F=,T=S:4m;R:4m')dnl
 
  INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,
  T=C:15m;S:4m;R:4m;E:10m')dnl
  define(`confMILTER_MACROS_CONNECT',`b, j, _, {daemon_name}, {if_name},
  {if_addr}')dnl
 
  INPUT_MAIL_FILTER(`greylist',`S=local:/var/milter-greylist/milter-
  greylist.sock')dnl
  define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')dnl
  define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')dnl
  define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')dnl
 
  I just realized I have two confMILTER_MACROS_CONNECT definitions.  I
  don't think
  that that would cause this but I need to address this tomorrow after
  I've slept some.  :-)
 
  Thomas
 
 Sorry, but that second confMILTER_MACROS_CONNECT -IS- what is causing
 you all your grief.
 
 In the m4 macro processing, last man wins, so that second
 confMILTER_MACROS_CONNECT def is preventing sendmail from passing the
 _, macro to your milter which causes it to not feed SA a valid
 'Received:' header.

Thanks a million for educating me on that - I have fixed it, rebuilt
senmail.cf and restarted the milters and sendmail.  I'm very interested
to see how that changes things.

Warmest regards,
Thomas

Re: ARGH!!! Why the *#%^$* is this tagged ALL_TRUSTED???

2004-12-07 Thread David B Funk 
On Tue, 7 Dec 2004, Thomas Cameron wrote:

 I do not understand why this is tagged ALL_TRUSTED!

 Here is my local.cf:
 ###
[snip..]

 clear_trusted_networks
 trusted_networks24.173.79.19/32
 ###

 As you can see, the only trusted network I have is my mail server!  Why is 
 ALL_TRUSTED hitting?  I am about to set ALL_TRUSTED to a score of 0!

 Thomas

Silly question; precisely how do you have SA integrated into your
mail system?

I noticed that you are using sendmail  clamav-milter, are you also
using a milter to connect spamd into your mail system?
If so, precisely which milter?

This is important, as not all sendmail spam-milters are created equal. ;)
Here is the issue specific to your situation.

The milter gets the message from sendmail raw, IE before sendmail
does any of it's usual processing of the message SUCH AS ADDING
Received headers.

So the milter does NOT see that particular header:

 Received: from CM02.outbound.mail (mailer4.monteraymedia.com [66.63.189.28]
(may be forged)) by mail.camerontech.com (8.13.1/8.13.1) with ESMTP id
iB75ihQg015990 for [EMAIL PROTECTED]; Mon, 6 Dec 2004
23:44:44 -0600

which is critical to SA's ability to determine local vs non-trusted
hosts.

Well crafted milters will understand that and internally synthesize
a 'Received:' header to mimic the one that your sendmail will add.
Without that (or if it isn't done well) then SA will never be able to
properly do the trust determination.

Dave

-- 
Dave Funk  University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{

Re: ARGH!!! Why the *#%^$* is this tagged ALL_TRUSTED???

2004-12-07 Thread Thomas Cameron 
On Tue, 2004-12-07 at 01:22 -0600, David B Funk wrote:
 On Tue, 7 Dec 2004, Thomas Cameron wrote:
 
  I do not understand why this is tagged ALL_TRUSTED!
 
  Here is my local.cf:
  ###
 [snip..]
 
  clear_trusted_networks
  trusted_networks24.173.79.19/32
  ###
 
  As you can see, the only trusted network I have is my mail server!  Why is 
  ALL_TRUSTED hitting?  I am about to set ALL_TRUSTED to a score of 0!
 
  Thomas
 
 Silly question; precisely how do you have SA integrated into your
 mail system?
 
 I noticed that you are using sendmail  clamav-milter, are you also
 using a milter to connect spamd into your mail system?
 If so, precisely which milter?
 
 This is important, as not all sendmail spam-milters are created equal. ;)
 Here is the issue specific to your situation.
 
 The milter gets the message from sendmail raw, IE before sendmail
 does any of it's usual processing of the message SUCH AS ADDING
 Received headers.
 
 So the milter does NOT see that particular header:
 
  Received: from CM02.outbound.mail (mailer4.monteraymedia.com [66.63.189.28]
 (may be forged)) by mail.camerontech.com (8.13.1/8.13.1) with ESMTP id
 iB75ihQg015990 for [EMAIL PROTECTED]; Mon, 6 Dec 2004
 23:44:44 -0600
 
 which is critical to SA's ability to determine local vs non-trusted
 hosts.
 
 Well crafted milters will understand that and internally synthesize
 a 'Received:' header to mimic the one that your sendmail will add.
 Without that (or if it isn't done well) then SA will never be able to
 properly do the trust determination.
 
 Dave
 

Hrm - that makes a lot of sense.  I am using spamass-milter (the latest
from CVS as of about a week ago).

I actually have the following at the bottom of my sendmail.mc:

INPUT_MAIL_FILTER
(`clmilter',`S=local:/var/run/clamav/clmilter.sock,F=,T=S:4m;R:4m')dnl

INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,
T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confMILTER_MACROS_CONNECT',`b, j, _, {daemon_name}, {if_name},
{if_addr}')dnl

INPUT_MAIL_FILTER(`greylist',`S=local:/var/milter-greylist/milter-
greylist.sock')dnl
define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')dnl
define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')dnl
define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')dnl

I just realized I have two confMILTER_MACROS_CONNECT definitions.  I
don't think 
that that would cause this but I need to address this tomorrow after
I've slept some.  :-)

Thomas

Re: ARGH!!! Why the *#%^$* is this tagged ALL_TRUSTED???

2004-12-07 Thread Michael Weber 
Why not make the change to /usr/share/spamassassin/50_scores.cf instead?
 That way when the next version comes out, presumably with the patch,
you don't have to remember to un-do the workaround?

-Michael

 Thomas Cameron [EMAIL PROTECTED] 12/7/2004 1:14:42
AM 
On Mon, 2004-12-06 at 22:52 -0800, Loren Wilton wrote:
 Received: from CM02.outbound.mail (mailer4.monteraymedia.com
[66.63.189.28]
   (may be forged)) by mail.camerontech.com (8.13.1/8.13.1) with
ESMTP id
   iB75ihQg015990 for [EMAIL PROTECTED]; Mon, 6 Dec
2004
   23:44:44 -0600
 Received: by CM02.outbound.mail (PowerMTA(TM) v2.0r6) id
h4mn9a050u48; Mon,
   11 Jun 2001 22:47:13 -0700 (envelope-from
[EMAIL PROTECTED])
 
 Remember all trusted really means no untrusted links in the
recieved headers that we were able to parse.
 
 If SA can't parse a received header line, it simply tosses it and
continues with the next one.  This may not be the best plan, and there
are various bugs open about the exact meaning and handling of
all-trusted.
 
 The second header shown above doesn't have any ip addresses in it, so
it would get tossed (or maybe considered as local, I'm not positive).
 
 That leaves the first header, which at a glance would seem to not
come from your network, so shouldn't be trusted.  I'm guessing that
there is something about the format of this header that SA doesn't much
care for, so it ended up tossing it as unreadable.
 
 That would leave you with no received headers, which would mean that
the mail had been sent locally, so was obviously trusted.  :-(
 
 There was a patch in the works a month or so back to somehow take
account of unparsable headers in determining all-trusted.  I was out of
town for most of November and lost track of the status of that change. 
Assuming that the problem here is the first received header was
unparsable, that patch may help matters if it is approved.
 
 Loren

Then I guess my next option is to set 

score ALL_TRUSTED 0 0 0 0

in /etc/mail/spamassassin/local.cf until this gets resolved?

Thomas


CONFIDENTIALITY NOTICE:  This communication and any 
attached or enclosed files may contain information 
that is privileged, confidential, proprietary and/or 
otherwise protected from disclosure under applicable 
law (Confidential Information).  Any review, 
retransmission, publication, dissemination, 
distribution, forwarding, printing, copying, storing, saving 
or other use or disclosure of this communication and/or the 
Confidential Information, or taking any action in reliance 
thereon, by an individual or entity other than the intended 
recipient(s) is strictly prohibited.  

This communication and the Confidential Information are 
intended solely for the use of the individual(s) and/or 
entity(ies) to which this communication is addressed. 
If you are not the intended recipient(s) (or responsible 
for delivery to said recipient(s)), please be advised 
that you have received this communication in error and 
have an obligation to promptly inform the sender by reply 
e-mail or facsimile and to permanently delete, shred or 
otherwise destroy, in its entirety, this original communication 
and all copies thereof, whether in electronic or hard copy format.

Re: ARGH!!! Why the *#%^$* is this tagged ALL_TRUSTED???

2004-12-07 Thread David B Funk 
On Tue, 7 Dec 2004, Thomas Cameron wrote:

 Hrm - that makes a lot of sense.  I am using spamass-milter (the latest
 from CVS as of about a week ago).

 I actually have the following at the bottom of my sendmail.mc:

 INPUT_MAIL_FILTER
 (`clmilter',`S=local:/var/run/clamav/clmilter.sock,F=,T=S:4m;R:4m')dnl

 INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,
 T=C:15m;S:4m;R:4m;E:10m')dnl
 define(`confMILTER_MACROS_CONNECT',`b, j, _, {daemon_name}, {if_name},
 {if_addr}')dnl

 INPUT_MAIL_FILTER(`greylist',`S=local:/var/milter-greylist/milter-
 greylist.sock')dnl
 define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')dnl
 define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')dnl
 define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')dnl

 I just realized I have two confMILTER_MACROS_CONNECT definitions.  I
 don't think
 that that would cause this but I need to address this tomorrow after
 I've slept some.  :-)

 Thomas

Sorry, but that second confMILTER_MACROS_CONNECT -IS- what is causing
you all your grief.

In the m4 macro processing, last man wins, so that second
confMILTER_MACROS_CONNECT def is preventing sendmail from passing the
_, macro to your milter which causes it to not feed SA a valid
'Received:' header.


-- 
Dave Funk  University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{