The issue I have is that any attempt to connect to any of those smtp servers using SSL/465 (via Spark VDSL) returns a frozen login attempt and eventual timeout error. Trust me I have spent two days trying this.

The questions are:

Is it Spark blocking access to Vodafone smtp SSL logins?

or

Is it Vodafone blocking my Spark VSDL connection?

Spark only filter port 25 (non secure SMTP).

it is my undertanding that vodafone actually use different smtp servers for the older paradice emails, this is a relic of them not merging email systems unfortunately.

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

smtp.clear.net.nz with p/ username is the correct SMTP server for paradise.net.nz when accessing outside the Paradise network.

smtp.paradise.net.nz is only for use on the Paradise network, which is all but gone except perhaps for non-FibreX cable and remaining business customers on legacy plans, maybe they have since included the 'Red'/ihug parts I don't know.

yitz: smtp.clear.net.nz with p/ username is the correct SMTP server for paradise.net.nz when accessing outside the Paradise network. smtp.paradise.net.nz is only for use on the Paradise network, which is all but gone except perhaps for non-FibreX cable and remaining business customers on legacy plans, maybe they have since included the 'Red'/ihug parts I don't know.

p/ is really a complicated setup.. really feel for their customers, explains why Spark have so many using the relay system.

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

yitz: smtp.clear.net.nz with p/ username is the correct SMTP server for paradise.net.nz when accessing outside the Paradise network. smtp.paradise.net.nz is only for use on the Paradise network, which is all but gone except perhaps for non-FibreX cable and remaining business customers on legacy plans, maybe they have since included the 'Red'/ihug parts I don't know.

Thanks for the confirmation.

Yep, the p/ login via clear.net.nz and password is working great via the Spark connection but only on port 25 and no SSL.

Ignoring the 'paradise aspect', I'm still confused as to why trying to access ANY vodafone smtp server on port 465 with SSL active will start to login, freeze then timeout without prompting for a password?

I'm still confused as to why trying to access ANY vodafone smtp server on port 465 with SSL active will start to login, freeze then timeout without prompting for a password?

As far as I can tell none of Vodafone's SMTP relays support SSL. Because non-SSL port 25 outbound traffic is blocked as part of security best practise on Spark and other ISPs you will not be able to access them easily (unless you whitelist port 25 for your broadband connection as you have done).

The alternative is of course authenticating your third party domain email address with Xtra servers (as has been the case with Yahoo Xtra) but as of yet it is unknown whether this facility is part of Xtra email on the new SMX platform.

I'm still confused as to why trying to access ANY vodafone smtp server on port 465 with SSL active will start to login, freeze then timeout without prompting for a password?

As far as I can tell none of Vodafone's SMTP relays support SSL. Because non-SSL port 25 outbound traffic is blocked as part of security best practise on Spark and other ISPs you will not be able to access them easily (unless you whitelist port 25 for your broadband connection as you have done). The alternative is of course authenticating your third party domain email address with Xtra servers (as has been the case with Yahoo Xtra) but as of yet it is unknown whether this facility is part of Xtra email on the new SMX platform.

This would come into a support issue for orcon rarther than spark if you are using their SMTP settings, i'd probably check password authentication as you may have been using a different password against the xtra servers.

That works! I just set it to use the same password as my incoming one and it's fine! Thanks so much, that's a great help.

I would have thought being able to relay email (authenticated / secured) is a key function of an ISP's service.

If my small hosting provider says "use your ISP, they are better equipped to send mail" - did I miss the memo and it's now ok for ISPs to begin to silently refuse it? To throw these clients onto the heap of blacklisted senders and domains? To silently ban "older" protocols and clients which are known to be perfectly secure enough to prevent unauthorised relaying (spam)?

A suggestion not to use the temporary workaround because it might break, when the only alternative is it not working at all.

