Plusnet to Gmail addresses - what's the problem?

[#1]

---

@jric wrote:

Just to clarify on a couple of points of confusion made by various members in the above thread...

1) I thought this forum had agreed that emails sent directly from the Plusnet webmail service on the Plusnet Member Centre website were NOT subject to the same delays. I have certainly satisfied myself that is the case.

However, although they arrive at the other end instantly they arrive with a completely different sender address i.e. user+mailbox@imap.plus.net.

@no, I think it was advised that the account identity settings were wrong.  It does not matter how the emails are sent, if they are "from" @myaccount.plus.com Google may chose to delay delivery to a free Gmail account.

There may be a way to configure things and use the webmail only to Gmail but I do not want to change my POP settings to IMAP and I do not want to use my primary Plusnet email address, even if changing either could make any difference.

POP & IMAP have noting to do with SENDING emails - that uses a SMTP service and empirical testing indicated that there is no issue with the SMTP address

2) There also seems some confusion between email clients and ISP's. The email client you use is unlikely to be relevant as everything still goes through the Plusnet servers (Plusnet being the ISP).

Correct, but flawed, the client is not relevant and recent tests indicate that the ISP providing the SMTP service is not relevant … the one unchanged common to all failure conditions if Google and Free Gmail accounts.

3) For the purposes of this discussion members are distinguishing between free and paid-for gmail accounts. However, if anyone is put off complaining to Gmail because they don't think they have the right to complain about something that is free N.B. there is no such thing as FREE Gmail.

The reason these are being distinguished is that Google is NOT choosing to delay delivery to their paying customers.

---

[#2]

Thanks to a number of informative posts on this forum, not least from Townman,  I think I have grasped essentially what's going on with this problem, but one thing continues to confuse me. This is the inconsistency with which Google treats incoming mail from @myaccount.plus.com addresses to free Gmail accounts. On Wednesday, I sent two messages to my Gmail address one after the other. The first arrived instantaneously. The second has still not arrived more than two days later. If Google's system is set up (for whatever reason - it doesn't matter) to capture such messages and delay them, I simply don't understand why this system would not treat two identical emails in exactly the same way. Any thoughts anyone?

And while I'm on - an update to the evidence on Plusnet's contention that all our emails to Gmail contacts do eventually "get there".  One test message I sent last week is now eight days late. No sign of it, so I think we can safely say it didn't "get there"!

[#3]

The process does seem murky and your question is a good one.

It has made me realise that the situation is even more odd than I've already accepted it to be.  The receiving service does not accept the email, store it and deliver it later, it simply refuses to accept delivery attempts ... until it's ready.

If the process were targeting the Plusnet email servers, then one might expect any mail sent from those servers to be progressively delayed.  That is not what is being seen - it is email from each individual mail address which is individually delayed, irrespective of which mail server (Plusnet or a third party) sends it.

That implies...

1. The Google mail server has to start accepting the inbound email
2. It has to identify the sender
3. It has to check the sender against a defer receipt grey list
4. It has data storage to record individual grey listed mail senders and their current delay time

That is a lot of effort to expend to not accept delivery of an email ... Until a later time when the process needs to be repeated.

I am now musing over how (4) might be implicated in respect of GDPR requirements? 

[#4]

With regard to 3) it’s perhaps worth recalling that gmail keeps a complete record of all emails received, with verified/unverified sender flag on each one. So including delay information with this is probably relatively straightforward.

[#5]

I'm having similar delays with emails sent using Thunderbird experiencing delays to gmail recipients only.

The issue is also being discussed on a Google forum and I've found this reply to as user which suggests that it may be a problem with Avast antivirus at Plusnet :-

QUOTE

Thanks for the headers.

You can see that there was a delay of 13 hours at avasout08.plus.net before they sent the mail to Google.

You will need to take this up with avasout08..

Let me know if you need more help

[#6]

@PhilRSoT 'avasout08' is not Avast AV, it is the PN outbound mail system.

[#7]

Hi Phil

It isn’t related to the sending server. The same will be seen sending the email from any server (even non Plusnet servers). The only relevant factors found are that the email address is @Username.plus.com and the receiver is a free gmail account. If it comes from a different Plusnet hosted domain or it is a paid for gmail account the issue isn’t seen.

[#8]

So this would imply that the delay mentioned in the Google forum post is caused by the Gmail incoming server refusing to accept the message from the PN outgoing server, rather than the PN server holding onto it itself ?

[#9]

@PhilRSoT,

A warm welcome to the forums.  Can you please provide a link to that Google forum post?

The response there is unfortunately too typical of a perspective that all delays arise from the sending service, ignoring the possibility that the receiving server can (and this case does) defer acceptance of a delivery attempt.

[#10]

OK.  This is a first - my wife's Gmail to me at Plusnet has been held up for 2 days.  There has only been delay the other way before.

Why do I think there may be some retaliation started up this week.  What Gmail can do so can Plusnet....

Anyone else had an incoming delay with Gmail? Mind you a test sent to me 2 mins ago arrived straightaway so perhaps it was just a fluke and not the beginning of a pattern.

[#11]

You could try pasting the full headers from the delayed Gmail message into the analyzer at:

https://mxtoolbox.com/EmailHeaders.aspx

- which might provide an explanation for the delay.  When I've done this with the headers of delayed messages from Plusnet to Gmail they usually indicate blacklisting or (more likely) greylisting.

The means of obtaining the headers will vary according to the application used to read the email, though, so I can't easily advise how you can do it.

Moderator's note by Dick (Strat): Full quote of preceding post removed as per Forum rules.

[#12]

I have ah ad a trawl through this thread and have some questions. Apologies if they have already been answered and I missed the answers.

The analyser https://mxtoolbox.com/EmailHeaders.aspx suggests that 212.159.14.18 (avasout06.plus.net) is blacklisted (0SPAM) using the headers of one of my emails that took three and half days to get delivered from a Force9 account to a free Google account email. I have had quite of few instances of this happening over the last couple of months.

Could someone from plusnet confirm whether attempts have been made to get delisted from 0SPAM?

As prior posts in the thread have said, Google appear to be throttling delivery in a less than transparent way.

Could someone from plusnet confirm that the issue has at least been raised with Google?

Could someone at plusnet confirm that in such cases the plusnet server would be aware that delivery has not been completed?

In principle, it should be possible to flag to the original sender (e.g. every 24 hrs) that email has not yet been delivered and that attempts to deliver will continue until whatever the timeout is to give up.

Could someone at plusnet confirm whether plusnet servers support delivery failure notifications?

Cheers, Richard

[#13]

Hi Richard,

0Spam listings might be a bit spurious.  The reason they give for listing the server is...

Reason for listing - Received: from avasout06.plus.net ([212.159.14.18]) Tue, 23 May 2017 09:50:16 -0500 Subject: =?UTF-8?Q?D_Gould_Tony?= 

Note the date - clearly their data is not current.

Questions asked of Google - I am aware that Plusnet has sought comment through the support channel but understand that there has been no engagement … which is much the same as my own experience on Google's support forum.

I have also raised the question about non-delivery notification … I will poke the question again.

Superuser escalation

This topic has been escalated by one of the Superusers; please allow time for Plusnet to respond before commenting further.

Escalation does not imply progressing this matter will be given priority, nor that a different outcome will result.

Reason for escalation:  Chase status

[#14]

Hi Richard

The other thing that may be worth pointing out is that the delays are present regardless of what SMTP servers are used.  You will still see the same delays if you use non-Plusnet SMTP servers to send the email.

[#15]

Interestingly when I send to (free) gmail addresses using non Plus net STMP servers, delivery is 'instant'.