Resumen

  • RFC 3098 trató la publicidad no solicitada como un traslado de costes en una red compartida. Propuso listas propias de destinatarios voluntarios, con la no suscripción como estado inicial.
  • La confirmación inmediata debía mostrar dirección, vía, hora, host de origen, cabeceras, identidad del anunciante y baja. Hacía discutible la solicitud sin darla por auténtica.

Enviar barato trasladó la factura

El correo electrónico redujo casi a cero el coste marginal de añadir un destinatario. El receptor y su proveedor seguían pagando conexión, almacenamiento, administración, filtros y atención. RFC 2635 describió esa inversión: a diferencia del correo de papel, el envío electrónico masivo hacía que quienes no lo pidieron soportaran gran parte del coste.

RFC 3098 partió de esa economía en abril de 2001. Su afirmación de que Internet no era un recurso gratuito no era simple etiqueta. Un anuncio cruzaba sistemas privados, consumía infraestructura y ocupaba el buzón de otra persona. La facilidad técnica no convertía esos recursos en propiedad del remitente.

El documento no prohibía el comercio. Buscaba una frontera en la que el anunciante pudiera pedir atención sin obligar a desconocidos a financiar la búsqueda. Debía investigar los espacios adecuados, mostrar identidad, usar sistemas con permiso y responder por el público elegido.

Comprar una lista no compraba permiso

Las listas compiladas podían contener direcciones extraídas de archivos, combinaciones inventadas, registros obsoletos y personas que ya habían cambiado de empleo o proveedor. RFC 3098 advirtió incluso que algunos vendedores reutilizaban peticiones de baja como nuevas listas comerciales.

La conclusión era estructural. Comprar el fichero no externalizaba la responsabilidad. Selección, identidad, autorización de sistemas y mantenimiento seguían perteneciendo al anunciante que esperaba el beneficio. También se rechazaba revender una lista propia: el permiso dado a una empresa no se extendía silenciosamente a sus socios.

La lista representaba una expectativa limitada entre una dirección y un remitente conocido. Tratarla como activo transferible destruía el contexto que hacía inteligible la elección inicial.

El valor inicial decidía quién debía actuar

La casilla de RFC 3098 estaba dentro de un diseño de privacidad. La persona debía saber que aportaba datos y recibir una explicación clara si se usarían para envíos. También debía poder entregar la información principal sin aceptar publicidad.

El RFC recomendó que no recibir correo fuese el valor predeterminado. Entrar en la lista exigía una acción deliberada, como seleccionar una casilla que solicitara anuncios. La inercia quedaba del lado de la no suscripción.

Así se devolvía el coste de captación al anunciante. Tenía que ganar una decisión positiva, no aprovechar una selección previa o una finalidad oculta en otro formulario. La lista podía crecer menos, pero cada entrada mantenía una relación más fuerte con una petición expresada.

La casilla no era una prueba absoluta. No demostraba comprensión, identidad humana ni validez jurídica en todas partes. RFC 3098 reconocía diferencias entre jurisdicciones y hacía responsable al anunciante de verificarlas. Su importancia histórica está en el valor inicial y el control, no en el dibujo del widget.

Confirmar volvió impugnable la inscripción

Un formulario público permite que alguien escriba la dirección de otra persona. RFC 3098 separó los datos de una solicitud de la autenticidad del acto. Solo el dueño de la dirección podía atestiguar la suscripción, y cada envío debía producir una confirmación inmediata.

No bastaba un saludo. La confirmación debía incluir la dirección inscrita, el modo de envío, fecha y hora, IP del host de origen, cabeceras completas cuando existieran, nombre y contactos del anunciante e instrucciones de baja permanente. Si un tercero había escrito la dirección, su dueño podía descubrir el hecho y responder.

Era un paquete temprano de procedencia para una relación comercial. Una disputa obtenía momento, ruta y contexto en lugar de una fila opaca. Pero una IP no identificaba al ser humano, la entrega no probaba que el dueño inició el formulario y las cabeceras no convertían una petición en autorización. El sistema aportaba aviso y contradicción.

La salida cerraba el circuito

Una preferencia cambia. RFC 3098 exigía explicar cómo abandonar la lista y proteger sus datos. La relación iniciada por elección debía conservar una salida accesible.

RFC 2369 normalizó List-Unsubscribe y otros controles; RFC 2142 documentó buzones como ABUSE y POSTMASTER; RFC 2505 y RFC 3013 trataron relés y responsabilidad operativa. Eran capas distintas: práctica del emisor, control del destinatario, comandos legibles por máquinas y defensa de infraestructura.

Ninguna capa garantizaba ejecución. Una cabecera podía señalar un mecanismo roto y un buzón podía quedar sin leer. La prueba útil era la secuencia completa: petición, aviso, respuesta, cese de envíos posteriores y tratamiento de la dirección.

Consejo, operación y ley eran autoridades distintas

RFC 3098 era Informational y FYI 38, no Standards Track, ley ni certificado. Tampoco publicó cifras de adopción. Describió controles recomendados sin probar que los anunciantes los aplicaran.

La ley estadounidense CAN-SPAM llegó en 2003. La FTC describe obligaciones como identificación y posibilidad de baja. Esa autoridad posterior no debe proyectarse hacia atrás como si RFC 3098 la hubiera promulgado o inspirado sin historia legislativa. Son cadenas de autoridad diferentes.

La aportación duradera del RFC fue convertir responsabilidad en decisiones observables: quién definió el estado inicial, poseyó la lista, registró la solicitud, reveló identidad y respetó la salida. Control y coste permanecían junto al actor que buscaba valor comercial.

El modelo era modesto y por eso útil. No garantizaba consentimiento, honestidad o cumplimiento. Hacía inspeccionable una afirmación de permiso y daba al receptor una vía para impugnarla. Antes de que “consentimiento” se volviera lenguaje habitual de interfaz, RFC 3098 ya mostraba que una casilla, una confirmación y la propiedad de una lista distribuían poder en la red.

Fuentes

  1. https://www.rfc-editor.org/rfc/rfc3098.html
  2. https://www.rfc-editor.org/info/rfc3098
  3. https://datatracker.ietf.org/doc/rfc3098/
  4. https://www.rfc-editor.org/rfc/rfc2635.html
  5. https://www.rfc-editor.org/info/rfc2635
  6. https://datatracker.ietf.org/doc/rfc2635/
  7. https://www.rfc-editor.org/rfc/rfc2505.html
  8. https://www.rfc-editor.org/info/rfc2505
  9. https://datatracker.ietf.org/doc/rfc2505/
  10. https://www.rfc-editor.org/rfc/rfc1855.html
  11. https://www.rfc-editor.org/rfc/rfc2142.html
  12. https://www.rfc-editor.org/rfc/rfc2369.html
  13. https://www.rfc-editor.org/rfc/rfc3013.html
  14. https://www.ftc.gov/legal-library/browse/statutes/controlling-assault-non-solicited-pornography-marketing-act-2003-can-spam-act