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.
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 formamailto:<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 MIMEmessage/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
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).
mailto
en los formularios HTMLEsto 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:
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).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:
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.
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:
© 2002-2003 Juan R. Pozo
Sitio Web mantenido por Juan R. Pozo (jrpozo arroba conclase punto net).
Última modificación: 04/08/2003 - © 2002 - 2003 Juan R. Pozo y conclase.net