Plusnet Email servers giving random SMTP 550 errors for inbound emails

[#1]

@DRWDRW and @coraledge 

Both of your examples are rather stale.  Do you have similar failures which have occurred more recently?

[#2]

Here's a fresh one for you:

The original message was received at Fri, 12 Apr 2019 09:02:23 GMTfrom cpc134260-whit5-2-0-cust177.know.cable.virginm.net [82.16.216.178]    ----- The following addresses had permanent fatal errors -----<coraledge@coraledge.co.uk>    (reason: 550 #5.1.8 Domain of sender address <richard@wenner.uk> does not exist)<mark.stanley@coraledge.co.uk>    (reason: 550 #5.1.8 Domain of sender address <richard@wenner.uk> does not exist)    ----- Transcript of session follows -----... while talking to mx.avasin.plus.net.:MAIL From:<richard@wenner.uk> SIZE=10441 BODY=8BITMIME<<< 550 #5.1.8 Domain of sender address <richard@wenner.uk> does not exist554 5.0.0 Service unavailable

Reporting-MTA: dns; post.internetprojects.co.ukReceived-From-MTA: dns; cpc134260-whit5-2-0-cust177.know.cable.virginm.netArrival-Date: Fri, 12 Apr 2019 09:02:23 GMT Final-Recipient: rfc822; coraledge@coraledge.co.ukX-Actual-Recipient: RFC822; coraledge@coraledge.co.ukAction: failedStatus: 5.0.0Diagnostic-Code: SMTP; 550 #5.1.8 Domain of sender address <richard@wenner.uk> does not existLast-Attempt-Date: Fri, 12 Apr 2019 09:02:52 GMT Final-Recipient: rfc822; mark.stanley@coraledge.co.ukX-Actual-Recipient: RFC822; mark.stanley@coraledge.co.ukAction: failedStatus: 5.0.0Diagnostic-Code: SMTP; 550 #5.1.8 Domain of sender address <richard@wenner.uk> does not existLast-Attempt-Date: Fri, 12 Apr 2019 09:02:52 GMT

[#3]

Thanks for that @coraledge, I'm sure those examples will be of use to my colleague @JonoH.

At this point we have no further update available but rest assured that we'll update here as soon as we do.

We'd also like to thank you for your patience in this matter.

[#4]

---

@OskarPapa wrote:

We'd also like to thank you for your patience in this matter.

---

Frankly, I'd rather you got around to fixing the issue as I think patience is starting to wear a bit thin!

[#5]

I can certainly appreciate you feeling that way @cso.

Unfortunately I'm only able to relay the information that I have to hand but will certainly pass your feedback along.

[#6]

---

@cso wrote:

---

@OskarPapa wrote:

We'd also like to thank you for your patience in this matter.

---

Frankly, I'd rather you got around to fixing the issue as I think patience is starting to wear a bit thin!

---

It is presumptive to assume that there is just one issue (cause) giving rise to the seen symptoms.  If it were easy, it would have been fixed a long time ago.  Given the intermittent nature of an issue like this, finding its cause(s) is not as easy as some appear to think.

[#7]

@Townman I think even for the most intermittent of issues, 16 months is probably more than enough time to diagnose them... if you're actually looking at them - and therein lies the problem; there doesn't even appear to be any hint that Plusnet are doing anything about investigating it - apart from asking us to be patient.

I have no qualms with the internet aspects of Plusnet (and given I've been a customer over 12 years that probably says something...) but it seems that the 'addons' are now seen as something of an inconvenience these days...

[#8]

Here, here. I was just writing a post saying much the same when you beat me to it. Personally I now advise any clients who ask me about ISPs to avoid Plusnet due to their apparent inability to solve problems delivering their clients' mail.

[#9]

There has been a lot of discussion on this matter within the SU group.  Low level diagnostics and logging can see the error events, but that is a far cry from discerning the cause(s).  Our most recent update within the group can be summarised thus:

• The issue is under investigation and has been throughout this thread
• Being able to discern the failure is not the same as being able to identify the cause
• A lot of low level diagnostics and logging has been developed which can see the failure events but that does not lead to identifying the cause
• The identified failure rate in less than 0.03% of all traffic processed
• Automatic error mitigation (retries) has significantly reduced the incidence of the issue, albeit not eliminated all occurrences of the symptoms
• Investigative diagnostic work continues to identify the cause of the other occurrences

Rest assured, the SUs are not being quiet about this issue, but as noted before if it were an easy issue, it would have been fixed months ago.

[#10]

>>> The identified failure rate in less than 0.03% of all traffic processed

What does that mean transposed into real figures?  Does anyone know the volume of mail the servers handle per day?
eg/ If their mail servers are handling millions of emails per day then that equates to 100/1000s of emails every day being lost?.


I've probably seen about 30-40 being bounced back to me (although admittedly haven't seen any in the past month or so), but the length of time this has now been outstanding is pretty diabolical, especially when there are some EU's saying that mail from their bank or insurance co has been lost.   I bet there is a heap load of customers who have no idea that some of their mail will have just gone missing. 

Whilst I appreciate you say the SU's are looking into this, there hasn't really been anything of substance coming from the mouths of Plusnet themselves.   

[#11]

So the question then becomes:

Why are Plusnet being so secretive of telling the users this, rather than just telling the “select few”?

[#12]

Depends on what you mean by secretive - Plusnet have not been secretive that they are investigating the issues; it has been stated plainly for all to read that the issue has been under investigation.  What they do hold in reserve are forecasts for resolution, when the cause of the issue has yet to be identified / confirmed.

All that is being said at the moment is that a mitigation has been put in place which substantially reduces the occurrence of the issue.  Other angles remain under investigation, as does the cause of the symptoms.  This is not the same as being confident that the CAUSE has been identified and eliminated.

[#13]

Hi @kitz 

You've been on the block here for a good while; you probably know as well as anyone what happens when Plusnet comment openly about on-going issues - and some wag in the media picks up on it - they get fried!

This is one of those issues which has not "split the beans" without a significant amount of low level diagnostic logging and analysis … initially just to profile the problem, let alone to locate the area of the failure.  One of the factors I guess not clearly understand by many is the difficulty of locating the most of the time it works, sometimes it fails … and then inexplicably retries largely succeed.

As you suggest, the good news is that the reduction in the level of failure seems to have been reduced somewhat.

[#14]

>>> The identified failure rate in less than 0.03% of all traffic processed

What does that mean transposed into real figures?  Does anyone know the volume of mail the servers handle per day?
eg/ If their mail servers are handling millions of emails per day then that equates to 100/1000s of emails every day being lost?.

I would have thought that would be impossible to say.  There are perfectly legitimate reasons for some of these rejections. Whether 1% (of the 0.03%) or 99% are legitimate or not isn't an easy figure to come to.

[#15]

here are many sayings about statistics and how they can be misleading so when I read this:

"The identified failure rate in less than 0.03% of all traffic processed"

This might sound impressive at first glance but given the problem seeming only applied to people with domains they will be a small (but significant) minority of people. So this statistic may be very misleading as some figure, let's say 95%, of emails would never have been affected anyway. Let's say 5% of emails were liable to be affected, and 0.03% of the TOTAL emails were affected, this would imply I'd thinkthat 0.03 x 20 = 0.6% of domain emails are still affected. This is of course using a total guess at 5% (thus 1/20) of customers using domains. And it might be worse for people with affected domains as it might not be all domains, it might just be people using certain forwarders e.g, 123-reg. It might be significantly higher error rates for such people.

I agree with the people above (I'd guess most people) that I'm surprised it seems so hard to fix but at least it's moving forward. Why can't they just disable this check for people who are happy to have a little more spam or just allow putting your domain in a whitelist, it would solve the problem easily surely?