You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Suhas (QualiSpace)" <su...@qualispace.com> on 2006/10/16 13:32:53 UTC
ALL_TRUSTED creating a problem
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.
Would appreciate your feedback.
Warm Regards,
Suhas
System Administrator
QualiSpace - A QuantumPages Enterprise
===========================
Tel India: +91 (22) 6792 - 1480
Tel US: +1 (614) 827 - 1224
Fax India: +91 (22) 2530 - 3166
URL: http://www.qualispace.com <http://www.qualispace.com/>
===========================
For Any Technical Query Please Use: http://helpdesk.qualispace.com
<http://helpdesk.qualispace.com/>
QualiSpace Community Discussion forum: http://forum.qualispace.com
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
> 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 using a
> custom installation, or at least a custom way of calling SA.
> An "out-of-the-box" installation of SA does not include a milter of any
> kind.
FreeBSD ports installation uses sendmail (included in base OS) and
milter for amavisd. It's the only method that works out of the box.
I can't confirm, but others indicate that RPMs on various linux
platforms do the exact same thing.
That's "out of the box" as far as open source OSes go :-)
> A correctly written milter calling SA is supposed to *create* a
> Received: header and prepend it to the message it send to SA
> (MIMEDefang, the milter we're using, does that for example).
Perhaps, but that is undocumented. Obviously as I've said
10,000,000,000,000 times now amavisd-milter has been patched to do this,
but documentation of that requirement should be done.
*AND* SA should be overhauled to not require alteration of the message.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Jonas Eckerman <jo...@frukt.org>.
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 installation, or at least a custom way of calling SA.
An "out-of-the-box" installation of SA does not include a milter of any kind.
A correctly written milter calling SA is supposed to *create* a Received: header and prepend it to the message it send to SA (MIMEDefang, the milter we're using, does that for example).
/Jonas
--
Jonas Eckerman, FSDB & Fruktträdet
http://whatever.frukt.org/
http://www.fsdb.org/
http://www.frukt.org/
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 that the last Received
>> header isn't yourself and can't possibly be related to you.
>
> No, you can't.. Again, separation of spamd is COMMON.
I don't see how separation of spamd changes the equation. If there's
something special about your spamd separation, then please document that
configuration. Using XNS protocol, or Appletalk instead of IP?
And again, doesn't that fall under "custom configuration" ?
I'll bet you a very nice dinner somewhere that there are 10, if not 100,
users with SA run via procmail or milter etc for every site which has
distributed mail servers. Maybe a 1000:1 even.
And again, in looking at the code I can't imagine why detecting the
distributed configuration would be difficult. Yeah, the current code
seems to do the whole network detection bit from end->beginning, but
it's certainly not that difficult to add these checks.
Look, forget this conversation. When I have time from some other
projects to deal with this, I'll prepare a long list of cases which will
fail under the current code, and a patch to fix it.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 the last Received
> header isn't yourself and can't possibly be related to you.
No, you can't.. Again, separation of spamd is COMMON.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 have to hack up their milters to
> make them feed SA properly. Most milters that handle SA already do this
> for you, right out of the box.
Petr Rehor is the maintainer for amavisd-milter. It's the *ONLY* way
that amavis works properly in a milter config. It's incredibly standard,
and works out of the (ports) box on FreeBSD and probably most linuxes.
There are tons of people using it today. So yeah, all of the "average
end users" who are using amavis out of ports on FreeBSD, really.
Petr never put this Received header forgery bit into amavisd-milter. He
didn't know he was supposed to, not having any documentation that
mentions this. So it was broken until Daryl flagged this issue, and I
brought it up with him and Marc (of amavisd-new fame) and we realized
that expectations didn't align. He pushed out a patch in < 24 hours and
this is now fixed.
>> Make autodetection work out of the box for the clueless people using
>> it out of the box. That's your real target audience.
> 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 the last Received
header isn't yourself and can't possibly be related to you.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 Linux Enterprise Sever.
Great. However, I must add that I've gotten 5 e-mails from people
telling me that my configuration was broken because amavis and
ALL_TRUSTED worked just fine with amavisd-milter out of the box.
So I had them pull logs and headers...
And in every case it was broken and showed no sign of ever not being
broken. Which is the only possible response, because Petr never had the
"forge a header" function in the code to start with.
We have to take it away from "works for me" and into "actually works in
a demonstrable manner"...
Yeah, I agree, a lot of people apparently never noticed it was broken.
But I spend my life playing Devil in the Details, and I'm sure that this
stuff just doesn't work. I'll supply examples as soon as I have a break
from an emergency rebuild of a friend's e-commerce gateway because their
online shopping cart provider apparently collapsed :-(
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by John Andersen <js...@pen.homeip.net>.
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 Sever.
Suse has gone to a lot of work to get it to run right out of the box.
About the only change I made was to tell it to STFU a bit because
its logging was a tad excessive.
--
_____________________________________
John Andersen
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 connect, no NAT system. (ie "most people")
> OK, maybe it doesn't work
> in Jo Rhett's system. But defining "most people" as "people who do
> things like Jo Rhett" is suspect at best.
Actually, I'm using it bone stock from FreeBSD ports, so yeah - in this
case my config is "normal" FWIW..
> I can see a case for saying "autodetection can't possibly work in all
> cases, so disable it by default". But saying "it doesn't do what I
> expect, so it's broken" seems to show a disregard for the documentation
> and all the (lots of) historical discussions about the subject. Anyone
> who has seen spam hitting ALL_TRUSTED (as I have) can sort the problem
> out with reference to good documentation in minutes. That's if they are
> like me and installed spamassassin without really knowing anything about
> it. If they were more switched on, they would have read the
> documentation first.
Really? Then why is it the most common FAQ on the list (see archives)
Why does it break for so very many people with normal configs? Why does
it completely fail when installed in an old (pre-1990) class-A network? Eh?
Nobody cares what I expect. When the docs say "it should work for you"
then I think it really should work for a majority of people. It's
working for some weird subset of people that I can't quite figure out
from reading the code.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Chris Lear <ch...@laculine.com>.
* 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
> things to work out of the box. Having it be broken for them creates a
> problem very visible if you search for all_trusted in the list archives.
>
> 2. "Any decent volume of mail" with "separate servers" means it's a
> customized mail environment CONFIGURED BY EXPERTS :-)
>
> I dunno. I would aim for the former, and then provide good docs for the
> latter. The former generally don't read the docs, and I prefer to avoid
> the mailing list noise.
>
I hope you don't mind an observer's view here.
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
This, it seems to me, is exactly what it does. OK, maybe it doesn't work
in Jo Rhett's system. But defining "most people" as "people who do
things like Jo Rhett" is suspect at best.
I can see a case for saying "autodetection can't possibly work in all
cases, so disable it by default". But saying "it doesn't do what I
expect, so it's broken" seems to show a disregard for the documentation
and all the (lots of) historical discussions about the subject. Anyone
who has seen spam hitting ALL_TRUSTED (as I have) can sort the problem
out with reference to good documentation in minutes. That's if they are
like me and installed spamassassin without really knowing anything about
it. If they were more switched on, they would have read the
documentation first.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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
in some odd config that I'm not imagining here.
> I'm sorry, but I still consider the "expert" here to be the amavis
> developer(s). There's only a few of them, and what they need to do is
> documented.
Really? I've asked 5 times now, and you divert every time I ask. Where?
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 of the box. Having it be broken for them creates a
> problem very visible if you search for all_trusted in the list archives.
Yeah, it's a shame that amavis is broken out of the box.
>
> 2. "Any decent volume of mail" with "separate servers" means it's a
> customized mail environment CONFIGURED BY EXPERTS :-)
Ok, so we should break all the "experts" end user setups and require
them to read some docs in order to avoid one symptom of a major problem
with amavis?
>
> I dunno. I would aim for the former, and then provide good docs for
> the latter. The former generally don't read the docs, and I prefer to
> avoid the mailing list noise.
>
I'm sorry, but I still consider the "expert" here to be the amavis
developer(s). There's only a few of them, and what they need to do is
documented.
It's a shame amavis missed out on this. But it seems odd to me that I
have talked to so many amavis users over the years and they all seem to
have working SA configs.
Missing that Received: header is going to result in a SA that's just
horrifyingly broken, even without ALL_TRUSTED.
How have all the amavis users not noticed this earlier? Have they all
been just disabling ALL_TRUSTED, the DNSBLs, the HELO_DYNAMIC rules and
never using whitelist_from_rcvd?
I'd think someone would have at least started complaining about
whitelist_from_rcvd by now..
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 broken for them creates a
problem very visible if you search for all_trusted in the list archives.
2. "Any decent volume of mail" with "separate servers" means it's a
customized mail environment CONFIGURED BY EXPERTS :-)
I dunno. I would aim for the former, and then provide good docs for the
latter. The former generally don't read the docs, and I prefer to avoid
the mailing list noise.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
> * 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 way to run
>> SA. So why the constant comments as if this is some one-off weird
>> config?
Chris Lear wrote:
> Frankly, anyone who considers the way they do things to be "the only
> possible right way" is in danger of being Just Plain Wrong.
Obviously. Sorry, you're right about the wording. And milter isn't
what I meant to say, so much as "During SMTP". Post SMTP makes many
things more difficult.
And frankly, I was just arguing against the idea that SA in *ONLY*
post-smtp, because very few people that I know of use it that way.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Chris Lear <ch...@laculine.com>.
* 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 said to be broken if it's not proving SA
>> with the required post-SMTP view of things. Instead of patching SA, or
>> trying to "fix" it even, any milter using SA should simply DTRT (Do The
>> Right Thing): which is: add a pseudo Received: header before handing it
>> over to SA.
>
> You'all are way behind the boat. We've already patched it to support
> the undocumented requirement. That's not an issue.
>
> 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 way to run SA.
> So why the constant comments as if this is some one-off weird config?
>
Frankly, anyone who considers the way they do things to be "the only
possible right way" is in danger of being Just Plain Wrong.
[further spleen-venting withheld]
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 responsibility of the MTA itself. But
>>> a milter using SA *can* be said to be broken if it's not proving SA with
>>> the required post-SMTP view of things. Instead of patching SA, or trying
>>> to "fix" it even, any milter using SA should simply DTRT (Do The Right
>>> Thing): which is: add a pseudo Received: header before handing it over to
>>> SA.
>> You'all are way behind the boat. We've already patched it to support
>> the undocumented requirement. That's not an issue.
>>
>> 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 way to run SA.
>> So why the constant comments as if this is some one-off weird config?
>
> Exim, another MTA, adds a preliminary Received: line before processing the
> DATA ACL, which is usually where spamd is called from (this is to say that
> not all MTAs have problem calling SA during SMTP). This lets SpamAssassin
> handle varying setups in a general way, without having to pass the parameters
> of the last hop out-of-band (e.g. command-line arguments). Since obviously
> Sendmail/Postfix and the milter protocol are different, a milter that talks
> to SpamAssassin must do the part of adding that preliminary header.
>
> Just to straighten things out, are you saying that auto-detection doesn't even
> work when there is a single "Received: from remote.example.com ([w.x.y.z]) by
> my.domain.example with ESMTP id 1234-567-9" and my.domain.example resolves to
> a local interface address?
Magnus, you're still stuck on old news. amavisd-milter has been patched
to add the (undocumented) required forged Received: line. This isn't
related to that any more.
I'm saying that in reviewing the code, it is fairly clear that the code
does an adequate job but not a great job and it will fail too easily,
too often and the failure will usually be a decrement of the score -
which is the wrong way to fail (should fail with no effect on the score)
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Magnus Holmgren <ho...@lysator.liu.se>.
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 the MTA itself. But
> > a milter using SA *can* be said to be broken if it's not proving SA with
> > the required post-SMTP view of things. Instead of patching SA, or trying
> > to "fix" it even, any milter using SA should simply DTRT (Do The Right
> > Thing): which is: add a pseudo Received: header before handing it over to
> > SA.
>
> You'all are way behind the boat. We've already patched it to support
> the undocumented requirement. That's not an issue.
>
> 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 way to run SA.
> So why the constant comments as if this is some one-off weird config?
Exim, another MTA, adds a preliminary Received: line before processing the
DATA ACL, which is usually where spamd is called from (this is to say that
not all MTAs have problem calling SA during SMTP). This lets SpamAssassin
handle varying setups in a general way, without having to pass the parameters
of the last hop out-of-band (e.g. command-line arguments). Since obviously
Sendmail/Postfix and the milter protocol are different, a milter that talks
to SpamAssassin must do the part of adding that preliminary header.
Just to straighten things out, are you saying that auto-detection doesn't even
work when there is a single "Received: from remote.example.com ([w.x.y.z]) by
my.domain.example with ESMTP id 1234-567-9" and my.domain.example resolves to
a local interface address?
--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
Re: ALL_TRUSTED creating a problem
Posted by Magnus Holmgren <ho...@lysator.liu.se>.
On Thursday 19 October 2006 20:34, Jo Rhett took the opportunity to say:
> Mark wrote:
> >> -----Original Message-----
> >> From: Jo Rhett [mailto:jrhett@netconsonance.com]
> >> 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 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 way
> >> to run SA. So why the constant comments as if this is some one-off
> >> weird config?
> >
> > I reckon the focus of SA on "post-SMTP" is due to the fact that it
> > operates, by nature, post DATA phase.
>
> Huh? It operates when I ask it to. What are you trying to say here?
>
> > I agree that milters, or any other stuff done during the SMTP dialogue,
> > are a preferable first line of defense. But since full SA checks need to
> > be done post-DATA anyway, you lose much of the advantage of a milter
> > (e.g. pre-DATA phase early-outs).
>
> Huh? I don't get you. What exactly about SA *requires* that it be done
> post-SMTP...?
Not strictly post-SMTP, but after the terminating "\r\n.\r\n".
> And if that's true, why isn't there a major effort to overhaul it?
>
> > As for backscatter to the poor folks whose e-mail got forged, you're not
> > supposed to do that anyway. And LDA using SA should either silently drop
> > a message indicated as spam, or attach it with ***SPAM*** in the subject
> > or some such. But never re-open a connection to who one thought was the
> > sender, to tell them they sent you spam; that very act is spamming
> > itself.
>
> No kidding. But silently dropping FP is a major problem too. You want
> FP to bounce back to the sender as normal. Therefore SMTP-time running
> is the only sensible solution.
I like to run SA at SMTP time too, but rejecting isn't always a good idea,
e.g. when mail is forwarded from some other place, or in some cases when it
comes from a mailing list, which might unsubscribe you if you're unlucky (if
the server has crappy spam protection and the MLM doesn't probe before
unsubscribing).
--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 said, Mark seems to be missing that milters don't have to run
> pre-DATA to be beneficial.
And Yes.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 post-SMTP
> environment to get it to work properly; which is what started this
> thread to begin with).
And you have failed to make your point. There are tons of disadvantages
to running SA after you have accepted the message. Those are all
implicit advantages to running SA before you accept the message. What
possible detraction can you find?
--
Jo Rhett
Network/Software Engineer
Net Consonance
RE: ALL_TRUSTED creating a problem
Posted by "Coffey, Neal" <nc...@langeveld.com>.
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.
> 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
How many false positives have you seen with a score over, say, 20?
Personally, I've never seen one, and I'm confident enough that I never
will. So, I've got my MTA rejecting anything over that during the SMTP
transaction.
Personally, I do see this as a "whole lot of advantage." One is that it
doesn't take up space in the queues or in my mailbox. Two is that I
don't have to look at it. (Spam that gets to my inbox -- tagged or not
-- is still spam that got to my inbox.) And perhaps most importantly is
that, if there ever is a false positive, the sender will get a notice
from THEIR server that the message was rejected by MY server. This
simultaneously eliminates backscatter (since I don't have to send any
bounce messages) and yet *still* allows legitimate senders to be
notified of FPs.
Of course, stopping spam before you even *get* to the DATA stage is
better. But this nicely takes care of most things that get past the
other defenses. I said in an earlier message that, in the last 7 days,
SpamAssassin here scanned over 119,500 messages. Of those, just over
58% of the messages (69,562) were stopped during the SMTP transaction.
That's just over 69,500 junk messages that didn't make it to my users.
RE: ALL_TRUSTED creating a problem
Posted by Mark <ad...@asarian-host.net>.
> -----Original Message-----
> From: Coffey, Neal [mailto:ncoffey@langeveld.com]
> 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 have to run
> pre-DATA to be beneficial. To take another useful example, using
> ClamAV's milter prevents your mail server from having to accept
> responsibility for delivery of a virus. But it, too, needs to run
> post-DATA.
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 post-SMTP
environment to get it to work properly; which is what started this
thread to begin with).
- Mark
RE: ALL_TRUSTED creating a problem
Posted by "Coffey, Neal" <nc...@langeveld.com>.
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't have to run
pre-DATA to be beneficial. To take another useful example, using
ClamAV's milter prevents your mail server from having to accept
responsibility for delivery of a virus. But it, too, needs to run
post-DATA.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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/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'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 in the logs that are due to load on the machine.
>> (2-3 timeouts in the logs per hour, usually due to icmp unreachables
>> from our replies to them)
>>
>> Richard Frovarp wrote:
>> > Large array of mail servers? What does that mean exactly? We have a
>>> small number of machines that scan mail and pass it on to a slightly
>>> larger number of mail storage machines. However, each of our scanning
>>> machines handles 150,000 to 200,000 messages per day, with our
>>> legitimate traffic occurring between 8:00 and 15:00 local, which is
>>> probably typical of most places. We use MailScanner with average scan
>>> times of 7 seconds per message. Even at that, when we are hit hard
>>> (ten of thousands of users is a pretty big target) we can have a
>>> large number of messages waiting to be scanned. Since we aren't
>>> holding SMTP connections open, we can keep accepting mail. I suppose
>>> if there were no available SMTP processes to accept, most servers
>>> would attempt a redeliver, so no harm no foul.
>>>
>>> Our 200,000/server is no where near the 500,000 reported on the list
>>> earlier, but it is a respectable number. Oh, and automatic
>>> ALL_TRUSTED works for us.
>>
>>
>
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
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'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 in the logs that are due to load on the machine.
> (2-3 timeouts in the logs per hour, usually due to icmp unreachables
> from our replies to them)
>
> Richard Frovarp wrote:
> > Large array of mail servers? What does that mean exactly? We have a
>> small number of machines that scan mail and pass it on to a slightly
>> larger number of mail storage machines. However, each of our scanning
>> machines handles 150,000 to 200,000 messages per day, with our
>> legitimate traffic occurring between 8:00 and 15:00 local, which is
>> probably typical of most places. We use MailScanner with average scan
>> times of 7 seconds per message. Even at that, when we are hit hard
>> (ten of thousands of users is a pretty big target) we can have a
>> large number of messages waiting to be scanned. Since we aren't
>> holding SMTP connections open, we can keep accepting mail. I suppose
>> if there were no available SMTP processes to accept, most servers
>> would attempt a redeliver, so no harm no foul.
>>
>> Our 200,000/server is no where near the 500,000 reported on the list
>> earlier, but it is a respectable number. Oh, and automatic
>> ALL_TRUSTED works for us.
>
>
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 in the logs that are due to load on the machine. (2-3
timeouts in the logs per hour, usually due to icmp unreachables from our
replies to them)
Richard Frovarp wrote:
> Large array of mail servers? What does that mean exactly? We have a
> small number of machines that scan mail and pass it on to a slightly
> larger number of mail storage machines. However, each of our scanning
> machines handles 150,000 to 200,000 messages per day, with our
> legitimate traffic occurring between 8:00 and 15:00 local, which is
> probably typical of most places. We use MailScanner with average scan
> times of 7 seconds per message. Even at that, when we are hit hard (ten
> of thousands of users is a pretty big target) we can have a large number
> of messages waiting to be scanned. Since we aren't holding SMTP
> connections open, we can keep accepting mail. I suppose if there were no
> available SMTP processes to accept, most servers would attempt a
> redeliver, so no harm no foul.
>
> Our 200,000/server is no where near the 500,000 reported on the list
> earlier, but it is a respectable number. Oh, and automatic ALL_TRUSTED
> works for us.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
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 system other
>> than milters for SA.
>
> Before I respond, let's clarify context. Do you work with a company
> that has a large array of mail servers? I do, and I've built more
> than a dozen in the last 4 years.
>
> And everything you're saying disagrees with all of my experience.
>
Large array of mail servers? What does that mean exactly? We have a
small number of machines that scan mail and pass it on to a slightly
larger number of mail storage machines. However, each of our scanning
machines handles 150,000 to 200,000 messages per day, with our
legitimate traffic occurring between 8:00 and 15:00 local, which is
probably typical of most places. We use MailScanner with average scan
times of 7 seconds per message. Even at that, when we are hit hard (ten
of thousands of users is a pretty big target) we can have a large number
of messages waiting to be scanned. Since we aren't holding SMTP
connections open, we can keep accepting mail. I suppose if there were no
available SMTP processes to accept, most servers would attempt a
redeliver, so no harm no foul.
Our 200,000/server is no where near the 500,000 reported on the list
earlier, but it is a respectable number. Oh, and automatic ALL_TRUSTED
works for us.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 than
> milters for SA.
Before I respond, let's clarify context. Do you work with a company
that has a large array of mail servers? I do, and I've built more than
a dozen in the last 4 years.
And everything you're saying disagrees with all of my experience.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
>
> > 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 that aren't
> in the list. Scan times average 9 seconds on ancient hardware.
>
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 than
milters for SA.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 well do it post-SMTP then (which
No, you might as well not. If you reject post DATA, then the right
behind happens. If you accept the message, then you have to either
discard a potential FP or create backscatter. You *should not* do it
post-smtp if you can possibly avoid it!
> is what I said: that you then lose much of the advantage of porting it to
> a milter environment; save the ability to reject during the SMTP
> dialogue).
Again, what advantage is lost? Advantage is only gained...
> Not interactive? It's full well interactive; the whole process is sending
> command codes, and waiting for reply codes (and acting based upon that
> communication). A timeout in that session is undesireable.
Look up interactive. It's a batch process. Nobody is watching it and
waiting unless they're using telnet to deliver mail by hand.
> 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 that aren't in
the list. Scan times average 9 seconds on ancient hardware.
--
Jo Rhett
Network/Software Engineer
Net Consonance
RE: ALL_TRUSTED creating a problem
Posted by Mark <ad...@asarian-host.net>.
> -----Original Message-----
> From: Jo Rhett [mailto:jrhett@netconsonance.com]
> 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" is due to the fact that it
> > operates, by nature, post DATA phase.
> Huh? It operates when I ask it to. What are you trying to say here?
Exactly what I said: SA works on examining a message (headers + body);
that makes it, per definition, a post-DATA phase operation.
> > I agree that milters, or any other stuff done during the SMTP
> > dialogue, are a preferable first line of defense. But since full SA
> > checks need to be done post-DATA anyway, you lose much of the
> > advantage of a milter (e.g. pre-DATA phase early-outs).
> Huh? I don't get you. What exactly about SA *requires* that it be
> done 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 well do it post-SMTP then (which
is what I said: that you then lose much of the advantage of porting it to
a milter environment; save the ability to reject during the SMTP
dialogue).
> And if that's true, why isn't there a major effort to overhaul it?
spamd/spamc + spamassassin have always been post-SMTP operations. Only
later a milter was written, too.
> > A milter gives you the advantage of REJECT-ing during the SMTP
> > dialogue (which really is a boon). But unless you close the connection
> > first (thus losing the aforementioned advantage), SA checks can be
> > quite time-consuming, especially with much RBL stuff done. Hence,
> > these days I choose to let the LDA do SA checks. That way a spamd
> > processcan chew away for a whole minute or so (an eternity within an
> > SMTP dialogue), without anything being at risk of timing out.
> Perhaps, but SMTP isn't interactive so who cares?
Not interactive? It's full well interactive; the whole process is sending
command codes, and waiting for reply codes (and acting based upon that
communication). A timeout in that session is undesireable.
> And hell, I'm running SA on a very ancient 1g system and scan times are
> only 9-12 seconds. You'd have to be running on a 486 or on the other
> side of a modem to see 1 minute scan times. (and I'm running the entire
> set of SARE rulesets and few dozen others as well).
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.
- Mark
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
Mark wrote:
>> -----Original Message-----
>> From: Jo Rhett [mailto:jrhett@netconsonance.com]
>> 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 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 way
>> to run SA. So why the constant comments as if this is some one-off
>> weird config?
>
> I reckon the focus of SA on "post-SMTP" is due to the fact that it
> operates, by nature, post DATA phase.
Huh? It operates when I ask it to. What are you trying to say here?
> I agree that milters, or any other stuff done during the SMTP dialogue,
> are a preferable first line of defense. But since full SA checks need to
> be done post-DATA anyway, you lose much of the advantage of a milter (e.g.
> pre-DATA phase early-outs).
Huh? I don't get you. What exactly about SA *requires* that it be done
post-SMTP...?
And if that's true, why isn't there a major effort to overhaul it?
> A milter gives you the advantage of REJECT-ing during the SMTP dialogue
> (which really is a boon). But unless you close the connection first (thus
> losing the aforementioned advantage), SA checks can be quite
> time-consuming, especially with much RBL stuff done. Hence, these days I
> choose to let the LDA do SA checks. That way a spamd process can chew away
> for a whole minute or so (an eternity within an SMTP dialogue), without
> anything being at risk of timing out.
Perhaps, but SMTP isn't interactive so who cares? And hell, I'm running
SA on a very ancient 1g system and scan times are only 9-12 seconds.
You'd have to be running on a 486 or on the other side of a modem to see
1 minute scan times. (and I'm running the entire set of SARE rulesets
and few dozen others as well)
> As for backscatter to the poor folks whose e-mail got forged, you're not
> supposed to do that anyway. And LDA using SA should either silently drop a
> message indicated as spam, or attach it with ***SPAM*** in the subject or
> some such. But never re-open a connection to who one thought was the
> sender, to tell them they sent you spam; that very act is spamming itself.
No kidding. But silently dropping FP is a major problem too. You want
FP to bounce back to the sender as normal. Therefore SMTP-time running
is the only sensible solution.
--
Jo Rhett
Network/Software Engineer
Net Consonance
RE: ALL_TRUSTED creating a problem
Posted by Mark <ad...@asarian-host.net>.
> -----Original Message-----
> From: Jo Rhett [mailto:jrhett@netconsonance.com]
> 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 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 way
> to run SA. So why the constant comments as if this is some one-off
> weird config?
I reckon the focus of SA on "post-SMTP" is due to the fact that it
operates, by nature, post DATA phase.
I agree that milters, or any other stuff done during the SMTP dialogue,
are a preferable first line of defense. But since full SA checks need to
be done post-DATA anyway, you lose much of the advantage of a milter (e.g.
pre-DATA phase early-outs).
A milter gives you the advantage of REJECT-ing during the SMTP dialogue
(which really is a boon). But unless you close the connection first (thus
losing the aforementioned advantage), SA checks can be quite
time-consuming, especially with much RBL stuff done. Hence, these days I
choose to let the LDA do SA checks. That way a spamd process can chew away
for a whole minute or so (an eternity within an SMTP dialogue), without
anything being at risk of timing out.
As for backscatter to the poor folks whose e-mail got forged, you're not
supposed to do that anyway. And LDA using SA should either silently drop a
message indicated as spam, or attach it with ***SPAM*** in the subject or
some such. But never re-open a connection to who one thought was the
sender, to tell them they sent you spam; that very act is spamming itself.
- Mark
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 SA
> with the required post-SMTP view of things. Instead of patching SA, or
> trying to "fix" it even, any milter using SA should simply DTRT (Do The
> Right Thing): which is: add a pseudo Received: header before handing it
> over to SA.
You'all are way behind the boat. We've already patched it to support
the undocumented requirement. That's not an issue.
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 way to run SA.
So why the constant comments as if this is some one-off weird config?
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Graham Murray <gr...@gmurray.org.uk>.
Mark <ad...@asarian-host.net> 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 be broken if it's not proving SA
> with the required post-SMTP view of things.
Some milters, such as mimedefang, do the 'right thing' and generate the
local Received header as though SA had been called post-SMTP rather
than during the SMTP session.
RE: ALL_TRUSTED creating a problem
Posted by Mark <ad...@asarian-host.net>.
> -----Original Message-----
> From: Matt Kettler [mailto:mkettler_sa@verizon.net]
> 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 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 have to hack up
> their milters to make them feed SA properly. Most milters that handle
> SA already do this for you, right out of the box.
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 SA
with the required post-SMTP view of things. Instead of patching SA, or
trying to "fix" it even, any milter using SA should simply DTRT (Do The
Right Thing): which is: add a pseudo Received: header before handing it
over to SA.
- Mark
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 lot of folks tend to get the impression I'm trying to make
them feel stupid.. I'm really not. I'm just kinda short with my words
sometimes.) Any adamance on my part is just me trying to
semi-forcefully help. I'm not trying to brow-beat.
>
> 1. Assuming that the Received headers are sane ... isn't.
True, but assuming your own received headers are sane, is. I mean, if
you can't trust yourself to add a valid Received header...
>
> 2. Decrementing the spam score is not failing gracefully.
True. But the primary issue is that SA can't detect this as a failure.
The input you've given it is valid for a different kind of network. SA
is operating properly assuming that common, ordinary network configuration.
>
> 3. And just because someone is using pig blatters to communicate with
> SpamD somewhere, someplace, doesn't mean that it's a *normal* config.
> If autodetection works great for the one user communicating with pig
> bladders but fails miserably for out of the box linux/freebsd
> installs, then I think you've missed your target audience.
I hate to say it, but those examples ARE a normal config, not some rare
esoteric expert option involving animal body parts.
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.
>
> Autodetection should work out of the box for out of the box installs.
And auto detection DOES work correctly for most out-of-the-box
installs.. AFAIK it works beautifully in MailScanner, procmail,
qmail-scanner, mimedefang, milter-spamc... I can only attest to personal
experience with procmail and MailScanner.
Let's face it, there are thousands upon thousands of SA users out
there. If this problem was so common that most "out of the box"
installs broke, we'd hear a lot more about it on this list. ALL_TRUSTED
has been around since SA 3.0.0 was released two years ago in September 2004.
AFAIK There's really only 3 cases where autodetection fails:
1) The hostname in the "by" clause of your outside-most MTA doesn't
resolve to a public IP. (This is the necessary caveat.. can't work for
both cases here)
2) some admin decided to customize their MTA and created an invalid
Received: format that SA can't parse because it's never been seen
anywhere else in the work before. (my favorite is the Received: with no
"by" clause.. )
3) There's a missing Received: header.
And none of those are really fixable without breaking another network
configuration that is equally as common as the one that's broken
Also, you're the first person I've ever heard of with problem 3. Ever.
I've been on this list since 2002 and it's completely new to me. Never
heard of anyone with this problem before. Honestly.
1) is common, because about 1/4 of the installs out there have a NATed
MTA, and about 3/4 don't. But it's not really a fixable case, there's
too little information to disambiguate the two.
2) I've seen before, but is pretty rare.. usually the result of someone
who's using qmail went overboard on the customizing.
Also, all three break so many other things in SA, ALL_TRUSTED misfires
is actually a bit of a good indicator flag that things are amiss.
Unfortunately, interpreting that requires detailed knowledge of your
network that SA doesn't have..
> Custom installations, and most especially people creating appliances
> out of this, are managed by Experts who have a clue.
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 have to hack up their milters to
make them feed SA properly. Most milters that handle SA already do this
for you, right out of the box.
>
> Make autodetection work out of the box for the clueless people using
> it out of the box. That's your real target audience.
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.
It's been suggested before that SA should just remove the autodetection
code and force the user to always manually declare trusted_networks and
internal_networks and fail miserably if they don't. That's about the
only "fix" that works universally, and I'm not entirely against it myself.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 failing gracefully.
3. And just because someone is using pig blatters to communicate with
SpamD somewhere, someplace, doesn't mean that it's a *normal*
config. If autodetection works great for the one user communicating
with pig bladders but fails miserably for out of the box linux/
freebsd installs, then I think you've missed your target audience.
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.
Make autodetection work out of the box for the clueless people using
it out of the box. That's your real target audience.
On Oct 17, 2006, at 10:53 PM, Matt Kettler wrote:
> 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.
>>>
>>> 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 SA supposed to do?
>>
>> Um... subtract points from the score as a backup approach? :-(
>>
>> Seriously, if it is confused then 0 points. But *NEVER* trust
>> something because it was confused.
> Erm, just exactly how can it tell this? That's a big part of the
> problem. SA doesn't have any way of detecting this case. There's no
> magic "Hey, a Received header is missing!" flag in the message.
>
> The reason SA gets confused is it has no other options. It goes with
> what's in the headers. There's no other information to work from.
>
> Keep in mind that spamd could be running on a different machine
> than the
> MTA is (commonly done for load handling in larger sites). Because of
> this SA can't just look at the IPs of the local interfaces and compare
> them to the Received: headers. It's quite possible for one spamd
> server
> to scan mail for several different MTA servers with different domain
> names, so it can't even compare the domain part of localhost
> against the
> Received: headers.
>
> Think about a hosting provider (hostinprovider.com) that provides
> services to "customer1.com" and "customer2.com". The hosting provideer
> actually has a dedicated spamd box set up, and allows any of their
> customers to use it to scan mail. Think about how
> "spamdbox.hostingprovider.com" views mail being fed to it from three
> MTAs: "mta.hostingprovider.com", "mta.customer1.com" and
> "mta.customer2.com". By comparing domains it could figure out the
> first
> one.. but it needs to correctly trust the other two as well.
>
> There's just no way for SA to detect this without breaking someone
> else's perfectly valid network.
>
> Now do you understand why it's such an absurd suggestion? Your broken
> input actually looks like perfectly valid input from a different
> kind of
> network configuration.
>
> SA's not just doing something stupid because it's confused. It's doing
> something stupid because it looks perfectly correct and normal.
>
>> Does your bank give out cash from your bank account when
>> confused? If
>> so, let me know where you bank...
> True, but again, how does SA know it's confused to avoid this? If my
> bank was sufficiently confused they damn well may give out cash.
>
> If an imposter showed up with a drivers license claiming to be me,
> wrote a check to himself from my account.. yeah, they'd cash it if the
> forgery was good enough.
>
> You've done a stellar job of convincing SA it's actually acting on
> behalf of another network. An excellent forgery.
>
>>
>> But why does it break by subtracting points from the score? There's
>> no logic in that.
> I'd agree.. Again, how does SA know it's confused to avoid this?
>>
>> Nothing. Nothing or "0" is a good response. "-4.5" as I've seen on
>> some messages is *NEVER* an appropriate response to confusion.
> I'd agree.. Again, how does SA know it's confused to avoid this?
>>
>> Fine. Misbehave. Reject the message. But don't subtract points
>> from
>> the score.
> SA can't reject the message. It's a mail filter. In it's normal
> aplication a message goes in one side and out the other. It has no
> ability to "fail", or otherwise return any kind of error. All it
> can do
> is modify the content of the message.
>
> And again, how does SA know it's confused to even detect this, in
> order
> to try to cause some kind of rejection that SA itself isn't capable
> of?
>
> Stop thinking about your specific implementation. SA has a much
> broader
> range of implementations it has to support and work correctly for.
>>
>>
>> Ah, but the message has not yet been received. So adding a Received:
>> header is lying to SA. We're waiting for SA to pass judgement on the
>> mail before we accept it. Read the Milter spec.
> Yes, but as others have pointed out, SA isn't a milter, it's not
> designed to be a milter, and does not expect milter-spec input. It is
> designed to be called in a generic way by tools in the mail chain
> after
> delivery. As such it expects post-receipt input.
>
> SA can be adapted to be used by milters, and a billion other
> things, but
> don't expect that to change what SA needs for input.
>
> I could probably adapt SA to be fed from a squid proxy to scan web
> page
> contents, but I don't think I'd start complaining about it not
> understanding http headers and not conforming to squid's interfaces.
>>
>>> The problem isn't SA breaking, it's the fact that a RFC required
>>> piece
>>> of information is missing from the message.
>>
>> You really are off your rocker without a clue. Sorry, I thought I
>> was
>> chatting with someone who grokked reality.
> No, it is in fact RFC required for the kind of input SA expects to
> see.
> SA is not a milter.
>
> I do grok reality. Quite well. I see a much larger universe than just
> your one broken milter. Perhaps you should grok more than your own
> project sometime.
>>
>>> It's complete insanity to try to expect SA to behave properly
>>> without a
>>> local Received: header.
>>
>> I never said that I expect SA to "behave properly". I said I wanted
>> it to not let more spam through. Failing gracefully is the right
>> response, and failing gracefully in this context is by not altering
>> the spam score.
> So, having all your RBL checks not work doesn't count as "letting more
> spam through"?
>
> After all, without that Received: header, SA can't do any RBL
> checks on
> the host delivering the mail. Unless of course the delivering system
> already added its own, but in the case of spam, it's probably not
> there,
> or if it is it's not accurate.
>
>
>
>
>
>
>
--
Jo Rhett
Senior Network Engineer
Network Consonance
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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.
>>
>> 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 SA supposed to do?
>
> Um... subtract points from the score as a backup approach? :-(
>
> Seriously, if it is confused then 0 points. But *NEVER* trust
> something because it was confused.
Erm, just exactly how can it tell this? That's a big part of the
problem. SA doesn't have any way of detecting this case. There's no
magic "Hey, a Received header is missing!" flag in the message.
The reason SA gets confused is it has no other options. It goes with
what's in the headers. There's no other information to work from.
Keep in mind that spamd could be running on a different machine than the
MTA is (commonly done for load handling in larger sites). Because of
this SA can't just look at the IPs of the local interfaces and compare
them to the Received: headers. It's quite possible for one spamd server
to scan mail for several different MTA servers with different domain
names, so it can't even compare the domain part of localhost against the
Received: headers.
Think about a hosting provider (hostinprovider.com) that provides
services to "customer1.com" and "customer2.com". The hosting provideer
actually has a dedicated spamd box set up, and allows any of their
customers to use it to scan mail. Think about how
"spamdbox.hostingprovider.com" views mail being fed to it from three
MTAs: "mta.hostingprovider.com", "mta.customer1.com" and
"mta.customer2.com". By comparing domains it could figure out the first
one.. but it needs to correctly trust the other two as well.
There's just no way for SA to detect this without breaking someone
else's perfectly valid network.
Now do you understand why it's such an absurd suggestion? Your broken
input actually looks like perfectly valid input from a different kind of
network configuration.
SA's not just doing something stupid because it's confused. It's doing
something stupid because it looks perfectly correct and normal.
> Does your bank give out cash from your bank account when confused? If
> so, let me know where you bank...
True, but again, how does SA know it's confused to avoid this? If my
bank was sufficiently confused they damn well may give out cash.
If an imposter showed up with a drivers license claiming to be me,
wrote a check to himself from my account.. yeah, they'd cash it if the
forgery was good enough.
You've done a stellar job of convincing SA it's actually acting on
behalf of another network. An excellent forgery.
>
> But why does it break by subtracting points from the score? There's
> no logic in that.
I'd agree.. Again, how does SA know it's confused to avoid this?
>
> Nothing. Nothing or "0" is a good response. "-4.5" as I've seen on
> some messages is *NEVER* an appropriate response to confusion.
I'd agree.. Again, how does SA know it's confused to avoid this?
>
> Fine. Misbehave. Reject the message. But don't subtract points from
> the score.
SA can't reject the message. It's a mail filter. In it's normal
aplication a message goes in one side and out the other. It has no
ability to "fail", or otherwise return any kind of error. All it can do
is modify the content of the message.
And again, how does SA know it's confused to even detect this, in order
to try to cause some kind of rejection that SA itself isn't capable of?
Stop thinking about your specific implementation. SA has a much broader
range of implementations it has to support and work correctly for.
>
>
> Ah, but the message has not yet been received. So adding a Received:
> header is lying to SA. We're waiting for SA to pass judgement on the
> mail before we accept it. Read the Milter spec.
Yes, but as others have pointed out, SA isn't a milter, it's not
designed to be a milter, and does not expect milter-spec input. It is
designed to be called in a generic way by tools in the mail chain after
delivery. As such it expects post-receipt input.
SA can be adapted to be used by milters, and a billion other things, but
don't expect that to change what SA needs for input.
I could probably adapt SA to be fed from a squid proxy to scan web page
contents, but I don't think I'd start complaining about it not
understanding http headers and not conforming to squid's interfaces.
>
>> The problem isn't SA breaking, it's the fact that a RFC required piece
>> of information is missing from the message.
>
> You really are off your rocker without a clue. Sorry, I thought I was
> chatting with someone who grokked reality.
No, it is in fact RFC required for the kind of input SA expects to see.
SA is not a milter.
I do grok reality. Quite well. I see a much larger universe than just
your one broken milter. Perhaps you should grok more than your own
project sometime.
>
>> It's complete insanity to try to expect SA to behave properly without a
>> local Received: header.
>
> I never said that I expect SA to "behave properly". I said I wanted
> it to not let more spam through. Failing gracefully is the right
> response, and failing gracefully in this context is by not altering
> the spam score.
So, having all your RBL checks not work doesn't count as "letting more
spam through"?
After all, without that Received: header, SA can't do any RBL checks on
the host delivering the mail. Unless of course the delivering system
already added its own, but in the case of spam, it's probably not there,
or if it is it's not accurate.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
> 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 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 SA supposed to do?
Um... subtract points from the score as a backup approach? :-(
Seriously, if it is confused then 0 points. But *NEVER* trust
something because it was confused.
Does your bank give out cash from your bank account when confused?
If so, let me know where you bank...
> Is SA supposed to know that the message magically appeared in your
> mail
> systems despite never being recorded as Received by them?
>
> What should SA do if a message is being direct-delivered and has no
> existing Recived: headers in it? Where should it decide the message
> came
> from?
>
> Look, here's a message that got here from nowhere. It wasn't even
> sent
> by the localhost, it just spontaneously appeared in the mail system.
> Nobody sent it, nobody Received it, it just appeared here.
>
> This whole scenario is ridiculous.. OF COURSE spamassassin will break
> when you feed it this.
But why does it break by subtracting points from the score? There's
no logic in that.
> It can't possibly even TRY to make sense of it because required
> records
> are missing. How could SA behave properly in this case? What should
> it do?
Nothing. Nothing or "0" is a good response. "-4.5" as I've seen on
some messages is *NEVER* an appropriate response to confusion.
> Should SA inherently assume that some magic exists where messages can
> magically poof from one mail queue to the next without ever being
> transmitted over a mail transport protocol?
>
> Should it assume hackers have taken over your server and are directly
> inserting messages into your system without going through your MTA
> (ie:
> writing queue files directly?)
>
> Or should it just misbehave so hopefully the admin realizes he
> needs to
> FIX a BROKEN SERVER.
Fine. Misbehave. Reject the message. But don't subtract points
from the score.
> YES IT DOES! Sa makes basic assumptions about REALITY. Messages get
> transmitted over the internet between mailservers. Durring this
> process,
> Received: headers are added as per RFC requirements for SMTP. SA
> depends
> on Received: those records generated by your own network. When your
> network is broken, SA becomes broken, but why would you ever not add a
> Received: header?
Ah, but the message has not yet been received. So adding a Received:
header is lying to SA. We're waiting for SA to pass judgement on the
mail before we accept it. Read the Milter spec.
> The problem isn't SA breaking, it's the fact that a RFC required
> piece
> of information is missing from the message.
You really are off your rocker without a clue. Sorry, I thought I
was chatting with someone who grokked reality.
> It's complete insanity to try to expect SA to behave properly
> without a
> local Received: header.
I never said that I expect SA to "behave properly". I said I wanted
it to not let more spam through. Failing gracefully is the right
response, and failing gracefully in this context is by not altering
the spam score.
--
Jo Rhett
Senior Network Engineer
Network Consonance
Re: ALL_TRUSTED creating a problem
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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 you have one already? If you
don't, it's possible it's working fine with auto detection (although I
recommend you set it manually anyway). If you do have such a line and
it doesn't contain the IP of the MX then it's not really configured
right (although it could still work with there not being any additional
trusted relays... but I won't get into why, it's not important).
> How should it specifically look again please?
Assuming this is for abbacomm.net...
trusted_networks 206.63.24.6
> ...and is it supposed to have the loopback address in it too?
Sure, never hurts... no point in not trusting the local machine.
trusted_networks 206.63.24.6 127.0.0.1
> Please clarify as some time ago I some posts from Pedersen and O'Shea
> talking back and forth about it a little...
Either the above config or the auto detection (no config) should work
for you. Although, with the auto config you'll end up trusting
206.63.0.0/16 which is just a little more than the /22 that it appears
you've got of that.
Daryl
RE: ALL_TRUSTED creating a problem
Posted by R Lists06 <li...@abbacomm.net>.
>
> 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 SA supposed to do?
>
> Is SA supposed to know that the message magically appeared in your mail
> systems despite never being recorded as Received by them?
>
> What should SA do if a message is being direct-delivered and has no
> existing Recived: headers in it? Where should it decide the message came
> from?
>
> Look, here's a message that got here from nowhere. It wasn't even sent
> by the localhost, it just spontaneously appeared in the mail system.
> Nobody sent it, nobody Received it, it just appeared here.
>
> This whole scenario is ridiculous.. OF COURSE spamassassin will break
> when you feed it this.
>
> It can't possibly even TRY to make sense of it because required records
> are missing. How could SA behave properly in this case? What should it do?
>
> Should SA inherently assume that some magic exists where messages can
> magically poof from one mail queue to the next without ever being
> transmitted over a mail transport protocol?
>
> Should it assume hackers have taken over your server and are directly
> inserting messages into your system without going through your MTA (ie:
> writing queue files directly?)
>
> Or should it just misbehave so hopefully the admin realizes he needs to
> FIX a BROKEN SERVER.
>
>
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?
How should it specifically look again please?
...and is it supposed to have the loopback address in it too?
Please clarify as some time ago I some posts from Pedersen and O'Shea
talking back and forth about it a little...
Thanks in advance...
- rh
--
Robert - Abba Communications
Computer & Internet Services
(509) 624-7159 - www.abbacomm.net
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 code will start working.
>>>>
>>>> After all, if you haven't Received: the message yet, how'd it get
>>>> to SA?
>>>> Do your really expect SA to work on a message that doesn't even appear
>>>> to have been delivered to your domain yet?
>
>> Jo Rhett wrote:
>>> As mentioned in my previous message, I have dozens of messages here
>>> that have as many as 12 received headers.
>
>> Yes, but none are LOCAL.
>
> RIGHT. So why are they Trusted?
>
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.
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 SA supposed to do?
Is SA supposed to know that the message magically appeared in your mail
systems despite never being recorded as Received by them?
What should SA do if a message is being direct-delivered and has no
existing Recived: headers in it? Where should it decide the message came
from?
Look, here's a message that got here from nowhere. It wasn't even sent
by the localhost, it just spontaneously appeared in the mail system.
Nobody sent it, nobody Received it, it just appeared here.
This whole scenario is ridiculous.. OF COURSE spamassassin will break
when you feed it this.
It can't possibly even TRY to make sense of it because required records
are missing. How could SA behave properly in this case? What should it do?
Should SA inherently assume that some magic exists where messages can
magically poof from one mail queue to the next without ever being
transmitted over a mail transport protocol?
Should it assume hackers have taken over your server and are directly
inserting messages into your system without going through your MTA (ie:
writing queue files directly?)
Or should it just misbehave so hopefully the admin realizes he needs to
FIX a BROKEN SERVER.
>
> Does this matter?
YES IT DOES! Sa makes basic assumptions about REALITY. Messages get
transmitted over the internet between mailservers. Durring this process,
Received: headers are added as per RFC requirements for SMTP. SA depends
on Received: those records generated by your own network. When your
network is broken, SA becomes broken, but why would you ever not add a
Received: header?
The problem isn't SA breaking, it's the fact that a RFC required piece
of information is missing from the message.
> SA *IS* scanning it, and for unknown reasons assigning the random
> remote host as trusted. That is *BROKEN*.
No, trying to pretend the message hasn't arrived at your server when it
has is BROKEN. Look, I have this message, but it hasn't gotten here
yet.. What???
Look, I agree, the trust path code breaks when you give it GARBAGE
NONSENSE as input. Fine. Garbage in, Garbage out.
It's complete insanity to try to expect SA to behave properly without a
local Received: header.
And the trust path isn't the only thing that breaks. It's just one of
DOZENS of problems. All your RBL checks, SPF checks, DomainKeys,
HELO_DYNAMIC rules, whitelist_from_rcvd, they're all going to be
completely and hopelessly broken. Why? Because SA doesn't know how the
message got to your network, there's no record of it. It's missing.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 than I thought.
> As stated in the documentation, SA *requires* you to at least forge a
> received header for the local relay before passing the mail to SA. This
> is the only way that SA can gather data about the connection, the
> envelope, etc.
Really? Show me the docs. I may have overlooked them.
> If you were to be doing what is *required*, SA would see this forged
> received header, assume that it is the local trusted server (like the
> docs says it will do). It'll then compare the IP addr info from the
> first forged received header to the one supplied by the remote host and
> see that it is not trusted and won't trust it -- just like you're
> bitching that it's not doing because you're not providing the correct
> input to SA.
SA should do the intelligent thing, and determine the local network from
system calls. It's not like it's written in C -- perl deals with the
inconsistencies of system implementations for you.
Without checking the local interface, how do you know what the network
is? Are you assuming that my 64.x address is a class-A network?
Seriously, auto detection can't possibly work if you're not checking the
local interface addresses.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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, and for unknown reasons
> assigning the random remote host as trusted. That is *BROKEN*.
As I've said before, YES, it does matter.
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.
As stated in the documentation, SA *requires* you to at least forge a
received header for the local relay before passing the mail to SA. This
is the only way that SA can gather data about the connection, the
envelope, etc.
If you were to be doing what is *required*, SA would see this forged
received header, assume that it is the local trusted server (like the
docs says it will do). It'll then compare the IP addr info from the
first forged received header to the one supplied by the remote host and
see that it is not trusted and won't trust it -- just like you're
bitching that it's not doing because you're not providing the correct
input to SA.
>>> What kind of logic says that it should trust a remote IP from a very
>>> random source that isn't authenticated by a local header?
>> Because it's equally absurd to assume that the most recent header isn't
>> local.
>
> I'm sorry, but phrases like "what are you babbling about" keep floating
> to the top of my mind when I read your response. (sorry, need more
> coffee) Your logic appears to be backwards -- if the results are
> confusing, assume trusted?
The application's documentation requires you to ensure that the first
received header it sees is local. It'd be awfully stupid if we required
the first header was local and then assumed it was remote just for the
hell of it.
The only flawed logic I see here is you expecting incorrect input to
lead to correct output (not that the output is wrong given the input, of
course).
> Slow down and explain to me exactly why the most recent header having a
> remote address in it should be trusted?
I've already told you this before, and again above. You are required to
ensure that the most recent received header is local. Maybe we're at
fault assuming that the user is going to call the application according
to the documentation.
> Seriously, I can't figure out what you think should be happening. None
> of these sites are local. None of them are even in the same /8 network.
> Why does autodetection decide that they are trusted?
I've only seen examples from you that include only one received header
that was actually presented to SA (which thus must be assumed to be
local), so I have no idea what you're saying isn't working here.
Anyway... that's it from me, at least until you start calling SA
correctly. Until you fix your milter and can demonstrate otherwise I
maintain that the auto-detection works as documented.
Daryl
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 you haven't Received: the message yet, how'd it get to SA?
>>> Do your really expect SA to work on a message that doesn't even appear
>>> to have been delivered to your domain yet?
> Jo Rhett wrote:
>> As mentioned in my previous message, I have dozens of messages here
>> that have as many as 12 received headers.
> Yes, but none are LOCAL.
RIGHT. So why are they Trusted?
>> 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, and for unknown reasons
assigning the random remote host as trusted. That is *BROKEN*.
>> What kind of logic says that it should trust a remote IP from a very
>> random source that isn't authenticated by a local header?
> Because it's equally absurd to assume that the most recent header isn't
> local.
I'm sorry, but phrases like "what are you babbling about" keep floating
to the top of my mind when I read your response. (sorry, need more
coffee) Your logic appears to be backwards -- if the results are
confusing, assume trusted?
Slow down and explain to me exactly why the most recent header having a
remote address in it should be trusted?
Seriously, I can't figure out what you think should be happening. None
of these sites are local. None of them are even in the same /8 network.
Why does autodetection decide that they are trusted?
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 ignore NAT. It's not your problem, I get it.
>>
>> 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 you haven't Received: the message yet, how'd it get to SA?
>> Do your really expect SA to work on a message that doesn't even appear
>> to have been delivered to your domain yet?
>
> As mentioned in my previous message, I have dozens of messages here
> that have as many as 12 received headers.
Yes, but none are LOCAL.
> 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?
> What kind of logic says that it should trust a remote IP from a very
> random source that isn't authenticated by a local header?
Because it's equally absurd to assume that the most recent header isn't
local.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 it.
>
> 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 you haven't Received: the message yet, how'd it get to SA?
> Do your really expect SA to work on a message that doesn't even appear
> to have been delivered to your domain yet?
As mentioned in my previous message, I have dozens of messages here that
have as many as 12 received headers. So perhaps I didn't get the
Received header that will be added by this host. What kind of logic
says that it should trust a remote IP from a very random source that
isn't authenticated by a local header?
Here's one from last week, before I disabled auto detection.
Received: from elasmtp-spurfowl.atl.sa.earthlink.net
(elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by
triceratops.lizardarts.com (8.13.8/8.13.8) with ESMTP id k972fkHF066354
for <jr...@lizardarts.com>; Fri, 6 Oct 2006 19:41:46 -0700 (PDT)
(envelope-from mjrhett@earthlink.net)
Received: from [66.32.20.12] (helo=[66.32.20.12]) by
elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id
1GW28H-0003Bs-QM for jrhett@lizardarts.com; Fri, 06 Oct 2006 22:41:45 -0400
X-Spam-Status: No, score=2.741 tagged_above=-1.99 required=4.01
tests=[ALL_TRUSTED=-1.44, DNS_FROM_RFC_ABUSE=0.479, HTML_MESSAGE=0.001,
RCVD_IN_NJABL_DUL=1.713, RCVD_IN_SORBS_DUL=1.988]
Now, in this case it's from my mother and valid, but it shows the
problem. Why is an earthlink host trusted?
Even if this problem with not having amavisd-milter insert a forged
Received header into the message for SA to read, then it means that the
only Received header to read would be
Received: from [66.32.20.12] (helo=[66.32.20.12]) by
elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id
1GW28H-0003Bs-QM for jrhett@lizardarts.com; Fri, 06 Oct 2006 22:41:45 -0400
So... why are we trusting 66.32.20.12 ? Really?
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 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 you haven't Received: the message yet, how'd it get to SA?
Do your really expect SA to work on a message that doesn't even appear
to have been delivered to your domain yet?
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 NATed MX servers but with NATed internal mailservers. You can't
> have both work.
Uh, no. Forget about people with NAT. Who cares? It doesn't work in
straight up normal external IP mode with no NAT at all. Period.
> The autodetection is broken, but it is fundamentally unfixable. You
> cannot fix it, you can only change between two different kinds of broken.
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.
> The fundamental problem is if you work backwards in time through the
...
> you'll under-trust for those with non-NAT MXes.
Nobody but you is talking about NAT. Nobody cares about NAT. The
feature itself is broken in non-NAT form.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 that autodetection
> should work unless you are behind a NAT. So a person who believes
> that without testing won't realize that they're looking at the problem.
>
> 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 NATed MX servers but with NATed internal mailservers. You can't
have both work.
The autodetection is broken, but it is fundamentally unfixable. You
cannot fix it, you can only change between two different kinds of broken.
The fundamental problem is if you work backwards in time through the
headers in time, if you start off with private addresses, what do you do
with the first non-private?
If you trust it, as SA does now, you'll work properly for networks with
a non-NAT MX server, but you'll over-trust for networks that NAT their MX.
If you don't trust it, it will work for networks that NAT their MX, but
you'll under-trust for those with non-NAT MXes.
And under-trust is NOT better than over-trust. Both cause severe
breakage in SA's accuracy.
ie: under-trust will break the DUL-RBL tests, just like over-trust, but
rather than causing properly relayed mail to hit a DUL it causes
direct-delivered mail to miss. It also breaks whitelist_from_rcvd, SPF,
and ALL_TRUSTED in various ways.
Both scenarios break roughly the same number of sites, and break them
for the same group of tests, but with slightly different cases causing
broken behavior.
RE: dealing with DoS attacks (Re: ALL_TRUSTED creating a problem)
Posted by R Lists06 <li...@abbacomm.net>.
>
> 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 radar of most providers, which argues to me that this
> guy is fairly clueful. (guy because so far I've never met a woman who
> dealt with their emotional drama in such stupid ways)
>
Snip
>
> You pretty much nailed it. The target is a DSL customer, so sending
> 100mb/sec is isn't enough to raise the eyebrows of any modern service
> provider, but the DSL switch receiving that flood gets fairly unhappy
> and the target is completely offline.
>
> --
> Jo Rhett
> Network/Software Engineer
> Net Consonance
Jo
I kinda figured you were a supertech, so as you know document, document,
document and you will eventually get the idiot...
....when I started doing this in the early 1990's we used to call the USWest
Interprise techs in Minnesota supertechs.
I made some friends there as we turned up a lot of frame relay and such...
So, as you know they can put flags in the switches to watch for those
traffic signs and alert log it and flag someone and they can get their Telco
Cops on it... they wear a badge and can carry a gun too.
It is a federal crime as I understand it, some of them wires cross state
boundaries etc.
:-)
Best wishes
- rh
--
Robert - Abba Communications
Computer & Internet Services
(509) 624-7159 - www.abbacomm.net
dealing with DoS attacks (Re: ALL_TRUSTED creating a problem)
Posted by Jo Rhett <jr...@netconsonance.com>.
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 note it at layer
> 3, document it, then get on the horn with super techs (if enough time) and
> have them document it too.
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 radar of most providers, which argues to me that this
guy is fairly clueful. (guy because so far I've never met a woman who
dealt with their emotional drama in such stupid ways)
> A long time ago when a full T1 was bigtime, sometimes people would ping
> flood smaller ISP circuits making them unusable at layer 2 and the frame
> switches would simply do what they were programmed to do and drop the
> packets because a 256k port would be running at well over 100% capacity and
> almost every packet was discard eligible etc etc
You pretty much nailed it. The target is a DSL customer, so sending
100mb/sec is isn't enough to raise the eyebrows of any modern service
provider, but the DSL switch receiving that flood gets fairly unhappy
and the target is completely offline.
--
Jo Rhett
Network/Software Engineer
Net Consonance
RE: ALL_TRUSTED creating a problem
Posted by R Lists06 <li...@abbacomm.net>.
>
> 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 network handles it fine (my day job, not
> netconsonance) but it so happens that this customer of a customer is on
> the same DSL switch as I am, and it makes life hell for me too. So I
> have to bring up my out of band access and try to nail this bleep-head.
>
> He's not randomizing source IPs, but he keeps moving from place to
> place. And it's always early evening or early morning PST, so I think
> the bleep is going to random well-connected internet cafes and doing
> these attacks from there.
>
> Unfortunately, a hundred megabytes just doesn't make a blip on most
> provider's radar (even ours), so it's pretty hard to trace backwards
> before he's gone.
>
> The fact that it's consistently just before/after working hours PST
> makes me hope that someday I'll figure out who he is and can go break
> the bleeping kneecaps.
>
> --
> Jo Rhett
Jo
Thank you for letting us know.
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
resources that can have get your back to get this "idiot" asap.
1) heavily document everything you can in regards to ip addresses and times
etc etc
2) contact the telephone company security and law enforcement people *and*
super-techs to put some flags in the ATM or FRAME switches/clouds to look
for high layer 2 utilization and dump the sniffer output to logs... they can
look into the layer 2 and 3 packets in the switch software and see ip
addresses etc too and they can trace faster with coordiations with other
telcos if necessary
3) possibly consider contacting other law enforcement as necessary
We have dealt with issues like this many times and we take note it at layer
3, document it, then get on the horn with super techs (if enough time) and
have them document it too.
A long time ago when a full T1 was bigtime, sometimes people would ping
flood smaller ISP circuits making them unusable at layer 2 and the frame
switches would simply do what they were programmed to do and drop the
packets because a 256k port would be running at well over 100% capacity and
almost every packet was discard eligible etc etc
Best wishes
- rh
--
Robert - Abba Communications
Computer & Internet Services
(509) 624-7159 - www.abbacomm.net
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 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 network handles it fine (my day job, not
netconsonance) but it so happens that this customer of a customer is on
the same DSL switch as I am, and it makes life hell for me too. So I
have to bring up my out of band access and try to nail this fuck-head.
He's not randomizing source IPs, but he keeps moving from place to
place. And it's always early evening or early morning PST, so I think
the fucker is going to random well-connected internet cafes and doing
these attacks from there.
Unfortunately, a hundred megabytes just doesn't make a blip on most
provider's radar (even ours), so it's pretty hard to trace backwards
before he's gone.
The fact that it's consistently just before/after working hours PST
makes me hope that someday I'll figure out who he is and can go break
the fucker's kneecaps.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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 localhost. And auto detection kept finding hosts to trust.
Not a single one of the hundreds of messages I looked at had my IP
range, or loopback, or rfc1918 space in the Received headers. Received
headers that would have been there, even missing the very last received
header. It was trusting very random external IP space.
Auto detection is completely and utterly broken.
1. Trusting random destination networks
2. And now you propose that missing the very last Received header - a
mail with no received headers in the worst case scenario - you are
proposing that this should be trusted? No.
It's broken, and it's so completely broken that every single reply on
this list is to disable it.
> Auto-detection works as documented, although I still recommend manual
> configuration myself.
Really? Then why is it the most common FAQ?
Seriously, show me a single site with auto detection enabled that
doesn't have false hits. I was struggling with it until I went to have
a beer with friends and found out that *NOBODY* uses the autodetection
because they've all found it to be broken.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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
> configuration myself.
Agree 110%
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 IPs are public ones unless SA couldn't make
sense of a Received: header.
Any chance UNPARSABLE_RELAY is firing off?
Can you extract a message with that header in it and feed it to SA with
debugging on and see if the Received: parser is getting confused? (This
could at least tell us a bit about why SA is misunderstanding things.)
>
> I was trying to build a test case for documenting the flaws, and after
> reviewing the code realized that it would take less effort to rewrite
> the entire autodetection bit than to explain to Matt Kettler and
> others why they need to fix it.
Wait, why do I need to fix it? I can't.. I'm a device-driver writer by
trade, I don't know jack-squat about writing perl code, so actually
working on the SA code itself is out of my area.
My involvement in SA is writing rules and trying to help people out. I'm
not one of the developers.
That said, if the Received: headers are in fact there, and the
auto-detect is screwing up, just add a trusted_networks statement to
your config. Don't go to all the work of rewriting it.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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.
I was trying to build a test case for documenting the flaws, and
after reviewing the code realized that it would take less effort to
rewrite the entire autodetection bit than to explain to Matt Kettler
and others why they need to fix it. I'll submit back something that
works reasonably, and fails gracefully.
On Oct 17, 2006, at 7:05 PM, Daryl C. W. O'Shea wrote:
> Mark wrote:
>>> -----Original Message-----
>>> From: Daryl C. W. O'Shea [mailto:spamassassin@dostech.ca] 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 required
>>> received header for his MX before passing the mail
>>> to SA which is what is causing his problem.
>> Jo's milter ain't broken: incoming email is passed to a milter
>> prior to
>> sendmail adding its local Received: header. That's the way milters
>> work:
>> they are hooks into the SMTP dialogue. When that communication
>> ends, and
>> the milter has not deciced to reject or discard the message, only
>> then
>> will sendmail actually prepend it's own Received: header.
>
> I'm fully aware of how the Sendmail milter interface works. A
> milter that is not providing SpamAssassin with the required message
> context "ain't not" broken. The primary purpose of the interface
> between the milter (the actual milter, not the milter interface
> between the milter and Sendmail) and SpamAssassin is to provide
> SpamAssassin with the complete message and message context.
>
> SA, which was initially designed as a mail filter to be called post
> SMTP, expects to see the complete set of received headers. The
> data contained in the final received header is vital to a large
> number of the decisions SA makes.
>
> Since SA is not itself a milter (if it were there would be no point
> in yet another milter to access the SpamAssassin libraries) it has
> no way to access the symvals that a milter would have access to.
> Thus any milter that utilizes the SpamAssassin libraries must
> provide SA with the info that it would normally see in a post SMTP
> environment. Providing the SA factory with some context object
> would do it, but would be dependent on the milter interface spec
> that the milter itself is interfacing with. It's much more
> simpler, and a heck of a lot more portable, to just have the milter
> forge a received header (based on the context object it has access
> to) for the sole purpose of providing SpamAssassin with the
> required info.
>
> Anyone who has considered SA's origin as a post SMTP filter, or
> even paid attention to the debug output from either "spamassassin"
> or "spamd" would immediately see why this is important and
> necessary. For anyone who hasn't, there's always the MTA
> Intergration Development note on the wiki: http://wiki.apache.org/
> spamassassin/MtaIntegrationDevNotes
>
>
> Daryl
--
Jo Rhett
Senior Network Engineer
Network Consonance
Re: ALL_TRUSTED creating a problem
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Mark wrote:
>> -----Original Message-----
>> From: Daryl C. W. O'Shea [mailto:spamassassin@dostech.ca]
>> 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 required
>> received header for his MX before passing the mail
>> to SA which is what is causing his problem.
>
> Jo's milter ain't broken: incoming email is passed to a milter prior to
> sendmail adding its local Received: header. That's the way milters work:
> they are hooks into the SMTP dialogue. When that communication ends, and
> the milter has not deciced to reject or discard the message, only then
> will sendmail actually prepend it's own Received: header.
I'm fully aware of how the Sendmail milter interface works. A milter
that is not providing SpamAssassin with the required message context
"ain't not" broken. The primary purpose of the interface between the
milter (the actual milter, not the milter interface between the milter
and Sendmail) and SpamAssassin is to provide SpamAssassin with the
complete message and message context.
SA, which was initially designed as a mail filter to be called post
SMTP, expects to see the complete set of received headers. The data
contained in the final received header is vital to a large number of the
decisions SA makes.
Since SA is not itself a milter (if it were there would be no point in
yet another milter to access the SpamAssassin libraries) it has no way
to access the symvals that a milter would have access to. Thus any
milter that utilizes the SpamAssassin libraries must provide SA with the
info that it would normally see in a post SMTP environment. Providing
the SA factory with some context object would do it, but would be
dependent on the milter interface spec that the milter itself is
interfacing with. It's much more simpler, and a heck of a lot more
portable, to just have the milter forge a received header (based on the
context object it has access to) for the sole purpose of providing
SpamAssassin with the required info.
Anyone who has considered SA's origin as a post SMTP filter, or even
paid attention to the debug output from either "spamassassin" or "spamd"
would immediately see why this is important and necessary. For anyone
who hasn't, there's always the MTA Intergration Development note on the
wiki: http://wiki.apache.org/spamassassin/MtaIntegrationDevNotes
Daryl
RE: ALL_TRUSTED creating a problem
Posted by Mark <ad...@asarian-host.net>.
> -----Original Message-----
> From: Daryl C. W. O'Shea [mailto:spamassassin@dostech.ca]
> 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 required
> received header for his MX before passing the mail
> to SA which is what is causing his problem.
Jo's milter ain't broken: incoming email is passed to a milter prior to
sendmail adding its local Received: header. That's the way milters work:
they are hooks into the SMTP dialogue. When that communication ends, and
the milter has not deciced to reject or discard the message, only then
will sendmail actually prepend it's own Received: header.
- Mark
Re: ALL_TRUSTED creating a problem
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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-NAT networks as
> well. I'm seeing this in 3.1.x, but it may affect other versions. If you
> are having trouble with this, please follow the instructions to manually
> set TrustedNetworks and see if it fixes your problem.''
> --------------
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
configuration myself.
Daryl
Re: ALL_TRUSTED creating a problem
Posted by Matt Kettler <mk...@verizon.net>.
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 that autodetection
> should work unless you are behind a NAT. So a person who believes
> that without testing won't realize that they're looking at the problem.
>
> 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-NAT networks as
well. I'm seeing this in 3.1.x, but it may affect other versions. If you
are having trouble with this, please follow the instructions to manually
set TrustedNetworks and see if it fixes your problem.''
--------------
Could you file a bug in bugzilla, and attach an example (if possible)?
If that's really happening, it should get fixed, and bugzilla is the
place to be.
Re: ALL_TRUSTED creating a problem
Posted by Jo Rhett <jr...@netconsonance.com>.
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
work unless you are behind a NAT. So a person who believes that without
testing won't realize that they're looking at the problem.
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.
--
Jo Rhett
Network/Software Engineer
Net Consonance
RE: ALL_TRUSTED creating a problem
Posted by "Suhas (QualiSpace)" <su...@qualispace.com>.
Thanks everybody.
I will fix it and see the results.
Warm Regards,
Suhas
System Admin
QualiSpace - A QuantumPages Enterprise
===========================
Tel India: +91 (22) 6792 - 1480
Tel US: +1 (614) 827 - 1224
Fax India: +91 (22) 2530 - 3166
URL: http://www.qualispace.com
===========================
For Any Technical Query Please Use: http://helpdesk.qualispace.com
QualiSpace Community Discussion forum: http://forum.qualispace.com
-----Original Message-----
From: Magnus Holmgren [mailto:holmgren@lysator.liu.se]
Sent: Monday, October 16, 2006 5:15 PM
To: users@spamassassin.apache.org
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 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.
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.
So see http://wiki.apache.org/spamassassin/FixingAllTrusted and
http://wiki.apache.org/spamassassin/TrustPath.
--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
Re: ALL_TRUSTED creating a problem
Posted by Magnus Holmgren <ho...@lysator.liu.se>.
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
> trusted networks yet and using the default setting. I am using SA 3.0.1.
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.
So see http://wiki.apache.org/spamassassin/FixingAllTrusted and
http://wiki.apache.org/spamassassin/TrustPath.
--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
Re: ALL_TRUSTED creating a problem
Posted by Martin Hepworth <ma...@solidstatelogic.com>.
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 setting. I am using SA 3.0.1.
>
>
>
> Would appreciate your feedback…
>
>
>
> Warm Regards,
>
> Suhas
>
> System Administrator
>
> *QualiSpace* - A QuantumPages Enterprise
>
> ===========================
>
> Tel India: +91 (22) 6792 - 1480
>
> Tel US: +1 (614) 827 - 1224
>
> Fax India: +91 (22) 2530 - 3166
>
> URL: http://www.qualispace.com <http://www.qualispace.com/>
>
> ===========================
>
> For Any Technical Query Please Use: http://helpdesk.qualispace.com
> <http://helpdesk.qualispace.com/>
>
> QualiSpace Community Discussion forum: http://forum.qualispace.com
>
>
>
You have to set the trusted_networks etc in order to get this working
properly....
--
Martin Hepworth
Senior Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**********************************************************************