Jump to content

everthewatcher

Members
  • Posts

    9
  • Joined

  • Last visited

Reputation

0 Neutral
  1. @Andavari It's not the spam itself, it's the fact that a unique email address used once to register for this formum has fallen into the hands of a spammer.
  2. @shane 194.168.4.100 & 194.168.8.10 - both Virgin Media defaults. FWIW I've used dozens of <unique_identifier>.mail@mydomain mail addresses and only three - two* from a long time ago and now piriform.mail@mydomain - have got into the hands of spammers. * One company went bust and I'm guessing the database was sold, and the other, legit and still trading, processed its data in India where it was leaked.
  3. @ JDPower The point is it's being sent to unique addresses used only once to sign up to this forum. And in my case nowhere else. It's now being marked as spam so it's probably sitting in a lot more people's spamtraps than have posted here.
  4. There's another Operation Jubilee mail in my spamtrap, dated Friday (yesterday) and again addressed to piriform.mail@mydomain. For the benefit of the hard-of-thinking 'mydomain' is once again a placeholder. This time it's the Rules of Engagement one and again all the 'content' is in the subject header.
  5. @suman If that were the case I'd be getting loads of spam to randomword.randomword@mydomain addresses but I don't. But I did get the same spam as you sent to the unique address used just once to sign up to this forum in April this year. The reason is simple - the data has been leaked, hacked or sold. What do the moderators have to say?
  6. I got exactly the same spam email, and just like the OP it was sent to a unique address (piriform.mail@mydomain) that used to register here back in April this year. So I'd say the address list has been leaked or hacked.
  7. Could be. An SMBus controller bug that the BIOS knows about and avoids/works around when it reads the SPD, or possibly one in the Windows XP SMBus driver. I used the XP in-box drivers and not the Toshiba ones, which include a "Common Module" driver so it's possible that this deals with the issue. But now I've figured out what seems to be happening, albeit at a cost of three SODIMMs, and more importantly how to avoid it happening again, I'll leave it at that as it's a freebie job for a neighbour.
  8. Answering my own question, it looks like the Tecra 8200 has an issue with reading the SPD data that the BIOS avoids. According to www.techsupportforum.com/forums/f25/memory-failure-after-memory-write-benchm ark-7435.html (watch the wrap) the defunct system info prog AIDA32 kills SODIMMs in exactly the same way. I certainly won't be running Speccy or any other prog that reads the SPD data. Graham
  9. I've put XP on a neighbour's old Toshiba Tecra 8200 laptop and it's just killed a third SODIMM. Symptoms are it's running fine for hours until you restart it, when it either doesn't see the module or fails to boot if it's just the one module installed. The original Toshiba 128MB module was the first to die. The common factor in two out of the three deaths was Speccy being run at some time in the session immediatley before it died - the third time there were two modules fitted so it wasn't clear exactly when the module failed. Nothing clever or tricky is being run - no memory testers or the like. Which makes me wonder if Speccy is corrupting the module's SPD info. I can't say exactly which version was being run as the laptop is dead ATM as I've run out of modules, but it's probably the latest, downloaded directly to the laptop a week or so back. So is it possible for Speccy to corrupt the SPD data? <edit> Perhaps I should rephrase that to say: So is it possible that running Speccy is somehow causing the SPD data to be corrupted? Graham
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.