I’m not sure whether there’s already an RFC in existence for this concept. I couldn’t find one, but frankly, didn’t spend a huge amount of time looking.
Anyway, consider this scenario: You purchase a widget from an online vendor, or sign up for a service. The vendor promises to send a one-time e-mail confirmation. But the e-mail doesn’t arrive immediately. You check your inbox again a little later, but still no e-mail. Then the phone rings or someone drops by for a chat, and you forget about it.
Meanwhile, your mail server’s spam cop took one look at the inbound vendor e-mail, and decided it was just too spammy to pass along to your inbox. So now what? Unless you’re in the habit of carefully reviewing the contents of your spam folder, that e-mail will be lost.
Considering how many legitimate e-mails are incorrectly rated as Spam, how about adding this protocol to the DKIM/SPF mix …
- Users log in to their mail server and update their profile, specifying a myWhiteListPassword. (Understand, this is a new field, so mail servers would need to be recompiled to include it, and mail programs like RoundCube, Outlook, SquirrelMail would need to be updated also.)
- Vendors add an additional field to their opt-in/shopping cart page. The new field prompts you for your myWhiteListPassword.
Here’s how the new feature would work: Let’s say you’re confirming your online order. In addition to providing your credit card number, shipping address, etc., you also type in your myWhiteListPassword. The vendor’s mail server includes that password in its outbound confirmation e-mail header. The first thing your mail server does is to check e-mail headers–comparing your e-mail address and your current myWhiteListPassword. If they match, the e-mail is whitelisted–bypassing further spam software intervention.
I realize this approach could open the door for spammers, if they sniff unencrypted e-mails for myWhiteListPassword values. When/if that happens, and you start seeing spam in your inbox, you’d need to change your myWhiteListPassword, and start using the new value when prompted for it online.
Or, maybe the mail server could offer several different automatic incrementing value schemes… Maybe it concatenates the myWhiteListPassword with the current day-of-the-month, or alpha day-of-the-week, or another hash. One example: specify a 12-letter word, like CONSIDERABLY or QUESTIONABLY. Your mail server concatenates the nth letter from that word to the front or back of your password. So in January, if your 12-letter word is CONSIDERABLY, the letter ‘C’ would be concatenated. In December, the letter ‘Y’ would be concatenated. And so on.
I’d welcome comments about this idea. Like I said, there wasn’t an RFC jumping out at me that promotes this concept. But maybe there are a thousand reasons why it wouldn’t work–and I just need to be enlightened.