An opinion that (home) businesses shouldn't use residential broadband for emails because there's no SLA (does that mean there's a higher level of service implied for the basic connection, or is it the same?).

(Maybe I did miss that memo - just saying I didn't see it - I really thought that the ability to securely relay outgoing email was a key function of ISPs to promote general net security and the fight against spam, and the days of "best effort only" residential delivery were effectively behind us with fibre and all.)

I have been unable to send email from normal email address - at all - for getting up to 2 weeks. If something goes wrong with my password on this forum, I can't fix it, because I can't send from my email address. How does this improve net "security"?

The problem appears to be a growing acceptance that "broken" is the new "supported". In the bad old days it used to be that companies couldn't get their act together, now it seems they are eager to tick a box which allows them to provide "broken" as a bona fide service.

A couple of days ago I was pleading with Spark support over chat to try to forward the message to Spark to change me over to SMX, I had no idea this had happened and was the cause of the problem, from what this thread says. She had no idea what was going on, other than "getting same issue from huge number of customers" and nobody was telling them anything.

I suppose its business, but I wouldn't have thought I'd have to look for alternative ISPs because one company I've been with for yonks has decided they are not interested in providing what I believed was a core service. Yes another option is to try to find a workaround, but Spark are directly in the firing line here.

I would have thought being able to relay email (authenticated / secured) is a key function of an ISP's service.

Its part of your email service. Xtra do allow you to send email, however only as the xtra address that they are selling you as part of the internet connection. If an ISP doesnt offer email like 2degress, bigpipe and many others then I would not say anything to do with email is a key part of the ISPs services at all.

If my small hosting provider says "use your ISP, they are better equipped to send mail" - did I miss the memo and it's now ok for ISPs to begin to silently refuse it? To throw these clients onto the heap of blacklisted senders and domains?

If your small provider says that they dont want to send emails for you, then you need to find one that does or else use a third part SMTP service

To silently ban "older" protocols and clients which are known to be perfectly secure enough to prevent unauthorised relaying (spam)?

The problem is that while the protocols are secure "enough" to stop spam being sent, having older protocols enabled will get lower scores when assessed for security, and when the details for authentication are the same as those to check email, allowing those obsolete protocols from 15 year old operating systems to run allows for people to insert themselves in the middle of people accessing their secure email box potentially getting their authentication details and therefore their emails.

A suggestion not to use the temporary workaround because it might break, when the only alternative is it not working at all.

An opinion that (home) businesses shouldn't use residential broadband for emails because there's no SLA (does that mean there's a higher level of service implied for the basic connection, or is it the same?).

(Maybe I did miss that memo - just saying I didn't see it - I really thought that the ability to securely relay outgoing email was a key function of ISPs to promote general net security and the fight against spam, and the days of "best effort only" residential delivery were effectively behind us with fibre and all.)

I have been unable to send email from normal email address - at all - for getting up to 2 weeks. If something goes wrong with my password on this forum, I can't fix it, because I can't send from my email address. How does this improve net "security"?

The problem appears to be a growing acceptance that "broken" is the new "supported". In the bad old days it used to be that companies couldn't get their act together, now it seems they are eager to tick a box which allows them to provide "broken" as a bona fide service.

A couple of days ago I was pleading with Spark support over chat to try to forward the message to Spark to change me over to SMX, I had no idea this had happened and was the cause of the problem, from what this thread says. She had no idea what was going on, other than "getting same issue from huge number of customers" and nobody was telling them anything.

I suppose its business, but I wouldn't have thought I'd have to look for alternative ISPs because one company I've been with for yonks has decided they are not interested in providing what I believed was a core service. Yes another option is to try to find a workaround, but Spark are directly in the firing line here.

yeah, spark have handled the change pretty badly with their communication, but to expect them to run servers to allow you to relay mails out which are nothing to do with the mail service you get from them with a high level of support for something that comes free with a cheap internet connection is a bit unrealistic IMO.

The service mostly works perfectly, people using current supported software are able to send and recieve emails using the spark provided servers and their supplied .xtra.co.nz email address.

I say good on spark for being the first to treat email authentication seriously. They need to after the yahoo fiasco, much better than some of the other ISPs that still allow for insecure pop and smtp, and sending emails with no authentication whatsoever when you are coming from one of their own IP ranges.

Will remind you my comments are not of my employer but my own, and yes i do have very clear lines drawn in the sand in that case.

adx:I would have thought being able to relay email (authenticated / secured) is a key function of an ISP's service.

If my small hosting provider says "use your ISP, they are better equipped to send mail" - did I miss the memo and it's now ok for ISPs to begin to silently refuse it? To throw these clients onto the heap of blacklisted senders and domains? To silently ban "older" protocols and clients which are known to be perfectly secure enough to prevent unauthorised relaying (spam)?

Now, those older clients could potentially use non ssl methods of connections, however spark recommends purely using the SSL setups from the start.

Once again, your security first. Plain text can be snooped, can be intercepted, can be modified.

There was no silent ban, a security upgrade was put in place which caused these clients to no longer work. Spark does not create the mail applications, spark simply supplies the service they connect to.

As microsoft are no longer supporting these applications, the application has not received the required upgrades to support the security requirements.

The fact that these clients no longer work is purely up to the third parties that create these applications.

Please, go try to use IE 6.0 to browse to Google over HTTPS, The security requirements do not match and thus that Browser can not be used. IE 6.0 is the equivalent to Outlook Express in this situation.

Outdated browsers are accepted, you just need to upgrade them. Why not look at mail applications like this?

In any case i handle for this particular situation I clearly offer a free alternative aswell. I am not out to put the customer out, nor is spark.

adx:A suggestion not to use the temporary workaround because it might break, when the only alternative is it not working at all.

Simple fact is, If you are using the relay system, that is a service provided to help you get your mail through as your provider has not setup the correct things on their side to work.

In this day and age, we are often on mobile devices, Laptops or whatever. You go around to tons of different connections, You may be using a Coffee shop behind an Orcon connection, Next day at a bank behind a spark Connection only to go to your home and be behind a Vodafone connection. In this instance, the relay system would Only work for that spark connection unless port 25 unblocks are on every one of those connections which is highly unlikely.

Second to this is, there are a few large providers out there that do not support SSL connections fully on their older email platforms. a large provider in mind in this certain case, Also does port 25 filtering by default.

This is pretty ironic considering the port 25 filtering is for security and yet the secure option is not offered for their own services. End of the day, this should be a basic service offered for any email service.

adx:An opinion that (home) businesses shouldn't use residential broadband for emails because there's no SLA (does that mean there's a higher level of service implied for the basic connection, or is it the same?).

(Maybe I did miss that memo - just saying I didn't see it - I really thought that the ability to securely relay outgoing email was a key function of ISPs to promote general net security and the fight against spam, and the days of "best effort only" residential delivery were effectively behind us with fibre and all.)

I have been unable to send email from normal email address - at all - for getting up to 2 weeks. If something goes wrong with my password on this forum, I can't fix it, because I can't send from my email address. How does this improve net "security"?The problem appears to be a growing acceptance that "broken" is the new "supported". In the bad old days it used to be that companies couldn't get their act together, now it seems they are eager to tick a box which allows them to provide "broken" as a bona fide service.

This is my personal opinion Yes, Any Business at all should own their own domain and use it IMO. I come from a very strong IT Background and personally really value seeing this.

Using an ISP provided email service (not counting domain email services provided by ISP's here) IS locking you into some sort of corner. - Changing isps likely lands you with a large fee for keeping the Email inbox open without services.

Best effort service is still definitely a thing, Having fibre makes no difference to this. a Business based email service gives you ground to stand on when things go wrong to say, hey i pay for X promise for service to be restored. There is no grounds for this with an xtra email service being a free addon your your BB account.

Yes, spark would love to resolve the Xtra mail issues, There are new teams developing recently Purely to resolve these issues as fast and as professionally as possible.

When correct procedure is followed for identified issues in this situation, there IS a follow up process to ensure things get back online.

adx:A couple of days ago I was pleading with Spark support over chat to try to forward the message to Spark to change me over to SMX, I had no idea this had happened and was the cause of the problem, from what this thread says. She had no idea what was going on, other than "getting same issue from huge number of customers" and nobody was telling them anything.

I suppose its business, but I wouldn't have thought I'd have to look for alternative ISPs because one company I've been with for yonks has decided they are not interested in providing what I believed was a core service. Yes another option is to try to find a workaround, but Spark are directly in the firing line here.

Unfortunately Chat agents are not Broadband trained, which is the skillset for handling xtra mail issues.

This agent should have referred you onto a callback to do trouble shooting, This agent would have also had access to the internal outage system and Updates being sent out which very clearly explain the process. I can not speak for how this was handled for you apart from indicating the answers you have indicated here are not that of which a Broadband agent will supply you.

If you are having further issues with your xtra email service, Please provide a Case number and i will make sure the correct procedure has been followed here. I can not promise to magically fix your issues right this moment but definitely want to make sure you are correctly looked after here.

Lastly, just a general thing about these xtra issues.

Agents have been a little bit confused in the initial weeks, There were multiple issues that were not clearly separated from each-other at first which caused confusion.

At first known support for the security changes were up in the air. Sometimes an agent could make a incorrect conclusion due to lacking a key detail, this happens.. End of the day we are only human and mistakes happen.

On a lighter note on SMX, As of last night the first batch of addresses were fully moved across.

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

If my small hosting provider says "use your ISP, they are better equipped to send mail"

....Then I would be looking at alternative email hosting services. Seriously .And not rely on a system that been unreliable for years , for anything but home email.Lets be honest, xtra is a basic email service for home users, not for business's . Want business class email, plenty of reliable options , incl from Spark.

:-)

"yeah, spark have handled the change pretty badly with their communication,"how about the most simple thing, fix the Spark email status page . Some honesty please. It changes every other day Own the issues . Admit the issues . Show the last few days history of issues, so at least people can see why they didnt get email the previous day. Shouldnt have to go to forums to find workarounds or temp fixes because there is nothing on the Status page