Xtra mail blocking authenticated email addresses from sending via SMTP server?

Forums › Spark New Zealand (including Skinny and BigPipe) › Xtra mail blocking authenticated email addresses from sending via SMTP server?

1 | 2 | 3 | 4 | 5 | 6 | 7

30048 posts

Uber Geek
+1 received by user: 9455

Trusted

Lifetime subscriber

#1720569 15-Feb-2017 12:12

Every year that Port 25 comes up, it gets hammered and rightly so. Steve Biddle commented a couple of years ago, that SSL has been here for 15 years, make that 17 now. Every ISP that provides email should use SSL. Its the internet. Security matters. Every ISP that provides email, should "provide email", not offer part of a service and expect others to pick up the tab, the security issues and use server space and time and capacity

adx

21 posts

Geek
+1 received by user: 6

#1720630 15-Feb-2017 13:45

From those replies, I can see that my thinking is a little outdated, a possibly I suspected and am fully willing to accept.

Back in the day when data cost mattered, I'd get charged for outgoing emails, incoming to my server, then outgoing again - even for local emails with a phew photos. My hosting providers actively discouraged sending via them, because of their inability to keep track of who was blacklisting their little unknown server (and support issues this entailed). An "ISP" was the provider of the real-time data connectivity service (which includes sending emails in most peoples' minds - you press the send button and watch it leaving your computer in real-time). A hosting service held the files that made up your website, and also received and stored emails to the domain(s) until the owner wanted to get them. Although providers wanted to sell both, they really worked much (much) better when completely separate - I also learned the hard way to keep domain management as separate as possible too. In this environment, it made every bit of sense to send all email via the ISP, and up until a few days ago, all ISPs I thought supported this as a reasonably core function.

I'm ready to accept that the way I've been doing it is a product of those old issues, and it is conceptually wrong (or at least odd) to send and receive emails using different services. Data costs are a non-issue now, and local traffic is free for most NZ hosting / VPS providers (well, mine anyway). I am guilty of putting too much trust in a system (Yahoo mail) that I knew was falling over, and am up the creek without a paddle for enabling my own solution (I should be able to) because I don't have the time to test it properly (for security, unauthorised relaying etc).

But I'm not completely wrong. The need for such a thing as a "third party SMTP service" is evidence of that. Chorus or whoever not providing it I can understand (and in some ways is something I've wanted - kind of naked internet connections), but an internet service provider? It's kind of what they're for (or were - willing to accept that).

Security - I see the point re the out and about uses today, and agree there really is no place for unencrypted connections to email services over public WiFi. It's something I've had to stop myself and think "hang on, this is a very bad idea" more than once when out and about. But to silently remove a customer's service on the basis of a vague unsubstantiated belief that their version of SSL might be "too old" is what I have the problem with. It might well be, but no way do I agree with silently denying support for protocols because some products that used to use them are no longer supported by their developers. That's conflating two different issues and is going to result in security problems if it hasn't already (defining new=secure, old=insecure). That, or removing support without warning or evidence, is possibly worse than the string-and-sellotape approach that holds together the port 25 stuff - because they know its dirty. Deferring to blanket security scores and statements of support isn't taking security at all seriously IMO.

I disagree about there being no silent ban. A security upgrade which deliberately stops things working without notice is a silent ban. There wasn't alignment with the timeframe of dropping of support of some third party product AFAIK, so how are people to know that was the reason? It wasn't the reason, it was a choice made by Spark and fashionably pinned on something else. Noble as the desire may be or not, it doesn't excuse the approach.

I pay Spark for what I believed was the ability to send emails - I would be just as miffed with Google if I paid it and it stopped working with my browser without warning. I do agree email is a use where security should matter more than random browsing for whether it's going to rain tomorrow. On the flip side a browser is "just a browser". An email client can be some horribly complex CRM system or store and index 100k emails. The implication from Spark is even to upgrade your OS as a solution. This is so much bigger for many people than upgrading a browser.

