In reply to a post by marjohn56:

So you would rather Zen not implement a global standard because it means your upstream mail forwarder has been lax in implementing a technology that has been on the horizon for a long time?

That would mean Zen would have to check every single mail forwarder that connects to their systems before they implement it, and that isn't ever going to happen.

The problem is NOT of Zens' making, the problem is poor implementation by the upstream host.

I'm sorry, but the problem is entirely of Zen's making. RFC7208 doesn't say that an email that fails SPF must be rejected, it makes it clear that the decision to do so is a local policy.

And it goes on to state in D.3 that if the owner of the mailbox wishes to trust the mediator, ie the forwarder, then he should be able to do so.

So as Zen are refusing to provide a means to allow forwarders or individual mailboxes to be whitelisted, I would say that their implementation is equally poor.

I agree with the other posters about the appalling way this has done by Zen. No warning or notification - at the very least something should have been posted in the forums or in the knowledge base about their changes

Many ISPs no longer provide email mailbox services ; due to the amount of hassle us customers give them over things like this.

I suggest email is bought from an email provider, and internet access from an ISP. Keep the things separate, then you can change them independently.

That you continue to fail to understand that the problem is for you to fix rather than Zen suggests that you may have far more serious problems to deal with than just your e-mail.

In reply to a post by rbn197:

In reply to a post by marjohn56:

So you would rather Zen not implement a global standard because it means your upstream mail forwarder has been lax in implementing a technology that has been on the horizon for a long time?

That would mean Zen would have to check every single mail forwarder that connects to their systems before they implement it, and that isn't ever going to happen.

The problem is NOT of Zens' making, the problem is poor implementation by the upstream host.

I'm sorry, but the problem is entirely of Zen's making. RFC7208 doesn't say that an email that fails SPF must be rejected, it makes it clear that the decision to do so is a local policy.

And it goes on to state in D.3 that if the owner of the mailbox wishes to trust the mediator, ie the forwarder, then he should be able to do so.

So as Zen are refusing to provide a means to allow forwarders or individual mailboxes to be whitelisted, I would say that their implementation is equally poor.

I agree with the other posters about the appalling way this has done by Zen. No warning or notification - at the very least something should have been posted in the forums or in the knowledge base about their changes

Yawn !

Well done Zen at least now the lazy Mail forwarders will have to comply or go bust

Setting up an SPF policy and then not rejecting mail that does not comply is pointless they lazy forwarders will continue being lazy. Carrot and Stick
This time the stick was used

dont know what zen's setup is like in regards to whitelisting.

But generally I dont recommend doing remote forwarding, forwarding I do is only ever local or using gmail.
Gmail forwarded to myself from netflix does arrive but only after a delay.

My own personal servers and other servers I manage will greylist on a SPF failure, based on experience of managing servers I dont consider outright blocking on SPF failures a good idea as is too many hosts out there even now in 2017 that have misconfigured SPF.

In reply to a post by jchamier:

Assumptions in technology industry are dangerous.

Like the assumption that everyone else will adopt SRS?

My mail server will only accept mail for forwarded addresses that will not cause an SPF failure when onward delivery is attempted. If someone wants their mail delivered then they can add me to their SPF record. I�m loathed to implement SRS because it only serves to encourage people to do more of this sort of thing. Not content with mangling the envelope sender people are now pushing things like DMARC which meddles with the From header of the message as well.

I can�t really blame Zen for rejecting mail based on SPF records as they are simply following the sender�s instructions. In my opinion the fault lies with with the originating domain making poor policy decisions.

I totally agree with you.
From what I have read about SRS it modifies the FROM Header, so that in a way would break DKIM if the message already has DKIM headers included.

So wouldn't SRS make things worse and at the same time open you up to get blacklisted for spamming?

Paul

In reply to a post by PaulKirby:

From what I have read about SRS it modifies the FROM Header, so that in a way would break DKIM if the message already has DKIM headers included.

SPF/SRS work on the envelope (the bit that SMTP servers use with and the user does not see) whilst DKIM works on message headers (the bit that shows up in your email client). SRS does not break DKIM.

In reply to a post by PaulKirby:

So wouldn't SRS make things worse and at the same time open you up to get blacklisted for spamming?

Without SPF/SRS if you accidentally forward too much spam you run the risk of the onward host blacklisting your IP address. With SPF/SRS you risk them blacklisting your domain name too. Neither is desirable but SRS makes it worse to be a forwarding host.

In reply to a post by AndyS:

In reply to a post by PaulKirby:

From what I have read about SRS it modifies the FROM Header, so that in a way would break DKIM if the message already has DKIM headers included.

SPF/SRS work on the envelope (the bit that SMTP servers use with and the user does not see) whilst DKIM works on message headers (the bit that shows up in your email client). SRS does not break DKIM.

Well I know SPS is only using a SPF / TXT DNS Record and that's it and the server check that to see if that mail server is allowed to send emails on behalf for that domain.
Just that the SRS info wasn't that clear, but yeah, so it uses the bit after the EHLO .... part, ok, I was wondering that.

In reply to a post by AndyS:

In reply to a post by PaulKirby:

So wouldn't SRS make things worse and at the same time open you up to get blacklisted for spamming?

Without SPF/SRS if you accidentally forward too much spam you run the risk of the onward host blacklisting your IP address. With SPF/SRS you risk them blacklisting your domain name too. Neither is desirable but SRS makes it worse to be a forwarding host.

Yeah, that's what I thought.

Well atm our forwarding is working ok with just SPF and people are getting their emails, so I guess I will hold off on the SRS patch / plugin until its really needed.

Paul

In reply to a post by savamac:

Does this explain my lack of emails from BA.com, Nextdoor.co.uk, Homebase.co.uk and others (which I can't list as I can't tell if they've sent me emails or not) ??

What's going on ?

So (as the young folk say), despite numerous facile / insulting / hostile posts in this thread, I can now report that Namesco (after a bit of prevarication) eventually responded with :

"Hi there

Thank you for contacting us

I have spoken to one of our engineers regarding this issue, they have notified me that this issue is caused by our servers not having SRS records in place which causes this issue.

Unfortunately they are aware of the issue but as of yet no correction can be implemented to add these to our system at this time.

This ticket will be marked as closed, this does not mean the issue is resolved. Simply reply to this ticket using your control panel in order to re-open the ticket. There is no need to open a new one."

So there you are.

I am now investigating having Zen host my domain - wish me luck.

PS I almost couldn't be bothered posting any more to this thread.... I worked in IT for 35 years (with a lot of experience of change management), and am not impressed by the quality of systems and "enhancements" foisted on the general public - there seems to be limited (if any) testing of changes, with regression planning being an afterthought.