On 24/02/2008 10:06 AM, giga328 wrote:
> Client in example is Outlook Express at 89.110.202.24 also in trusted
> networks.
> Relevant configuration lines are:
> trusted_networks 212.62.32.0/19
> trusted_networks 89.110.192.0/18
Not that this is the cause of your problem, but I'm wondering why
89.110.192.0/18 is included in trusted_networks.
Assuming there's a good reason for it to be included, why is it not
included in internal_networks too? Doing so would resolve your issue
(except for any clients that have their own relay... ie have their
clients send to their own MSA and then smart host it to your MSA), but
read on anyway.
> trusted_networks 213.137.96.0/19
> trusted_networks 82.208.192.0/18
> trusted_networks 10.0.0.0/8
> internal_networks 212.62.57.32/30
> msa_networks 212.62.57.116/30
> msa_networks 212.62.57.156/30
> msa_networks 212.62.57.36/30
>
> MTA acting as MX is mtain1.isp.ptt.rs 212.62.57.32 and I put it in trusted
> and internal networks (if relevant).
> MTA receiving email from clients is mtaout1.isp.ptt.rs 212.62.57.36 and I
> put it in trusted and msa networks.
With msa_networks, you can actually include your MSA as internal for
better results.
The problem in your case, though, is something I've felt uneasy about
for a long time, is the way SA identifies trusted/internal/msa relays...
it's one hop late in doing so (it bases it on the from, not the by).
So if (and I'll admit I don't think this occurred to me before) you're
running SA on outgoing mail on your MSA right after you receive it (it's
not relayed to an intermediate machine) SA can't detect the MSA and the
whole msa_networks thing doesn't work.
To make things work with the way SA works now you need a header
structure something like this:
Received: from msa.example.com (msa.example.com [1.2.3.4])
by out-mta.example.com with ESMTP id m1O2Vcnu010976;
Sat, 23 Feb 2008 21:31:39 -0500
Received: from client (client.example.net [4.3.2.1])
by msa.example.com with ESMTP id m1O2Vcnu010976;
Sat, 23 Feb 2008 21:31:39 -0500
That is, you need an extra received header so that "(msa.example.com
[1.2.3.4])" is shown to SA. There's two ways to get the extra header...
relay the mail, or forge it in what you feed to SA. You could even
forge something like this (which would keep the headers sane and not
require you to actually relay the mail somewhere):
Received: from msa.example.com (msa.example.com [1.2.3.4])
by msa.example.com with ESMTP id m1O2Vcnu010976;
Sat, 23 Feb 2008 21:31:39 -0500
Received: from client (client.example.net [4.3.2.1])
by msa.example.com with ESMTP id m1O2Vcnu010976;
Sat, 23 Feb 2008 21:31:39 -0500
That is, just forge a header for a relay from the msa to itself. In
your case swap msa for mtaout1 in both headers.
> SpamAssassin is implemented by using spamd running on machine which is also
> in trusted networks (if it is relevant for anything).
Just for reference, unless that machine's IP shows up in Received
headers (it relays or sends mail itself) it's not required. Including
it won't hurt anything though.
Daryl
