Emails from one individual being bounced from my email account

[LeDoofer]

A friend reports sending me emails, which used to arrive with now problems, but since the 20th March 2024 they have been bounced from my tiscali.co.uk email (hosted by TalkTalk) with no useful info beyond that they have bounced. He asked his ISP to investigate, they replied: ""I've ran a few more checks and I'm afraid I can't seem to locate anything wrong from our end. There are no blocks placed upon your mailbox/domain and the mailbox appears to be functioning normally. Perhaps it'd be best for the other party to check with their email provider as well to see if they can locate your emails in their server's logs and find out more about this."

Of course, he was able to ask his ISP to check things, but unfortunately for me I have TalkTalk, who don't offer a helpdesk, just hours of irrelevant FAQs.

I need TalkTalk to see what is happening to these messages, find out why they are bouncing.

Anyone know of a help email address?

The account continues to work fine for everyone else every day, I see no errors reported this end, I've never put a block on his address, I'm well below my storage quota.

[Ady-TalkTalk]

No engineers will post on this community. Just staff members paid to do this. 

Ady

[LeDoofer]

So you're clearly the wrong person. What's needed is an engineer (computer/networking/software or whatever they call themselves these days) who can reach out to an equivalent at Heart, discuss this and find a solution, as has occurred on a number of occasions over the years when things like this have cropped up... until TalkTalk. This ridiculous 'he says she says' to-ing and fro-ing by text is hopelessly time-consuming. I expect TalkTalk is aware of this, many problems just 'going away' (to the 1-star feedback box) when customers give up.

I could ask Heart if they would like to join this forum discussion, but I can imagine they would only want to talk to a TalkTalk engineer.

Can you guarantee that an engineer (or whatever they want to call themselves) will respond in a timely fashion?

[Ady-TalkTalk]

Hi LeDoofer, I'm not an engineer and have never claimed to be one. Well not in the last 18 years anyway. I can't talk to heart unless they post on the community as I'm here to offer community support only. I've been campaigning for years to have a postmaster email address for other providers to contact our mail team. but it falls on deaf ears. I'll raise a fault ticket for you. 

Ady

[LeDoofer]

Okay, look - this would be funny, if it wasn't so pathetic.

I've had an implicit admission by TalkTalk that they, unlike other ISPs, don't provide access to engineers to solve problems, I just have to get lucky that a forum discussion is picked up, maybe. Then I finally get a response from a TalkTalk engineer (hoorah?) who thinks that explaining what is going wrong now is helpful (oh dear!).

Look, 'Ady the TalkTalk engineer', it seems incredible that I have to point this out to you, if you really are an engineer - I'm an end user you're providing a service to, so I don't have any control over TalkTalk servers. My friend John has no control over Heart servers - YOU NEED TO TALK TO HEART, DIRECTLY, AND SORT THIS OUT! Neither I (using TalkTalk) nor my friend John (using Heart), as end users, can do anything about how TalkTalk and Heart are functioning, nor can we do anything about the problem that suddenly arose (not very long ago, after years of working correctly) between your two servers. 

Pick up the 'phone and sort this out! It's ridiculous that I should have to continue to carry messages between you two, like two arguing parents who won't talk to each other...

[Ady-TalkTalk]

Hi LeDoofer, I ran the Robinnet.co.uk mailbox through the 7 day scan and it completed the scan with no results in record time. Very unusual. As its so unusual these scans take 5 -10 minutes even on low use email domains. I thought I do a quick check on the verifalia site to see what that said and I think we now know why you're not getting the mail. 

Validation summary

Input data:********@robinet.co.uk

Classification:

Risky

---

Status:

Possibly risky email type: the external mail exchanger accepts fake and nonexistent email addresses. Therefore, the provided email address may not exist, and the existence of the individual mailbox cannot be verified.

Status code:

