You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Tomas Macek <ma...@fortech.cz> on 2011/10/10 12:19:56 UTC
DOS_OE_TO_MX rule and trusted_networks
I'm using SpamAssassin 3.3.1 together with Amavis 2.6.4 on one server with
Postfix. All our customers have public static IP addresses on their PC's
213.x.x.x/y. We use only one mailserver with one public IP address from
the 213.x.x.x/y range mentioned earlier for both the incoming and outgoing
mail traffic to/from all of our domains. We are ISP.
Our customer complained about false positive mail with DOS_OE_TO_MX.
How exactly this rule works? Should I add all my range 213.x.x.x/y to the
trusted_networks and my mailserver should be added to the
internal_networks?
I guess, that the DOS_OE_TO_MX rule says, that someone from the
internet/outside world is connected directly to my mailserver, says it
sends mail using Outlook Express and sends the mails to my domains. He
does not uses his ISP's mailserver for sending mails. Right?
I suggest something like this:
trusted_networks 213.x.x.x/y # all our public ip addresses range
internal_networks 213.0.0.5 # let's say that's our mailserver's IP
I have none lines with trusted_networks and internal_networks in my config
now.
The doc says:
"Trusted in this case means that relay hosts on these networks are
considered to not be potentially operated by spammers, open relays, or
open proxies. A trusted host could conceivably relay spam, but will not
originate it, and will not forge header data"
But I think, that almost everone is sometimes infected and sends spam...
So I'm confused howto setup my system.
Kind regards, Tomas
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 10.10.11 13:14, Tomas Macek wrote:
>OK, this should be good:
> trusted_networks 213.0.0.5 213.0.0.10 # primary mx IP and backup mx IP
> internal_networks 213.0.0.5 # only the IP of primary mx
>Right?
No. All the backup MX servers must be in internal_networks too
>I know, that smtp auth often solves many problems, but today I cannot
>force all our clients to use it. So that means, that someone uses it,
>but mostly not.
you should add all clients that do not use smtp authentication to your
trusted_networks. Note that this will make it harder to detect spam
they will send to you.
>>hope that helps, if not post sample on pastebin, and just mangle
>>sender donain with example.org
>
>But there is still the question what bad happened when DOS_OE_TO_MX
>matched the message?
because the client used outlook express and has sent mail directly to
destination (your) server. Mail clients should use SMTP servers for
sending e-mail. That's why you need to use SMTP authentication or
trusted_networks - to let SA know it's not spamming MUA from outside
spamming your network.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Mon, 10 Oct 2011 13:14:21 +0200 (CEST), Tomas Macek wrote:
>>OK, this should be good:
>> trusted_networks 213.0.0.5 213.0.0.10 # primary mx IP and backup
>>mx IP
>> internal_networks 213.0.0.5 # only the IP of primary mx
>>Right?
On 10.10.11 16:40, Benny Pedersen wrote:
>backup is imho also internal, only ecception is if its another isp
if the backup doesn't behave as SMTP server for anyone, it should
be in internal_networks too. You wouldn't use as MX a server you do not
trust, would you?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Benny Pedersen <me...@junc.org>.
On Tue, 11 Oct 2011 07:37:53 +0200 (CEST), Tomas Macek wrote:
[snip]
> No, there is not ALL_TRUSTED in the headers. I'm sorry, I did not
> write here the rules that matched the message, so here it is:
>
> X-Spam-Status: Yes, score=5.988 tagged_above=3 required=5
> tests=[DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001,
> HELO_NO_DOMAIN=0.001, HELO_OEM=2.899, HTML_MESSAGE=0.001]
> autolearn=disabled
>
one can meta it:
meta ADJ_DOS_OE (rules-that-hit1 && rules-that-hit2)
score ADJ_DOS_OE -0.5
but where is sender send from ?, its not trusted_network, its not
internal_networ
rulescore says me its not spamassassin 3.3.2 with latest updates
adjust HELO_OEM down if DOS_OE_TO_MX is hitting
i never use rule scores that is over 2.5
> What the rule DOS_OE_TO_MX exactly does?
> This
> (http://www.gossamer-threads.com/lists/spamassassin/users/110344) for
> example says, that OE from some outside network used our mailserver
> to
> send mail to our network. The outside OE client did not used it's
> isps
> mailserver.
> Is that right? If so, I think I must somewhere say, what our network
> and I don't know where...
it tracks oe clients that is not auth, and send direct to mx as a mta
witch thay are not, since clients cant do smtpd on reverse from your
mailserver, call it failing callback :=)
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Tomas Macek <ma...@fortech.cz>.
On Mon, 10 Oct 2011, Benny Pedersen wrote:
> On Mon, 10 Oct 2011 13:14:21 +0200 (CEST), Tomas Macek wrote:
>> On Mon, 10 Oct 2011, Benny Pedersen wrote:
>>
>>> On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
>>>> I suggest something like this:
>>>> trusted_networks 213.x.x.x/y # all our public ip addresses range
>>>> internal_networks 213.0.0.5 # let's say that's our mailserver's IP
>>>
>>> the above should only list all the mailserver(s) you have as isp, not
>>> custommers ips in network, same with trusted_network
>>
>> OK, this should be good:
>> trusted_networks 213.0.0.5 213.0.0.10 # primary mx IP and backup mx
>> IP
>> internal_networks 213.0.0.5 # only the IP of primary mx
>> Right?
>
> backup is imho also internal, only ecception is if its another isp
it's our server in another isp's network :-))
>>
>>> if you forward mails in clusters add cluster ips as trusted_networks, not
>>> internal_network
>>>
>>>> But I think, that almost everone is sometimes infected and sends
>>>> spam... So I'm confused howto setup my system.
>>>
>>> verify with above change
>>>
>>> spamassassin -t msg | less
>>>
>>> your clients still use sasl auth even from isp ip ranges ?, thats the
>>> correct way to solve most problems, but are unrelated to the error you
>>> see, here i use amavisd-new and have seperate policy banks for submision
>>> and smtpd incomming mails, smtpd is never originating mails here,
>>> submission reject non sasl authed clients
>>
>> I know, that smtp auth often solves many problems, but today I cannot
>> force all our clients to use it. So that means, that someone uses it,
>> but mostly not.
>
> i remember clients problems can be isps problems understanding as well :=)
>
> what kind of problems remain to be solved if sasl auth is only way to send
> mail ?
At the early begginings we did not have smtp auth, so now it's too late to
force the clients to setup this on their OE or Thunderbird or something
similar. So the
solution is easy: to setup about ten thousands clients to use smtp auth
:-))
> what logs say ? >
>>
>>> hope that helps, if not post sample on pastebin, and just mangle sender
>>> donain with example.org
>>
>> But there is still the question what bad happened when DOS_OE_TO_MX
>> matched the message?
>
> yes, check if msg is with ALL_TRUSTED test or not
>
>> The client sent the mail from internal network 213.x.x.x/y from his
>> public static IP through our mailserver into some mailbox hosted on
>> our mailserver. I think I must have some misconfiguration in
>> spamassassin...
>
> if ALL_TRUSTED agree its sure a bug, but imho its not scoring 5.0 ?
No, there is not ALL_TRUSTED in the headers. I'm sorry, I did not write
here the rules that matched the message, so here it is:
X-Spam-Status: Yes, score=5.988 tagged_above=3 required=5
tests=[DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001,
HELO_NO_DOMAIN=0.001, HELO_OEM=2.899, HTML_MESSAGE=0.001]
autolearn=disabled
What the rule DOS_OE_TO_MX exactly does?
This (http://www.gossamer-threads.com/lists/spamassassin/users/110344) for
example
says, that OE from some outside network used our mailserver to send mail
to our network. The outside OE client did not used it's isps mailserver.
Is that right? If so, I think I must somewhere say, what our network and I
don't know where...
Tomas
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Benny Pedersen <me...@junc.org>.
On Mon, 10 Oct 2011 13:14:21 +0200 (CEST), Tomas Macek wrote:
> On Mon, 10 Oct 2011, Benny Pedersen wrote:
>
>> On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
>>> I suggest something like this:
>>> trusted_networks 213.x.x.x/y # all our public ip addresses range
>>> internal_networks 213.0.0.5 # let's say that's our mailserver's IP
>>
>> the above should only list all the mailserver(s) you have as isp,
>> not custommers ips in network, same with trusted_network
>
> OK, this should be good:
> trusted_networks 213.0.0.5 213.0.0.10 # primary mx IP and backup mx
> IP
> internal_networks 213.0.0.5 # only the IP of primary mx
> Right?
backup is imho also internal, only ecception is if its another isp
>
>> if you forward mails in clusters add cluster ips as
>> trusted_networks, not internal_network
>>
>>> But I think, that almost everone is sometimes infected and sends
>>> spam... So I'm confused howto setup my system.
>>
>> verify with above change
>>
>> spamassassin -t msg | less
>>
>> your clients still use sasl auth even from isp ip ranges ?, thats
>> the correct way to solve most problems, but are unrelated to the error
>> you see, here i use amavisd-new and have seperate policy banks for
>> submision and smtpd incomming mails, smtpd is never originating mails
>> here, submission reject non sasl authed clients
>
> I know, that smtp auth often solves many problems, but today I cannot
> force all our clients to use it. So that means, that someone uses it,
> but mostly not.
i remember clients problems can be isps problems understanding as well
:=)
what kind of problems remain to be solved if sasl auth is only way to
send mail ?
what logs say ?
>
>> hope that helps, if not post sample on pastebin, and just mangle
>> sender donain with example.org
>
> But there is still the question what bad happened when DOS_OE_TO_MX
> matched the message?
yes, check if msg is with ALL_TRUSTED test or not
> The client sent the mail from internal network 213.x.x.x/y from his
> public static IP through our mailserver into some mailbox hosted on
> our mailserver. I think I must have some misconfiguration in
> spamassassin...
if ALL_TRUSTED agree its sure a bug, but imho its not scoring 5.0 ?
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Jernej Porenta <je...@arnes.si>.
On Oct 10, 2011, at 1:14 PM, Tomas Macek wrote:
>> hope that helps, if not post sample on pastebin, and just mangle sender donain with example.org
>
> But there is still the question what bad happened when DOS_OE_TO_MX matched the message?
> The client sent the mail from internal network 213.x.x.x/y from his public static IP through our mailserver into some mailbox hosted on our mailserver. I think I must have some misconfiguration in spamassassin...
I believe the right variable to set up would be "msa_networks" instead of "trusted_networks".
We had similar issues, with our pop-before-smtp users relaying through our mail servers to domains that we hosted. In the end, we lowered the DOS_OE_TO_MX score, since we were unable to dynamically specify msa_networks variable.
I know that there was a plugin for that: http://wiki.apache.org/spamassassin/POPAuthPlugin
We eventually developed the SA plugin, that could dynamically specify the msa_networks, but in the end we settled for lowering the score and advising the users to use SMTP AUTH which bypasses the DOS_OE_TO_MX...
regards, Jernej
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Tomas Macek <ma...@fortech.cz>.
On Mon, 10 Oct 2011, Benny Pedersen wrote:
> On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
>> I suggest something like this:
>> trusted_networks 213.x.x.x/y # all our public ip addresses range
>> internal_networks 213.0.0.5 # let's say that's our mailserver's IP
>
> the above should only list all the mailserver(s) you have as isp, not
> custommers ips in network, same with trusted_network
OK, this should be good:
trusted_networks 213.0.0.5 213.0.0.10 # primary mx IP and backup mx IP
internal_networks 213.0.0.5 # only the IP of primary mx
Right?
> if you forward mails in clusters add cluster ips as trusted_networks, not
> internal_network
>
>> But I think, that almost everone is sometimes infected and sends
>> spam... So I'm confused howto setup my system.
>
> verify with above change
>
> spamassassin -t msg | less
>
> your clients still use sasl auth even from isp ip ranges ?, thats the correct
> way to solve most problems, but are unrelated to the error you see, here i
> use amavisd-new and have seperate policy banks for submision and smtpd
> incomming mails, smtpd is never originating mails here, submission reject non
> sasl authed clients
I know, that smtp auth often solves many problems, but today I
cannot force all our clients to use it. So that means, that someone uses
it, but mostly not.
> hope that helps, if not post sample on pastebin, and just mangle sender
> donain with example.org
But there is still the question what bad happened when DOS_OE_TO_MX
matched the message?
The client sent the mail from internal network
213.x.x.x/y from his public static IP through our mailserver into some
mailbox hosted on our mailserver. I think I must have some
misconfiguration in spamassassin...
Re: DOS_OE_TO_MX rule and trusted_networks
Posted by Benny Pedersen <me...@junc.org>.
On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
> I suggest something like this:
> trusted_networks 213.x.x.x/y # all our public ip addresses range
> internal_networks 213.0.0.5 # let's say that's our mailserver's IP
the above should only list all the mailserver(s) you have as isp, not
custommers ips in network, same with trusted_network
if you forward mails in clusters add cluster ips as trusted_networks,
not internal_network
> But I think, that almost everone is sometimes infected and sends
> spam... So I'm confused howto setup my system.
verify with above change
spamassassin -t msg | less
your clients still use sasl auth even from isp ip ranges ?, thats the
correct way to solve most problems, but are unrelated to the error you
see, here i use amavisd-new and have seperate policy banks for submision
and smtpd incomming mails, smtpd is never originating mails here,
submission reject non sasl authed clients
hope that helps, if not post sample on pastebin, and just mangle sender
donain with example.org