on 12-03-2022 08:46 PM - last edited on 12-03-2022 10:09 PM by Gondola
Apparently, Gmail made a change very recently that causes emails to be blocked if the sending domain doesn't have an SPF record.
The error detail is:
Hi. This is the qmail-send program at apm-internet.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
18.104.22.168 failed after I sent the message.
Remote host said: 550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks. To best protect our users from spam, the
550-5.7.26 message has been blocked. Please visit
550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more
550 5.7.26 information. z21-20020a17090665d500b006d1ddb409bbsi6577603ejn.234 - gsmtp
STARTTLS proto=TLSv1.2; cipher=ECDHE-ECDSA-AES128-GCM-SHA256; subject=/CN=mx.google.com; issuer=/C=US/O=Google Trust Services LLC/CN=GTS CA 1C3;
on 11-07-2022 09:42 PM
I had a call today from Jane Hanby who has taken over my complaint from Stewart, who, as you say, has left the business. It would make sense for both of these cases to be handled by the same person but Jane did say that she was aware of other cases similar to mine.
As regards the comments from Gordon, we already know that adding an SPF record at the parent level will NOT work. The records need to be added for individual subdomains. That said though, as we’ve suggested before, they really don’t need to do it for all 90k+ subdomains, just the ones that are being used to send emails. And even easier, just do the individual subdomains that customers have raised issues for in the short term, then tackle the others as a secondary fix. Let’s hope Gordon/Jane can make some quick progress with the individual approach!
on 11-07-2022 05:21 PM
Further Update....Stewart has left TalkTalk Business! The new man is Gordon Campbell.
There are over 90,000 sub domains for f2s.com. I am currently trying to find out how to add a record at the parent zone but this has not been possible so far. If this does not work we would have to figure out a quick way to add an SPF record to all the sub zones. I have taken forward the suggestion that we add the SPFD record just to your account, along with the others who have raised the same concern and we will take if forward from there.
Customer Experience Team | TalkTalk
on 11-07-2022 03:59 PM
Ultimately they need to add DNS TXT records for the subdomains that are sending emails. There are a variety of admin tools that facilitate that sort of change, most of them GUI tools, but there are some command line utilities. The only reason they might need coding is if they’re scripting multiple changes via one of the command line utilities. Unless they’ve got dozens or hundreds of users complaining about our issue they really ought to be concentrating on getting the few of us sorted out in the short term. For a few changes it must be very straightforward to use GUI tools to create the DNS TXT records. Based on my own experience in the past I’d say a couple of minutes tops for each subdomain.
If they want to put a solution in place for every subdomain then they can script something for use in the longer term. But *@#][!!'#[@#]!* why can’t they just get on and sort us out?!
on 11-07-2022 02:07 PM
Tedious I know but latest update this time from Kit on nonprogress...
I would like to give you an update regarding with this case. I can now confirm our team from Linux and Unix Specialist is working on this case and once we received an update I will send you an email right away.
on 03-07-2022 06:54 PM
"I'm just getting in touch as we're still investigating this with our higher department and awaiting their response on resolving this issue, as we have had to escalate this."
Well the excuses and platitudes continue from a new TTB person ... Callum N , SME (???) Customer Services, TTB to join the long line ...Kit, Stewart, Hazron in never actually saying or doing anything productive that gives you any confidence that they are even adressing the problem seriously!
on 01-07-2022 04:00 PM
on 29-06-2022 01:26 PM
Kit Rodrigo -
"I talk with our IT specialist earlier and I can confirm they are working it. Since there are over 97,000 sub domains for f2s.com they are unable to add an SPF record for every one of them. However they are looking for better resolution to fix this as soon as possible."
Stewart Anderson -
"David (presumably one of the expert engineers?) advised that the main issue is getting access to edit the SPF records and the PTR needing to be edited which we are already aware of"
on 28-06-2022 09:26 PM
on 24-06-2022 09:13 PM
A REQ is likely to be a ‘request’ , in service management terms it’s a request from a user for something to be provided. In this case it’s probably something they need to have in place to justify the change they want to make, i.e. the SPF TXT record they need to create.
on 24-06-2022 06:54 PM
They have raised a new ticket (or jobsheet) indexed by REQ (which I assume means Required) and two supposedly highly ranked senior engineers of Network Systems Mail Group will be meeting Stewart at 11am on Monday. The purpose seems to be something around looking at the problem although recent Emails only refer to looking at a plan of action or agreeing a timeframe in getting this matter resolved. This is the first time in 4 months, that anyone appears to be prepared to do something, although the only TTB guy who supported the legacy TTB email domain has left, so I have no great confidence in them achieving anything. Certainly seems that Trivia Harrison has tried to raise some urgency on this matter...
on 24-06-2022 05:23 PM
To All for info. Hazron is also looking at my (re)opened case , this time TTB say it won't be closed unless a satisfactory resolution has been reached . Incidentally I have been unable to create a login with TTB support as my account number ( 500xxxxxxxx etc ) is not recognised.
on 24-06-2022 12:56 PM
just checking whether you are aware that you can view your cases via the supportcentre at https://supportcentre.talktalkbusiness.co.uk/home if you have a login? That will enable you to check whether a case has been closed. In this instance I suspect Hazron has made a typo and should have been quoting two different references. The system won’t have generated two cases with the same number because the number is almost certainly the primary key for the case record in their system management database.
on 24-06-2022 12:54 PM
Tristia Harrison (CEO) has just written an Email on a chain several deep to the Manager of the Network team Michael Waugh asking for a Resolution Date for this problem. Meantime, I am told that the one person who had access to the legacy domain has left the company so nobody knows hw to logon to the legacy system to do the SPF change or whatever!!
Don't hold your breath!
on 24-06-2022 12:30 PM
Todays Email from a new player Hazron of Domain Admin team:
I hope you're doing well. We apologise for any inconvenience this has caused and we are making every effort to resolve this issue for you. Also, I can see that you still have an on going case 08960949 I will close this case as duplicate and please refer to this case number 08960949 for any updates regarding with your issue.
Words fail me as to how any system can generate two cases with the same number?????
on 23-06-2022 01:05 PM
I must admit I’ve made the assumption that TTB adhere to ITIL service management standards, which I think are pretty much industry standards.
…but nothing would surprise me… 😕
on 23-06-2022 01:00 PM
Quite agree. From my recollection of ITIL service management processes they may well have raised an internal problem record to address the issue for everyone and that should probably reference all the individual incident records (cases from our perspective), but that does not mean they should be closing all those incidents. The incident records are a means for the customer to track progress through to resolution so must be held open until the customer is satisfied that the remedial action has actually solved the problem.