http - puerto - servidor imap
¿Es seguro usar la URL relativa del protocolo en el correo electrónico? (2)
Existe una discusión [1] sobre el uso de la URL relativa del protocolo en HTML, pero ¿qué hay del correo electrónico?
¿El cliente de correo electrónico o los proveedores de servicios como Gmail eliminarán o modificarán la URL relativa del protocolo cuando se utilicen en el correo electrónico HTML?
Envié un correo electrónico a través de Gmail con este contenido:
<a href="//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js">link</a>
Y se recibió sin modificaciones. Cuando hice clic con el botón derecho en el enlace para copiar la dirección del enlace, Chrome agregó https: (ya que Gmail usa HTTP seguro), pero cuando inspeccioné el HTML del elemento, mostró la etiqueta <a> como la había escrito.
No es normal que los servidores de correo electrónico cambien el contenido de los correos electrónicos.
Omitir el protocolo está destinado a permitir que un navegador web elija entre versiones seguras e inseguras del mismo contenido. Si carga una página a través de https y contiene una imagen con un inicio src en http, el navegador advierte al usuario de que es peligroso cargar contenido inseguro, un mensaje confuso y preocupante. Si carga una página a través de http y contiene una imagen con un inicio src en https, eso evita el almacenamiento en caché entre otras ineficiencias.
El compromiso es permitir que el navegador cargue contenido con seguridad que coincida con la página que lo carga: eficiencia para una página insegura; Garantía completa de seguridad para una página segura.
Pero un cliente de correo electrónico siempre advierte sobre el contenido incrustado (imágenes, scripts, ...), lo que significa que omitir el protocolo no tiene ningún beneficio.
Además, un cliente de correo electrónico que no es del navegador no tiene un protocolo para empezar. Descarga información y luego la carga desde el disco. Si realmente desea que el cliente de correo electrónico elija cargar contenido incrustado con el nivel de seguridad con el que cargó el correo electrónico, le permitiría al cliente buscar la información en la misma computadora. (De hecho, lo harán asumiendo que // significa file:/// .)
Entonces, ¿es seguro poner un // URI en un correo electrónico? Yo diría que no tiene sentido; por lo tanto, no se ha convertido en una forma estándar para que lo manejen los clientes que no son navegadores, lo que significa que está viendo un comportamiento indefinido.
Es mejor elegir el protocolo en función de la sensibilidad de la información identificada por el URI. ¿Es un cuadro de datos financieros propietarios? Utilice https. ¿Es un lolcat? Utilizar http.
No, no es seguro usar la URL relativa del protocolo en el correo electrónico. porque cambia el protocolo para que el navegador pueda obtener un recurso de cualquier protocolo que el sitio le indique que use.
pero algunos clientes de correo electrónico (especialmente Outlook, como es habitual) no intentarán usar HTTP o HTTPS como protocolo. En su lugar, usarán el protocolo file: // y asumirán que el recurso al que se refiere está en la máquina local. Pero no lo será. Así que no uses esto en los correos electrónicos. Debe asegurarse de que el servidor desde el que está solicitando sea capaz de entregar contenido a través de HTTP y HTTPS. Si no, puede terminar obteniendo contenido de un puerto de servidor no seguro o inexistente.
IE6 no sabe cómo manejar esto. Si le importa que sea compatible con Internet Explorer 6, no debe usarlos.
IE7-8 admite las URL relativas al protocolo, pero terminarán obteniendo el recurso dos veces. Una vez de HTTP y una vez más de HTTPS. Esto puede ralentizar un poco las cosas, pero la forma en que veo las cosas no es un problema para nadie, excepto para la persona que usa IE7-8 y, si está utilizando IE, tiene cosas más importantes de las que preocuparse.
depende de su navegador, de modo que depende de qué navegador esté usando GMAIL que funciona bien en Crome pero no en IE6.