Mail to Tiscali rejected from certain senders

[PhilK4]

I have recently discovered that one sender (from gmx.at) has, since at least last October) been sending mails to my Tiscali address which have been neither received nor bounced back.

Recently I have tried copying a reply to a mail from the same sender (to a second address of mine) to Tiscali, and have received, several times now, the following rejection message:

A message that you sent has not yet been delivered to one or more of its
recipients after more than 48 hours on the queue on fallback4.mail.ox.ac.uk.

The message identifier is:     1rV8Jx-0007QA-I6
The date of the message is:    Wed, 31 Jan 2024 10:59:51 +0000
The subject of the message is: Fwd: Fragen, Probleme, Korrekturen, Bitten

The address to which the message has not yet been delivered is:

  [*****]@tiscali.co.uk
    host mx.tiscali.co.uk [62.24.139.42]
    Delay reason: SMTP error from remote mail server after end of data:
    452 4.2.0 VskirzfNysd0nVskirgAZV Content deferred (TT991)

No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.

Any offers on what is causing this or how it may be rectified?

[Gondola]

I can see that the originating IP address is authenticated by the spf:_netblocks.ox.ac.uk SPF authentication file.  The root cause for suspicion is not obvious.

[PhilK4]

Typical diagnostics attached.

[Gondola]

Yes it reveals exactly what's happening as I've explained. It does not reveal the root cause.

[PhilK4]

There is a load of diagnostics with each of the "Message delayed" notices: is this likely to reveal anything?

[Gondola]

That's why I recommend you stop sending via the University servers. Repetitive attempts will just cause the spam protection to drop the mail.

I have asked TalkTalk Support to look into this to try and identify the root cause.

[PhilK4]

Thank you - but that does not help! Some of the messages are so simple that there is no way they could contain anything suspicious. They continue to be rejected until after 96 hours the sending server gives up.

[Gondola]

The ESMTP code 4.2.0 is not a rejection of mail it's a temporary indication of issues and the description of Content deferred (TT991) means that the mail message has a delayed delivery due to suspicious activity requiring that the message be scanned.

If the message hasn't been delivered then it's failed to pass scanning.

Clearly something about the messages or the way they're being sent to your tiscali mailbox is deemed suspect. Whether it's the sending email address, the originating or sending IP address or content.

I recommend you stop sending via the University servers. Something suspicious has been flagged up. The continual retries by the University mail servers will just cause further suspicion. Although it is standard practice for a mail server to re-attempt a failed delivery, in this case, it's not a failed delivery as such it's a deferred or delayed delivery. If the mail message passes scanning then the message would arrive in the destination mailbox.

[TonyOldone]

Hi Phil.

I too am having problems getting emails from certain addresses to my Tiscali email.

This started last November with me.

I added the URLs for where the emails were to come from to my anti-virus allow list.

Still nothing.

Having looked at my email settings, there is nothing there to prevent these emails from getting through, that I can see.

I have 'phoned one of the providers and they have informed me that they have responded to every email I have sent to them since November.

I fully expected their emails to come through because they did in April 2023, when I was last in contact with them.

Their IT people are of the opinion that it is a problem at the TalkTalk (Tiscali) end. 

I do not receive any notification at all.

I am beginning to think that they are correct. 

Password reset emails from software companies and from other suppliers should be allowed go to the requester.

It is almost as if TalkTalk are wanting to close down all accounts for tiscali.co.uk but have not said anything to those using the account.

If that is the case, they should tell us and give us plenty of time to transfer our emails and let our contacts know of the change.

[PhilK4]

This is still a problem. Tiscali is rejecting even simple mails from ox.ac.uk without attachmentts and after thorough scan for viruses.

This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 4 hours on the queue on fallback4.mail.ox.ac.uk.

The message identifier is:     1rX0aF-0006ie-JJ
The date of the message is:    Mon, 5 Feb 2024 15:08:28 +0000
The subject of the message is: Testing 5-2-24

