No hay ninguna razón por la que no puedas escribirlo en PHP, aunque yo no conviértalo en parte de un proceso webrequest/HTTP. He implementado con éxito para dar o recibir 500.000 suscriptores por correo (dependiendo de los datos locales disponibles, ya que este era un proyecto específico de la ubicación). Fue un proyecto interno, por lo que desafortunadamente no hay código/paquete para usted, pero encontré algunos consejos:
Configurar la entrega
- Comenzó con phpmailer en sí mismo, para encargarse del formato, la codificación de contenidos y encabezados, la adición de archivos adjuntos, etc. Esa parte funciona bien y no me gustaría escribir eso desde cero.
- El 'envío' de un correo electrónico en sí mismo es simplemente configurar una bandera en una base de datos sobre si / cómo / qué se debe enviar a (una parte de) los suscriptores.
- Después de que se establezca este indicador, un cronjob lo recogerá automáticamente, sin más servidores web involucrados.
- Empecé con una base de datos muy contaminada con millones de direcciones de correo electrónico, de las cuales muchas eran obviamente no válidos, por lo que lo primero fue validar todas las direcciones de correo electrónico para el formato, luego para el host:
filter_var($email, FILTER_VALIDATE_EMAIL);sobre los suscriptores (y el almacenamiento del resultado obviamente) eliminó los primeros cientos de miles de correos electrónicos no válidos.- Dividir el host (y almacenar el nombre de host) de los correos electrónicos y validarlo (¿tiene un registro MX o al menos un registro A en DNS, pero tenga en cuenta:puede enviar un correo electrónico a una dirección IP
[email protected][255.255.255.255], así que manténgalos válidos)) se deshizo de una buena parte más. Las direcciones de correo electrónico aquí no deshabilitados permanentemente, pero con una bandera de estado que indica que están deshabilitados debido al nombre de dominio/ip. - Los guiones se cambiaron a requerir direcciones de correo electrónico válidas en la suscripción/antes de la inserción, esta tontería de 'no obtendrás example@ sqldat.com ' la contaminación por suscripción en la base de datos era simplemente ridícula.
- Ahora terminé con una lista de direcciones de correo electrónico que tenían el potencial de ser válidas. En esencia, existen 3 formas de detectar direcciones no válidas (recuerde, las todas puede ser temporal):
- Son denegadas inmediatamente por el servidor.
- El servidor determinado anteriormente simplemente no escucha el tráfico.
- Se devuelven mucho después de que pensó que los había entregado.
- Cosa extraña, los rebotes, para los que cada servidor de correo electrónico parece tener otro formato y fueron difíciles de analizar al principio, terminaron siendo bastante fáciles de capturar usando VERP
. En lugar de analizar correos electrónicos completos, una dirección de correo electrónico dedicada (llamémosla [email protected] ) se configuró para enviarlo al buzón de correo, para canalizarlo a través de un comando, y si enviamos un correo electrónico a [email protected]
, la
Return-Pathse configuró para[email protected]. Se analiza fácilmente en el recibo y después de cuántos rebotes (el buzón no puede existir, el buzón puede estar lleno (¡sí, todavía!), etc.) usted decide si declara que una dirección de correo electrónico no se puede utilizar. - Ahora, la negación directa por parte del servidor. Probablemente podríamos haber configurado correctamente algunos MTA y/o escribir complementos para ellos, pero como los correos electrónicos eran sensibles al tiempo, y teníamos que tener un control configurable absoluto por correo sobre el último tiempo de entrega utilizable (después del cual el correo electrónico no era más largo). de interés para el usuario), aceleración por servidor receptor y, en general, todo, llevaría casi el mismo tiempo escribir un correo en PHP que conocíamos mejor, que usaba el protocolo SMTP directamente en el socket 25 en los servidores receptores. Con una cantidad mínima de esfuerzo, se incorporó la posibilidad de otro transporte, luego se incorporaron las opciones predeterminadas en PHPMailer. El protocolo SMTP en realidad es bastante simple, pero hay algunas advertencias:
- Muchos servidores de recepción aplican la lista gris:a la mayoría de los spambots no les importa si llega un correo específico, simplemente lo envían en masa. Por lo tanto, si un remitente desconocido o aún no confiable envía un correo, será rechazado temporalmente. Captura eso (generalmente el código 451) y coloca el correo electrónico en la cola para volver a intentarlo más tarde.
- Un servidor de correo, especialmente los ISP más grandes y los servicios gratuitos (gmail, hotmail/msn/live, etc.) no soportarán un torrente de correo sin contraatacar:después de los primeros cientos/mil, comienzan a rechazar usted. Más sobre eso más adelante.
Obteniendo velocidad
- Ahora, teníamos un sistema de entrega que funcionaba, pero tenía que ser rápido . Enviar 10 000 correos electrónicos en una hora está bien si solo tiene 10 000 direcciones para enviar, pero el mínimo que requerimos fue de aproximadamente 200 000 por hora. El comienzo fue un servidor dedicado (que en realidad puede tener bastante poca potencia, sin importar lo que haga, la mayor parte del tiempo que se tarda en enviar el correo electrónico está en la red, no en su servidor).
- Caché de IP:¿recuerda todas las IP que solicitamos de los nombres de host en las direcciones de correo electrónico? Los almacenamos obviamente, y buscar sus IP una y otra vez causa un retraso considerable. Sin embargo, las direcciones IP pueden cambiar:un registro DNS allí, otro MX en otro lugar... los datos se vuelven obsoletos rápidamente. La mayoría de las veces, el servidor en realidad no envía nada (obviamente, los boletines de suscripción vienen en ráfagas), se está ejecutando un cronjob de baja prioridad verificando todos los nombres de host con una IP obsoleta (elegimos más de 1 día como obsoletos) para una dirección IP , incluidos los que anteriormente no tenían (Los nuevos dominios se registran todo el tiempo, entonces, ¿por qué un dominio no debería estar disponible el día después de que alguien ya se suscribió con entusiasmo con su nueva dirección de correo electrónico? O se resuelven los problemas del servidor con algún dominio, etc.). En realidad, enviar los correos electrónicos ahora no requería más búsquedas de dominios.
- Reutilización de la conexión SMTP:configurar una conexión a un servidor lleva relativamente una gran parte del tiempo para entregar un correo electrónico cuando está hablando directamente al puerto 25. No tiene que configurar una nueva conexión para cada correo electrónico, puede enviar el siguiente a través de la misma conexión. Un poco de prueba y error ha resultado en establecer el valor predeterminado aquí en aproximadamente 50 correos electrónicos por conexión (suponiendo que tenga tantos o más para el dominio). Sin embargo, en caso de falla de una dirección de correo electrónico, cerrar y volver a abrir la conexión para un reintento a veces ayudó. Considerándolo todo, esto realmente ayudó a acelerar las cosas.
- Algo obvio, tan obvio que casi me olvido de mencionarlo:sería un desperdicio tener que crear el cuerpo del correo electrónico en el acto:si es un correo general, tenga el cuerpo listo (alteré un poco PHPMailer para poder utilizar un correo electrónico en caché), posiblemente días antes (si sabe Vas a enviar un correo el viernes y tu servidor está inactivo, ¿por qué no prepararlos ya el miércoles? Si es personalizado, aún puede prepararlo de antemano con suficiente tiempo, si no, al menos tenga las porciones no personalizadas esperando para llevar.
- Múltiples procesos. ¿Mencioné que gran parte del tiempo que se tarda en enviar un correo electrónico se gasta en la red? Un proceso de envío de correo no está aprovechando al máximo su servidor de correo electrónico, la carga apenas se nota y los correos se están escurriendo. Experimente con una serie de procesos que envían correos electrónicos a diferentes partes de la cola para ver qué es lo correcto para su servidor/conexión, pero recuerde dos cosas muy importantes:
- Diferentes procesos te hacen muy vulnerable a las condiciones de carrera:ten totalmente seguro tiene un sistema completo que nunca enviar el mismo correo dos veces (tres veces, o incluso más). No solo molesta seriamente a los usuarios, sino que su calificación de spam aumenta un poco.
- Mantenga los dominios juntos siempre que sea posible:al elegir aleatoriamente de la cola, perderá la ventaja de mantener una conexión abierta con el servidor que recibe el correo electrónico del dominio.
Evitar rechazos
- Vas a enviar muchos correos. Eso es exactamente lo que hacen los spammers. Sin embargo, no quiere que lo vean como un spammer (después de todo, no lo es, ¿verdad)? Hay una serie de mecanismos implementados que aumentarán considerablemente su confiabilidad para los servidores receptores:
- Tener un DNS inverso adecuado:los procesos verifican el DNS perteneciente a la IP que envía el correo electrónico como muy mucho si los dominios de segundo nivel coinciden:¿está enviando correo en nombre de example.com? ? Asegúrese de que el DNS inverso de su servidor sea algo así como somename.example.com .
- Publicar registros SPF para su dominio:indique explícitamente que la máquina utilizada para enviar su correo electrónico masivo está permitida y se espera que envíe correo con los encabezados From/Return-Path.
- recordar rechazos :a los servidores no les gusta que les digan una y otra vez que no existen diferentes direcciones de correo electrónico. Cualquiera de los mecanismos automatizados, e incluso los administradores humanos, bloquearon nuestro servidor mientras trabajábamos con todas las direcciones de correo electrónico no validadas que (ya no) existían. No empleamos una suscripción doble hasta más tarde, por lo que la base de datos estaba contaminada con errores tipográficos, personas que cambiaban de IP y, por lo tanto, de dirección de correo electrónico, direcciones de correo electrónico de broma, etc. Asegúrese de capturar esos inválidos y, dados los suficientes o graves errores, anule su suscripción. . No te están haciendo ningún bien, están acaparando recursos, y si realmente quieren tu correo y el buzón está disponible más tarde, simplemente tendrán que volver a suscribirse.
- DKIM es otro mecanismo que puede aumentar su confiabilidad, pero como no lo hemos implementado (todavía), no puedo decirle mucho al respecto.
- Registros MX:a algunos servidores todavía les gusta que su servidor de envío sea también el servidor de recepción del dominio. Como estaba en ese momento, solo teníamos 1 MX, y como el servidor de correo todavía no estaba muy ocupado, lo llamamos el servidor MX alternativo para el dominio. El servidor MX normal no el servidor que envía las suscripciones, ya que es muy irritante ser bloqueado temporalmente por un servidor al que intenta enviar un correo electrónico importante (clientes, etc.) porque ya envió una carga de correo menos importante. Tiene la preferencia más alta para recibir MX, pero en caso de que fallara, teníamos la buena ventaja de que nuestro servidor de envío de suscripciones seguiría siendo un respaldo para la entrega, por lo que en caso de crisis aún podríamos llegar a él, evitando rebotes incómodos para los clientes que intentan para llegar a nosotros.
- Cuéntales sobre ti. En serio. Muchos jugadores importantes en las direcciones de correo electrónico gratuitas como live.com le ofrecen la oportunidad de registrarse de alguna manera, o tener algún punto de contacto para obtener ayuda y soporte si sus correos electrónicos son rechazados. Si tiene una razón legítima para enviar tantos correos electrónicos, y es creíble que tiene tantos suscriptores, es probable que aumenten seriamente la cantidad de correos electrónicos que puede enviar a su servidor por hora. Unos escasos 1.000 pueden convertirse en diez mil o incluso más si eres lo suficientemente persuasivo y honesto. Puede haber contratos, requisitos que debe cumplir y promesas que debe hacer (y cumplir) para que se le permita esto. Los ISP son una marca aparte, y todos los demás jugadores son diferentes. Por lo general, no se moleste en llamarlos, porque el 99% de las veces los únicos números que puede encontrar solo tendrán personas dispuestas a solucionar su conexión a Internet, que entienden (o están permitidas) poco más. Un
[email protected]La dirección de correo electrónico es un buen lugar para comenzar, pero vea si puede encontrar una dirección de correo electrónico más precisa desde algún lugar. Sea preciso, honesto y completo:aproximadamente cuántos suscriptores suyos tienen una dirección de correo electrónico con ese ISP, con qué frecuencia intenta enviarles correos electrónicos, cuáles son los errores o denegaciones que recibe, cómo es el proceso de suscripción y cancelación de suscripción, y qué es el servicio que realmente proporciona a sus clientes. Además, sea amable:cuán vital puede ser enviar esos correos para su negocio, entrar en pánico y reclamar pérdidas terribles no les concierne. Una declaración cortés de hechos y deseos, y preguntar si pueden ayudar en lugar de exigir una solución es muy útil. - Aceleración:por mucho que lo intentes, algunos servidores aceptarán solo una cierta cantidad de correo por hora y/o día de tu parte. Aprenda esos números (estamos registrando éxitos y fracasos de todos modos), configúrelos en un valor predeterminado razonable para los dominios normales, configúrelos en límites acordados para jugadores más grandes.
Evitar ser etiquetado como spam
- Primera regla:¡no envíes spam!
- Segunda regla:¡nunca! No es un 'único', ni un 'no se han suscrito, pero este puede ser el trato de su vida para ellos', no con las mejores intenciones, las personas han tenido que pedir sus correos electrónicos.
- Obviamente, configure un mecanismo de suscripción de suscripción doble correcto.
- PHPMailer establece encabezados adecuados por sí solo,
- Configure un mecanismo fácil para darse de baja, por web (incluya un enlace en cada correo), posiblemente también correo electrónico y servicio al cliente si lo tiene. Asegúrese de que el servicio de atención al cliente pueda dar de baja a las personas directamente.
- Como se dijo anteriormente:cancelar la suscripción (excesiva) falla y rebota.
- Evite las expresiones de spam "acuerdo de su vida".
- Use las direcciones URL en sus correos electrónicos con moderación.
- Evite agregar enlaces a dominios fuera de su control, a menos que esté absolutamente seguro de que puede confiar en ellos. no enviar spam, si aun así...
- Proporcione valor al usuario:ser etiquetado como spam por la interacción del usuario en los clientes de correo web de google/yahoo/live daña seriamente los éxitos futuros (en una nota del sitio:si se registra, live/msn/hotmail reenviará todos correo enviado por su dominio que está etiquetado como spam por los usuarios. Aprenda a amarlo y, como siempre:anule la suscripción, claramente no quieren su centro comercial y están perjudicando su calificación de spam).
- Supervise las listas negras de su IP. Si aparece en uno de esos, es adiós, así que tome medidas inmediatas para limpiar su nombre y se requiere determinar el caso.
Midiendo la tasa de éxito
- Con todo el proceso bajo su control, está razonablemente seguro de que el correo electrónico terminó en alguna parte (aunque podría ser el bitbucket de MX o una carpeta de correo no deseado), o ha registrado un error y el motivo. Eso se encarga de los números 'realmente entregados'.
- Algunas personas intentarán convencerlo de que agregue enlaces a imágenes en línea a sus correos electrónicos (ya sean reales o el famoso gif transparente 1x1) para medir cuántas personas realmente leen su correo electrónico. Como un alto porcentaje bloquea esas imágenes, estos números son inestables en el mejor de los casos, y creemos que no deberíamos molestarnos con ellos, sus números son totalmente poco confiables.
- Su mejor opción para medir la tasa de éxito real es mucho más fácil si desea que los usuarios hagan algo. Agregue parámetros a los enlaces en el correo, para que pueda medir cuántos usuarios llegan al sitio que vinculó, si realizaron las acciones deseadas (vieron un video, dejaron un comentario, compraron productos).
En total, con todo el registro, la interfaz de usuario, las configuraciones configurables por dominio/correo electrónico/usuario, etc. Nos llevó alrededor de 1,5 meses-hombre construir y solucionar las peculiaridades. Puede ser una gran inversión en comparación con la externalización de los correos electrónicos, puede que no lo sea, todo depende del volumen y el negocio en sí.
Ahora, dejemos que comience la flama de que fui un tonto al escribir un MTA en PHP, lo disfruté muchísimo (que es una de las razones por las que escribí esta gran cantidad de texto), y las capacidades de registro y configuración extremadamente versátiles, por host. las alertas basadas en el porcentaje de fallas, etc. están haciendo que vivir sea tan fácil;)
