on 09-02-2022 16:44
Still so frustrated with VM throwing valid emails into spam for no reason and letting actual spam through.
Now I find that to make things worse it now chooses to delete out of hand emails.
Today I found this in my deleted folder and if I try to move it to the inbox it is immediately deleted again. No matter what I do. I can't even use a filter rule as whatever is deleting this is working before any rule is touched.
WHY WHY WHY!!!!!?????????? This email system is so flawed and it's leading to such notifications causing havock.
As you can see this email is a perfectly normal notification from Hermes to say they have a parcel on it's way. Why on earth is VM interfering with MY Emails????
[MOD EDIT: Subject title changed for clarity]
on 09-02-2022 16:51
It's the address as I can forward this which will then have my address as sender and it's left alone so VM has blacklisted my "myhermes.co.uk" and chosen to actually delete the messages rather than put it to spam where it might be seen. You have no right to do this VM and you know it!!
on 09-02-2022 19:45
Does the same issue occur when moving other emails from Trash folder?
―
I'm a Very Insightful Person, I'm here to share knowledge, I don't work for Virgin Media. Learn more
Have I helped? Click Mark as Helpful Answer and solved, or use Kudos to say thanks
on 09-02-2022 21:59
No I only noticed this one doing it. 99% of the VM email woes are to do with its insistence of putting perfectly valid emails into spam.
By chance I saw this in the trash folder. It was sent to my secondary address which gets forwarded to my primary one. On both accounts this email is not allowed to stay in the inbox for more than 1 second. It is deleted immediately.
If there are other emails treated in this way I don't know about them, so they'd be gone forever. Nothing I've tried will stop it which includes going to the WebUI and trying to move it and creating a filter to intercept. Obviously the decision to delete is happening at a much earlier stage.
I've never seen this behaviour before and it shouldn't happen, that is what the Spam folder is for. It is up to me to decide what gets deleted.
on 10-02-2022 01:39
As far a I know:
Do you use other email clients that might explain the behaviour observed?
To help troubleshoot the issue consider creating the following filter rule to confirm these email are: (a) delivered to Inbox; and (b) later deleted or moved to Trash folder:
If you find an email from myhermes.co.uk in the Trash folder with its flag set to red then is has got there after first being delivered to the Inbox folder. If its flag is not set then it was either delivered directly to the Trash folder or deleted from Spam folder. Post back here with your observation.
on 10-02-2022 08:58
Hi,
To answer the first question. I eliminated email clients by going direct to the WebUI. Originally I did think it was my client doing this. Also it happens so fast that I doubt my android clients could be responsible for this when they poll at longer intervals (especially when dormant) which couldn't explain this kind of behaviour.
As for the rule, I see no difference to a rule I set up to find evidence. My rule differs in that I simply attempted to move or copy to a temporary folder. Initially I tried the "keep" action and then tried the copy. Both failed so I don't see how marking it red would work either as a copy should work just the same as tagging. This email isn't allowed to hit the ground obviously.
I'm talking in terms of timing, 1.5 to 2 seconds tops between dragging to the inbox and appearing in the deleted folder and that is when I do it in my client on the PC (Postbox), so on the server it must be a lot quicker ie. Milliseconds.
Also noting your comment about it not possibly being in the inbox, I can't say what the original path might have been but bear I mind that I am physically moving it to the inbox subsequently which shows that there IS a filter vetting what goes in there. I can copy this email to any other folder without it being touched.
on 10-02-2022 12:40
@louiscar wrote:
⋮
To answer the first question. I eliminated email clients by going direct to the WebUI. Originally I did think it was my client doing this. Also it happens so fast that I doubt my android clients could be responsible for this when they poll at longer intervals (especially when dormant) which couldn't explain this kind of behaviour.
⋮
Push notification would be near immediate but as Polling interval is being used then yes it would likely not explain the behaviour seen.
⋮
As for the rule, I see no difference to a rule I set up to find evidence. My rule differs in that I simply attempted to move or copy to a temporary folder. Initially I tried the "keep" action and then tried the copy. Both failed so I don't see how marking it red would work either as a copy should work just the same as tagging. This email isn't allowed to hit the ground obviously.
⋮
That is effective as well; advantage of setting an email's flag is that it is least impactful IMHO.
⋮
I'm talking in terms of timing, 1.5 to 2 seconds tops between dragging to the inbox and appearing in the deleted folder and that is when I do it in my client on the PC (Postbox), so on the server it must be a lot quicker ie. Milliseconds.Also noting your comment about it not possibly being in the inbox, I can't say what the original path might have been but bear I mind that I am physically moving it to the inbox subsequently which shows that there IS a filter vetting what goes in there. I can copy this email to any other folder without it being touched.
To decisively rule out involvement of other email clients consider disconnecting them from the internet whilst test the issue in webmail. Should the issue persist then post back here to it flagged to the forum team.
on 10-02-2022 13:35
Will do
on 11-02-2022 15:07