The address to which the message has not yet been delivered is:

    [****@tiscali.co.uk]
    host mx.tiscali.co.uk [62.24.139.42]
    Delay reason: SMTP error from remote mail server after end of data:
    452 4.2.0 X5RMrshW7ZFJWX5RMr7FO9 Content deferred (TT991)

No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.

Reporting-MTA: dns; fallback4.mail.ox.ac.uk

Action: delayed
Final-Recipient: [****@tiscali.co.uk]
Status: 4.0.0
Remote-MTA: dns; mx.tiscali.co.uk
Diagnostic-Code: smtp; 452 4.2.0 X5RMrshW7ZFJWX5RMr7FO9 Content deferred (TT991

This was the mail:

To my knowledge, it has also rejected a mail from univie.at.

How can this be resolved?

[Gondola]

I did indicate in my first reply that I hoped the University server would not get blacklisted by TalkTalk for sending on the same content that the TalkTalk inbound mail servers clearly did not like being sent from Vienna via the gmx.at servers. 

As a precaution I advise you both to scan your email devices for potential viruses, trojans or other malware.

Is the TalkTalk inbound mail server giving your alternate email address a bounceback error and if so what is the description and TT error code.

[PhilK4]

I can now confirm that even a simple text mail from gmx.at is not getting through, also that equally simple mails from ox.ac.uk are being blocked. This is looking like an inter-server dispute, with the ox.ac.uk repeatedly trying to send the same mail and Tiscali now blocking anything from that source.

[PhilK4]

Waiting for that ...

[Gondola]

TalkTalk will always scan attachments and if there is anything suspicious then the mail will be dropped.

Are you able to confirm that your contact in Vienna, Austria can send an email without attachment and that gets delivered to your Tiscali mailbox?

[PhilK4]

I am really not sure. I am beginning to wonder if it is something to do with attachments and am making some more experiments.

[Gondola]

What is it then that you are asking TalkTalk to do?  It's obvious that the spam protection has been triggered to send back the TT991 error and to scan the content. If something undesirable has been found then, as I've explained, the mail can be dropped without further notification.

[PhilK4]

I don't think that anything which has 'gone wrong' with the output from the gmx email is likely to be at fault, or it would have been more widely apparent to the sender over the months that it has been happening (e.g. blocked by a number of domains).

[Gondola]

The first step in troubleshooting from Vienna is to scan email devices to remove potential viruses, trojans or other mailware and then use a different email service to contact you.

For example, set up a Gmail account and send from Gmail webmail a plain text message to your Tiscali email account.

Then if that comes through to use the same content as previously attempted.

Then if that comes through the issue has to be:

• The gmx.at domain has been sending spam
• Or the public IP address of your contact has been sending spam (if sending from an email client rather than from webmail)

If the first is the issue then it's up to the admins at gmx.at to stop spam at source. If the originator's public IP address is blacklisted and their ISP uses dynamic IP addresses then switch off their router for at least 30 minutes before repowering to see if a new IP address has been allocated.

[PhilK4]

Thank you. That is an explanation (of a sort), but does not suggest how I (or the sender, in Vienna) can do anything about it. At least the ox.ac.uk server sent (and continues to send) a warning; but that may not have happened with gmx.

[Gondola]

Hi Philip

I've moderated your content to remove your email address.

The original sender uses an Austrian top level domain which explains the German language subject title. There is something about the content that the TalkTalk Mail inbound servers do not like which is why you see the TT991 Content deferred bounceback. This means that the content has not been delivered, is being scanned for security reasons and may be subject to a delayed delivery.  If the scanning determines that the email is undesirable to allow through then it can be silently dropped. i.e. not delivered and no bounceback mail delivery fail notification issued.

The University mail server has obviously been retrying the sending so I hope this hasn't resulted in the University mail server being blacklisted. The gmx.at domain is blacklisted by one agency although not an agency that is widely trusted.