On Wed, 2 Feb 2005, Dennis Davis wrote:
> On Wed, 2 Feb 2005, Matthew Newton wrote:
>
> >Just for the record, the config snippet from before doesn't quite
> >work. If an incoming message is _not_ being scanned, then we
> >should leave the headers alone (otherwise messages from inside that
> >go back inside again will have their scores wiped, as we don't spam
> >score for internal mail).
>
> Yup, been there and had the same problems. When I considered
> how mail could travel through our servers I realised that just
> one system filter wouldn't cut it. So the relevant bit of my
> configuration says:
We have a huge amount of complexity in email routeing, mainly because of
the variety of configurations of departmental email servers. Common setups
include:
1. send and receive email to and from the Internet directly
2. receive email via the central relay but send directly
3. send and receive via the relay
We also only spam scan email from "outside" - in principle. But because of
the promiscuous forwarfing that goes on, email can come into a type 1
department then be forwarded to us, at which point it has got in without
being scanned. This tends to irritate people, so we spam scan email from
some type 1 departments.
However we now have a very clear separation between the incoming MX
service and outgoing smarthost service, so I plan to change the logic so
that spam scanning is based on the SMTP connection's destination address
rather than its source address: if the message arrives via the MX it is
spam scanned regardless of its origin, otherwise it isn't. This will deal
with all the type 1 departments without us having to maintain yet another
list of special cases, at the expense of also covering some type 2 depts.
At least I hope it will...
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
