cancel
Showing results for 
Show  only  | would you rather see results for 
Did you mean: 
Need help?

Incoming email being rejected...

Reply
Highlighted
Team Player
Hi Ady, some positive news would be useful. Not knowing anything is VERY frustrating now.
Thank you
Teapot
Highlighted
Community Team - TT Staff

Hi Teapot, if I had anything I promise you'd already know it. I'm still chasing this daily for you. 

 

Ady


Please log in to My Account if you need to view or pay your bill, manage boosts and track your usage. From My Account you can also check your connection and test your line for any issues in the Service Centre.


Highlighted
Participant

Yeh teapot he's chasing it daily.. How dare you suggest he do more than click on his inbox once a day?

 

Hey Ady - how bout you go chase it every 10 minutes until you can explain why your company are blocking access to the most basic public internet functions such as email for weeks. I'm 2 minutes away from calling and demanding a refund for this months payment - and quoting your name specifically.

Highlighted
Participant

Ady I appreciate your help in trying to get this resolved by raising fault tickets for those of us who have complained on this forum.  All indications are this is a system wide problem with the pipex domain and you can bet there are many more people affected.

 

However to me it is completely unacceptable that this problem started very nearly a month ago, and if I understand correctly all the fault tickets raised are just being ignored by the email team at Talk Talk.  Not even an acknowledgement that there is a problem, and no indication whatsoever that anybody (other than Ady) cares or that it will ever be fixed.

 

I know the Pipex mailboxes are due at some point to be migrated onto the main TalkTalk platform, but since this particular problem only started when some elements of that platform were introduced (the front end MX server) I have no confidence that migration will resolve it.

 

Before posting on the forum I tried the webchat support route where I was assured the problem has been escalated and would be looked into and someone would contact me within days to request further information.  I'm still waiting. 

 

What else can we long suffering customers do, apart from voting with our feet and ceasing to be customers??

Highlighted
Community Team - TT Staff

Hi delwynh, your tickets are being ignored there's a problem it seems with our ticketing system not pushing the tickets across to the email team. We've been given a workaround now and I've escalate your ticket across. 

 

Ady


Please log in to My Account if you need to view or pay your bill, manage boosts and track your usage. From My Account you can also check your connection and test your line for any issues in the Service Centre.


Highlighted
Participant

Thank you Ady.  So the fault reporting system is itself faulty?!  This level of incompetence is quite farcical.  So now they have no excuses I look forward to a positive resolution.

Highlighted
Community Team - TT Staff

You're welcome.

 

Ady


Please log in to My Account if you need to view or pay your bill, manage boosts and track your usage. From My Account you can also check your connection and test your line for any issues in the Service Centre.


Highlighted
Wizz Kid

 

 


@johnrg wrote:

I too have been told by a contact in Austria using an email address domain "gmx.at" that I have previously received ok at my "dsl.pipex.com" domain many times, they now get a bounce message and annoyingly are trying to blame "brexit" I wish they knew that the real problem is TALKTALK !!!!


Interesting. I opened an account at GMX.com (related company, AFAICT) and trying to send a message to any of my @dsl.pipex.com address produces:

 

my.email@dsl.pipex.com:
no valid MX hosts found

which would seem to at least show where this particular problem lies. (It doesn't indicate who's causing the problem though, as the dsl.pipex.com MX records I can see appear to be OK.)

 

