In IE8, Internet explores YOU.

This might help, http://www.displaylag.com/display-database/

The SMTP "RCPT TO" command (AKA the envelope To, and what PlusFiveTroll was most likely referring to with "MAIL TO") is different than the "To:" header inside the email. It is always your address, as that's how the mail actually gets routed to and accepted by the receiving mail server. The headers that address might show up in are "X-Original-To", and one of the Received headers.

The best action to take if a unique address falls into the wrong hands is to set the receiving mail server to give a 500-level SMTP response code when that address is given to RCPT TO. This is not the same as writing a bounce message. For legitimate senders, their sending server will give them the undeliverable notice, and it will know them as an authorized user and not be sending backscatter to some random third party.

Most spam doesn't go through real SMTP servers, it's zombie/botnet PCs throwing scripted SMTP commands at the MX servers for a list of email addresses. They ignore SMTP response codes and just move on anyway. No delivery, and no backscatter, in that case.

What's left is spam that is sent through compromised/open-relay mail servers. People can either chose to ignore these and let the situation get worse, or draw attention to the fact there's a mail server that needs to be fixed. If everyone who gets spam from these says /dev/null it, the problem is going ignored. If you reject it with a 5xx response code, you or your mail server still isn't generating a bounce message to an unverified address. But the the server it gave the 5xx code to might. And it will be traceable to the that server which needs to be fixed. And that's not yours to deal with. That backscatter-creating server will likely get on blacklists if it isn't already. And then that server is likely to either be fixed or largely ignored. And overall the bigger problem gets more dealt with.

The trick is, the SMTP response code has to be given during the SMTP session, preferably before the DATA command. If you're accepting the message and then doing content/header analysis, it's probably too late to properly reject it. If you do so at that time, you will likely be creating backscatter. Content/header analysis should be the last line of defense, not the line of defense. There are many things that can be done at SMTP time to determine what's bad, where false positives won't go to oblivion, and backscatter will be reduced to cases where a 3rd party mail server needs to be fixed.

Also, backscatter does not normally go to the "From" header in the email (content analysis in the user mail client might do it that way, but that would be a very bad idea). It generally goes back to the SMTP "MAIL FROM:" value (AKA the envelope From), which is usually prepended to the email content as the Return-Path header. If you don't want your domain name to be a tempting pawn as a forged MAIL FROM, it doesn't hurt to set an SPF record for it, and be diligent about setting any email software you use to use the right outbound mail server for it.

If hooked up to a computer over USB or a PS/2 keyboard port, the X-Arcade controllers can have up to 3 custom keyboard mappings.(you need a PS/2 keyboard to plug into the X-arcade itself to assign them). The computer just sees the X-Arcade as a keyboard, and the mapping happens in the X-arcade hardware, not as software on the computer. You could assign the right stick to the same keys as the left stick.

Yeah, I can also vouch for the X-arcade stuff it is fantasic, and can even be used on game consoles.

If you really want to get into it, they're compatible with real arcade parts (which you can order from other places), and can be used in something custom. I gutted an X-Arcade Dual for the circuit board (before it was available separately) and made some Mortal Kombat arcade controllers (that work with both the classics in MAME and the newer console games). ...Probably not within the original poster's budget. ...wasn't in my original budget either, but I couldn't resist.

SPF implementations are not supposed to check the From: header in the email, they are supposed to check the SMTP MAIL FROM address (which you might recognize as the Return-Path: header).

Situations like your avon/filltek scenario, greeting cards, 3rd-party mailers, etc, can still function as intended with proper SPF records, as long as the MAIL FROM SMTP command from the sending MTA software doesn't misrepresent itself. (it should not match the From: header in these cases)