Re: ALL_TRUSTED is Always in Headers

nt: Mon, Jun 26, 2023 5:21 am Subject: Re: ALL_TRUSTED is Always in Headers >>On 24.06.23 02:12, Denny Jones via users wrote: >>>Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1 >>> >>>ALL_TRUSTED is always in every header:Here's an example header: >On 6/25/

Re: ALL_TRUSTED is Always in Headers

On 24.06.23 02:12, Denny Jones via users wrote: Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1 ALL_TRUSTED is always in every header:Here's an example header: On 6/25/2023 9:23 AM, Matus UHLAR - fantomas wrote: do you use amavisd-milter? There's bug in older versions of amavis describ

Re: ALL_TRUSTED is Always in Headers

On 6/25/2023 9:23 AM, Matus UHLAR - fantomas wrote: On 24.06.23 02:12, Denny Jones via users wrote: Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1 ALL_TRUSTED is always in every header:Here's an example header: do you use amavisd-milter? There's bug in older versions of amavis describe

Re: ALL_TRUSTED is Always in Headers

On 24.06.23 02:12, Denny Jones via users wrote: Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1 ALL_TRUSTED is always in every header:Here's an example header: do you use amavisd-milter? There's bug in older versions of amavis describes here: https://gitlab.com/amavis/amavis/-/issues/61

Re: ALL_TRUSTED is Always in Headers

On 2023-06-23 at 22:12:50 UTC-0400 (Sat, 24 Jun 2023 02:12:50 + (UTC)) Denny Jones via users is rumored to have said: Hello, Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1 ALL_TRUSTED is always in every header:Here's an example header: [snip] I have both internal_networks and tru

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Nov 11, 2018, at 13.35, Benny Pedersen wrote: > > listsb skrev den 2018-11-11 19:20: > >> thanks, agreed. is continuation of this discussion ok here? or >> should i take to the amavis list? > > its important that networks ip ranges is equal in all software used > > its not done automatic

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sun, 11 Nov 2018, John Hardin wrote: On Sat, 10 Nov 2018, listsb wrote: what am i misunderstanding? Is there some possibility that you're stripping external Received headers? (grasping at straws here) Heh. Ignore that. I have *got* to learn to catch up *before* replying to stuff... :)

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sat, 10 Nov 2018, listsb wrote: On Nov 10, 2018, at 21.01, John Hardin wrote: On Sat, 10 Nov 2018, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following:

Re: ALL_TRUSTED always shown in X-Spam-Status header

listsb skrev den 2018-11-11 19:20: thanks, agreed. is continuation of this discussion ok here? or should i take to the amavis list? its important that networks ip ranges is equal in all software used its not done automatic ALL_TRUSTED is not a amavis problem to solve so keep it here, unti

Re: ALL_TRUSTED always shown in X-Spam-Status header

