Problems sending PN email to Gmail addresses

[#1]

---

@PeterB1 wrote:

So come on, Plusnet: what the b****y hell is going on with the Gmail failure? What have you found from the logs? What are the prospects (or not) of a solution? On what timeframe? We need to be clear that an email service that cannot send to Gmail is no email service at all and a broadband/email provider that refuses to communicate with its customers should not be in business.

---

That is a good question - what the hell are Gmail doing?  I think if that was understood, one might be able to make progress.

There most certainly does not appear to be anything wrong with Plusnet's outgoing mail servers: email sent to Gmail using a hosted domain name is delivered instantly.  As a point of reference, that email domain only has SPF configured.

It is difficult to fathom what mysterious practices Gmail have invoked: *.plus,com email addresses now have...

• DKIM and
• DMARC (on plus.com) and
• (now) SPF

In other words all of the anti-spam measures demanded by the big bully boys are in place ... yet Google continues to grey-list (defer acceptance) of email using those domain names (which should not be confused with from Plusnet's email servers).

All that will be seen in the logs is Gmail refusing delivery of emails and directing that the sender try again later.  It is very doubtful that those deferments will offer any explanation as to why the action is being taken.  Indeed to explain why this is being done, might be deemed to be telling potential spammers too much information.

Considered opinion is that grey listing causes more issues than it purports to solve - see Greylisting (email) - Wikipedia

"One 2007 analysis of greylisting considers it totally undesirable due to the delay to mail, and unreliable as, if greylisting becomes widespread, junkmailers can adapt their systems to get around it. The conclusion is that the purpose of greylisting is to reduce the amount of spam that the server's spam-filtering software needs to analyze, resource-intensively, and save money on servers, not to reduce the spam reaching users. The conclusion: "[Greylisting] is very, very annoying. Much more annoying than spam."

This service https://www.mail-tester.com/ gives a 10/10 "perfect" score for emails from @account.plus.com - yes it does suggest that DMAC at sub-domain level might be "better" but that is not necessary.

What is interesting though is the suggested expectation that the email should have a List-Unsubscribe header...

"The List-Unsubscribe header is required if you send mass emails, it enables the user to easily unsubscribe from your mailing list."

So if Gmail is now following the barking stupidity of Microsoft and treating ALL email from *.plus.com as being part of the same mass email sender ... does that mean that all individual users have to provide an unsubscribe link?

As you say, what the hell is Gmail up to?  The associated issue is that if the above is what's happening, we are not going to see a post from the business which appears to "blame" a third party for issues caused by the third party.

Unfortunately the @googlemail.com ruse does not appear to work when tested earlier, as it did last week.

See Getting someone else's emails - Gmail Help

"Messages sent to @gmail.com and @googlemail.com are the same.

Some countries use @googlemail.com instead, but messages sent to the address will go to the same place."

You are though right that a resolution is needed, but when every thing works for everywhere else and the only problem is sending to Gmail ... one has to consider that the resolution might need to come from Gmail ... and as we all know, it takes ages to turn a massive oil tanker!

[#2]

=@Townman It appears some people are still unaware of the fact that Google (and Microsoft) are the standards non-compliant entities here, which I can't get my head around.

[#3]

@jab1 

Somewhat understandably some people just do not want to understand the issue ... they only want it to go away.  For that to happen, the cause of failure needs to be identified and understood.  Grey-listing just causes problems if the reason for grey-listing is not disclosed along with the refusal to accept delivery.

Rhetorical question: why does email from my domain which has minimal adherence to anti-spam measures get through immediately ... whilst email from a domain which is (apparently) fully compliant does not ... they both being sent by the SAME mail service?

Something somewhere is being selective about what inbound email its accepts.  Why does email with only SPF measures get through, whereas one with all the bells and whistles on (SPF / DKIM / DMARC) not?  The fair possibility that Gmail is doing something wrong should NOT be dismissed here.

One cannot claim that Gmail and Microsoft are standards non-compliant (they do use SPF / DKIM / DMARC), however their unilateral imposition that others should also user every optional configuration is indeed very suspect.

[#4]

One cannot claim that Gmail and Microsoft are standards non-compliant (they do use SPF / DKIM / DMARC), however their unilateral imposition that others should also user every optional configuration is indeed very suspect.

Apologies, @Townman . I see your point and agree with you. Maybe I should desist from posting until I am fully recovered and my aging brain isn't clouded by constant severe discomfort. 😀

[#5]

@jab1 

John,

Nah, do not do that ... when one stops exercising one's brain, it atrophies.

You might forgive my pedantry, but having spent sometime in IT litigation, being precise is in-grained second nature.  What we are experiencing here is not the compliance with (optional) standards but their imposition as being mandatory on third parties.  Only the international standards body can make their adoption / implementation mandatory.

Unfortunately, in the absence of an international over-sight (policing) body, school playground bullies can rule unchallenged, a bit like the mafia.

[#6]

You might forgive my pedantry

I do, and totally get your point.👍

[#7]

It seems to me the missing piece of the jigsaw here is WHY Gmail s reacting as it is to incoming emails from account.plus.com.

If (as appears to be the case) Plusnet is the only business affected by this, then there must be something about the way Plusnet's email system works that's prompting Gmail - or rather some algorithm in the Gmail system - to put up the shutters.

I'm not implying that Plusnet has necessarily done anything wrong, merely that there must be a reason why The Evil Gmail is uniquely discriminating against Plusnet users.

Is there something different about the way Plusnet does things compared to other email providers (e.g. the use of multiple servers or whatever) which maybe ought not to cause Gmail to have a hissy fit but is perhaps doing exactly that?

[#8]

Hi Peter,

That is the real issue here - WHY?

WHEN is known - it appears to be coincident with fixing the Microsoft issue.  If anything that ought to have made working with Gmail even more water tight.

I have just reviewed the space with the business contact - there is little consistency in attempts to reproduce the issue.  Some emails are being delivered instantly, whilst a few get through only after a while.

I do have a theory, but it will take time to verify: IIRC last time Gmail started this malarky, after a couple of days, they reset the back-off interval on an address by address basis.  If that is correct, it might explain why some users are impacted more than others.

I have also raised another couple of questions which might help find the back cat in the unlit cellar.

Comparing Plusnet's set up with others is probably not a practical approach: knowing how the innards of mail systems work has both commercial and security exposure risks.  Yes Plusnet's outbound 'server' is in fact a collection of servers; there is the sceptre that retries coming from different servers might give Gmail a hissing fit ... but why then does Gmail not also take a fit when sending via the SAME servers from a hosted domain name?

plus.com is not on any email black list ... I'll check the AVSouts when I can!

[#9]

Here's a question I think it's reasonable for customers to ask Plusnet.

What are the implications of the Gmail stalemate in relation to the forthcoming migration of the emali service to Greenby assuming no quick resolution is found?

1) GIven Plusnet's current assessment of the cause of the Gmail problem as outlined by Townman, is the migration likely to have no effect (because Gmail will still block messages from @account.plus.com customers when Greenby are running things? Or is there a possibility tings might improve (perhaps because Greenby may configure their servers differently)?

Or could matters get even worse?

2) To look at this from a different point of view, will it make sense for Greenby to take on Plusnet's email customers when to do so might mean inheriting a whole heap of trouble? Will Greenby want go ahead with the deal?

PS: A personal update. All my emails to Gmali addresses are currently disappearing. None are being delivered,  even very late. And here's me: the most vanilla, least spammy emailer you're ever likely to meet !

[#10]

We have asked for a comment.

Given that email on other domain names gets through and the intel available suggests that a significant portion is getting through with *.plus.can m (all using the same server setup) then its not likely to be the platforms.

The “why” remains unclear.  All google support guidance is non-specific and is set in the context of mass marketing email campaigns.

[#11]

The situation is extremely bizarre:

any email from my own domain (hosted by PN)  to a gmail address is instantly bounced "mail delivery failed, returning message to sender."

If I send from my PN force9 address then it gets through no problem.

If I change the gmail address to googlemail.com then it also gets through no problem regardless of which address I send from.

Can somebody please save my sanity and explain what is going on?

[#12]

Try this …

Mitigating email delivery failures (notably Gmail)

Many users are reporting challenging issues in sending emails to some of the big email players. Some of those providers (notably Gmail, but only in respect of their free email accounts) have mandated the SPF & DKIM non-mandatory RFCs on other email providers, such as Plusnet. This can bring about significant difficulty when attempting to send emails using the various Plusnet and vISP legacy email services.

How you mitigate Google's behaviour very much depends on how you send your emails via Plusnet's SMTP servers and which Plusnet vISP email brands you use.

• A Plusnet email account or a legacy brand (for example MAAF) email account
• you@youraccount.plus.com (native Plusnet email address)
• you@yourdomain.co.uk which is registered and hosted by Plusnet (or MAAF)
• you@yourdomain.co.uk which is registered elsewhere and hosted by Plusnet
• you@yourdomain.co.uk which is hosted elsewhere which forwards  mail to your Plusnet (or MAAF) mailbox

The vISP email brands have different level of mitigation capability - for some, the only practical solution might be to migrate your email hosting elsewhere.

Native Plusnet email address

If a user sends email using a from address of you@youraccount.plus.com then DKIM signing will be applied to the email automatically (and pass Gmail's imposed restrictions) if the SMTP server is configured to require authentication. Somewhat unhelpfully, Plusnet's email setup guide suggests that such authentication is NOT required if connecting over a Plusnet connection. Whilst technically true, operational complications can occur and it is much tidier to just enable authentication with the "use the same account settings as the incoming server" option.

Your own domain

If you send from your own domain name, then DKIM signing is not available and you will need to configure SPF instead. How to do this depends on where your domain is hosted - by Plusnet or by third party.

Plusnet fully hosted and registered domain

For Plusnet brand registered and managed domains, SPF configuration is facilitated by the addition of a TXT record in the domain's DNS settings. Plusnet's DNS configuration tool for hosted domains does not permit the creation of TXT records. However, there is an unsupported "facilitation" which will create an SPF record for a hosted domain.

On the basis that your account ALREADY has a hosted domain:

• Log into the user portal
• Go to Manage Account
• Manage Your Domains (Manage your domains link)
• Configure domain name
• Create an "Additional DNS records (Advanced)" as follows...

For the avoidance of doubt leave the left side blank, exactly as shown. It might take Plusnet's systems up to 6 hours to generate the SPF record.

If your email service is provided by one of the legacy vISP brands (for example MAAF) acquired over the years by Plusnet, similar options are not available to you.

Domain name registered and managed elsewhere (third party)

There are two scenarios here:

1. Plusnet hosts the email service for the domain
2. The domain forwards email to the native Plusnet email address

THESE ARE NOT THE SAME.  Ideally email forwarding should be avoided as it brings about numerous complications - you should use the DOMAIN's email servers to received and send your domain email, not Plusnet's.

To configure SPF on a domain name registered elsewhere, you must use your domain name provider's DNS configuration tools to set up the applicable SPF record:

v=spf1 a mx include:_spf-internal.plus.net include:_spf-internal2.plus.net ~all

or

v=spf1 include:_spf-internal.madasafish.com include:_spf-internal2.madasafish.com include:_spf-external.madasafish.com -all

[#13]

Native Plusnet email address

If a user sends email using a from address of you@youraccount.plus.com then DKIM signing will be applied to the email automatically (and pass Gmail's imposed restrictions) if the SMTP server is configured to require authentication. Somewhat unhelpfully, Plusnet's email setup guide suggests that such authentication is NOT required if connecting over a Plusnet connection. Whilst technically true, operational complications can occur and it is much tidier to just enable authentication with the "use the same account settings as the incoming server" option.

Apologies, Townman, but I don't see how this advances anything - at least as far as native Plusnet addresses like mine are concerned.

My account is in the format myname@account.plus.com.

My outgoing server settings are as follows (exactly as this latest post suggests):

Server: relay.plus.net

Port: 587

Encryption: STARTTLS

"My outgoing SMTP server requires authentication is TICKED

"Use same settings as my incoming mail server" is SELECTED"

But none of my emails to  Gmail recipients are being delivered..

So this latest post doesn't seem to help at all.

Or am I missing the point? (It probably wouldn't be the first time!)

[#14]

Last post was from @CMOTD which reports that emails from their HOSTED domain were being rejected immediately.  That suggests there is no SPF on their hosted account.

Using the specific reference to that above from the longstanding guidance should fix that issue.

At present all bets are off on what’s causing the very variable experience with Gmail with the “native” domain emails.

[#15]

Tried to do the additional DNS thing but the Pri box would only allow me to add 5 x #9 instead of the 6 suggested. Is this important and should it still work?