Re the best effort thing, I was probably getting ahead of myself believing that services had matured to the point where the need for things like an SLA is diminished. Of course it's not, just the nature of the problems has changed - the connections seem to suffer less outages, but the service that supports those connections seems to actively generate outages (as is the case here).

Wo, essay. Anyway, I do stand largely corrected on many of these issues and am grateful for the quick replies. It sounds like the problem in my case is that Spark has dropped all support for sending "from" my domain and that's that. If this is genuinely a thing, and I was always going to have to find another solution, I'm ok with that, but a bit more (or any) technical detail from Spark would have been appreciated. I'm using Pegasus Mail still, latest 2016 version, post-heartbleed fix, so I don't think this is an SSL issue.

lxsw20

3689 posts

Uber Geek
+1 received by user: 2175

Subscriber

#1720634 15-Feb-2017 13:52

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

More pointing out it didn't make sense for their helpdesk to publish the information for a quick fix. All that will do, come the day of Yahoo being cut off, is cause another massive influx of angry customers and calls. IMO Spark were better off fixing the issue once, rather than handing people a quick fix that would just lead to another helpdesk call. To you and I doing a quick server change is easy, to many many Spark customers it is not.

richms

29104 posts

Uber Geek
+1 received by user: 10219

Trusted

Lifetime subscriber

#1720635 15-Feb-2017 13:55

IMO any consumer ISP that chooses to offer an outgoing SMTP service should strictly enforce the sender of emails should be either the use themselves or at worst case be at a domain that the ISP uses for email even if the user doesnt match the one that authenticted with the server.

To allow any address to go out will make the ISPs server be usable for a joe job attack on other people, getting them a crapload of bouncebacks that should never have been sent in the first place.

Allowing unauthenticated SMTP, non SSL, and other bad practices for so long is why email is such a spammy mess. I support any step towards cleaning it up so the absurdity of anonymous emails coming from random IP addresses claiming to be any random person is eliminated.

Richard rich.ms

adx

21 posts

Geek
+1 received by user: 6

#1720658 15-Feb-2017 14:32

lxsw20:

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

More pointing out it didn't make sense for their helpdesk to publish the information for a quick fix. All that will do, come the day of Yahoo being cut off, is cause another massive influx of angry customers and calls. IMO Spark were better off fixing the issue once, rather than handing people a quick fix that would just lead to another helpdesk call. To you and I doing a quick server change is easy, to many many Spark customers it is not.

Ah I see, makes sense. But that is a very non-customer-centric way of doing things. In doing that Spark (or any other company with the same commercial values, which is "all of the big ones") is putting their own costs and ease above the most basic of functionality of the service they exist to supply. Customers are stuck without email at all (some are, I've just edited my Gmail reply-to to be my domain email so I could almost pretend it's ok). "Big company" is more worried about how an angry backlash might affect it, than the anger itself. Sign of the times and probably a big ole "welcome to the market". Not saying Spark desires it, but they put themselves in this position, kind of yet again. Yet again it's at the business level, not the technical level. And it's not Spark per se, it's a commercial mindset that I'm really starting to think is going bring about the end of civilisation before idiot governments or climate change gets us - what happens when food suppliers start doing this?! "Yeah we know you haven't eaten in a couple of weeks, really sorry all your suppliers have the same issue, but it turns out we don't support your age any more, no one should, you ought to have known you were too old, yes we have emergency food nearby but probably better not to let you access it in case it provides fuel for an angry response, sorry bout that." (Getting a bit off track there.)

I was going to say "but the few people who could fix the issue themselves are the most likely to be able to do it again without needing support so why not tell them?" but I accept we are a relatively rare few and the bulk of people are so desperate they will try any ham-fisted solution to fix it, invariably making it worse. Spark must feel really out on a limb on this one. But even more untouchable. It's not a nice situation to be in, on either side.

adx

21 posts

Geek
+1 received by user: 6

#1720671 15-Feb-2017 15:06

richms:

IMO any consumer ISP that chooses to offer an outgoing SMTP service should strictly enforce the sender of emails should be either the use themselves or at worst case be at a domain that the ISP uses for email even if the user doesnt match the one that authenticted with the server.

To allow any address to go out will make the ISPs server be usable for a joe job attack on other people, getting them a crapload of bouncebacks that should never have been sent in the first place.

Allowing unauthenticated SMTP, non SSL, and other bad practices for so long is why email is such a spammy mess. I support any step towards cleaning it up so the absurdity of anonymous emails coming from random IP addresses claiming to be any random person is eliminated.

I kind of disagree. Gmail do this - free third part service and entirely up to them.

As long as the headers identify the real source of the email, and it is not open to the public, there should be no problem with spam or joe jobs. As it is, the quickest (or really only) way of stopping a joe job is to complain about the unauthorised sources of the bouncebacks (not the bounces themselves), doing 6 per minute gets a spammer's campaign shut down faster than they would have ever thought possible.

There is a lot that could be done to prevent spam, that isn't, or is done so badly it might as well not be there. Probably the "no one wants to take (or share) responsibility" reason. Absurd mess it is, that has always surprised me. ISPs are a part of the system, them and the RBLs have become sort of de-facto cops, for different reasons. Well that's how it worked when I last looked.

If an ISP allows authenticated emails to be sent from "any old address" (or ones that are set up), then by my mind that is no more open to abuse than a user of an email service / SMTP service. The case I'm making is that if it needs to be done, then the ISP is the logical place to send mail from. They just don't want to touch the mess that is email policing.

Ok, nuff of that before it looks too much like I'm spamming this forum...

Samsung

Shop now on Samsung phones, tablets, TVs and more (affiliate link).

yitz

2239 posts

Uber Geek
+1 received by user: 594

#1720690 15-Feb-2017 15:33

So apparently the first batch of users have been moved over to SMX?

Is anyone able to comment on whether there exists the facility to add third party sending addresses?

hio77

'That VDSL Cat'
13036 posts

Uber Geek
+1 received by user: 3896

ID Verified

Trusted

Lizard Networks

Subscriber

#1720692 15-Feb-2017 15:41

yitz: So apparently the first batch of users have been moved over to SMX? Is anyone able to comment on whether there exists the facility to add third party sending addresses?

my understanding of the third party authentication process.

How exactly to add NEW accounts is yet to be completely set in stone, it will be part of the self service tools however.

Any Already authenticated accounts should have been transferred over to SMX but visibility to this may be limited at this point in time (in full transparency i can state that as it is my day off today i am not aware of what functions our SMX admin panel offers to an actually fully transferred account as of yet)

I am told the facility will exist on SMX, and SMX have already made changes to their system to support this - look back to the inital jump when first lot of third party issues arose, it was after here that was added.

I am also told historically the third party process was not intended to be a heavily used feature however was pass around the center at the time and became the goto solution to resolve customers issues on the spot

I am very much of the opinion that this work around should not have been put in place unless attempts were made to resolve this directly with the third party email provider first were made and failed.

Take the above as hearsay however, as i said told not informed.

#include <std_disclaimer>

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

nunz

1421 posts

Uber Geek
+1 received by user: 314
Inactive user

#1725871 24-Feb-2017 19:51

kiwigeek1:

Just use yahoos smtp server for now or when it dont work.. I setup 2 accounts .. one using yahoos only settings

and xtras settings since at the moment they both access the same files until they fully switch

Plus one from me - but found an issue with that today.

mail.yahoo.co.nz is now using a cetificate that fails - says it is a legacy or superceded domain on the cert and trying to download or access the cert to add it to the okay list for authentication leads to server time outs.

smtp.mail.yahoo.com

pop.mail.yahoo.com

imap.mail.yahoo.com

Don't use *.mail.yahoo.co.nz or *.yahoo.co.nz addresses as certificate issues now.

Currently on another hour long wait as valid email address and passwords fail to log on to the web portal but work for mail via already setup outlook connection using *.mail.yahoo.com Fails using fully authenticated third party address and the native @xtra address.

nunz

1421 posts

Uber Geek
+1 received by user: 314
Inactive user

#1725880 24-Feb-2017 20:04

richms:

IMO any consumer ISP that chooses to offer an outgoing SMTP service should strictly enforce the sender of emails should be either the use themselves or at worst case be at a domain that the ISP uses for email even if the user doesnt match the one that authenticted with the server.

To allow any address to go out will make the ISPs server be usable for a joe job attack on other people, getting them a crapload of bouncebacks that should never have been sent in the first place.

Allowing unauthenticated SMTP, non SSL, and other bad practices for so long is why email is such a spammy mess. I support any step towards cleaning it up so the absurdity of anonymous emails coming from random IP addresses claiming to be any random person is eliminated.

The problem with that is when you get a mobile phone, and a laptop and desktop at home, then it has traditionally been an issue as the ISPs themselves have failed to let authenticated mail be sent if you aren't on their domain as isp. ISPs are reaping what they have sown. If they actually had let authenticated mail be sent through their servers, even if your device was connected to another isp at the time then half the messed up work arounds we used over the last 10 years would have been null and void.

Xtra were quicker off the mark with authenticated SMTP than most but then botched that with port 25 blocking and a raft of other idiot processes banning emails until you filled out impossible to find forms they then ignored.

Vodafone / Clear / Paradise - probably the very worst. Still no authenticated smtp for clear last time I checked and I think paradise ditto. Trying to use vodafone authenticated smtp was a failure in the making if you were a clear or paradise client so thus loose spf records allowing you to send from other ISPs / anywhere becuase at the end of the day you arent allowed to put in enough isp names and ip addresses in an spf to cover all of NZs offerings.

I still wince at the number of mail servers we had on telecom / xtra networks where the client connected to them as the single point of authenticated mail sending, using anything other than port 25 / 26 and the support issues that raised. Then having to smart mail them through xtras smtp or send.xtra.co.nz as the sillybuggers blocked sending ports on their networks.

Again - the ISPs are their own worst enemies.

I always said I would never run commercial mail servers but now have three as it is still less painful to take that responsibility than deal with the crap using ISPs email has caused. Uptimes all reflect we only reboot once a year on some of the servers to get windows processes to pick up the renewed certificates. Happy clients. Happy IT guy.

tdgeek

30048 posts

Uber Geek
+1 received by user: 9455

Trusted

Lifetime subscriber

#1725891 24-Feb-2017 20:23

nunz:

richms:

IMO any consumer ISP that chooses to offer an outgoing SMTP service should strictly enforce the sender of emails should be either the use themselves or at worst case be at a domain that the ISP uses for email even if the user doesnt match the one that authenticted with the server.

To allow any address to go out will make the ISPs server be usable for a joe job attack on other people, getting them a crapload of bouncebacks that should never have been sent in the first place.

Allowing unauthenticated SMTP, non SSL, and other bad practices for so long is why email is such a spammy mess. I support any step towards cleaning it up so the absurdity of anonymous emails coming from random IP addresses claiming to be any random person is eliminated.

The problem with that is when you get a mobile phone, and a laptop and desktop at home, then it has traditionally been an issue as the ISPs themselves have failed to let authenticated mail be sent if you aren't on their domain as isp. ISPs are reaping what they have sown. If they actually had let authenticated mail be sent through their servers, even if your device was connected to another isp at the time then half the messed up work arounds we used over the last 10 years would have been null and void.

Xtra were quicker off the mark with authenticated SMTP than most but then botched that with port 25 blocking and a raft of other idiot processes banning emails until you filled out impossible to find forms they then ignored.

Vodafone / Clear / Paradise - probably the very worst. Still no authenticated smtp for clear last time I checked and I think paradise ditto. Trying to use vodafone authenticated smtp was a failure in the making if you were a clear or paradise client so thus loose spf records allowing you to send from other ISPs / anywhere becuase at the end of the day you arent allowed to put in enough isp names and ip addresses in an spf to cover all of NZs offerings.

I still wince at the number of mail servers we had on telecom / xtra networks where the client connected to them as the single point of authenticated mail sending, using anything other than port 25 / 26 and the support issues that raised. Then having to smart mail them through xtras smtp or send.xtra.co.nz as the sillybuggers blocked sending ports on their networks.

Again - the ISPs are their own worst enemies.

I always said I would never run commercial mail servers but now have three as it is still less painful to take that responsibility than deal with the crap using ISPs email has caused. Uptimes all reflect we only reboot once a year on some of the servers to get windows processes to pick up the renewed certificates. Happy clients. Happy IT guy

If your with Acme ISP, use their SSL settings.

If your with Joe ISP, use their SSL settings

And so on. Use your email providers SSL settings, no BB provider cares, as SSL is secure.

If your provider can only support 17 year old Port 25 smtp, use that, after asking your BB provider to unblock Port 25. They won't care, but don't use your BB providers servers, they do care, they don't want insecure, relayed email. Yes, you can authenticate as a third party, but why add more to the mix? Use YOUR email providers SSL or Port 25, don't involve the BB provider, they are quite happy to provide the internet connection.

Dyson

Shop now for Dyson appliances (affiliate link).

hio77

'That VDSL Cat'
13036 posts

Uber Geek
+1 received by user: 3896

ID Verified

Trusted

Lizard Networks

Subscriber

#1725892 24-Feb-2017 20:23

nunz:

The problem with that is when you get a mobile phone, and a laptop and desktop at home, then it has traditionally been an issue as the ISPs themselves have failed to let authenticated mail be sent if you aren't on their domain as isp. ISPs are reaping what they have sown. If they actually had let authenticated mail be sent through their servers, even if your device was connected to another isp at the time then half the messed up work arounds we used over the last 10 years would have been null and void.

Any authenticated mail cases are null in void when the recommended settings are used. There is no reason in this day in time that you should use a relay service, That is going to cause issues soon as you visit a friends, Change providers etc.

Using SSL configurations allows you to skip all the hassle and have your security, No work around just looking forward to where things should be at these days..

nunz:

Xtra were quicker off the mark with authenticated SMTP than most but then botched that with port 25 blocking and a raft of other idiot processes banning emails until you filled out impossible to find forms they then ignored.

Spark make port 25 unblocks easily found..

Spark.co.nz/port25

Search will also bring this up straight away, I can't speak for other ISP's

nunz:

Vodafone / Clear / Paradise - probably the very worst. Still no authenticated smtp for clear last time I checked and I think paradise ditto. Trying to use vodafone authenticated smtp was a failure in the making if you were a clear or paradise client so thus loose spf records allowing you to send from other ISPs / anywhere becuase at the end of the day you arent allowed to put in enough isp names and ip addresses in an spf to cover all of NZs offerings.

I still wince at the number of mail servers we had on telecom / xtra networks where the client connected to them as the single point of authenticated mail sending, using anything other than port 25 / 26 and the support issues that raised. Then having to smart mail them through xtras smtp or send.xtra.co.nz as the sillybuggers blocked sending ports on their networks.

Filtering port 25 by default is normal these days, i dont exactly understand why you look at this as playing silly buggers.

Vodafones support for email service is absolutely the bane of my existence at this time, 95% of the cases i deal with on this issue, Are Vodafone based services.

Vodafone do have an option for their paradise servers to add /p to the front of your username to be able to authenticate externally But this is not sparks job to setup Vodafone customers emails correctly.

Vodafone unfortunately do a horrible job at supporting customers through this process aswell, the lack of SSL support on many of their platforms and janky workarounds such as /p adds to the frustration.

Vodafone will not take ownership of this for customers and pass the blame, when technically it is Their product that is not working correctly.

nunz:

Again - the ISPs are their own worst enemies.

