Re: DOS_OE_TO_MX rule and trusted_networks
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
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...
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
