Many sites require email verification to prevent impersonation by spammers (and to ensure that a user can retrieve their password, should they forget it.) Since this practice is a bit of a hassle for the user and does not require any thought on the user's part (sign into email, see registration email, click link), it should be automated. I've written a proposal of how to implement this.

Possible objections

Note that I am ignoring other uses of email verification, usually bot prevention. However, I believe that bot prevention should be implemented through more appropriate methods, such as accessible CAPTCHAs, sandboxing, web of trust, or pattern analysis.

Theory

When the user enters their email address to register on a website ("sending party"), the browser needs to pass an authorization signal to the user's email client or mail server ("receiving party") that indicates verification is appropriate. In other words, the browser needs to vouch for the site as legitimate. The best method for this is cryptographic signing, for three reasons:

1. Direct communication with the email client or server is unfeasible for many reasons;
2. The registering website is already going to be sending a message that the email client or server will receive;
3. Signing removes the need for a trusted carrier (so the registering website is okay as a messenger);
4. "Vouching" for an entity implies a trust model.

The authorization message could be either a signature or a secret-salted digest:

Signature

The browser has a unique asymmetric key pair that is recognized by the receiving party. The details of the registration are signed with this key, which the receiving party can verify. Requires that each receiving party knows each browser's public key. Could be arranged on the fly, e.g. "This is the first time you have used this feature. Here are instructions on getting your browser's key."

Digest

The receiving party would share a randomly-generated secret string with the browser(s). The browser SHA-1 hashes the secret with the details of the registration. The receiving party can recompute and confirm the hash. The secret could be unique to each email address.

Implementation

The implementation I describe here uses cryptographic signing.

1. The registering website serves up the registration form with this HTTP header:

   X-email-autover: v=1; regid-field=registrationID; email-field=emailAddr; auth-field=autover-auth; domain=login.example.com; path=/~tim

   The header indicates that the registration form contains the following fields:

   registrationID

   Prefilled and hidden, contains a unique string identifying this registration request.

   emailAddr

   Text field the user fills in with their email address.

   autover-auth

   Hidden and empty. Autover plugin will fill this field with the authorization message.

   The header arguments domain and path work to restrict the scope of the verification request in the same way cookies do: Both the registration form and the verification URL (discussed later) must be within the domain and path specified. The path will most likely be / in the majority of web applications.

2. When the user submits the registration form, the autoverification plugin intercepts the request.
3. The email address, registration ID, path argument, and domain argument are concatenated and cryptographically signed. This value is placed in the autover-auth field.
4. The form is allowed to submit.

At this point, the user's job is done.

1. The website sends the usual "verify your email address" email to the specified email address, with the following headers:

   X-autover: v=1; registrant=emailAddr; requestID=registrationID; auth=signature; domain=domain; path=path; verify=verificationURL

2. The autover-compliant receiving party (mail server or mail client) sees the headers and recomputes the signature. If it matches the signature provided, the receiving party checks the verification URL against the domain and path. If it passes, the receiving party POSTs the registration ID to the verification URL.
3. The website responds with either a success or error message.
4. If verification succeeds, the receiving party deletes or archives the message and logs the verification.
5. Either the sending or receiving party may notify the user of successful or failed verification.

Compatibility

Every step of the process is backwards compatible with existing registration and verification techniques. The protocol is completely optional.