Resumen

  • RFC 2368 amplió mailto: para expresar destinatarios, encabezados y un cuerpo corto de texto, pero resolver la URL no obligaba a iniciar una interacción de red.
  • El cliente podía descartar campos peligrosos y debía mostrar el mensaje ya decodificado antes de pedir permiso; enlace, clic y borrador no eran recibos de envío ni de entrega.

Un enlace web suele parecer una orden de movimiento: se pulsa y el navegador consulta otro sistema. mailto: introdujo una pausa distinta. Podía abrir un compositor local con casi todo escrito y, aun así, no producir un solo paquete de correo.

La forma inicial de RFC 1738 era una dirección. RFC 2368 añadió una lista de buzones y pares de encabezado y valor después de ?, unidos por &. El nombre body preparaba la primera parte text/plain. Así una página podía ofrecer una petición para un robot, una orden de suscripción, una respuesta de archivo o un mensaje con copia sin convertir la URL en un cliente SMTP.

Cada transformación pertenecía a un actor diferente. El editor publicaba la cadena. El intérprete separaba destino, encabezados y cuerpo. El cliente decidía qué campos aceptaba. La persona veía el resultado. El servidor de envío, la red y el buzón remoto aportaban pruebas posteriores. Un campo rellenado no autorizaba a ninguno de los sistemas siguientes.

La codificación era parte de ese límite. ?, = y & tenían función estructural; usados como datos debían expresarse con escapes. Los espacios eran %20, los saltos de línea %0D%0A y un porcentaje literal %25. Dentro de HTML, & se escribía &. Decodificar dos veces o en el orden equivocado podía cambiar el destino o abrir un encabezado inesperado.

La norma también mostraba las fronteras lingüísticas de la época. Prohibía caracteres de ocho bits sin codificar. Admitía palabras MIME codificadas en valores de encabezado, no en body. No ofrecía sustitución de variables: una URL fija no podía insertar de manera fiable la dirección del usuario ni firmar un mensaje con datos locales. Era una plantilla estática, deliberadamente incapaz de apropiarse del contexto.

Que la sintaxis aceptara un nombre de encabezado no obligaba a ejecutarlo. El agente podía negarse a crear el mensaje o conservar solo un subconjunto seguro. Subject, Keywords y Body se consideraban útiles; los campos de identidad, rutas, copias ocultas y varios campos MIME eran sospechosos. La política local tenía prioridad sobre la amplitud del formato.

Antes de enviar, el programa debía enseñar el mensaje completo y decodificado, incluidos los encabezados introducidos por la URL, avisar de que se trataba de correo electrónico y pedir aprobación. La cautela respondía a efectos concretos: revelar la identidad a un tercero, generar cargos, infringir la ley o activar una acción dañina atribuible al remitente.

Por eso la evidencia debe leerse por capas. Encontrar la URL prueba una oferta editorial. Registrar el clic prueba, como mucho, activación. Ver el compositor prueba que ciertos campos llegaron al borrador. La decisión de envío, la aceptación del servidor, la entrega, la lectura y la acción solicitada necesitan registros independientes.

RFC 6068 sustituyó esta especificación y mejoró la internacionalización mediante UTF-8 y escapes porcentuales, además de aclarar campos repetidos y seguridad. No cambió la frontera central: la URI seguía siendo una plantilla. Una codificación correcta no confería consentimiento ni demostraba que el mensaje llegara.

La innovación de RFC 2368 fue modesta y profunda: permitió que la red propusiera una acción sin trasladar automáticamente a la red la autoridad de la persona.

Fuentes