You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Nick Edwards <ni...@gmail.com> on 2015/10/16 01:10:27 UTC
SPF code change?
Was there a change recently to the spamassassin code for SPF?
Lately, any messages that come in via secondary MX's are failing, this
nevefr used to be the case
Most common is facebook, lately they are marked as complete fail did
someone break something? I assumed it used trusted networks or such to
know, but its not.
(we also run spf milters on MTA so hard fail would not normally get to
spamassassin so not sure how long this gone on for)
(yes - they ARE from facebookmail before anyone asks)
Re: SPF code change?
Posted by Benny Pedersen <me...@junc.eu>.
Nick Edwards skrev den 2015-10-16 01:10:
> (yes - they ARE from facebookmail before anyone asks)
is this a faq ?
2 things to check:
1: is the mail forwarded from an untrusted ip ?
2: add that ip to spf domain, or local in local.cf, then spf tests in
spamassasin would know how to handle it
3: if noop, use spf tests in mta stage will solve it nicely, but then
satup spf test in spamassassin to reuse mta results only
4: add more options to solve it.....
Re: SPF code change?
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.10.2015 um 19:59 schrieb Benny Pedersen:
> Matus UHLAR - fantomas skrev den 2015-10-17 19:11:
>> no forward host has been mentioned. Backup MX servers were, they are not
>> forward hosts. And they should not change envelope sender...
>
> but forward host should change envelope sender, just not backup mx, but
> since both is known in spf record it gets handled fine imho
the backup MX is *not* known as sending server for SPF which was the
whole topic and hence SA needs to know that this IP is a
trusted-forwarder to make the SPF check for the corerct Received header
frankly that was the whole topic and nothing else
Re: SPF code change?
Posted by Benny Pedersen <me...@junc.eu>.
Matus UHLAR - fantomas skrev den 2015-10-17 19:11:
>> in that case its dkim pass, but maybe spf fail or unrelayted since
> do you mean "unrelated"?
yes sorry for misspelling
> the MX servers do not change envelope sender.
> That is why spamassassin must be told about them in internal_networks
> configuration option.
dkim dont care of envelope sender, but spf do
> no forward host has been mentioned. Backup MX servers were, they are
> not
> forward hosts. And they should not change envelope sender...
but forward host should change envelope sender, just not backup mx, but
since both is known in spf record it gets handled fine imho
Re: SPF code change?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>Matus UHLAR - fantomas skrev den 2015-10-16 17:17:
>
>>the SPF wasn't reported to fail on own domains. it was reported for
>>foreign
>>domains like facebookmail, when coming through secondary MXes, which is
>>clearly problem of SA configuration...
On 16.10.15 17:51, Benny Pedersen wrote:
>in that case its dkim pass, but maybe spf fail or unrelayted since
do you mean "unrelated"?
>envelope sender on forward host ip is not sending from facebookmail
the MX servers do not change envelope sender.
That is why spamassassin must be told about them in internal_networks
configuration option.
>the forward host could still make spf pass on there own sending
>envelope sender domain
no forward host has been mentioned. Backup MX servers were, they are not
forward hosts. And they should not change envelope sender...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name.
Re: SPF code change?
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.10.2015 um 17:51 schrieb Benny Pedersen:
> Matus UHLAR - fantomas skrev den 2015-10-16 17:17:
>
>> the SPF wasn't reported to fail on own domains. it was reported for
>> foreign
>> domains like facebookmail, when coming through secondary MXes, which is
>> clearly problem of SA configuration...
>
> in that case its dkim pass
DKIM has no business to the question about SPF_FAIL
> but maybe spf fail or unrelayted since
> envelope sender on forward host ip is not sending from facebookmail
boah from what else should the backup MX send to the primary when he
receives a message from facebook, queues it and delivers later?
Re: SPF code change?
Posted by Benny Pedersen <me...@junc.eu>.
Matus UHLAR - fantomas skrev den 2015-10-16 17:17:
> the SPF wasn't reported to fail on own domains. it was reported for
> foreign
> domains like facebookmail, when coming through secondary MXes, which is
> clearly problem of SA configuration...
in that case its dkim pass, but maybe spf fail or unrelayted since
envelope sender on forward host ip is not sending from facebookmail
the forward host could still make spf pass on there own sending envelope
sender domain
Re: SPF code change?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>Matus UHLAR - fantomas skrev den 2015-10-16 14:43:
>
>>the MX servers for your domain MUST be listed in internal_network
>>(and in
>>trusted_network too).
>>This is exactly what internal_networks is for...
On 16.10.15 14:58, Benny Pedersen wrote:
>just that is not completely true
>
>if spf fails on own domains, make spf dns record correct will help
>more, but if its not own domain, make sure all forwarding or own ips
>in internal_networks and trusted_networks is a demend for aktive spf
>testing in spamassassin
the SPF wasn't reported to fail on own domains. it was reported for foreign
domains like facebookmail, when coming through secondary MXes, which is
clearly problem of SA configuration...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot.
Re: SPF code change?
Posted by Joe Quinn <jq...@pccc.com>.
On 10/16/2015 10:18 AM, Benny Pedersen wrote:
> Reindl Harald skrev den 2015-10-16 15:57:
>
>> and why the hell should a SPF test for mails coming with envelopes
>> from yahoo, google, hotmail care about *that* entry for *your* domain?
>
> eh what ?
Slow your roll, guys.
Nick, can you give us a sample message and its debug output with -D?
Re: SPF code change?
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.10.2015 um 16:18 schrieb Benny Pedersen:
> Reindl Harald skrev den 2015-10-16 15:57:
>
>> and why the hell should a SPF test for mails coming with envelopes
>> from yahoo, google, hotmail care about *that* entry for *your* domain?
>
> eh what ?
backup MX?
* message is received by the backup MX
* message has a *foreign* envelope
* primary MX receives that message from the backup MX
* primary MX says SPF_FAIL
* the primary MX needs to know which one was the
first untrusted Received line for SPF to work
and hence you whole "just that is not completely true" reply to a
correct answer was crap from the first moment
-------- Weitergeleitete Nachricht --------
Betreff: Re: SPF code change?
Datum: Fri, 16 Oct 2015 14:58:43 +0200
Von: Benny Pedersen <me...@junc.eu>
Organisation: Jersore Underground Network Center
An: users@spamassassin.apache.org
Matus UHLAR - fantomas skrev den 2015-10-16 14:43:
> the MX servers for your domain MUST be listed in
> internal_network (and in
> trusted_network too). This is exactly what
> internal_networks is for...
just that is not completely true
Re: SPF code change?
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-10-16 15:57:
> and why the hell should a SPF test for mails coming with envelopes
> from yahoo, google, hotmail care about *that* entry for *your* domain?
eh what ?
Re: SPF code change?
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.10.2015 um 15:46 schrieb Benny Pedersen:
> Reindl Harald skrev den 2015-10-16 15:07:
>
>> what exactly did you not understand in "messages that come in via
>> secondary MX's" and that this is *by definition* unrelated to own
>> domains?
>
> v=spf1 mx -all
and why the hell should a SPF test for mails coming with envelopes from
yahoo, google, hotmail care about *that* entry for *your* domain?
frankly you should learn to read and understand topics *before* you
answer, not only on this list, on every list i recognized your presence
the last years
> dont troll
the only one trolling here is you
Re: SPF code change?
Posted by Benny Pedersen <me...@junc.eu>.
Reindl Harald skrev den 2015-10-16 15:07:
> what exactly did you not understand in "messages that come in via
> secondary MX's" and that this is *by definition* unrelated to own
> domains?
v=spf1 mx -all
dont troll
Re: SPF code change?
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.10.2015 um 14:58 schrieb Benny Pedersen:
> Matus UHLAR - fantomas skrev den 2015-10-16 14:43:
>
>> the MX servers for your domain MUST be listed in internal_network (and in
>> trusted_network too).
>> This is exactly what internal_networks is for...
>
> just that is not completely true
>
> if spf fails on own domains, make spf dns record correct will help more
what exactly did you not understand in "messages that come in via
secondary MX's" and that this is *by definition* unrelated to own domains?
Re: SPF code change?
Posted by Benny Pedersen <me...@junc.eu>.
Matus UHLAR - fantomas skrev den 2015-10-16 14:43:
> the MX servers for your domain MUST be listed in internal_network (and
> in
> trusted_network too).
> This is exactly what internal_networks is for...
just that is not completely true
if spf fails on own domains, make spf dns record correct will help more,
but if its not own domain, make sure all forwarding or own ips in
internal_networks and trusted_networks is a demend for aktive spf
testing in spamassassin
for passive spf testing the mta know what to do
Re: SPF code change?
Posted by Nick Edwards <ni...@gmail.com>.
Situation is resolved.
Below is part of the fault.
Our secondaries are dual stacked, although they are configured to use
ipv4 over ipv6 and usually do.
Our config only trusts ipv4 addresses (the problem)
There was a 3 day blockage in routing for one ipv4 range (it is
external and out of our hands, its on a third party network and there
was a problem with BGP on their end), this did not affect routing of
ipv6, so ipv6 because ipv4 failed, sent the messages, resulting in SPF
fail, we have since added ipv6 addresses to trusted settings.
On 10/16/15, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> On 16.10.15 09:10, Nick Edwards wrote:
>>Was there a change recently to the spamassassin code for SPF?
>>
>>Lately, any messages that come in via secondary MX's are failing, this
>>nevefr used to be the case
>
> the MX servers for your domain MUST be listed in internal_network (and in
> trusted_network too).
> This is exactly what internal_networks is for...
>
>
> --
> Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> I just got lost in thought. It was unfamiliar territory.
>
Re: SPF code change?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 16.10.15 09:10, Nick Edwards wrote:
>Was there a change recently to the spamassassin code for SPF?
>
>Lately, any messages that come in via secondary MX's are failing, this
>nevefr used to be the case
the MX servers for your domain MUST be listed in internal_network (and in
trusted_network too).
This is exactly what internal_networks is for...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory.