You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Support SimpleRezo <si...@gmail.com> on 2016/05/25 11:05:57 UTC
Problem with SPF plugin and MX2
Hi,
We are expecting a problem when emails are coming from our MX2 with the SPF
plugin, because the SPF test is made on the last "Received" IP and not the
first one (as we can expect for a SPF test).
So if the domain is one of our domain, the result is always SPF_PASS when
the email arrived from MX2 (since the SPF rule is including "MX"), and when
it's not, the result is SPF_FAILED even if coming from a good IP (because
the test is made with our MX2 IP).
Does someone has already notice this? Can this be fixed by configuration?
Regards
Clement
Re: Problem with SPF plugin and MX2
Posted by Support SimpleRezo <si...@gmail.com>.
You are totally right, fixed! Thank you!
2016-05-25 13:24 GMT+02:00 RW <rw...@googlemail.com>:
>
> It sounds like you haven't setup internal_networks and trusted_networks.
>
> https://wiki.apache.org/spamassassin/TrustPath
>
>
Re: Problem with SPF plugin and MX2
Posted by RW <rw...@googlemail.com>.
On Wed, 25 May 2016 13:05:57 +0200
Support SimpleRezo wrote:
> Hi,
>
> We are expecting a problem when emails are coming from our MX2 with
> the SPF plugin, because the SPF test is made on the last "Received"
> IP and not the first one (as we can expect for a SPF test).
>
> So if the domain is one of our domain, the result is always SPF_PASS
> when the email arrived from MX2 (since the SPF rule is including
> "MX"), and when it's not, the result is SPF_FAILED even if coming
> from a good IP (because the test is made with our MX2 IP).
>
> Does someone has already notice this? Can this be fixed by
> configuration?
It sounds like you haven't setup internal_networks and trusted_networks.
https://wiki.apache.org/spamassassin/TrustPath
Re: Problem with SPF plugin and MX2
Posted by Vincent Fox <vb...@ucdavis.edu>.
In 20 years never saw need for backup mx.
If MX pool is down remote MTA should queue it.
Only practical use I've seen is NoListing setup.
I suppose you might run a server in the Arctic which could lose contact for weeks and you'd want to ensure no bounces. Ymmv.
Sent from my iPhone
> On May 25, 2016, at 08:18, "shanew@shanew.net" <sh...@shanew.net> wrote:
>
>> On Wed, 25 May 2016, Dianne Skoll wrote:
>>
>> On Wed, 25 May 2016 13:05:57 +0200
>> Support SimpleRezo <si...@gmail.com> wrote:
>>
>>> We are expecting a problem when emails are coming from our MX2 with
>>> the SPF plugin, because the SPF test is made on the last "Received"
>>> IP and not the first one (as we can expect for a SPF test).
>>
>>> Does someone has already notice this? Can this be fixed by
>>> configuration?
>>
>> Yes. Don't run a backup MX machine that relays to a primary machine
>> that does spam-scanning. It's more trouble than it's worth, particularly
>> as spammers sometimes specifically pick the worst MX record rather than
>> the best.
>
> It also seems problematic for your backup MX to accept an email only
> for your primary to potentially reject said email later on. At that
> point you can no longer reject the mail, leaving the problematic (some
> might say wrong) choices to either bounce it or drop it (or deliver
> it, I suppose, if you're only using SA to provide info to end users).
>
> Running the same SA setup on your backup would seem to minimize that
> risk, but not totally eliminate it, since network-based tests might
> return different results given sufficient time until your backup
> finally transfers to the primary.
>
> So, for those with more experience, what is the preferred way to run a
> backup MX (or two or three, etc.) without losing or breaking the
> benefit of spam filtering?
>
> --
> Public key #7BBC68D9 at | Shane Williams
> http://pgp.mit.edu/ | System Admin - UT CompSci
> =----------------------------------+-------------------------------
> All syllogisms contain three lines | shanew@shanew.net
> Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Problem with SPF plugin and MX2
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.05.2016 um 17:28 schrieb Dianne Skoll:
> On Wed, 25 May 2016 10:17:19 -0500 (CDT)
> shanew@shanew.net wrote:
>
>> So, for those with more experience, what is the preferred way to run a
>> backup MX (or two or three, etc.) without losing or breaking the
>> benefit of spam filtering?
>
> For small installations, I find a backup MX is more trouble than it's
> worth. So I just don't bother. Seriously, if your Exchange server or
> whatever is down for more than a couple of hours, you have deeper IT
> infrastructure problems than can be solved with a backup MX host
the only real usage of a backup-mx is a "always 450" instance on the
same-machine but a different IP because many zombies first try the
backup-mx, most never come back and the one which would work with
greylisting have some minutes more so URIBL/DNSBL catches them
postfix with postscreen supports such a setup with a single config line
Re: Problem with SPF plugin and MX2
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Wed, 25 May 2016 10:17:19 -0500 (CDT)
shanew@shanew.net wrote:
> So, for those with more experience, what is the preferred way to run a
> backup MX (or two or three, etc.) without losing or breaking the
> benefit of spam filtering?
For small installations, I find a backup MX is more trouble than it's
worth. So I just don't bother. Seriously, if your Exchange server or
whatever is down for more than a couple of hours, you have deeper IT
infrastructure problems than can be solved with a backup MX host.
For large installations, I run multiple MX hosts that all run as part
of the same spam-filtering cluster and which then relay onward to the
real mail host. Of course, it's important for the scanners to be aware
of all valid recipients on the back-end so they can reject mail to
invalid recipients without causing backscatter.
Regards,
Dianne.
Re: Problem with SPF plugin and MX2
Posted by sh...@shanew.net.
On Wed, 25 May 2016, Dianne Skoll wrote:
> On Wed, 25 May 2016 13:05:57 +0200
> Support SimpleRezo <si...@gmail.com> wrote:
>
>> We are expecting a problem when emails are coming from our MX2 with
>> the SPF plugin, because the SPF test is made on the last "Received"
>> IP and not the first one (as we can expect for a SPF test).
>
>> Does someone has already notice this? Can this be fixed by
>> configuration?
>
> Yes. Don't run a backup MX machine that relays to a primary machine
> that does spam-scanning. It's more trouble than it's worth, particularly
> as spammers sometimes specifically pick the worst MX record rather than
> the best.
It also seems problematic for your backup MX to accept an email only
for your primary to potentially reject said email later on. At that
point you can no longer reject the mail, leaving the problematic (some
might say wrong) choices to either bounce it or drop it (or deliver
it, I suppose, if you're only using SA to provide info to end users).
Running the same SA setup on your backup would seem to minimize that
risk, but not totally eliminate it, since network-based tests might
return different results given sufficient time until your backup
finally transfers to the primary.
So, for those with more experience, what is the preferred way to run a
backup MX (or two or three, etc.) without losing or breaking the
benefit of spam filtering?
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Problem with SPF plugin and MX2
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Wed, 25 May 2016 13:05:57 +0200
Support SimpleRezo <si...@gmail.com> wrote:
> We are expecting a problem when emails are coming from our MX2 with
> the SPF plugin, because the SPF test is made on the last "Received"
> IP and not the first one (as we can expect for a SPF test).
> Does someone has already notice this? Can this be fixed by
> configuration?
Yes. Don't run a backup MX machine that relays to a primary machine
that does spam-scanning. It's more trouble than it's worth, particularly
as spammers sometimes specifically pick the worst MX record rather than
the best.
Regards,
Dianne.