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
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
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'
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
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
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
> 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
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.
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
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
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
> -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
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'
> -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"
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
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
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
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
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
> -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
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
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
* 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
* 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
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
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
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
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
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
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
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
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
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
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
> -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
* 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
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
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
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
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
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
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
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
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
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.
>>
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
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
R Lists06 wrote:
Do you put the loopback 127.0.0.1 in your configs?
Yeah.
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
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
>
> 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
> -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 dis
Jo Rhett wrote:
> Matt Kettler wrote:
>>> Matt Kettler wrote:
YOUR network is broken because YOUR network doesn't add Received:
headers before calling SA.. That's not EVERYONE, that's YOU.
Get your tools to add a local Received: header before you call SA, the
auto-detection
On Oct 17, 2006, at 1:22 PM, David B Funk wrote:
BWT, RFC-2821 section 4.4 states that SMTP servers MUST add
"Rececived" headers that indicate the x-fer of the message.
So for your milter to hand a message to SA that lacks the
corresponding
"Received" header cannot be anything but broken.
Uh
On Tue, 17 Oct 2006, Jo Rhett wrote:
> Bowie Bailey wrote:
> > Unless you specify it in the configuration, SA has no idea what
> > servers are local for you. In this case, it has to make a guess so it
> > makes the (fairly reasonable) assumption that the most recent received
> > header comes from
>
> Yes, I know. I'm actually one of the supertechs you refer to. Er, at
> least top of the food chain in that regard :-)
>
> Law enforcement in Santa Clara is excellent, but they have to focus on
> the big fish. This is small stuff to them. It's also just small enough
> to fall under the rad
Jo Rhett wrote:
Oh. I get it. We're trusting headers to be more accurate than
getifaddrs() ? Am I supposed to agree that this makes sense?
Seriously...
Daryl C. W. O'Shea wrote:
Yeah, seriously. Especially when your cluster of 50+ SA machines don't
share the same interface as the other cl
Daryl C. W. O'Shea wrote:
SA knows *nothing* about the connection that isn't in the headers. In
your example in this thread you had two headers, one that was added
after SA saw it, and one that came in as DATA.
You believe the headers entirely? Okay, so auto detection is even more
broken th
Jo Rhett wrote:
Bowie Bailey wrote:
Unless you specify it in the configuration, SA has no idea what
servers are local for you. In this case, it has to make a guess so it
makes the (fairly reasonable) assumption that the most recent received
header comes from a local MX.
Oh. I get it. We're t
Jo Rhett wrote:
Matt Kettler wrote:
Matt Kettler wrote:
So perhaps I didn't get the Received header that will be added by this
host.
Yeah, so how did it get to SA? That's the problem. How can SA be
scanning it, if it hasn't reached this host yet?
Does this matter? SA *IS* scanning it, a
R Lists06 wrote:
As you more than likely already know
...I would encourage you to do consider several things here as realistically
several federal and local laws are being broken here and others have
... ...
We have dealt with issues like this many times and we take not
Bowie Bailey wrote:
Unless you specify it in the configuration, SA has no idea what
servers are local for you. In this case, it has to make a guess so it
makes the (fairly reasonable) assumption that the most recent received
header comes from a local MX.
Oh. I get it. We're trusting headers t
Matt Kettler wrote:
Matt Kettler wrote:
YOUR network is broken because YOUR network doesn't add Received:
headers before calling SA.. That's not EVERYONE, that's YOU.
Get your tools to add a local Received: header before you call SA, the
auto-detection code will start working.
After all, if yo
>
> I just wanted to apologize for my pissy attitude. It wasn't you guys,
> and you didn't deserve these responses.
>
> (the rest of this e-mail is off topic, so unless you're bored hit D)
>
> Some idiot out there keeps sending a hundred megabyte flood against a
> customer of a customer. Our n
Jo Rhett wrote:
> Matt Kettler wrote:
>> Jo Rhett wrote:
>>> You're still babbling about NAT. I could care less about NAT. All
>>> trusted breaks for EVERYONE, and EVERYONE ends up hardcoding
>>> trusted_networks because auto detection is completely and utterly
>>> broken.
>>
>> Fine.. We'll ign
Jo Rhett wrote:
> Matt Kettler wrote:
> > Jo Rhett wrote:
> > > You're still babbling about NAT. I could care less about NAT.
> > > All trusted breaks for EVERYONE, and EVERYONE ends up hardcoding
> > > trusted_networks because auto detection is completely and utterly
> > > broken.
> >
> > Fine
Matt Kettler wrote:
Jo Rhett wrote:
You're still babbling about NAT. I could care less about NAT. All
trusted breaks for EVERYONE, and EVERYONE ends up hardcoding
trusted_networks because auto detection is completely and utterly broken.
Fine.. We'll ignore NAT. It's not your problem, I get
Jo Rhett wrote:
>
> You're still babbling about NAT. I could care less about NAT. All
> trusted breaks for EVERYONE, and EVERYONE ends up hardcoding
> trusted_networks because auto detection is completely and utterly broken.
Fine.. We'll ignore NAT. It's not your problem, I get it.
YOUR networ
Jo Rhett wrote:
Auto detection is completely and utterly broken.
...
Seriously, show me a single site with auto detection enabled that
I just wanted to apologize for my pissy attitude. It wasn't you guys,
and you didn't deserve these responses.
(the rest of this e-mail is off topi
Daryl C. W. O'Shea wrote:
I've reverted this change. As discovered today, Jo's milter isn't
adding the required received header for his MX before passing the mail
to SA which is what is causing his problem.
No, it wasn't. There are *NO* trusted networks in my config. I don't
even trust loc
Matt Kettler wrote:
Jo Rhett wrote:
The autodetection is totally broken actually, and needs to be fixed.
How do you propose it be fixed?
This has been brought up a few dozen times, and really it boils down to
breaking people with NATed MX servers (as it is now), or breaking people
without NAT
Daryl C. W. O'Shea wrote:
>
> I've reverted this change. As discovered today, Jo's milter isn't
> adding the required received header for his MX before passing the mail
> to SA which is what is causing his problem.
>
> Auto-detection works as documented, although I still recommend manual
> configu
Matt Kettler wrote:
Jo Rhett wrote:
The autodetection is totally broken actually, and needs to be fixed.
I've added a comment to the Wiki to let people know about this.
Erm, Jo.. I assume you're referring to this:
---
''Comment: auto detection appears to be broken in non-NA
Jo Rhett wrote:
> Magnus Holmgren wrote:
>> A list search for ALL_TRUSTED would have given you tons of hits. You
>> could also have gone to the FAQ page and from there to the
>> FixingErrors wiki page, where you'd find a reference to ALL_TRUSTED.
>
> Magnus, to be fair - the search will tell you th
Jo Rhett wrote:
> Magnus Holmgren wrote:
>> A list search for ALL_TRUSTED would have given you tons of hits. You
>> could also have gone to the FAQ page and from there to the
>> FixingErrors wiki page, where you'd find a reference to ALL_TRUSTED.
>
> Magnus, to be fair - the search will tell you th
Magnus Holmgren wrote:
A list search for ALL_TRUSTED would have given you tons of hits. You could
also have gone to the FAQ page and from there to the FixingErrors wiki page,
where you'd find a reference to ALL_TRUSTED.
Magnus, to be fair - the search will tell you that autodetection should
w
Subject: Re: ALL_TRUSTED creating a problem
On Monday 16 October 2006 13:32, Suhas (QualiSpace) took the opportunity to
say:
> Most of the spam emails are getting through due to ALL_TRUSTED. If
> ALL_TRUSTED (is reducing the score) was not there then they might have
> caught by SA. What c
On Monday 16 October 2006 13:32, Suhas (QualiSpace) took the opportunity to
say:
> Most of the spam emails are getting through due to ALL_TRUSTED. If
> ALL_TRUSTED (is reducing the score) was not there then they might have
> caught by SA. What can be the solution on this; I haven't declared any
>
Suhas (QualiSpace) wrote:
Hello,
Most of the spam emails are getting through due to ALL_TRUSTED. If
ALL_TRUSTED (is reducing the score) was not there then they might have
caught by SA. What can be the solution on this; I haven’t declared any
trusted networks yet and using the default setti
Hello,
Most of the spam emails are getting through due to ALL_TRUSTED.
If ALL_TRUSTED (is reducing the score) was not there then they might have
caught by SA. What can be the solution on this; I haven’t declared any
trusted networks yet and using the default setting. I am using SA 3.0.1
80 matches
Mail list logo