Re: [nznog] Xtra and SPF

On 8/02/2017 1:51 p.m., Glen Eustace wrote:

...

On 8/02/2017, at 1:15 PM, Criggie mailto:criggie(a)criggie.org.nz> wrote:

Its not really an answer, but SPF is doing what its told.

Agreed.

Yes. If you choose to publish a -all record you are explicitly asking mail platforms that enforce SPF, to reject email delivered from any place that isn't declared within the SPF record. It's well known that this breaks mail forwarding, and forwarding that doesn't also rewrite the envelope has been 'broken' for a long time. The SPF standard is hardly new (RFC4408, 2006). From earlier:

It seems that there are folks who still believe that SPF is a good thing and have ‘-all’ on their record. SPF is indeed a good thing, as part of a wider anti-spam toolset. Publishing -all more or less instructs the SPF-capable mail server on what it is expected to do.

Someone mentioned mailing lists; decent ones rewrite the envelope and don't break SPF. old-school .forward (or equivalent) relaying _does_ break SPF. SRS is the solution. http://www.openspf.org/SRS is pretty straightforward to follow.

...

So either you have to convince Xtra's mail to disable their rejections (unlikely) or you have to get something into the customer's SPF record to permit your hosts to send.

The domains with the hard fail SPFs are not my customers so I have no control over them at all. The issue is people emailing from those domains to domains we do host and they are getting the bounce and blaming us. (perhaps rightly so, but this has only become an issue in the last week and even then for only 2 customers)

Xtra have the right to enable SPF enforcement; I wonder if this is to do with them moving their email to SMX's technology (which includes SPF enforcement). In terms of blame, the forwarding platform is unfortunately the part that's 'non compliant'. SRS, or using a 'mail pull' from the end-target system (if supported; Not sure Xtra do, might pay to clarify) is the solution. As an interim position you can point out to senders that their domain having a -all SPF record published is going to make life difficult for platforms that use mail forwarding, but I doubt that'll be sustainable :-) Senders who publish SPF hard-fail records need to also (by design) apply some fairly rigid sending restrictions (so, Speaking personally, i've got some mail domains I handle with 'classic' forwarding but I have also hosted pop/imap services as an alternative arrangement... in the knowledge that the use of 'classic' forwarding is a timebomb for recipients who're SPF enabled. 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.