WikkaAndEmail:Wikka

Revision [1512]

This is an old revision of WikkaAndEmail made by JavaWoman on 2004-10-01 03:59:38.

Wikka And Email

Some thoughts and observations on Wikka and email.

Wikka gathers and (often) stores email addresses at various moments. This starts at installation when the WikiMaster privides an email address for the WikiAdmin to be stored in the configuration; every WikiVisitor signing up for an account to be able to become a WikiEditor also must provide an email adddress. Finally, someone providing "feedback" through the feedback form (displayed with the {{feedback}} action) must also provide an email address.

A problem I note is that various programs and actions use different validation rules for email addresses (and associated names).

Admin email address at installation

During installation the file setup/default.php requests an email address for the WikiAdmin. This address is validated with a very simple Regular Expression (RE) using JavaScript. This RE excludes many perfectly valid email addresses. The email address provided will (together with the Admin's WikiName) be stored in the the [prefix-]users table as well. Although the RE does not allow many perfectly valid email addresses, at least any email address that is validated by the RE will actually be a valid address.

A possible workaround (to allow valid addresses that would be rejected) is to disable JavaScript during installation - but then the email address for a WikiAdmin is not validated at all.

[Question: can the installation be done / completed without JavaScript?]

WikiEditor email address at registration

When a WikiVisitor signs up for an account, she is asked for an email address; an email address is required and the address provided is validated with an RE.

The email validation RE used here is different from that used for Admin's email address during installation. More worrying is that the RE used is very "lax" and actually allows strings that are not syntactically valid as an email address: many characters are accepted that would be invalid in an email address.

WikiEditor email address when updating account

When a logged-in WikiUser wants to update his account, the form presented by the actions/usersettings.php file displays a field to permit changing the email address. However, no validation is performed here at all; it's possible to enter an invalid email address, or even to remove an email address completely.

Obviously, this negates the requirement of providing an email address during registration; apart from the fact that now (as opposed to registration-time) any string can be stored as "email address". It's safe from SQL injection - but that is all.

Why require an email address on registration when it can be erased immediately? Or: why not validate an email address during update when it is validated at registration?

WikiEditor request temporary password

When a (registered) WikiUser forgets her password, she can request a temporary password to be sent via email. The action provided for this via actions/emailpassword.php blindly accepts whatever is stored as "email address" for the WikiName provided; this could in fact be an empty string (see "WikiEditor email address when updating account" above) or an invalid email address (see "WikiEditor email address at registration" above).

In addition, an email is "sent" to the presumed address as stored in the database (which may be empty) but there is no error trapping for the PHP mail() function used. If this WikiUser also forgot that an invalid email address was stored (or none at all - see above), she would be none the wiser as the application would not tell her there was a problem (or rather, an error message might result - but one formulated in language for a WikiMaster, not aimed at a WikiEditor end user).

Feedback

In the distribution a {{feedback}} action is provided which can be used to enable a WikiVisitor (or any WikiUser) to send comments by email email to the WikiAdmin. The form requires an email address to be provided for the sender and the provided email address is validated. However, the RE used for the validation - while less strict than that for WikiAdmin during installation - will reject many perfectly valid email addresses.

Many people, in view of being bombarded by spam, will want to provide a "throw-away" email address here (at least until they have sufficient trust in the operators of the Wiki); the problem is that some of the "throw-away" email address services may generate an email address that is perfectly valid, but would be rejected by the RE used in this form/action (this has happened to me on several occasions on (other) websites doing similar too-restrictive validation).

An additional problem is that the email address for the WikiAdmin role is blindly accepted while the WikiMaster may have disabled JavaScript during installation to get around the obvious limitations thus disabling all validation of that address: a simple typo might result in the WikiVisitors' feedback messages not going anywhere near a WikiAdmin...

Conclusions

We have three different REs to validate email addresses

One of these can be circumvented by disabling JavaScript

In one context the email address provided is not validated or even required at all

While seemingly WikiUsers need a "valid" email address, providing any old string that happens to validate and then removing or invalidating it via update is perfectly possible

There are (at least) two different issues with this:

Requiring users to provide an email address that matches an arbitrarily restrictive RE instead of merely providing a valid email address throws up a hurdle that may send some people away that could otherwise be(come) valuable contributors - while the {{feedback}} action will not provide them with a channel to actually provide feedback on this because the email address would likely be rejected there, too.

Different criteria in different places implies inconsistency, which detracts from usability. (Inversely, consistency breeds usability.)

Obviously, we have some problems here, and more potential problems when people are customising the action programs as provided without being aware of these inconsistencies.

Solutions

I'm working on some (more robust) solutions, but please have a little patience: I can think much faster than I can code (solid) solutions; writing email applications (especially robust email) is never easy, and the PHP mail() function isn't all that robust by itself either.

Meanwhile I wanted to share my observations, just to make my fellow Wikka users and implementors aware that there are a few problems lurking in there with respect to email from Wikka...

I will be posting code to address or get around some of these issues but I will not release any code before having tested it as best I can and having documented it properly.

Note:
The above is based on version 1.1.5.1.
More (or different) - including code - when it's ready ... hang in there. :)