I always said I would never run commercial mail servers but now have three as it is still less painful to take that responsibility than deal with the crap using ISPs email has caused. Uptimes all reflect we only reboot once a year on some of the servers to get windows processes to pick up the renewed certificates. Happy clients. Happy IT guy.

I'm glad you keep your clients off ISP provided services, Business's should be on Business grade email address's.

The amount of business's that i deal with who have xtra email address's is astonishing.

I will say at this point, the issues with Authenticated email address's do seem resolved, There is a few edge cases however spark have a special back-end team who is going through double checking these cases and returning to be followed up.

The one case where this still will not work, Is clients that are unsupported by sparks network - EG Outlook Express does not support the SSL requirements.

#include <std_disclaimer>

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

adx

21 posts

Geek
+1 received by user: 6

#1725998 25-Feb-2017 00:47

Just an update on where I'm at: After my support chat a survey came through "How did we do?" or something along those lines, so I filled it in explaining some of the difficulties I had. Within a couple of days someone from Spark rang me about it - understood my problem(s) - and put me on to the tech team (not sure the exact words now). A guy from there rang and after asking how long I've been sending 'from' those addresses for ( = decade/s) added the 2 main aliases needed to get things running again, I'm assuming this is just one big semi-managed list. Whatever, it just worked. In a couple of hours I tested it and all working like it used to. Received headers no longer include Yahoo.

In the mean time I had set up SSL on my server, mostly working but having trouble authenticating. I could have got there but more things to maintain and worry about ongoing.

Fortunately I had Gmail, and they have SMTP, because without this, 2 weeks+ of no emails sent and I would have been 'spewing' (more so than my posts here...).

Which brings me back to my "case" that I made earlier: If mail has to be sent via SMTP, then unless you're big or using someone big, the ISP is the logical place to do that (because of spam). I don't see any alternative to that (other than ban small players). Personal or business should not matter because if the internet is working (connectivity, DNS) then there's no reason to expect that SMTP won't - provided the ISP can keep its servers up - another way of saying that if you're willing to accept the risk of a consumer connection, then it seems obvious that the risk of SMTP failing should not exceed that.

Although perhaps stretching the above case to the "edge", once a customer of the ISP is paying for this facility, and assuming it is their main way of sending emails, the only real reason that they should not be able to send authenticated email through it via some different reasonably-trusted connection (say of a friend, or a different mobile supplier), is lack of encryption should they get sloppy and think this applies to unsecured public WiFi as well. Other than that, the chances of a plaintext email connection being hijacked for spam are low - it's only visible to a computer on the friend's local network if it is on WiFi and running a sniffer, the rest will be going through switches and routers straight to the ISP. An encrypted SMTP connection solves both those problems almost entirely. There is almost no reason to block that authentic customer from masquerading as whatever email address they want to (since the originating headers are all nicely taken care of by the ISP), and never any reason why they should be blocked from sending from their usual email address (own domain etc).

That seems logical to me. What I now find is that change has come along and broken that. An ISP would be mortified if it inflicted 3 week long connectivity outages onto large batches of its customers, but evidently didn't really consider that having broken SMTP service for that length of time was a biggie, out of the blue. Despite the fact that many smaller web hosts still exist and are non-optimum places to be sending email from, suddenly it is is a thing that customers are all automatically expected to have a Gmail-sized "provider" to the point of wide-eyed confusion from the ISP when it turns out they don't. A tacit industry-wide assumption that the cloud is something "big", email is an optional extra, and ever-increasing levels of security are absolutely required to fight the (insert conceptual evil entity of choice, whether that be your own, or fashionable). I understand where this is coming from and that it is part of the evolution of things, but what I see is a set of beliefs becoming ever more powerful at abstracting the business logic away from technical logic until it disconnects. Failure. Belief is no good if it's wrong, but that point is getting lost more and more these days, often the proposed solution is "just believe more". By no means limited to Spark, and they had special problems because of their connection with Yahoo obviously. What I'm moaning about is the entry into a technological dark ages, which I where I started in this thread.