GMX.com appears to be part of 1and1 (there's a big logo on the site that looks like 1and1) so this could be the problem there too.

 

This is unlikely to be the cause of the intermittent problems which this thread is mostly about.

Highlighted
Wizz Kid

 

 


@johnrg wrote:

I too have been told by a contact in Austria using an email address domain "gmx.at" that I have previously received ok at my "dsl.pipex.com" domain many times, they now get a bounce message and annoyingly are trying to blame "brexit" I wish they knew that the real problem is TALKTALK !!!!


I posted a response to this, but for some unknown reason it has been marked as Spam, and held in the filters.

 

I'm now supposed to "If not spam, please contact us by posting in the community for the attention of the community team." - which isn't a particularly helpful direction. Post where? So I'm hoping that this will do.

 

I have evidence of what is probably wrong in this particular case (but is unlikely to be the cause of the intermittent bouncing).

 

 

Highlighted
Wizz Kid

 


I have evidence of what is probably wrong in this particular case (but is unlikely to be the cause of the intermittent bouncing).

Or possibly it is....

 

The problem I have seen, trying to send to ANY of my dsl.pipex.com

addresses from GMX.com (part of 1and1?) is:

my.email@dsl.pipex.com:
no valid MX hosts found

And in the intervening hours my mind has wandered over past interactions with DNS, with a vague recollection about how MX records are set up.

 

Now I reckon this is the problem.

 

The dsl.pipex.com one goes thusly:

 

dsl.pipex.com mail is handled by 10 mx-1.dsl.pipex.com.
dsl.pipex.com mail is handled by 10 mx-2.dsl.pipex.com.

 

and

 

mx-1.dsl.pipex.com. 300 IN CNAME mx.talktalk.net.
mx.talktalk.net. 299 IN A 62.24.202.42

 

So, the dsl.pipex.com MX record points at a CNAME (an "alias").  And that's where alarm bells started to ring...

 

This is why:  Adding both a CNAME and MX records 

 

Basically you can't have an MX record pointing at a CNAME record and have it be valid.

I have no doubt that there will be resolving implementations that allow it, but it is against the rules.

And yet that is how TalkTalk has set things up...

 

Basically the dsl.pipex.com MX records have to point directly to mx.talktalk.net. and mx.tiscali.co.uk. And until they do there will be problems.

 

Now, how to we get that info to the people who configure things and make them believe it? Because until they do believe it the problem will not get fixed.

Highlighted
Wizz Kid

Arrrggghhhh!!!!!

 

Now ANOTHER message has gone into the Spam filters.

 

Which is particularly annoying as this one was pointing out where the problem lies and what needs to be done!!!!

Highlighted
Wizz Kid

And the authorization service has just started to fail again, so no incoming OR outgoing mails at the moment.

 

I've lost track of which thread is following that one....

 

Ady - is there a ticket open with the mail team about that repeating failure? It's not the same as the mail bouncing problem (although it may, of course, cause mail bounces)?

Highlighted
Wizz Kid

The SMTP server is just refusing connexions:

 

[parent]: telnet smtp.dsl.pipex.com 587
Trying 212.74.114.24...
Connected to smtp.pipex.tiscali.co.uk.
Escape character is '^]'.
Connection closed by foreign host.

 

IMAP is accepting connexions, but takes a long time (30s?)  to fail authentication:

 

[parent]: openssl s_client -connect imap.dsl.pipex.com:143 -crlf -quiet -starttls imap
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Organization Validation Secure Server CA
verify return:1
depth=0 C = GB, postalCode = W11 4AR, ST = London, L = London, street = 11 Evesham Street, O = TalkTalk Communications Limited, OU = Hosted by TalkTalk Communications Limited, OU = Unified Communications, CN = pop3.tiscali-business.co.uk
verify return:1
. OK Capability completed.
a1 login xx.yyyy@dsl.pipex.com xxxxxxx
* OK Waiting for authentication process to respond..
a1 NO [UNAVAILABLE] Temporary authentication failure.

Highlighted
Conversation Starter

So for "incoming mail being rejected", I believe that for "gmlack" you are maybe confusing your email client connecting to the pipex mail servers to "retrieve" email addressed to you - a problem which I have got on a regular basis with pipex over the years by the way - and for the same reason you describe - authentication failures or timeouts.

 

But the incoming email being rejected by pipex from external email senders such as from domains at "gmx.at" and others all over the world is a different problem since no authentication takes place with external email sending servers into the pipex mail domain - after all how could all the external providers of email across the world have a "logon" to a pipex server account? A massive overhead in maintaining all of the logins etc I think your post is referring to your connection to an MSA as described below.

I hope this doesn't confuse our Pipex support staff to look in the wrong place which is their MX record structures and their MDA servers etc

 

See https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

 

"A MUA knows the outgoing mail SMTP server from its configuration. A relay server typically determines which server to connect to by looking up the MX (Mail eXchange) DNS resource record for each recipient's domain name. If no MX record is found, a conformant relaying server (not all are) instead looks up the A record. Relay servers can also be configured to use a smart host. A relay server initiates a TCP connection to the server on the "well-known port" for SMTP: port 25, or for connecting to an MSA, port 587. The main difference between an MTA and an MSA is that connecting to an MSA requires SMTP Authentication."

Highlighted
Wizz Kid



@johnrg wrote:

 

But the incoming email being rejected by pipex from external email senders such as from domains at "gmx.at" and others all over the world is a different problem since no authentication takes place with external email sending servers into the pipex mail domain -


Possibly, but when the authentication process is running slow (as it was overnight) it's quite possible that he relay servers will run out of sockets for any incoming connexion.

 


@johnrg wrote:

 

I hope this doesn't confuse our Pipex support staff to look in the wrong place which is their MX record structures and their MDA servers etc


Which is what the messages I sent overnight that ended up flagged as Spam referred to.

 

I reckon the pipex.dsl.com MX records are wrong in that they point to CNAME records. Some (many) resolvers will be OK with this, but some will not (I recall having such problems myself in the early 90's) . GMX.com is one that objects - trying to send a mail to pipex.dsl.com from there instantly results in "No valid MX record found".

Highlighted
Wizz Kid

Oddly, every time I put a post in here that refers to the cause of one of the problems (and hence a solution) It gets treated as Spam.

That's 3 in a row now.

Highlighted
Wizz Kid

Well, that one stuck.

Let's try this one...

 

Here is an extract from https://help.ubuntu.com/community/BIND9ServerHowto 

Mail Exchange Records

Used to define where email should be sent to and at what priority. Must point to an A record, not a CNAME.

 

The MX records for dsl.pipex.com point to CNAME records!

They need to be changed to point to mx.talktalk.net and mx.tiscali.co.uk (the real servers, not aliases for them).

Highlighted
Wizz Kid

More  info...hoping this won't be treated as Spam.

 

I created free accounts on outlook.com and gmx.com to send test messages to my Pipex account every 30mins.

 

The gmx.com one failed instantly with "No valid MX record", which is why I lookeed into the CNAME thing (vaguely recalling having had the same issue myself in the early 90s). This fits the permanent delivery problem.

 

The outlook.com one started to run, but overnight I've had two bounces from it (and it then started delivering again, so fits in with the transient problem). So I now have full headers (indeed - the entire message) from  one of these bounces.

Highlighted
Wizz Kid

And yet more Spam detected when I post that I have generated a TT512 error (so have the full bunce report).

>>Sigh...<<

Participant

@gmlack  I don't think the problem you mention with the MX records for dsl.pipex.com resolving to CNAME instead of A records is anything to do with the problem this thread is about.  The misconfiguration will increase DNS traffic by forcing an extra lookup, but clearly the sending domains whose mails are being rejected are able to connect to the TalkTalk server or they wouldn't be receiving bounce messages back.