Re: ARGH!!! Why the *#%^$* is this tagged ALL_TRUSTED???
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???
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???
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???
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???
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{