On 6/30/2006 9:29 PM, Mark Martinec wrote:
Daryl,
You've told SA that your users aren't a part of your internal network
though. If you configure SA to treat your users as part of your
internal network then it won't do net tests on them.
For clarity, I should have said RBL and SPF tests here
Daryl,
> You've told SA that your users aren't a part of your internal network
> though. If you configure SA to treat your users as part of your
> internal network then it won't do net tests on them.
I forgot what was the original reason that it became a must to treat
MSA as non-internal. Was it
Bart Schaefer wrote:
On 6/30/06, Daryl C. W. O'Shea <[EMAIL PROTECTED]> wrote:
OK, I see now that you want to unconditionally trust the MSA *and* all
hosts after it. Which is reasonable if the MSA is just an MSA. For
whatever reason you don't want to rely on auth tokens, etc. Seems
reasonabl
On 6/30/06, Daryl C. W. O'Shea <[EMAIL PROTECTED]> wrote:
OK, I see now that you want to unconditionally trust the MSA *and* all
hosts after it. Which is reasonable if the MSA is just an MSA. For
whatever reason you don't want to rely on auth tokens, etc. Seems
reasonable to me.
That would
Mark Martinec wrote:
Daryl C. W. O'Shea writes:
Yeah, and correct. Your MSA is the host responsible for sending the
mail to your server running SA. Your SPF record must cover the MSAs IP.
Ok, as a stop-gap solution this works, thanks.
But it is not the right general-purpose solution. This i
Radoslaw Zielinski wrote:
Daryl C. W. O'Shea <[EMAIL PROTECTED]> [30-06-2006 00:45]:
Mark Martinec wrote:
Hmm, I don't think that our own is supposed to be tested for SPF.
It is normal?
Yeah, and correct. Your MSA is the host responsible for sending the
mail to your server running SA. Y
> > Is it normal that our own MSA ip address is being submitted for RBL
> > tests?
Daryl C. W. O'Shea writes:
> It' normal, in the sense that that's what the code says to do. I'm sure
> that this isn't optimal, but it works better than the way we did it
> before (lastuntrusted FP'd all over).
S
Daryl C. W. O'Shea <[EMAIL PROTECTED]> [30-06-2006 00:45]:
> Mark Martinec wrote:
[...]
>> dbg: dns: checking RBL sbl-xbl.spamhaus.org., set sblxbl
>> dbg: dns: IPs found: full-external: ,
>> untrusted: originating:
>> dbg: dns: only inspecting the following IPs:
>> Good, is being t
>...
>Mark Martinec wrote:
>
>> As required per docs, the MTA is considered trusted and internal,
>> and MSA is declared trusted and NOT internal.
>> (both MSA and MTA are on the same IP network)
>>...
>>
>> Is it normal that our own MSA ip address is being submitted for RBL tests?
>
>It' normal,
Mark Martinec wrote:
As required per docs, the MTA is considered trusted and internal,
and MSA is declared trusted and NOT internal.
(both MSA and MTA are on the same IP network)
A mail from an authorized external user follows the route:
->->
(I obfuscated IP addresses and host names
Sorry, I know the topic has been hashed and rehashed several times
recently. I though I understood issues around internal/trusted
networks and I believe that it worked as expected the last time
I checked, but now I'm suprised again, please help me understand it.
This is SA 3.1.3.
We have a MSA whi
11 matches
Mail list logo