Well, that depends. Is it something I need to see? Did I proactively ask for it, or did I neglect to opt out? Etc, etc. If you are having to measure response rate, and it doesn't involve an emergency alert or some such, it is probably spam.
OK. So what, I'm not going to complete my password reset notification because the page isn't beautiful? If you are tracking response rates it is because people aren't expecting an email, because they didn't ask for one (i.e. it isn't a password reset notification). GP is right - I want information I /need/ to be in an email in a succinct format, and I don't want emails I don't need.
What a remarkable idea! "HTML mail = useless bullshit" is such a strong correlation in my mind that it had never occurred to me other people might see it the opposite way.
Personally, I've been using mutt in the terminal as my primary email client for several years, and I absolutely prefer plaintext email.
But this isn't about me. Nor is it about any other computer nerd here clutching their pearls over HTML email. The reality is that users of web applications — the kind that probably a significant proportion of HN readers develop to earn a living — expect HTML transactional email.
I think response rate is meant more generally in this context. It doesn't necessarily literally mean an email in response. I think more typically it means the recipient following the call to action link in the email.
