[NCLUG] html form to email cgi advice

Anthony Foiani tkil at scrye.com
Sun Feb 19 21:29:33 MST 2012


> On Wed, Feb 15, 2012 at 06:56:33PM -0700, Anthony Foiani wrote:
>> This passion for re-implementing email clients (poorly, insecurely) on
>> web pages is inevitably a bad idea.

Chad Perrin <perrin at apotheon.com> writes:
> Wait . . . seriously?

Yes, seriously.

Almost all of your reasons have to do with the ease of the server /
provider side; my complaints with your reasons are mostly on the
consumer side.

> 1. Some people find it inconvenient to have to move from the webpage
>    to an email client to send feedback.

Many people use gmail or other web-based email anyway, so this is
often not an issue.

>From personal experience, I'd rather use one interface (either gmail
or thunderbird or emacs+vm or...) than try to figure out each site's
magic.

> 2. Sometimes, using a web form to automate an initial filter against
>    unwanted email (by not exposing the email address to the world)
>    is desirable.

Then you need better documentation and better customer service.

If you start doing things like "go through a big form, then answer a
captcha to send us mail", you're saying "our time is more important
than yours."

> 3. Where contact is utterly useless without specific information
>    being provided, a web form provides a way to require that
>    specific fields be filled out.

And then those pulldowns don't get updated when a new product comes
out, etc.  On the same page as the raw email address, give a list of
items that would make your life easier -- and point out that it would
make resolving *the customer's* issue easier and faster as well.

Not to mention the fact that these pulldowns inevitably reflect the
point of view of the person writing the form (or writing the spec for
the form), etc.  You are then forcing the customer to do extra work to
make their questions fit your schema.  Again, you're telling the user
that their time is cheaper than yours.

> 4. If the form of the email can be controlled, received contact
>    messages can be more easily parsed and handled by automated
>    systems where such is desirable.

Again, you simply need better customer service.  Hire a temp at
10$/hour to do initial parsing, classification, filtering (ref 2
above), possibly first line of replying asking for more info (as in
3), etc.

> 5. When the message is going to an email address that is used for
>    more than one single purpose, a web form allows control of things
>    like subject lines to ensure that those messages stand out within
>    the recipient's inbox.

Uh... so you're inconveniencing your users and customers so that you
don't have to be bothered to set up another email alias?

I think it's a bit wonky to send email to customer service (through
form or direct), and then get mail back from "bob at ...".  What happens
if I want to reply and Bob is on vacation?

Using role-based email addresses is the obvious answer, and it's
better in the long run for both the provider and the consumer.

> There are other reasons too, but five seems like a nice round number.

Fair enough.  I just disagree with all of them.  :-)

t.



More information about the NCLUG mailing list