On Thu, 23 Feb 2012 21:25:40 +0000 Mark Porthouse wrote: > On 23/02/2012 18:36, RW wrote: > > We went though this on the bug tracker. SA is failing to > > differentiate between an mx handover and submission. The main way > > that it does this via internal and trusted network settings. If you > > have submission on the same IP address as the MX server, or you > > network setting are wrong then it can fall back to detecting > > Authentication. In your case no authentication is recorded in the > > received header. > > Submission is *not* on the same server that SA is running on.
Yes, I know. > Whilst POP, IMAP and SMTP are running on the one and only MX for that > domain, SA is running on the server that has just used fetchmail to > pick up the mail using POP from the MX for the domain. > > Surely SA cannot be confident that mail received by the MX (that the > SA equipped, final destination server fetchmails from) has either > been sent via an authenticating client or by a relay. With most ESPs/ISPs it can. If you retreive mail via fetchmail you really need to extend the internal network to the remote mx servers because many important tests that target botnets only run on the handover to the internal network. Spamassassin provides two ways of preventing FPs from mail client submissions. The first is to put the submission server into the trusted network, but not the internal network (this is pretty much the purpose of the trusted/internal distinction). The second method is that the tests on the internal network handover are disabled if authentication is detected in the received header In your case neither mechanism works. You can't distinguish by IP address or received header. You can of course just put the server in trusted networks, but that will degrade Spamassassin's effectiveness significantly unless the server itself is doing aggression filtering against botnets.
