King Spook's dashboard

Exactly! I'd like to have a "clear my rating" feature as well. – Ján Sokoly, on October 11, 2008 22:20

I excluded the entire directory of VM bundles; no change. – King Spook, on September 27, 2008 09:18

That's awesome, thanks. – Scott Fleckenstein, on September 25, 2008 14:34

#1:
Well, 'Precedence' is not an _official_ header (eg. not listed in RFC-2822, or related docs), but it's fairly common to see.
On reflection, there are other headers which will convey a similar meaning to 'Precedence', which you might feel are preferable. For example, you might consider treating your mails as a mailing list (hardly a stretch of the imagination), and thus putting in the List-* headers. Putting in a 'List-Id' header would make it easy to filter your mail; and a List-Unsubscribe header gives people another opt-out mechanism (which is _always_ a plus, unless you're a spammer). If it is any comfort to you, this is the route taken by Google for (at least) their Google Alerts product.
If you should decide to pursue the latter, RFC-2369 will basically tell you everything you'll need to know. It is entitled "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", but don't let that scare you, it's one of the most readable RFCs I've run across.
Ideally, you'd put in both; but if I had to pick one, I would definitely go with the latter (List-*).

#2
I suspected that would be the case; such as it is, as a band-aid, you might look into any options for handling BCC headers in your MTA. As it stands now, when your mail goes out with the big BCC field, your MTA just passes the mail along sans the BCC header. Some MTAs have the option of passing a separate copy of the mail to each person, with each mail containing just their address in the BCC field. (But make sure the MTA isn't taking the third path: just leaving the BCC header as it is when you send it, and thus letting every BCC'd party see the address of every other.)
This way, your app doesn't have to do all the processing off recipients itself, and it only has to compose one message; and your MTA is probably a lot better and faster at manipulating the BCC header than your app is (and it's less code you have to support).
If you could do that, I would say that alone is enough.

As it stands now, quite honestly, I'm surprised your mails aren't winding up in more Junk Mail bins. As it is now, your headers don't contain my email address in it at all. Putting it in _some_ header will be very helpful. Putting the List-* headers in will likely also make your mail look more legitimate.

Cheers.

Thanks for the ideas, King Spook.

#1 is easily doable. I'll add it into our bug tracker and get it done after I learn some more about the ramifications of including that header. My knowledge of email is sorely lacking.

#2 is a little tough at the moment. We rely on our mail server to distribute email notifications using a single message with a big BCC field. We certainly plan to change it such that our application is sending out individual messages to each user, for the reason you mention above, as well as some of our plans around personalizing messages according to your options (daily digest, etc.)

Thanks so much!

I believe that if you add the .vmwarevm bundle to Spotlight's exception list, they won't be searched (and the applications won't be registered as potential applications). I think. ^_^

Yeah, that should change...X amount of years should release it.

I'm going to ping the design team about this one. – Thor Muller, on September 24, 2008 06:31

Thanks (though I'd still prefer a way to add it with no judgement).
And how do I remove items (products) from my dashboard now?

Good point. This was lost during a recent refinement. Thanks for the heads up about it. In the meantime, rating it a 5 essentially associates you with the product and gives the product a neutral score which you can update later.

I think this would be a good idea...
It would help with issues like my creation of a "GetSatisfaction" org, when it was actually already listed under "Satisfaction".