Duplicate email (Plusnet MX issue?)

[#1]

Hello, I've got this problem with one of my mailboxes where every single message is received three times. I've had it for a while (a few months) but haven't had enough of a reason to look at it until now.

I have *@example.com set to forward to mymailbox@myuser.plus.com. However every single message sent to example.com is received three times - twice immediately and a third copy after about 15 minutes. If I try sending a test direct to mymailbox@myuser.plus.com then it does not happen - such messages are received only once.

So I approached support in respect of the forwarder and it was checked - they say the smtp responses show errors. Here is an excerpt:

2022-08-15 17:59:39 1oNdRC-00054I-2C H=mx.core.plus.net [212.159.9.1]: Remote host closed connection in response to end of data
2022-08-15 17:59:39 1oNdRC-00054I-2C H=mx.core.plus.net [212.159.8.1]: Remote host closed connection in response to end of data
2022-08-15 17:59:39 1oNdRC-00054I-2C == mymailbox@myuser.plus.com R=probable T=remote_smtp defer (-18) H=mx.core.plus.net [212.159.8.1]: Remote host closed connection in response to end of data
2022-08-15 18:07:05 1oNdRC-00054I-2C == mymailbox@myuser.plus.com R=probable T=remote_smtp defer (-54): retry time not reached for any host for 'myuser.plus.com'
2022-08-15 18:07:05 1oNdRC-00054I-2C == mymailbox@myuser.plus.com R=probable T=remote_smtp defer (-54): retry time not reached for any host for 'myuser.plus.com'
2022-08-15 18:17:13 1oNdRC-00054I-2C -> mymailbox@myuser.plus.com R=probable T=remote_smtp H=mx.core.plus.net [212.159.9.1] K C="250- 29739 byte chunk, total 32900\\n250 OK id=1oNdiD-00077z-1C"

I've seen other postings on here in the past, like this one and especially this one that appear similar but  I don't know how to troubleshoot this myself as the server is plusnet's not mine. The duplicates can be seen in the Plusnet webmail client which verifies this isn't a client-side issue.

My guess at this is there is some issue with the PN mailserver that only affects senders that try to use the protocol "properly" and perform 2 resends due to that issue. The second-linked issue above is almost exactly the same as what I am seeing and would seem to have started occurring around the same time as it did for me.

Anyone got any ideas ?

[#2]

Hello anyone from Plusnet able to comment on my issue please ?

[#3]

There's a theme here 🤔

Both your observation and that of the the others on the threads you've linked to all relate to Plusnet mailboxes that have spam filtering disabled, and possibly some sort of SMTP forwarding in place from an external domain.

Where is your domain hosted?

[#4]

Hello @bobpullen 

The domain is on 20i.com. It has two identical "catch-all" forwarders, one forwards to the main "myuser@myuser.plus.com" and the second one forwards to "othermailbox@myuser.plus.com". The first works fine, the second receives each message three times. I have already asked 20i support and they gave me the logs posted previously.

In case you're wondering why 2 forwarders... the main one is regularly collected and flushed by my own mail server and is therefore mostly empty. The second one is like a backup copy - it is not collected but I have a job that keeps it to 30 days or so. The trouble is, it has 3 times the content it should  

[#5]

@bobpullen did you get a chance to take a look at this?

[#6]

@starfry

You might consider switching on spam filtering for your domain and see if your experience changes. Filtered and not filtered use different inbound MX servers. Switching from one to the other might take 24 hours to become effective.

[#7]

@starfry  - the logs from your domain host seem to align with what you're seeing. I'm no expert, but here's my interpretation...

There are two separate entries with the response 'Remote host closed connection in response to end of data'. This will relate to the first two copies of the message you get immediately. I'm not 100% convinced it's indicative of an error at our side though. A mail server will close the connection after a message has been accepted e.g. (this email may hit your mailbox BTW): -

$ telnet mx.core.plus.net 25
Trying 212.159.8.1...
Connected to mx.core.plus.net.
Escape character is '^]'.
220 mx.core.plus.net ESMTP Exim Fri, 26 Aug 2022 12:22:15 +0100
ehlo mxcore
250-inmx-peh-009.plus.net Hello mxcore [80.229.150.170]
250-SIZE 104857600
250-8BITMIME
250-VRFY
250-PIPELINING
250-CHUNKING
250 HELP
mail from:<me@privacy.net>
250 OK
rcpt to:[REDACTED]
250 Accepted
data
354 Enter message, ending with "." on a line by itself
subject: test
this is a test, please ignore
.
250 OK id=1oRXQJ-000GJe-QP
quit
221 inmx-peh-009.plus.net closing connection
Connection closed by foreign host <-- THIS IS NORMAL

First question - why did your host forward the email twice in the first place?

What follows in the logs is interesting. There are another three attempts to send the email that our server defers, seemingly because they are attempted so quickly after the first couple of attempts. Second question - why does the domain forwarder think the previous two messages weren't accepted? i.e. why continue to try sending it?

The sixth attempt is accepted, which looking at the timestamps, relates to the copy you receive ~15 mins later.

Whilst I can't rule out our servers doing something odd, if it wasn't for the other similar-sounding reports you've linked to, I'd put the onus here squarely on your domain forwarder.

The domain is on 20i.com. It has two identical "catch-all" forwarders, one forwards to the main "myuser@myuser.plus.com" and the second one forwards to "othermailbox@myuser.plus.com".

This is a real odd setup and is something I'm surprised your host even permits. It's essentially defining two mailbox entities that share exactly the internal routing. No idea if it's contirbuting to the problem or not but it certainly wouldn't surprise me if it was.

Edit: Whilst it doesn't get to the bottom of the problem, @Townman's suggestion is a good one.

[#8]

@starfry - also, can you narrow this behaviour down to a specific date that it started?

[#9]

Hey folks,

I am not a PlusNet user, but I have this exact issue, so I thought we could all help each other out. I also have a similar setup: on my web host, I have a catch-all *@domain.tld (redacted) which forwards to my email address which is on a separate VPS I run. 

I don't know about this possible duplicate routing talked about earlier, but I have heaps of these 'catch alls' setup on that web host, going to different services, eg *@dom2.tld goes to my MS365 work account, *@legacy.tld goes to an old Gmail account, and they all work fine - each email you send to that domain gets forwarded and then cleared from the queue. This issue appears specific to Exim on the web host delivering the email to Postfix on my VPS.

In this instance I am lucky; I own the web hosting company, and so I have access to all the logs, but even after having been a Linux server engineer for 10+ years, I've not seen this before, and it has me a tad stumped.

On the host, I can see the email in the queue for delivery as if it's never tried (status Queued). Not frozen or anything. If I tell it to deliver it all looks kosher - redacted output from Exim attached. After this though, the message is still in the queue as if nothing ever happened. Postfix on the receiving end looks all happy; message received, connection closed, spamd processes it as 'clean' and then I see it in my inbox. An hour or so late, Exim retries, and I get another copy.

This goes on for days, until the retry counter exceeds its limit in one wa or another. Thoughts?

[#10]

I have confirmed that main.cf line

smtpd_tls_security_level = may

and master.cf config

smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may

Results in this. Changing 'may' to 'none' prevents it, but of course then you're not opportunistically encrypting incoming emails.

As best I can find from doing some verbose logging (add -v to end of master.cf line and restart postfix), the TLS process is closing the connection before telling the sender that the message was accepted. Eg:

Aug 28 09:11:53 domain postfix/smtpd[1355134]: proxymap stream disconnect
Aug 28 09:11:54 domain postfix/smtpd[1355134]: auto_clnt_close: disconnect private/tlsmgr stream

But I know my certificates are good etc (Lets Encrypt!), so I am not sure WHY it is doing this. I found one ServerFault thread that referenced rspamd failing to connect to a Redis server, however, I am using SpamAssassin and even when I turned that off, the fault still occurs.

Consulted another engineer and he is as stumped as me.

FYI @bobpullen: Since this is in the Postfix/smptd config on my server that is clearly causing the duplications - the receiving end - that would mean that this is also an issue on the PlusNet email server(s) if one of your mail users is having this same issue. Hopefully we can find a fix that is not "set TLS to none"

[#11]

An interesting comment in the Postfix TLS readme https://www.postfix.org/TLS_README.html 😁

NOTE: By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on hundreds of thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduces one additional bug into Postfix. 

[#12]

Hahah very well said in that readme!

Given that so many servers support encrypted SMTP receive, I'd guess this is either a postfix bug in this version (version 3.5.8 for me), else something in the configuration that both my private VPS and PlusNet are doing wrong.

So odd.

[#13]

---

@bobpullen wrote:

A mail server will close the connection after a message has been accepted e.g. (this email may hit your mailbox BTW):

First question - why did your host forward the email twice in the first place?

What follows in the logs is interesting. There are another three attempts to send the email that our server defers, seemingly because they are attempted so quickly after the first couple of attempts. Second question - why does the domain forwarder think the previous two messages weren't accepted? i.e. why continue to try sending it?

The sixth attempt is accepted, which looking at the timestamps, relates to the copy you receive ~15 mins later.

This is a real odd setup and is something I'm surprised your host even permits. It's essentially defining two mailbox entities that share exactly the internal routing. No idea if it's contirbuting to the problem or not but it certainly wouldn't surprise me if it was.

@bobpullen 

I didn't get an email on Friday at 12:22.

I'll ask about the sequence of events on the ticket I have with 20i.

I'm not sure what's odd about the setup - they allow multiple "catch all" forwarders and I've been using multiple for years.

* Another family member has a domain that has two - one into a plusnet mailbox and another into her icloud. Works fine, no duplicates (actually, that one isn't on 20i but 123-reg I think).

* I have a domain (on 20i, the one being discussed) with two forwarders - one into one pn mailbox and a second into another.

The reason for having the pairs of forwarders is confidence in the mailservers - we know icloud drop messages without informing because we have copies in a plusnet mailbox and, in my case, I run my main mailserver and hack about on it so I have a backup for those times we all experience.... )

I cannot be certain, but I can tell you that it did happen on 31st July 2022. Prior to that I only have a few retained messages there and they are all single messages marked to be retained - the mailbox purges older messages. I think the problem started around April but I cannot be sure.

[#14]

@starfry thanks, just don't recall coming across a set-up before with multiple catch-alls for the same domain. Not saying it's the sole cause, just alluding to the fact that it may well be a contributing factor. I'm trying to pin down a particular set of dates in April to see if it coincides with any changes that were made at our side.

@Platima also thanks, interesting deduction. Unless something has changed since I was last aware, the inbound delivery servers that seem to be subject to this issue at our side are running Exim, not Postfix.

The domain is on 20i.com. It has two identical "catch-all" forwarders, one forwards to the main "myuser@myuser.plus.com" and the second one forwards to "othermailbox@myuser.plus.com". The first works fine, the second receives each message three times. 

@starfry - how are each of these destination Plusnet mailboxes configured? Are either of them catch all mailboxes at our side?

If I find some time, I might register a domain with 20i.com so we've a method of readily replicating the problem.

[#15]

@bobpullen right you are! When I telnet to mx.core.plus.net I get an Exim banner. It could then perhaps be something to do with the TLS library (or version) being used, unless they are using similar libsmtpd (made up but guessing exists) etc libraries.