ServerIsCatchAll (What's this?)

[LeDoofer]

Yup, you're one of The Good Guys! I just don't think you should have to be; we all pay TalkTalk for a service, yet volunteers like you get sqwat for doing their support job for them. You even put up with the 'I'm a bit irritated' tone! Tut-tut TalkTalk.

A test email was sent again today, nothing got through.

[Gondola]

I am grateful to you for chasing up the information that does really help to clarify what's happening. I have escalated this topic into the TalkTalk workflow with a request for direct help by TalkTalk Community Support. If you could ask your friend to try to send you a mail message from their Heart Internet mailbox direct to your tiscali.co.uk mailbox and then TalkTalk will be able to run their standard checks knowing that there was a message sent within 7 days of the checks.

As for me, I volunteer my time to Community. My experience of telecommunications, including broadcasting, broadband, mobile and fixed wireless access technologies is not from TalkTalk as I am not employed by and have never been employed by TalkTalk nor its predecessors.

[LeDoofer]

Gondola, you've been very kind. From your knowledge of the TalkTalk setup I'd presume you're an ex-employee? 

You're saying the best that TalkTalk customers can hope for is that their queries on this forum might (or, presumably, might not?) be 'picked up' by TalkTalk Community Support?  Whatever they are. At which point the customer is perhaps expected to express gratitude for getting the service they are actually paying for? 

It is getting harder and harder to actually speak to a human being that represents a company these days. I changed my bank recently because they were increasingly trying on this sort of web-based 'you do the work, why should we?' runaround nonsense. I found a bank where I can speak to a human being after just a few rings. It seems deeply ironic that a communications company thinks it can avoid the activity it's named after! If I didn't have to stay with TalkTalk in order to keep a key legacy email address, I would certainly find a company that doesn't rely on the goodwill of contributors to their forum like Gondola.

[Gondola]

At last, the actual content deferral notification TT991 means that TalkTalk have selected the mail message for scanning to ensure there is no spam or other malicious content. Was there an attachment? Mail with attachments is regularly scanned because this is a method of scammers getting malware delivered to a recipient. The scanning is a temporary delay to delivery, assuming the mail message does pass the scanning process, so does not require the mail service to queue or resend or repeat the delivery.

This topic will be picked up by TalkTalk Community Support during a normal working week and a check of your mailbox and the sending email address will be carried out and the results given to you right here.

[LeDoofer]

(I have to say that I find it extraordinary that I'm having to act as postman here - TalkTalk's refusal to provide any direct support to its customers means there's no-one for Heart to talk to, just me facilitating this weird 'He says she says' with a third party with no affiliation to TalkTalk on a discussion forum. TalkTalk should be able to do better: With other ISPs it's been pretty easy in the past to get them to talk to each other directly to out this sort of thing.)

Anyway (sigh):

Heart Internet have replied as follows:

"Thanks for your reply. The server logs indicate a content deferral rejection with the TT code - TT991 - I believe this may be the recipient server rejecting due to an attachment but Talk Talk should be able to provide more specific information."

So we're back to the question, why did the TalkTalk server suddenly decide to reject emails from this source? Or rather, having done it once, out of the blue, why is it continuing to do it with subsequent messages?

And how can I ask TalkTalk, so they can sort it out, rather than just get suggestions from helpful people on a forum? What is the helpline email/phone number??

[Gondola]

Heart Internet have got it wrong.  Not surprising as the Internet in general does not understand that deferring by the recipient mail server means a delayed delivery for accepted mail and confuse this with deferring by the sending mail server when retrying mail delivery after a permanent failure. 

If a mail server rejects or is unable to accept a mail message for delivery then there will be a "permanent" failure bounceback. e.g. TT512 Mailbox does not exist or is locked or rejecting the sender's mail.  Some sending mail services will treat this as a temporary condition and put the email in an outgoing queue to retry sending at intervals for a defined period of time just in case the permanent failure was the result of a temporary fault. 

If a mail server accepts but defers a message this is a temporary condition and there will be a "temporary" bounceback notification e.g. TT901 Content deferred telling the sender that mail is accepted for delivery but delivery will be deferred or delayed, in this case for scanning the content. This deferral or delayed delivery does not require further attempts by the outgoing mail server to send the mail message.

If Heart Internet will therefore advise what the permanent failure bounceback description and TT code from TalkTalk was then it'll give us some help in identifying the root cause.

[LeDoofer]

More info from Heart Internet:

"Talktalk servers, along with many freemail services for that matter, including bt, and yahoo addresses, have a system where by emails can be "deferred". Deferring is a process where basically a sender will attempt to deliver an email to their servers, but their server is unable to handle the request, and so instead of the email actually failing, it states it can't receive it right now, but to try again later.

As a result, the email doesn't fail, but it stays in the sender's queue, in this case, ours, and it tries again later repeatedly. Eventually, the sender will just discard the email as it's not being accepted, and it's a bad idea to keep all emails like this stored for a long time.

As a result, you get that bounce from us, but the issue is with the recipient server."

Looks like the ball remains in TalkTalk's court?

[Gondola]

The bounceback appears to come from Heart Internet and reported as undeliverable by GoDaddy mail servers. So that's why there's no TalkTalk error code.  The GoDaddy mail servers are the ones reporting delivery failure not the TalkTalk servers.

So who is using GoDaddy? You or the Heart Internet originator?  Are the mail messages sent direct to the TalkTalk Mail address from the Heart Internet mailbox?

Being in a queue for too long means that the outgoing mail from Heart Internet has attempted delivery and that failed so the outgoing message was put in a queue for redelivery to try again and those retries timed out so that message was undeliverable even after retries.

If the delivery failure is still ongoing then TalkTalk Community Support can run a check on your TalkTalk email address to see if mail has been rejected. Put your email address and the sending email address in your Community profile Private notes.

[LeDoofer]

Maybe, but it's not being bounced as 'undeliverable' - these emails suddenly started to be 'in a queue too long'.  When nothing changed at the sender's end.

Anyway, my question was actually how I can contact TalkTalk and get them to check the server logs to see why these messages are being 'queued too long' .

Does anyone know? 

[LeDoofer]

The header is:

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed permanently:

* XXXXXX@tiscali.co.uk

Reason: There was an error while attempting to deliver your message with [Subject: "Re: Tea etc."] to XXXXXXr@tiscali.co.uk. It has been in queue too long, and will not attempt delivery again.

Reporting-MTA: dns; sxb1plwbeout01.prod.sxb1.secureserver.net [92.204.80.2]
Received-From-MTA: dns; mta2.hi.local [80.90.192.26]
Arrival-Date: Thu, 28 Mar 2024 03:26:54 -0700

Final-recipient: rfc822; XXXXXX@tiscali.co.uk

So no TT code. 

So I'd like TalkTalk to look through their server logs and see what happened. It's a nice idea that the lack of a TT code means it never got to TalkTalk in the first place, but the only proof of that (rather than some TalkTalk internal error - which seems likely, as this problem has suddenly arisen and isn't a problem at the sender's end) will be checking the logs.

[Gondola]

If the mail message has been bounced back from TalkTalk servers as undeliverable there will be a description and a TT 3 digit error code eg TT991. Knowing the error code will help to identify why the message is not delivered.

If there's no TT error code then the bounce back is not by TalkTalk.