email - trabajo - que poner en el asunto de un mail formal
¿Cómo enviar mensajes de correo electrónico limpios desde su aplicación? (3)
Al desarrollar una aplicación que envía mensajes de correo electrónico de notificación, ¿cuáles son las mejores prácticas para
- no ser marcado como spammer por su empresa de hosting. (Cubra cualquiera de :)
- La mejor técnica para no inundar un servidor de correo
- mejores productos de servidor de correo, si tuvieras que configurar tu propio
- enviar mensajes como si provinieran de un usuario específico, pero aún así claramente desde su aplicación (para asegurar que las quejas, etc. vuelvan a usted) sin romper la buena etiqueta del correo electrónico
- cualquier otra lección aprendida
- no ser marcado como spam por el cliente del receptor? (Cubra cualquiera de :)
- configurar y usar sender-id, domain-keys, SPF, reverse-dns, etc. para asegurarse de que sus correos electrónicos estén identificados correctamente
- mejores técnicas de encabezado SMTP para evitar que se marque como spam cuando se envían correos electrónicos para los usuarios (por ejemplo, usando los encabezados Sender y From juntos)
- cualquier otra lección aprendida
Un requisito adicional: esta aplicación estaría enviando un solo mensaje a un único destinatario basado en un evento. Por lo tanto, las técnicas para enviar los mismos mensajes a destinatarios múltiples no se aplicarán.
La mejor técnica para no inundar un servidor de correo
no hay mucho que pueda hacer al respecto más allá de consultar con el administrador de su servidor de correo (si es una cuenta de alojamiento compartido / no bajo su control). pero si el requisito es un correo electrónico a un único destinatario por evento, eso no debería ser un gran problema. las cosas que tienden a obstruir los sistemas de correo son los correos electrónicos con cientos (o más) de destinatarios.
si tiene eventos que se disparan todo el tiempo, tal vez considere consolidarlos y enviar un correo electrónico que los resuma periódicamente.
enviar mensajes como si provinieran de un usuario específico, pero aún así claramente desde su aplicación (para asegurar que las quejas, etc. vuelvan a usted) sin romper la buena etiqueta del correo electrónico
puede lograr esto usando el encabezado "Responder a", que luego hará que los clientes utilicen esa dirección en lugar de la dirección De cuando se está compilando un mensaje de correo electrónico.
también debe establecer el encabezado "Return-Path" de cualquier correo electrónico, ya que el correo electrónico sin este a menudo se filtrará.
ex.
From: [email protected]
Return-Path: [email protected]
Reply-To: [email protected]
configurar y usar sender-id, domain-keys, SPF, reverse-dns, etc. para asegurarse de que sus correos electrónicos estén identificados correctamente
todo esto depende en gran medida de la propiedad que tenga de su correo y servidores DNS. spf / sender-id, etc ... son todos problemas de DNS, por lo que necesitaría tener acceso a DNS.
en su ejemplo, esto podría presentar bastante el problema. como configura el correo para que sea de un usuario específico, ese usuario debería tener SPF (por ejemplo) configurado en su DNS para permitir que su servidor de correo sea un remitente válido. se puede imaginar lo desordenado (si no totalmente imposible) que obtendría una cantidad de usuarios con varios nombres de dominio.
en cuanto a DNS inverso y similares, realmente depende. la mayoría de los ISP clientes, etc ... simplemente verifican que DNS inverso esté configurado. (es decir, 1.2.3.4 resuelve host.here.domain.com, incluso si host.here.domain.com no resuelve de nuevo a 1.2.3.4). esto se debe a la cantidad de hosting compartido que existe (donde los servidores de correo a menudo se reportarán a sí mismos como el nombre de dominio del cliente, y no el servidor de correo real).
Hay algunas redes estrictas que requieren la coincidencia de DNS inverso, pero esto requiere que tenga control sobre el servidor de correo si no coincide en primer lugar.
si puedes ser un poco más específico, puedo darte un poco más de consejo, pero en general, para las personas que necesitan enviar correos de aplicaciones, y no tienen un montón de control sobre su entorno, te sugiero lo siguiente :
- asegúrese de establecer un "Camino de retorno"
- es bueno agregar la información de tu aplicación y abuso también en los encabezados, es decir: "X-Mailer" y "X-Abuse-To" (estos son encabezados personalizados, con fines informativos únicamente)
- asegúrese de que el DNS inverso esté configurado para la dirección IP de su servidor de correo saliente
ahora para los otros bits que valen la pena
IP''s mencionados son tus servidores de correo
a tener el punto ptr de su ip a un nombre que también resuelve el mismo FQDNS de IP
b tiene su servidor helo / ehlo con whatever.domain.com donde domain.com es el mismo que el dominio del nombre en el paso A {no es el mismo nombre para resons a continuación}
Tenga que helo / ehlo servername también resuelva en la ip de su servidor
d añada el siguiente registro spf a ese nombre de helo / ehlo "v = spf1 a -all" {es decir, permita helo / ehlo con este nombre de ip, este nombre solo apunta a}
e agregue las siguientes líneas de Id. de remitente al nombre helo / ehlo {puramente para completar "spf2.0 / mfrom, pra -all" {es decir, no hay usuarios @ this-domain}
f añada el siguiente spf al nombre FQDNS y a cualquier otro nombre de host para su servidor "v = spf1 -all" {es decir, ningún equipo podrá helo / ehlo como este nombre y ningún usuario @ this-domain}
{ya que el nombre fqdns puede ser determinado por bots / infecciones, es mejor que nunca permita que este nombre se use en los saludos de helo / ehlo directamente; basta con que sea del mismo dominio que la identidad helo / ehlo para probar la validez de ambos }
primero una corrección rápida a la anterior
return-path: es un encabezado agregado al recibir el sistema basado en el remitente del mensaje entrante
para que spf funcione, return-path / envelope-sender debe ser [email protected]
y asegúrese de que el registro spf para sudominio.com {o si por usuario spf} para [email protected] permite que los correos se originen en el servidor que aloja la aplicación / envía el correo electrónico
este remitente del sobre es la dirección que recibirá todos los rebotes / errores
ahora sender-id es completamente distinto, comprueba el remitente-ruta / envio-sobre y desde: dirección {almacenado dentro del mensaje} si envía desde: hisname [email protected] reply-to: hisname [email protected]
esto no será un problema si se envía desde: hisname [email protected]
Será y usted debe agregar un Resent-From: hisname [email protected], ya que esto especifica ignorar el from: para los cheques sender-id use esto en su lugar, ya que ha sido enviado por usted en su nombre