Strange Incoming e-mail Issue - multiple copies being received
I'm getting multiple (typically 3) copies of messages from a particular sender since April this year. First thought is they're just sending it 3 times so I'm getting 3 copies ! This is technically correct, of course, but is it possible that PN have changed something between 21/03/2022 and 10/04/2022 that could possibly be causing this ?
Looking at the raw message data, the 3 messages received are to all intents and purposes identical other than the data transfer timing:
> Delivery-date: Thu, 16 Jun 2022 17:00:00 +0100
> Received: from [216.250.248.239] (helo=server17.robohosting.solutions)
> by inmx-peh-004.plus.net with esmtp (PlusNet MXCore v2.00) id 1o1rua-000AsX-2x
> for Me@My_Account.plus.com; Thu, 16 Jun 2022 17:00:00 +0100
> Delivery-date: Thu, 16 Jun 2022 17:00:03 +0100
> Received: from [216.250.248.239] (helo=server17.robohosting.solutions)
> by inmx-ptp-007.plus.net with esmtp (PlusNet MXCore v2.00) id 1o1rua-000928-NA
> for Me@My_Account.plus.com; Thu, 16 Jun 2022 17:00:03 +0100
> Delivery-date: Thu, 16 Jun 2022 17:47:17 +0100
> Received: from [216.250.248.239] (helo=server17.robohosting.solutions)
> by inmx-ptp-007.plus.net with esmtp (PlusNet MXCore v2.00) id 1o1seK-0006XI-Vt
> for Me@My_Account.plus.com; Thu, 16 Jun 2022 17:47:17 +0100
This is solely an SMTP/POP3 transfer not IMAP and there is no spam filtering etc. set up on my account. All messages come straight in and get delivered to a catch-all account.
Anyone have any thoughts ? ... other than like me that it's almost certainly something a tad weird at their end ! Some kind of recent(ish) grey listing attempt by PN going wrong perhaps ?
Hi there,
I think it's worth contacting the sender and ask them if they're inadvertently sending you duplicate emails.
If they confirm they aren't then drop me a PM with the full unredacted headers from the emails and I'll raise with NetOps. Would need to be within the last 24 hours as we only keep logs for 7 days and it can take some time for an investigation.
Thanks for the reply. I've not been ignoring it, just waiting to hear from the sender and also see what happens with their next mail out.
I obviously contacted the sender long before posting here to let them know something odd is going on somewhere. The reason being that if it's a general issue at their end then it's likely to end up causing no end of significant problems ultimately because it just 'looks' like abuse rather than a genuine attempt to deliver 1 message to 1 user. The sender and their service provider have been looking at things at their end, and they still are, but whatever the issue actually is, it's apparently nothing obvious and it's still happening.
Like I said in the first post, they obviously are sending 3 copies of the message but for reason or reasons completely unknown. The only thing I have subsequently noted is that their server DNS/rDNS/HELO data isn't exactly as kosher-looking as it perhaps ought to be in an ideal world ! Maybe PN is doing some kind of verification and isn't overly happy hence the message not being accepted immediately and acknowledged as such ?
My thought still is that maybe PN isn't terminating the data transfer sensibly and/or is providing an unexpected/undocumented error code or whatever hence the repeated attempts being made. It seems like the sender doesn't think the message has been delivered satisfactorily but PN are in fact receiving each attempt and delivering them all to me. I guess the only way to know what's actually going on here is going to be from looking at the SMTP session transcript from either end. Somewhat difficult and/or a right old PITA when it's a company sending 1000's of genuine bulk emails to customers via their service provider and an ISP receiving several orders of magnitude more every hour !
The latest message was sent on Sunday 10th and I'll PM you the raw message data for the 3 copies received by PN ... when I can remember how to do it ! As also stated in the first post though, the messages appear to be to all intents and purposes identical other than in the data transfer timing. Maybe the server logs will have some useful info for the typically unique message ID(s) involved though ?
As stated in the first post, the ONLY significant difference between the 3 messages being received is the date/time of data transfer. Everything else bar what appears to be a message list 'housekeeping' header is identical.
COPY #1: Message-Id:
<E1oAXfe-0007Ew-U8@server17.robohosting.solutions>
COPY #2: Message-Id:
<E1oAXfe-0007Ew-U8@server17.robohosting.solutions>
COPY #3: Message-Id:
<E1oAXfe-0007Ew-U8@server17.robohosting.solutions>
It's 3 attempts to deliver the very same message with the very same ID leading me to believe that the sending end doesn't think the data transfer was successful and is therefore trying again. However, PN is in fact receiving all 3 attempts without any apparent issue and delivering them all to me.
This issue suddenly started happening in April. All recent(ish) messages up to and including 21/03/2022 were handled entirely correctly. All messages from 10/04/2022 onwards have been problematic. There does not appear to be any significant fundamental difference between older messages and current messages or anything in any way different and/or unusual in the manner in which they were sent.
TBH, I'm getting an increasingly annoying déjà vu feeling about this. The more I think about it, the more I'm becoming almost certain that I've been here, done this and bought the tee shirt before at some point in time over the past 25 years with PN. I shall be more than a bit bl**dy annoyed if it ultimately turns out that whatever is going on here is a known 'problem' that countless hours have already been wasted on previously and it's suddenly reappeared for no particularly good reason whatsoever ! I can't see anything after a quicky looky see ... but I think I'd be prepared to put quite a significant amount of money on there being a very similar thread lurking somewhere in the mists of time either around here or, perhaps much more likely, on one of Ye Olde Forums various 
Any news from NetOps seeing that the working week and data retention time is rapidly coming to end ?
@mikeb wrote:
Any news from NetOps seeing that the working week and data retention time is rapidly coming to end ?
Yeah sorry for the delay. One of my colleagues in NetOps has advised that he can see the emails are received, but the logs aren't able to identify the root cause. He recommends you to enable SPAM filtering as the emails are then handled differently and have resolved issues in the past. If you set SPAM to "On" and if using a mail client, set the SPAM rule to leave in Inbox and add [SPAM] to the beginning of the Subject line.
Hi Bob. V.long time no see and all that 
Absolutely 100% confident. It's a company that I have used for some considerable period of time who send me messages regularly but not very often compared to most companies. Other than order confirmations and updates, it's typically just one message a month sent out to all customers unless there's something of any particular urgency needing to be announced/advised.
The two dates quoted are the date of the last message received with no issues and the first message received that ended up as being 3 identical copies. It's still going on now. Every message they've sent out since this started happening has ended up as 3 identical copies being received.
They've just sent a message out today in fact regarding the RM Strike action affecting deliveries. I've received the first 2 copies and the third will no doubt be with me in a hour or so !
I PM'd the complete raw data for the 3 received messages (and also for the last message received with no issues) to Gandalf as requested earlier so these should be available to look at somewhere. I can also PM you the complete raw data for today's message when the 3rd copy arrives if you like. However, the raw data really does show that the only significant difference between the 3 messages is the date/time of connection to the PN server.
It just looks like the sending end doesn't think the data transfer was successful so is trying again, once almost immediately and then again some period of time later. However, only a session transcript is going to provide definitive info.
Re the déjà vu ... I think I'd be prepared to put a significant amount of money on us having this conversation before. I'm almost certain that it's something I found happening for a period time to some received messages from some senders the last time that the e-mail system was all shiny & new after being replaced following one of the previous e-mail nightmares. I just can't remember when that might have been and where exactly it was discussed tho.
My guess is that PN doesn't 'like' the SMTP helo, server name or server IP etc. and are therefore effectively bouncing messages with a 45X "try again later" code. However, they are in fact receiving and delivering all attempts to me. The sender, meanwhile, is left to keep trying due to multiple alleged delivery failures and they subsequently give up after 3 attempts. The big potential problem with this is that some senders may well give up completely and stop sending all future messages due to too many attempts, bounces or errors etc. That's sort of what I think I remember was the conclusion when this was being seen for some time after a new e-mail system first went live.
I'll check out the linked thread a bit later on tonight, I don't have time just now I'm afraid.
@Gandalf wrote:
He recommends you to enable SPAM filtering as the emails are then handled differently and have resolved issues in the past. If you set SPAM to "On" and if using a mail client, set the SPAM rule to leave in Inbox and add [SPAM] to the beginning of the Subject line.
Sorry, only just seen this but it's not realistically possible to do that I'm afraid. I also really can't see how it could actually help in any case. The issue is clearly with the incoming SMTP server (MX) and not whatever might happen to message(s) after they've been received.
Unfortunately, much past experiences over many years tells me that I will lose up to 50% of my totally genuine and requested/wanted messages with spam filtering enabled. That's why it was disabled just as soon as the option to do so was made available and it has never been used on my main A/C since.
In fact I still have a test A/C with spam filtering enabled that should receive what are effectively duplicate copies of a significant number of messages that are sent to my main A/C. Even today, some several years after spam filtering first became available, it does not. A very significant number of totally genuine messages apparently disappear without trace when spam filtering is turned on. At best the message loss from a particular sender is intermittent at worst it's always. This also led to problems with being permanently deleted from message lists or frequently having the service suspended due to too many errors or bounces etc.
TBH, it's completely unacceptable to me that PN can (and do) quietly & silently decide what incoming messages I can and cannot receive
I might be able to try getting the current problematic sender messages sent to this A/C though just to see what happens. However, it may not be possible to have 2 purchase A/Cs with the same name & address and service or marketting messages may not be sent out to dormant or unused A/Cs in any case.
It *REALLY* shouldn't be this difficult or take this long for a professional IT guy at a professional ISP to know or at least be able to work out what is or might be going on here ... and then resolve whatever the problem is that's been created or advise what the issue probably is and then justify why it's not considered to be a PN problem.
I am well aware that enabling spam filtering means that a completely different MX will be used for incoming SMTP connections i.e.
non-filtered: mx.core.plus.net
filtered: mx.avasin.plus.net
But how on earth does using a completely different server with completely different set-up and using a completely different set of rules in any way help in understanding what is going on with another totally different server ?
mx.core.plus.net appears to have been randomly tweaked in April and no longer seems to be behaving sensibly in some specific instances. I believe that it has also been seen doing this before several years ago but was fixed and the problem hasn't been noticed by me again until relatively recently. Whether mx.avasin.plus.net behaves in much the same way or quite differently is totally irrelevant isn't it !
Having done a few telnet tests earlier, it is perfectly clear that the two MX routes really are quite different. For instance, mx.core.plus.net accepts and delivers mail from my static IP whereas mx.avasin.plus.net rejects it outright because my static IP is allegedly blacklisted on Spamhaus. It would appear that mx.core accepts any old rubbish and delivers it but at no time could I make it formally complain or reject anything other than due to a typo or my own stupidity. However, mx.avasin is no doubt *very* pedantic in all respects.
As for changing my settings ... I know that I will lose mail if I do which makes it a non-starter in my book. It will also be anything up to a month before I can expect to see another message from the sender in any case. However, I will never actually know whether a message has been sent but PN have chosen to bounce or silently delete it after receipt. I have little confidence in PN mail and zero confidence in PN spam filtering in particular following many months/years of problems and lengthy investigations & monitoring various.
I have absolutely no idea what the sender's service provider uses in terms of equipment, software or services etc. and nor should I or indeed the sender need to. It's just a company sending customers totally genuine and solicited messages occasionally via their service provider. It's worked just fine for donkey's years but suddenly something isn't quite right. It 'looks' very much like a PN problem and I genuinely believe that we've had it before. Something appears to have fundamentally changed at some point in time between 21/03/2022 and 10/04/2022. It *really* shouldn't be that difficult to establish what, where and why and then put things right where necessary. There should be definitive records of work done, change notes and Quality Control checks etc. available.
Sorry, I know you're trying to be helpful but I've been around the block way more than few times with PN over the past 25 years. Not only have I been here and done all this before but I've definitely got an entire wardrobe full of tee shirts to prove it ! I have always been one of the "very small number of customers" affected by each and every single nightmare that has occurred over the past 25 years and have wasted an extraordinary amount of time & effort fault finding and investigating issues various for PN. If it ain't broke then don't try to fix it and all that ... so please can someone just unfix mx.core sometime soon if they've been caught playing around with it in early April
Hmmmmmmmmm ... OK ... So who's been tweaking what ... AGAIN !!!!!
Following a forced reboot at somewhere around 0230 hours, it would appear that I can no longer access mail.plus.net at all and haven't been able to for around a couple of hours. All attempts are now either ignored or refused i.e. just a timeout or "connection closed unexpectedly by server" error message. No ultimate change in gateway apparently occurred it was simply a rather suspicious looking maintenance period reboot/reconnection together with the inevitable drop in synch speeds that almost always accompany such unexpected events.
Access to mail.force9.net (and servers elsewhere) appear to be working just fine ... famous last words and all that 
If you don't stop playing with it you'll go blind I'll cut your bl**dy fingers off and all that :lol:
Deleted and will repost due to not redacting personal data
OK, as per much earlier request to try using the other MX ... here's the end result of the same message sent by the same company using the same mailing list on the same system and at very much the same kinda time ... to both flavours of PN MX:
Three copies received via mx.core.plus.net as per usual since end March / early April
[quote]
> Received: from [216.250.248.239] (helo=server17.robohosting.solutions)
> by inmx-peh-004.plus.net with esmtp (PlusNet MXCore v2.00) id 1oZDVr-0008Rf-95
> for Me@MyAccount.plus.com; Fri, 16 Sep 2022 16:44:19 +0100
> Message-Id: <E1oZDVq-0003uR-JN@server17.robohosting.solutions>
> Date: Fri, 16 Sep 2022 16:44:18 +0100
[/quote]
[quote]
> Received: from [216.250.248.239] (helo=server17.robohosting.solutions)
> by inmx-ptp-001.plus.net with esmtp (PlusNet MXCore v2.00) id 1oZDVr-0008o6-TJ
> for Me@MyAccount.plus.com; Fri, 16 Sep 2022 16:44:20 +0100
> Message-Id: <E1oZDVq-0003uR-JN@server17.robohosting.solutions>
> Date: Fri, 16 Sep 2022 16:44:18 +0100
[/quote]
[quote]
> Received: from [216.250.248.239] (helo=server17.robohosting.solutions)
> by inmx-ptp-009.plus.net with esmtp (PlusNet MXCore v2.00) id 1oZG08-0003uC-AG
> for Me@MyAccount.plus.com; Fri, 16 Sep 2022 19:23:44 +0100
> Message-Id: <E1oZDVq-0003uR-JN@server17.robohosting.solutions>
> Date: Fri, 16 Sep 2022 16:44:18 +0100
[/quote]
Only one copy received via mx.avasin.plus.net
[quote]
> Received: from [84.93.230.238] (helo=avasin-ptp-004.plus.net)
> by inmx-peh-009.plus.net with esmtp (PlusNet MXCore v2.00) id 1oZDZV-00020q-20
> for Me@MyAccount.plus.com; Fri, 16 Sep 2022 16:48:05 +0100
> Received: from server17.robohosting.solutions ([216.250.248.239])
> by Plusnet Cloudmark Gateway with ESMTP
> id ZDYroWWQKgJIiZDYuoT44e; Fri, 16 Sep 2022 16:47:29 +0100
> Message-Id: <E1oZDYr-00071n-An@server17.robohosting.solutions>
> Date: Fri, 16 Sep 2022 16:47:25 +0100
[/quote]
... famous last words and all that
So now what ? Is this sufficient proof that this problem does actually exist, something more than a bit strange is definitely going on and it does seem to be most likely at the PN end ?
Thought for the day:
Although mx.avasin appears to only receive and deliver 1 copy of the message, it is entirely plausible that the sender is actually still trying to deliver more than 1 copy for whatever reason but mx.avasin is simply rejecting or silently deleting any additional attempts. Multiple virtually identical copies of a message that have apparently been sent for no particularly good or obvious reason could well be considered as spam or abuse and thus dealt with accordingly. That is why it's so important to get to the bottom of what's actually going on here and resolve whatever the real problem is.
Like I said previously, knowing how mx.avasin handles these messages doesn't really help in understanding why some problem appears to exist with mx.core ... at least not directly anyway. We need to know much more about what mx.avasin has been up to !
Please can someone obtain confirmation of whether mx.avasin did or did not see any additional attempts to deliver the same message and if so what action was taken ? The second attempt would have been almost immediately and the third attempt probably around an hour or more later if they happened.