Cómo no usar mailto

Existen dos errores comunes en el diseño web relacionados con el esquema de URLs mailto. Además de ser errores muy comunes, sus consecuencias pueden ser bastante graves (incluso pueden perderse mensajes sin que nadie se entere), por lo que es importante saber cuáles son estos errores y cómo evitarlos.

Error número 1: Poner parámetros en los URLs mailto

Es muy normal encontrar páginas con cosas de este estilo:

<a href="mailto:info@example.com?subject=\'Mi casa\'&body=Telefono">Contacte con nosotros!</a>

Esto es incorrecto por el siguiente motivo:

El elemento A, según las especificaciones de HTML, tiene un atributo opcional HREF, cuya función es la siguiente:

Este atributo especifica la localización de un recurso de la Web, definiendo así un vínculo entre el elemento actual (el origen del vínculo) y el destino del vínculo definido por este atributo. (http://html.conclase.net/w3c/html401-es/struct/links.html#adef-href)

El valor de este atributo es un URI (identificador uniforme de recursos, ver http://www.ietf.org/rfc/rfc2396.txt para su definición formal), el cual puede ser, por ejemplo, un URL tipo mailto. Naturalmente, éste debe ser un URL válido.

Los URLs del tipo mailto están especificados, como el resto de URLs, en "Uniform Resource Locators (URL)", sección 3.5, que traduzco a continuación:

3.5. MAILTO

El esquema de URLs mailto se usa para designar una dirección de correo de Internet de un individuo o servicio. Aparte de una dirección de correo de Internet, no hay ninguna otra información adicional presente o implícita.

Un URL mailto tiene la siguiente forma

mailto:<rfc822-addr-spec>

donde <rfc822-addr-spec> es (la codificación de un) addr-spec, según se especifica en RFC 822 [declarada obsoleta por RFC2822]. Dentro de un URL mailto no hay caracteres reservados.

Obsérvese que el signo de tanto por ciento ("%") se usa normalmente dentro de direcciones RFC 822 y debe ser codificado.

A diferencia de otros muchos URLs, el esquema mailto no representa un objeto de datos al que pueda accederse directamente; no designa un objeto en ningún sentido. Tiene una utilización diferente a la del tipo MIME message/external-body. (http://www.ietf.org/rfc/rfc1738.txt)

En el RFC2822, "Internet Message Format" se define un addr-spec del siguiente modo (sección 3.4.1):

3.4.1. Especificación de addr-spec

Un addr-spec es un identificador específico de Internet que contiene una cadena interpretada localmente, seguida del símbolo arroba ("@", valor ASCII 64), seguida de un dominio de Internet. [...]

addr-spec       =       local-part "@" domain

(http://www.ietf.org/rfc/rfc2822.txt)

Es decir, un enlace HTML cuyo atributo HREF sea un URL del esquema mailto no puede contener más información que la dirección de correo electrónico vinculada: ni asunto, ni cuerpo, ni nada. Sólo la dirección de correo.

El hecho de que funcione en algunas o en muchas combinaciones navegador web/cliente de correo, no quiere decir que funcione en todas, ni que tenga que funcionar, ni que vaya a funcionar en el futuro. Su comportamiento es esencialmente impredecible, porque es incorrecto. Lo que sí se puede esperar es que habrá situaciones en las que no funcionará.

Además no tendría ninguna utilidad para usuarios que no utilicen un cliente de correo (por ejemplo porque usan correo web).

Error número 2: Poner una acción mailto en los formularios HTML

Esto no sólo está mal sino que existen tantos motivos para no hacerlo que el propio sentido común debería bastar para darse cuenta. Lamentablemente el 99,9% de los tutoriales de HTML siempre usan una acción mailto para explicar cómo funcionan los formularios.

Formularios como éste son lo más normal del mundo:

<form action="mailto:info@example.com" enctype="text/plain" method="post">

Esto está mal por dos motivos:

  1. Según la especificación de HTML 4, los dos únicos tipos de contenido que deben soportar los navegadores son "application/x-www-form-urlencoded" y "multipart/form-data". El comportamiento para otros tipos de contenido queda sin especificar. Incluido naturalmente el tipo de contenido "text/plain" (ver http://html.conclase.net/w3c/html401-es/interact/forms.html#h-17.13.4).
  2. El valor del atributo ACTION se refiere a un agente procesador del formulario que reside en el servidor. Según define la especificación El comportamiento del agente de usuario frente a un valor diferente de un URI HTTP es indefinido. (ver http://html.conclase.net/w3c/html401-es/interact/forms.html#adef-action).

De modo que para empezar es pura y llanamente HTML incorrecto. No hay ningún motivo para que un navegador que se atenga a las especificaciones haga con ese formulario lo que nosotros creemos que tendría que hacer. Es un error, y por tanto sus resultados son impredecibles. Al igual que antes, lo que sí se puede predecir es que habrá situaciones en que no funcionará.

Por si eso no fuera poco, aquí hay una batería más de buenas razones:

  • No es muy fiable. Puede que funcione en tu computadora, pero no sabes si funcionará en la de tus visitantes, porque depende de su cliente de correo y de la configuración de su sistema. Y tu visitante tampoco sabrá si funciona hasta que no pulse el botón de enviar, después de rellenar todos los campos. Bastante frustrante. O puede no suceder nada, y el visitante creería que te ha enviado algo cuando en realidad no lo ha hecho. O puede que la dirección esté mal formada y no llegue a enviarse o rebote y acabe donde no queremos que acabe (en el buzón de un postmaster, por ejemplo, o perdido en el ciberespacio).
  • ¿Has leído el mensaje que da Internet Explorer?

    Este formulario se está enviando por correo electrónico. El envío de este formulario revelará su dirección de correo electrónico, y no cifrará la información del formulario como medida de privacidad.

    Puede continuar o cancelar el envío.

    [Aceptar] [Cancelar]

    Después de leer tal mensaje, más de uno le dará a "cancelar", por si las moscas.

  • Si el visitante usa correo web, el que se le abra un programa de correo (suponiendo que lo tenga) probablemente no le sirva para nada.
  • El visitante podría estar en un cibercafé, usando una computadora sin programa de correo.
  • Como inconveniente adicional, la dirección destino está en el código HTML y es accesible por los spambots, pudiendo caer presa de los espámers. Con un programa propio, con la dirección en el código del programa, no existe este peligro.

La solución

La única manera segura de generar un mensaje de correo emitido por el visitante de una página web es por medio de un formulario de correo que se ejecute en el servidor, ya sea en CGI, PHP, ASP, etc., no en el cliente.

Aunque pueda parecer complicado, en realidad es muy sencillo y basta con ver un ejemplo para saber cómo se hace.

Existen empresas que permiten utilizar gratuitamente o a cambio de publicidad sus servidores para la ejecución de estos formularios, por ejemplo:

Muchas compañías de alojamiento web (incluso gratuitas) ponen a disposición de sus usuarios formularios de correo listos para usar.

También es posible que puedas alojar tus propios scripts junto con tu página. Aquí tienes una lista con scripts para procesamiento de formularios, muchos de ellos de uso libre y gratuito:

Más información

© 2002-2003 Juan R. Pozo