On 8 February 2017 at 15:34, Mark Foster wrote:

And in response to Jo Booth:

Certainly had at least one case recently with a customer who hosts with Mesh|net using SMTP via snap to an xtra address, that went via orcon and failed. They had the Snap MXs in SPF etc (*+include:**snap.net.nz* http://snap.net.nz/* -all )* but not orcon or xtra. It looked like Xtra was looking at the Orcon EHLO and failing.

I'm lost on this one; the customer hosts with Mesh|net, sent email via snap's SMTP to an xtra address - why did Orcon get the email? Snap should've done an MX lookup and connected to Xtra, which Xtra would pass if Snap were declared in the SPF record for the envelope-sender domain.

Mark.

That was the bit I didn't get. Snap -> Orcon -> Xtra - but I'm not up to play which ISP is in bed with which other. I'm thinking the recipient host their domain MX with Orcon and then forward to an Xtra mailbox? Either way, everyone needs SRS if SPF is in play at the ends. -- Jo Booth - Mesh|net *Connecting Communities*

I'm getting mail bouncing with ~all spf record soft fail .. and xtra (actually smx) are rejecting. Could be that they don't like me :) On Wed, Feb 8, 2017 at 3:57 PM, Brian E Carpenter < brian.e.carpenter(a)gmail.com> wrote:

On 08/02/2017 15:34, Mark Foster wrote: ...

...

Someone mentioned mailing lists; decent ones rewrite the envelope and don't break SPF.

Or rather, are not broken by SPF. Unfortunately, the same is not true of DMARC. There's still no good solution for lists or forwarders that are broken by DMARC. Glen, I fear that DMARC problems are in your future.

Brian

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog

From the RFC https://tools.ietf.org/html/rfc7208

'The "include" mechanism makes it possible for one domain to designate multiple administratively independent domains. For example, a vanity domain "example.net" might send mail using the servers of administratively independent domains example.com and example.org. Example.net could say IN TXT "v=spf1 include:example.com include:example.org -all" This would direct check_host() to, in effect, check the records of example.com and example.org for a "pass" result. Only if the host were not permitted for either of those domains would the result be "fail". Whether this mechanism matches, does not match, or returns an exception depends on the result of the recursive evaluation of check_host():' So it's possible that the 'hard fail' in the aspmx.sailthru.com SPF is causing the bounce Cheers Jodi ----- Original Message ----- From: "Jean-Francois Pirus" To: "Paul Willard" , nznog(a)list.waikato.ac.nz Sent: Tuesday, February 21, 2017 3:02:15 PM Subject: Re: [nznog] Xtra and SPF Here's an example of an Xtra bounces which looks like soft fail but which includes a hard fail. So I'm assuming that a hard fail anywhere takes precedence, does anybody know the rules, I could not find any references. sailthru.com. 10800 IN TXT "v=spf1 include:aspmx.sailthru.com include:_spf.google.com include:_netblocks.zdsys.com ~all" aspmx.sailthru.com. 900 IN TXT "v=spf1 ip4:64.34.47.128/27 ip4:64.34.57.192/26 ip4:65.39.215.0/24 ip4:192.64.236.0/24 ip4:192.64.237.0/24 ip4:173.228.155.0/24 ip4:192.64.238.0/24 ip4:204.153.121.0/24 -all" _netblocks.zdsys.com. 54000 IN TXT "v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ip4:188.172.128.0/20 ip4:216.198.0.0/18 ~all" _spf.google.com. 55 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" On 21/02/17 14:17, Paul Willard wrote:

I'm getting mail bouncing with ~all spf record soft fail .. and xtra (actually smx) are rejecting.

Could be that they don't like me :)

On Wed, Feb 8, 2017 at 3:57 PM, Brian E Carpenter mailto:brian.e.carpenter(a)gmail.com> wrote:

On 08/02/2017 15:34, Mark Foster wrote: ... > Someone mentioned mailing lists; decent ones rewrite the envelope and > don't break SPF.

Or rather, are not broken by SPF. Unfortunately, the same is not true of DMARC. There's still no good solution for lists or forwarders that are broken by DMARC. Glen, I fear that DMARC problems are in your future.

Brian

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz mailto:NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog https://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog

-- Jean-Francois Pirus | Technical Manager francois(a)clearfield.com | Mob +64 21 640 779 | DDI +64 9 282 3401 Clearfield Software Ltd | Ph +64 9 358 2081 | www.clearfield.com _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog

