I think saying that I don't "get" UI is being somewhat presumptuous. Good UI on the registration form can go a long way in alleviating the "switching the email address and username fields" problem, but anything more than a check for /@/ (or, if you're feeling ambitious, /.+@.+\..+/) is just overkill. If I enter a valid email address that's just typo'd, the result is the same: the activation email bounces.

/.+@.+\..+/ would be a bit too ambitious as the dot is not necessarily part of a valid email - an MX record can appear on a TLDs DNS records[1]. Considering ICANNs new licensing of hundreds of TLDs this could be a very real concern soon.

1: http://blog.nerdchic.net/archives/191/

>If I enter a valid email address that's just typo'd, the result is the same: the activation email bounces. //

No, you're excluding the set of emails that are entered incorrectly and thus are not valid. The result for those is not the same as if the UI included a simple test (such as your "ambitious" example).

1) Without UI validation:

- 1.1) Email address entered correctly -> activation email sent

- 1.2) Email address entered incorrectly but forms a valid address -> activation email sent to wrong address

- 1.3) Email address entered incorrectly but doesn't form a valid address -> activation email not sent

2) With UI validation:

- 2.1) Email address entered correctly -> activation email sent

- 2.2) Email address entered incorrectly but forms a valid address -> activation email sent to wrong address

- 2.3) Email address entered incorrectly but doesn't form a valid address -> user warned

-- 2.3.1) Email address re-entered correctly -> activation email sent

-- 2.3.2) other states

In the 1.3 case all of the activation emails fail to be sent. In the 2.3.1 case activation emails are sent that otherwise wouldn't be.

You are completely missing the the one case the whole argument circles around:

2.1a) Email address entered correctly -> validation fails, no mail sent

This prevents activation mails that would be sent without validation (or validation against a regex like [^@]+@[^@]+).

Sorry, yes, this wasn't supposed to be exhaustive just to illustrate the point that not providing a warning on apparently erroneous email address entries was some what pathological.

The problem is that the "protection" invariably prevents someone from using their odd but valid address.

I think the point is that in reality the user should be protected from the service -- which may be trying to validate their input and telling them their perfectly valid email address (or address, postal code, name, password) cannot possibly exist.