>On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: >>i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: >> >>>grep -riF 'internal_networks' /etc/spamassassin/* >>/etc/sp

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Nov 11, 2018, at 13.18, Matus UHLAR - fantomas wrote: > >>> On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassas

Re: ALL_TRUSTED always shown in X-Spam-Status header

> On Nov 11, 2018, at 12.23, Henrik K wrote: > > On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: >> hi- >> >> i've just noticed that every mail received seems to be hitting the >> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come >> from. i have the following

Re: ALL_TRUSTED always shown in X-Spam-Status header

> On Nov 11, 2018, at 12.05, RW wrote: > > On Sun, 11 Nov 2018 10:35:18 -0500 > listsb wrote: > >>> On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas >>> wrote: >>> >>> On 10.11.18 20:04, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED t

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sun, Nov 11, 2018 at 06:43:27PM +0100, Matus UHLAR - fantomas wrote: > >On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: > >>i've just noticed that every mail received seems to be hitting the > >>ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come > >>from. i ha

Re: ALL_TRUSTED always shown in X-Spam-Status header

Amavisd does not use spamassassin *networks settings Orignation bug is not spamassassin problem Benny On 11. november 2018 18.24.05 Henrik K wrote: On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: hi- i've just noticed that every mail received seems to be hitting the ALL_TRUSTED te

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: >grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassass

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote: > hi- > > i've just noticed that every mail received seems to be hitting the > ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come > from. i have the following: > > >grep -riF 'internal_networks' /etc/spamassassin/

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sun, 11 Nov 2018 10:35:18 -0500 listsb wrote: > > On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas > > wrote: > > > > On 10.11.18 20:04, listsb wrote: > >> i've just noticed that every mail received seems to be hitting the > >> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the mes

Re: ALL_TRUSTED always shown in X-Spam-Status header

> On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas wrote: > > On 10.11.18 20:04, listsb wrote: >> i've just noticed that every mail received seems to be hitting the >> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come >> from. i have the following: >> >>> grep -riF

Re: ALL_TRUSTED always shown in X-Spam-Status header

On 10.11.18 20:04, listsb wrote: i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-config.cf:

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Nov 10, 2018, at 21.01, John Hardin wrote: > > On Sat, 10 Nov 2018, listsb wrote: > >> hi- >> >> i've just noticed that every mail received seems to be hitting the >> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come >> from. i have the following: >> >>> grep -r

Re: ALL_TRUSTED always shown in X-Spam-Status header

On Sat, 10 Nov 2018, listsb wrote: hi- i've just noticed that every mail received seems to be hitting the ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i have the following: grep -riF 'internal_networks' /etc/spamassassin/* /etc/spamassassin/99_local-co

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

amavisd seems to be involved in this issue; not sure whether it's the 'culprit' or the 'victim'. A 'ham' mail received through postfix+amavisd+spamassassin arrives with headers ... X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

> > UNPARSEABLE_RELAY still hits. I've not yet determined what the actual > > problem with the parsing is. > > It's a shortcoming/bug in the SpamAssassin ad-hoc parser. > > Please open a Bugzilla ticket and provide a sample of > your Received header field (which is perfectly valid > according to

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

PGNd wrote: The LHLO/LMTP header still is added at the backend, and UNPARSEABLE_RELAY still hits. I've not yet determined what the actual problem with the parsing is. It's a shortcoming/bug in the SpamAssassin ad-hoc parser. Please open a Bugzilla ticket and provide a sample of your Received

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

Am 19.06.2015 um 16:31 schrieb PGNd: Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly prevents it from triggering the shortcircuit. However, it still fires -- incorrectly & intermittently, albeit now with a "-1" score attached. The LHLO/LMTP header still is adde

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly prevents it from triggering the shortcircuit. However, it still fires -- incorrectly & intermittently, albeit now with a "-1" score attached. The LHLO/LMTP header still is added at the backend, and UNPARSEABLE_RELAY s

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

> Are the 196.28.80.29, 196.28.80.61, and 196.28.66.13 in your > trusted X.X.X.X/29 ? If they are, then hitting ALL_TRUSTED is expected. No, the X.X.X.X/29 is a different server -- one of my own, not in a 186. block, and definitely not in ZA. > > Jun 18 22:38:19.967 [19747] dbg: check: > > tes

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

PGNd wrote: I'm running postfix 3.0.1 amavisd-new-2.10.1 (20141025) SpamAssassin version 3.4.1 on linux/64. amavisd/spamassasin is invoked as a postfix prequeue proxy filter. Spam is getting scanned and scored. Usually correctly. Intermittenly, I get an email that get

Re: ALL_TRUSTED triggering _intermittently_ on external mails?

>/local.cf > internal_networks 127.0.0.0/8 10.2.2.0/24 10.1.1.0/24 X.X.X.X/29 > trusted_networks 10.2.2.0/24 10.1.1.0/24 X.X.X.X/29 >etc, the msg's received-from headers are _not_ all on my internal networks, What are the X.X.X.X/29 above? It can

Re: ALL_TRUSTED does not disable DKIM_ADSP_ALL

Benny, > X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 > tests=[ALL_TRUSTED=-0.1, DKIM_ADSP_ALL=1.1, DKIM_SIGNED=0.1, > DKIM_VALID=-0.1, NO_X_MAILER=0.1] autolearn=no > > ALL_TRUSTED does not disable DKIM_ADSP_ALL Why would an ALL_TRUSTED be disabling an ADSP test??? Trus

Re: ALL_TRUSTED

Casartello, Thomas wrote: > I'm having an issue with the ALL_TRUSTED rule in SA 3.3.1. I > recently rebuilt my server running SA, and now for some reason the > ALL_TRUSTED rule is not triggering when a user sends a message using > SASL authentication from outside our site. Before it would work when

Re: ALL_TRUSTED

On Fri, 2010-10-22 at 16:00 -0400, Casartello, Thomas wrote: > I’m having an issue with the ALL_TRUSTED rule in SA 3.3.1. I recently > rebuilt my server running SA, and now for some reason the ALL_TRUSTED > rule is not triggering when a user sends a message using SASL > authentication from outside

Re: ALL_TRUSTED rule no longer working

On 1/6/2010 3:43 PM, Julian Yap wrote: > > On Tue, Jan 5, 2010 at 5:12 PM, Matt Kettler > wrote: > > On 1/5/2010 8:03 PM, Julian Yap wrote: >> Previously I was running SpamAssassin-3.1.8_1 on FreeBSD. >> >> I recently upgraded to 3.2.5_4. >> >> It's

Re: ALL_TRUSTED rule no longer working

On Tue, Jan 5, 2010 at 5:12 PM, Matt Kettler wrote: > On 1/5/2010 8:03 PM, Julian Yap wrote: > > Previously I was running SpamAssassin-3.1.8_1 on FreeBSD. > > I recently upgraded to 3.2.5_4. > > It's seems now, I never get any hits on the rule ALL_TRUSTED. > > Previously it seemed like SA was doi

Re: ALL_TRUSTED rule no longer working

On 1/5/2010 8:03 PM, Julian Yap wrote: > Previously I was running SpamAssassin-3.1.8_1 on FreeBSD. > > I recently upgraded to 3.2.5_4. > > It's seems now, I never get any hits on the rule ALL_TRUSTED. > > Previously it seemed like SA was doing some kind of dynamic evaluation > which was working wel

Re: ALL_TRUSTED - problem (yes I set trusted_networks already)

peter pilsl wrote: Our mailserver is behind a NAT-firewall (port 25 is passed through to the internal mailserver) and I ran into the ALL_TRUSTED-problem. I looked up the FAQ and set trusted_networks 127.0.0.1 (which actually gives me a warning that 127.0.0.1 is already part of trusted_net

Re: ALL_TRUSTED - problem (yes I set trusted_networks already)

On 28.03.08 14:26, peter pilsl wrote: > Our mailserver is behind a NAT-firewall (port 25 is passed through to > the internal mailserver) and I ran into the ALL_TRUSTED-problem. I > looked up the FAQ and set > > trusted_networks 127.0.0.1 (which actually gives me a warning that > 127.0.0.1 i

RE: ALL_TRUSTED - problem (yes I set trusted_networks already)

peter pilsl wrote: > Our mailserver is behind a NAT-firewall (port 25 is passed through to > the internal mailserver) and I ran into the ALL_TRUSTED-problem. I > looked up the FAQ and set > > trusted_networks 127.0.0.1 (which actually gives me a warning that > 127.0.0.1 is already part of trusted

Re: ALL_TRUSTED and DOS_OE_TO_MX

On 24/02/2008 10:06 AM, giga328 wrote: > Client in example is Outlook Express at 89.110.202.24 also in trusted > networks. > Relevant configuration lines are: > trusted_networks 212.62.32.0/19 > trusted_networks 89.110.192.0/18 Not that this is the cause of your problem, but I'm wondering why 89.

Re: ALL_TRUSTED and DOS_OE_TO_MX

Matus UHLAR - fantomas wrote: > > We've had similar problem. It was caused by our clients who did not SMTP > authentication and sent mail to our clients, so they were really sending > mail from outlook express to the destination server (we use the same > servers > for primary MX as for outgoing

Re: ALL_TRUSTED and DOS_OE_TO_MX

On 23.02.08 17:34, giga328 wrote: > I'm testing SpamAssassin and I'm getting false positives. Both tests > ALL_TRUSTED and DOS_OE_TO_MX are firing for emails sent by Outlook Express > for local clients and it seems like I have something wrong in *_networks. > Here is my setup: > All my servers and

Re: ALL_TRUSTED and DOS_OE_TO_MX

Daryl C. W. O'Shea wrote: > > > Please post the full received headers of the problem message and your > trusted/internal/msa networks config. If you're paranoid about publicly > posting them you can send them to me directly. > > Daryl > > Hi Daryl, Email system will not use NAT so IP adre

Re: ALL_TRUSTED and DOS_OE_TO_MX

On 23/02/2008 8:34 PM, giga328 wrote: > I'm testing SpamAssassin and I'm getting false positives. Both tests > ALL_TRUSTED and DOS_OE_TO_MX are firing for emails sent by Outlook Express > for local clients and it seems like I have something wrong in *_networks. > Here is my setup: > All my servers

Re: ALL_TRUSTED Overriding Bayes

On Wed, 16 May 2007, Clay Davis wrote: I only have one internal network 10.0.0.0 (mask: 255.255.255.0). I have attached a few of the message that scored like this. Do you have any trusted_networks or internal_networks set up in SA's local.cf? If not, SA would be trying to guess your internal

Re: ALL_TRUSTED Overriding Bayes

On Wed, 16 May 2007, Clay Davis wrote: Hi gang: I am getting a bunch of messages that are passing through my SA setup with the following scores: pts rule name description -- -- 0.0 SUBJ_FOR_ONLY Sub

RE: ALL_TRUSTED rule fires despite no trusted_networks defined

I'm afraid a lot of rules are completely misfiring because of this (DNSRBL, SPF, ALL_TRUSTED...) Thanx for your help -Message d'origine- De : Jim Maul [mailto:[EMAIL PROTECTED] Envoyé : jeudi 8 février 2007 17:24 À : Stéphane LEPREVOST Cc : users@spamassassin.apache.org Objet : Re

Re: ALL_TRUSTED rule fires despite no trusted_networks defined

Stéphane LEPREVOST wrote: We are actually checking the configuration of our SA installation (SA 3.1.7 + qmail + qmail-scanner 1.25st + clamav running on SLES *) and just saw a very weird thing : despite we don't have any 'trusted_networks' line in our local.cf file, more than 50 000 received

Re: ALL_TRUSTED creating a problem

On Thursday 19 October 2006 20:34, Jo Rhett took the opportunity to say: > Mark wrote: > >> -Original Message- > >> From: Jo Rhett [mailto:[EMAIL PROTECTED] > >> Sent: donderdag 19 oktober 2006 9:56 > >> To: Mark > >> Cc: users@spamassassin.a

Re: ALL_TRUSTED creating a problem

1.2 - 2.7mil per day varying. Sometimes as high as 5mil during spam floods. Modern AMD dualcore processor, 4gb of ram. Nothing special. Richard Frovarp wrote: Okay, out of curiosity about how many messages do these single machines handle in an average day? 500,000/machine/day? 800,000/machin

Re: ALL_TRUSTED creating a problem

Okay, out of curiosity about how many messages do these single machines handle in an average day? 500,000/machine/day? 800,000/machine/day? 1,000,000/machine/day? Jo Rhett wrote: Respectable enough, but I'm not sure why you bother having that big of an array with that small of a mail load. I'

Re: ALL_TRUSTED creating a problem

Respectable enough, but I'm not sure why you bother having that big of an array with that small of a mail load. I've got single machines handling loads several times larger, all doing Clamd, a commercial scanner, SA and more on milter during the connection time, and there are no SMTP timeouts

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: Richard Frovarp wrote: This is partially a function of scale. Machines that handle large numbers of messages probably don't want to hold the SMTP connection open while the scanning takes place, even if scan time is 9 seconds. Of course these users are possibly using a different

Re: ALL_TRUSTED creating a problem

Richard Frovarp wrote: This is partially a function of scale. Machines that handle large numbers of messages probably don't want to hold the SMTP connection open while the scanning takes place, even if scan time is 9 seconds. Of course these users are possibly using a different system other tha

Re: ALL_TRUSTED creating a problem

> But I specifically mentioned RBL checks. Those can take a while. Things like Razor2, Pyzor, and dcc checks can take a good while, too. I have Razor2 and Pyzor timeouts set to 30 seconds. And sometimes they really need that, too. I have all of those, all of the default RBLS and 12 RBLs th

RE: ALL_TRUSTED creating a problem

Mark wrote: > Mark is well aware of the benefits of milters. ;) In fact, I run > clamav too. But clamav isn't SA. No, but it needs the message body just like SA does, and it serves a similar purpose in my mind: detecting email you don't really want to receive, based on the contents of the message.

Re: ALL_TRUSTED creating a problem

Mark wrote: Mark is well aware of the benefits of milters. ;) In fact, I run clamav too. But clamav isn't SA. And I was arguing the case that, since SA needs to be done post-DATA, there's really not a whole lot of advantage you gain from bringing it to a milter (where you then have to emulate a p

Re: ALL_TRUSTED creating a problem

Coffey, Neal wrote: Jo Rhett wrote: ... it operates, by nature, post DATA phase. Huh? It operates when I ask it to. While that's certainly true, if you've configured SA to scan *before* the DATA phase, I'd be curious to see how well it's working for you. *giggle* yes :-) Sorry. That sai

Re: ALL_TRUSTED creating a problem

Mark wrote: Exactly what I said: SA works on examining a message (headers + body); that makes it, per definition, a post-DATA phase operation. Ah, gotcha. But not post SMTP :-) Not post-SMTP per se, but post-DATA phase. And since the end of the DATA completes the SMTP dialogue, you might as

RE: ALL_TRUSTED creating a problem

> -Original Message- > From: Coffey, Neal [mailto:[EMAIL PROTECTED] > Sent: donderdag 19 oktober 2006 21:03 > To: users@spamassassin.apache.org > Subject: RE: ALL_TRUSTED creating a problem > > > That said, Mark seems to be missing that milters don't

RE: ALL_TRUSTED creating a problem

Jo Rhett wrote: >> ... it operates, by nature, post DATA phase. > > Huh? It operates when I ask it to. While that's certainly true, if you've configured SA to scan *before* the DATA phase, I'd be curious to see how well it's working for you. That said, Mark seems to be missing that milters don'

RE: ALL_TRUSTED creating a problem

> -Original Message- > From: Jo Rhett [mailto:[EMAIL PROTECTED] > Sent: donderdag 19 oktober 2006 20:36 > To: Mark > Cc: users@spamassassin.apache.org > Subject: Re: ALL_TRUSTED creating a problem > > > > I reckon the focus of SA on "post-SMTP"

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: Autodetection should work out of the box for out of the box installs. Custom installations, and most especially people creating appliances out of this, are managed by Experts who have a clue. Jonas Eckerman wrote: If you are using a milter that calls SA, you are in effect us

Re: ALL_TRUSTED creating a problem

Mark wrote: -Original Message- From: Jo Rhett [mailto:[EMAIL PROTECTED] Sent: donderdag 19 oktober 2006 9:56 To: Mark Cc: users@spamassassin.apache.org Subject: Re: ALL_TRUSTED creating a problem Perhaps SA being focused on "post-SMTP" is the problem here. Why is this the

Re: ALL_TRUSTED creating a problem

Magnus Holmgren wrote: On Thursday 19 October 2006 09:55, Jo Rhett took the opportunity to say: Mark wrote: We cannot really say SA's autodetection is broken, because SA is designed to be called post-SMTP. Nor that a milter is broken per se for not adding a Received: header, as that is the resp

Re: ALL_TRUSTED creating a problem

Kevin Golding wrote: Anyway, not conclusive but a fair range of traffic and no visible problems. I'm just rambling to avoid real work if I'm honest. The answer you're looking for is "no, I didn't do extensive and deliberate testing. I say auto-detection works fine based just on general testing

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: Autodetection should work out of the box for out of the box installs. Custom installations, and most especially people creating appliances out of this, are managed by Experts who have a clue. If you are using a milter that calls SA, you are in effect using a custom install

RE: ALL_TRUSTED creating a problem

> -Original Message- > From: Jo Rhett [mailto:[EMAIL PROTECTED] > Sent: donderdag 19 oktober 2006 9:56 > To: Mark > Cc: users@spamassassin.apache.org > Subject: Re: ALL_TRUSTED creating a problem > > > Perhaps SA being focused on "post-SMTP" is the

Re: ALL_TRUSTED creating a problem

On Thursday 19 October 2006 09:55, Jo Rhett took the opportunity to say: > Mark wrote: > > We cannot really say SA's autodetection is broken, because SA is designed > > to be called post-SMTP. Nor that a milter is broken per se for not adding > > a Received: header, as that is the responsibility of

Re: ALL_TRUSTED creating a problem

Someone, quite probably Jo Rhett, once wrote: >Kevin Golding wrote: >> FWIW I've run SpamAssassin on a bog-standard, normal, plain, old- >> fashioned FreeBSD box sitting in a rack with a public IP, no NAT, no >> patches, and no pixies or faeries. Auto-detection worked fine. > >Just for my referenc

Re: ALL_TRUSTED creating a problem

* Jo Rhett wrote (19/10/06 08:55): Perhaps SA being focused on "post-SMTP" is the problem here. Why is this the focus? In the modern world, you want to reject during SMTP not send backscatter to the poor folks whose e-mail got forged. Frankly, a milter environment is the only possible right

Re: ALL_TRUSTED creating a problem

* Jo Rhett wrote (19/10/06 08:55): Mark wrote: We cannot really say SA's autodetection is broken, because SA is designed to be called post-SMTP. Nor that a milter is broken per se for not adding a Received: header, as that is the responsibility of the MTA itself. But a milter using SA *can* be s

Re: ALL_TRUSTED creating a problem

John Andersen wrote: On Thursday 19 October 2006 00:00, Jo Rhett wrote: This, it seems to me, is exactly what it does. Show me it working properly on a out-of-the-box rpm/ports config on a direct connect, no NAT system. (ie "most people") Amavis worked for me that way when I installed Suse L

Re: ALL_TRUSTED creating a problem

Matt Kettler wrote: Jo Rhett wrote: I'd love to, but the SA project didn't write the milter you're using, and the problems you're having can't be "fixed" by having SpamAssassin "detect" the problem without doing something even dumber to someone else. Sure it can! It's dead simple to determine

Re: ALL_TRUSTED creating a problem

On Thursday 19 October 2006 00:00, Jo Rhett wrote: > > This, it seems to me, is exactly what it does. > > Show me it working properly on a out-of-the-box rpm/ports config on a > direct connect, no NAT system.  (ie "most people") Amavis worked for me that way when I installed Suse Linux Enterprise

Re: ALL_TRUSTED creating a problem

Kevin Golding wrote: FWIW I've run SpamAssassin on a bog-standard, normal, plain, old- fashioned FreeBSD box sitting in a rack with a public IP, no NAT, no patches, and no pixies or faeries. Auto-detection worked fine. Just for my reference "Worked fine" meaning "it never demonstrated a probl

Re: ALL_TRUSTED creating a problem

Chris Lear wrote: It seems that Jo wants autodetection to: 1) comply with the documentation 2) just work for most people 3) be easily fixable in other cases Yes. This, it seems to me, is exactly what it does. Show me it working properly on a out-of-the-box rpm/ports config on a direct conn

Re: ALL_TRUSTED creating a problem

Mark wrote: We cannot really say SA's autodetection is broken, because SA is designed to be called post-SMTP. Nor that a milter is broken per se for not adding a Received: header, as that is the responsibility of the MTA itself. But a milter using SA *can* be said to be broken if it's not proving

Re: ALL_TRUSTED creating a problem

Matt Kettler wrote: Yeah, it's a shame that amavis is broken out of the box. You're still on this amavis kick. This has nothing to do with amavis. I'm saying that when I read the code, it won't work on a normal system NO MATTER WHAT CONFIG. Period. It can't work properly, except perhaps i

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: > Matt Kettler wrote: >> It's *really* common to separate spamd from the MTA for anyone that's >> got any decent volume of mail. And that's not a few sites. > > And I guess that I'm saying > > 1. People installing from RPMs and/or Ports (or Portage, etc) expect > things to work out

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: > >> I'd love to, but the SA project didn't write the milter you're using, >> and the problems you're having can't be "fixed" by having SpamAssassin >> "detect" the problem without doing something even dumber to someone >> else. > > Sure it can! It's dead simple to determine that t

Re: ALL_TRUSTED creating a problem

Mark <[EMAIL PROTECTED]> writes: > We cannot really say SA's autodetection is broken, because SA is designed > to be called post-SMTP. Nor that a milter is broken per se for not adding > a Received: header, as that is the responsibility of the MTA itself. But a > milter using SA *can* be said to b

RE: ALL_TRUSTED creating a problem

> -Original Message- > From: Matt Kettler [mailto:[EMAIL PROTECTED] > Sent: woensdag 18 oktober 2006 8:54 > To: Jo Rhett > Cc: users@spamassassin.apache.org > Subject: Re: ALL_TRUSTED creating a problem > > > True.. and writing a milter should be an expert t

Re: ALL_TRUSTED creating a problem

* Jo Rhett wrote (18/10/06 08:57): > Matt Kettler wrote: >> It's *really* common to separate spamd from the MTA for anyone that's >> got any decent volume of mail. And that's not a few sites. > > And I guess that I'm saying > > 1. People installing from RPMs and/or Ports (or Portage, etc) expect

Re: ALL_TRUSTED creating a problem

Anthony Peacock wrote: Kevin Golding wrote: In article <[EMAIL PROTECTED]>, Jo Rhett <[EMAIL PROTECTED]> writes These arguments are getting sillier and sillier. I'm asking why it doesn't work in a plain-jane do-nothing normal public box not behind a NAT. And every argument so far has been

Re: ALL_TRUSTED creating a problem

Kevin Golding wrote: In article <[EMAIL PROTECTED]>, Jo Rhett <[EMAIL PROTECTED]> writes These arguments are getting sillier and sillier. I'm asking why it doesn't work in a plain-jane do-nothing normal public box not behind a NAT. And every argument so far has been some strange configurati

Re: ALL_TRUSTED creating a problem

In article <[EMAIL PROTECTED]>, Jo Rhett <[EMAIL PROTECTED]> writes >These arguments are getting sillier and sillier. I'm asking why it >doesn't work in a plain-jane do-nothing normal public box not behind >a NAT. And every argument so far has been some strange configuration >that is very c

Re: ALL_TRUSTED creating a problem

Matt Kettler wrote: It's *really* common to separate spamd from the MTA for anyone that's got any decent volume of mail. And that's not a few sites. And I guess that I'm saying 1. People installing from RPMs and/or Ports (or Portage, etc) expect things to work out of the box. Having it be b

Re: ALL_TRUSTED creating a problem

I'm skipping the more important stuff I don't have time to reply to for this little topic. Matt Kettler wrote: True.. and writing a milter should be an expert task. I'm sorry the milter your are using is causing you such fits, but I really don't think it's normal for the average end-user to hav

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: > Matt, I'm tired and my day ended badly yesterday and started badly > today and I'm in danger of being way too bitchy (probably way past > that point already) so I'm going to keep it simple and sweet. Fair enough. I hope my own short-worded nature hasn't come across too harshly. (A

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: > Daryl, this part of the conversation is academic at best. Amavisd > milter has been patched and is providing the proper received headers, > and network autodetection is still broken. Really, that seems quite odd. I myself have never had it fail for that case before when all the I

Re: ALL_TRUSTED creating a problem

Matt, I'm tired and my day ended badly yesterday and started badly today and I'm in danger of being way too bitchy (probably way past that point already) so I'm going to keep it simple and sweet. 1. Assuming that the Received headers are sane ... isn't. 2. Decrementing the spam score is not

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: > > On Oct 17, 2006, at 5:59 PM, Matt Kettler wrote: >> Because there *HAS* to be a local. If there isn't, then the message >> isn't at your server. >> >> This is the whole point. If the message hasn't been Received: by a local >> server, it is by definition not in your network. >>

Re: ALL_TRUSTED creating a problem

al Message- From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED] Sent: dinsdag 17 oktober 2006 5:37 To: Matt Kettler Cc: Jo Rhett; Magnus Holmgren; users@spamassassin.apache.org Subject: Re: ALL_TRUSTED creating a problem As discovered today, Jo's milter isn't adding the require

Re: ALL_TRUSTED creating a problem

Jo Rhett wrote: RIGHT. So why are they Trusted? On Oct 17, 2006, at 5:59 PM, Matt Kettler wrote: Because there *HAS* to be a local. If there isn't, then the message isn't at your server. This is the whole point. If the message hasn't been Received: by a local server, it is by definition n

Re: ALL_TRUSTED creating a problem

R Lists06 wrote: Do you put the loopback 127.0.0.1 in your configs? Yeah.

Re: ALL_TRUSTED creating a problem

R Lists06 wrote: Im a little confused in this thread now... please clarify this... Does this mean my SA config is not correct if I do not have the ip address of the SA box which is also the main SMTP box in the local.cf in that trusted host config line? *that* trusted host config line? Do yo

Re: ALL_TRUSTED creating a problem

Mark wrote: -Original Message- From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED] Sent: dinsdag 17 oktober 2006 5:37 To: Matt Kettler Cc: Jo Rhett; Magnus Holmgren; users@spamassassin.apache.org Subject: Re: ALL_TRUSTED creating a problem As discovered today, Jo's milter is

RE: ALL_TRUSTED creating a problem

> > This is the whole point. If the message hasn't been Received: by a local > server, it is by definition not in your network. > > By feeding messages to SA without a local Received: header, you are > explicitly telling SA that the message is still in some other network, > not yours. So what's

  1   2   >