Hayley,
Thanks. I've checked my settings, which havent changed, ie "move all spam mail to spam folder"
I also note that I can't "teach" the filter to ignore particular mail by moving items into the spam folder
However, looking at the email headers, I am very surprised that that the filter is not working, as it is so obvious from simple manual inspection that the messages are of extremely dubious provenance; Here are a couple of extracts from two spam mails that I have received in the last 24 hours:
First one
Return path is null ie <>
Sender alias is "McAfee", and its full (apparent) email address is <karmenATnear.edecender.org.uk>
Second one
Return path is null
Sender alias is "Payment Failure" and its full email address is <xhUjsdfejVGfATemuweb.fieldmuseum.org>
(In both cases I've replaced '@' with AT just in case something tries to resolve these into clickable links.)
Although setting the Return Path is optional in the RFC standard, it being set and having the same top level domain name as the sender is regarded by many outgoing mail servers as being an indication of authenticity, indeed many mail servers simply won't transmit a mail where there isn't such a match. Spammers tend to omit this field because the Return Path is the address that any bounced mail will be returned to and as a large proportion of spam mail would otherwise be bounced such a large volume in incoming traffic could potentially cause denial of service on the outgoing domain. So my question is why is the lack of a Return Path alone not a huge red flag for VM's spam filter?
Regards, David