Hi guys, While not totally helpful here, yes There are a few spf issues with xtra right now. Please make sure to report these through spark so it can be followed up. Submit full headers while reporting so it can be looked into properly. Thoses with open cases, thank you for already raising it. On 21/02/2017 4:19 PM, "Martin Kealey" wrote:

This represents a gross failure on Xtra's part in failing to separate 2 distinctly different scenarios. SPF is intended to regulate outbound relaying, where the relay acts as an agent of the sender. It has nothing to say about inbound relaying, where the relay is an agent of the recipient.

SPF enforcement should not the touch inbound relays.

A reasonable implementation would allow recipients to designate their own inbound relays, either by host, or by reference to the SPF record of the primary domain of the relay.

Having said all that, what has changed recently is not SPF enforcement on the envelope sender, but DKIM enforcement on the From: header. The former has no effect on mailing lists which have been rewriting envelope sender (and Sender: header) for many years; but the latter has become a big problem just recently for mail going to Xtra.

-Martin

On 21 Feb. 2017 13:55, "Jodi Thomson" wrote:

...

...

From the RFC https://tools.ietf.org/html/rfc7208

'The "include" mechanism makes it possible for one domain to designate multiple administratively independent domains. For example, a vanity domain "example.net" might send mail using the servers of administratively independent domains example.com and example.org.

Example.net could say

IN TXT "v=spf1 include:example.com include:example.org -all"

This would direct check_host() to, in effect, check the records of example.com and example.org for a "pass" result. Only if the host were not permitted for either of those domains would the result be "fail".

Whether this mechanism matches, does not match, or returns an exception depends on the result of the recursive evaluation of check_host():'

So it's possible that the 'hard fail' in the aspmx.sailthru.com SPF is causing the bounce

Cheers Jodi

----- Original Message ----- From: "Jean-Francois Pirus" To: "Paul Willard" , nznog(a)list.waikato.ac.nz Sent: Tuesday, February 21, 2017 3:02:15 PM Subject: Re: [nznog] Xtra and SPF

Here's an example of an Xtra bounces which looks like soft fail but which includes a hard fail.

So I'm assuming that a hard fail anywhere takes precedence, does anybody know the rules, I could not find any references.

sailthru.com. 10800 IN TXT "v=spf1 include: aspmx.sailthru.com include:_spf.google.com include:_netblocks.zdsys.com ~all"

aspmx.sailthru.com. 900 IN TXT "v=spf1 ip4: 64.34.47.128/27 ip4:64.34.57.192/26 ip4:65.39.215.0/24 ip4:192.64.236.0/24 ip4:192.64.237.0/24 ip4:173.228.155.0/24 ip4:192.64.238.0/24 ip4:204.153.121.0/24 -all"

_netblocks.zdsys.com. 54000 IN TXT "v=spf1 ip4: 192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ip4:188.172.128.0/20 ip4:216.198.0.0/18 ~all"

_spf.google.com. 55 IN TXT "v=spf1 include:_ netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

...

I'm getting mail bouncing with ~all spf record soft fail .. and xtra (actually smx) are rejecting.

Could be that they don't like me :)

On Wed, Feb 8, 2017 at 3:57 PM, Brian E Carpenter mailto:brian.e.carpenter(a)gmail.com> wrote:

On 08/02/2017 15:34, Mark Foster wrote: ... > Someone mentioned mailing lists; decent ones rewrite the envelope and > don't break SPF.

Or rather, are not broken by SPF. Unfortunately, the same is not

On 21/02/17 14:17, Paul Willard wrote: true

...

of DMARC. There's still no good solution for lists or forwarders

that

...

are broken by DMARC. Glen, I fear that DMARC problems are in your future.

Brian

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz mailto:NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog https://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog

-- Jean-Francois Pirus | Technical Manager francois(a)clearfield.com | Mob +64 21 640 779 <+64%2021%20640%20779> | DDI +64 9 282 3401 <+64%209-282%203401>

Clearfield Software Ltd | Ph +64 9 358 2081 <+64%209-358%202081> | www.clearfield.com _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog

So I'm assuming that a hard fail anywhere takes precedence, does anybody know the rules, I could not find any references.

https://tools.ietf.org/html/rfc7208#section-8.5 A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none". The ADMD believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal. So technically you could reject on a softfail but you shouldn't. But the spammy-ness could be increased for example on the message which may make the message be rejected.