My problem solved so I'm outa here! (After small rant.)

richms

29104 posts

Uber Geek
+1 received by user: 10219

Trusted

Lifetime subscriber

#1726111 25-Feb-2017 14:17

Why is the ISP the logical place to do it?

They don't provide IRC, discord, WhatsApp or any other servers so not sure why they are logical just for email?

Richard rich.ms

nunz

1421 posts

Uber Geek
+1 received by user: 314
Inactive user

#1726125 25-Feb-2017 15:31

tdgeek:

nunz:

richms:

IMO any consumer ISP that chooses to offer an outgoing SMTP service should strictly enforce the sender of emails should be either the use themselves or at worst case be at a domain that the ISP uses for email even if the user doesnt match the one that authenticted with the server.

To allow any address to go out will make the ISPs server be usable for a joe job attack on other people, getting them a crapload of bouncebacks that should never have been sent in the first place.

Allowing unauthenticated SMTP, non SSL, and other bad practices for so long is why email is such a spammy mess. I support any step towards cleaning it up so the absurdity of anonymous emails coming from random IP addresses claiming to be any random person is eliminated.

The problem with that is when you get a mobile phone, and a laptop and desktop at home, then it has traditionally been an issue as the ISPs themselves have failed to let authenticated mail be sent if you aren't on their domain as isp. ISPs are reaping what they have sown. If they actually had let authenticated mail be sent through their servers, even if your device was connected to another isp at the time then half the messed up work arounds we used over the last 10 years would have been null and void.

Xtra were quicker off the mark with authenticated SMTP than most but then botched that with port 25 blocking and a raft of other idiot processes banning emails until you filled out impossible to find forms they then ignored.

Vodafone / Clear / Paradise - probably the very worst. Still no authenticated smtp for clear last time I checked and I think paradise ditto. Trying to use vodafone authenticated smtp was a failure in the making if you were a clear or paradise client so thus loose spf records allowing you to send from other ISPs / anywhere becuase at the end of the day you arent allowed to put in enough isp names and ip addresses in an spf to cover all of NZs offerings.

I still wince at the number of mail servers we had on telecom / xtra networks where the client connected to them as the single point of authenticated mail sending, using anything other than port 25 / 26 and the support issues that raised. Then having to smart mail them through xtras smtp or send.xtra.co.nz as the sillybuggers blocked sending ports on their networks.

Again - the ISPs are their own worst enemies.

I always said I would never run commercial mail servers but now have three as it is still less painful to take that responsibility than deal with the crap using ISPs email has caused. Uptimes all reflect we only reboot once a year on some of the servers to get windows processes to pick up the renewed certificates. Happy clients. Happy IT guy

If your with Acme ISP, use their SSL settings.

If your with Joe ISP, use their SSL settings

And so on. Use your email providers SSL settings, no BB provider cares, as SSL is secure.

If your provider can only support 17 year old Port 25 smtp, use that, after asking your BB provider to unblock Port 25. They won't care, but don't use your BB providers servers, they do care, they don't want insecure, relayed email. Yes, you can authenticate as a third party, but why add more to the mix? Use YOUR email providers SSL or Port 25, don't involve the BB provider, they are quite happy to provide the internet connection.

you missed the point in the first lines. Most of us today end up hooked to multiple ISP by virtue of our mobility. Even if your phone is with Acme ISP you are on a differnt network to the broadband network they offer and without the ability to tunnel back into your home mail server using authentication and/or SSL then you are screwed. Add to that my internet at home is possibly different ISP to work and then hotels / motels / cafe / client sites etc - you end up coming out of multiple ISPs. Until recently many of the ISPs were only using port 25 and port 25 is still the default receiving port for all SMTP servers - so if they are blocking it on your ISP you cant send outgoing email from your own mail server, that sits with your ISP.

1 | 2 | 3 | 4 | 5 | 6 | 7