¿Cómo enviar 100.000 correos electrónicos semanalmente? [cerrado]

Resuelto xRobot asked hace 54 años • 3 respuestas

¿Cómo se puede enviar un correo electrónico a 100.000 usuarios semanalmente en PHP? Esto incluye correo a suscriptores que utilizan los siguientes proveedores:

  • AOL
  • Correo Gmail
  • hotmail
  • yahoo

Es importante que todos los correos electrónicos se entreguen, en la medida de lo posible. Evidentemente, simplemente enviar el correo de forma convencional no haría más que crear problemas.

¿Existe alguna biblioteca para PHP que simplifique esto?

xRobot avatar Jan 01 '70 08:01 xRobot
Aceptado

Respuesta corta: si bien es técnicamente posible enviar usted mismo 100.000 correos electrónicos cada semana, la solución más simple, fácil y económica es subcontratar esto a una de las empresas que se especializan en ello (dije " más barata": no hay límite para el cantidad de tiempo de desarrollo (y por lo tanto dinero) que puedes invertir en esto cuando intentas hacerlo tú mismo).

Respuesta larga: si decide que absolutamente quiere hacerlo usted mismo, prepárese para un mundo de dolor (después de todo, estamos hablando de correo electrónico/e-fail). Necesitarás:

  • contenido de correo electrónico que no sea spam (de lo contrario, se encontrará con obstáculos importantes adicionales en cada paso, incluso repercusiones legales)
  • Además, su contenido debe ser fácil de distinguir del spam, lo que puede ser un poco difícil de hacer en algunos casos (escuché que cierta compañía farmacéutica tuvo que abandonar el correo electrónico, ya que sus marcas son bastante comunes en el spam). )
  • un servidor SMTP propio configurable, uno que no fallará cuando descargues 100.000 correos electrónicos en él (el servidor ascendente de tu ISP no será suficiente aquí y harás que el ISP se sienta muy infeliz; usamos dos cajas dedicadas)
  • algún contenedor de correo (por ejemplo, PhpMailer si PHP es su veneno preferido; usar PHP mail()es bastante horrible por sí solo)
  • su propia función de remitente se ejecute en un bucle, cree los correos electrónicos y páselos al contenedor (tenga en cuenta que puede encontrarse con los límites de memoria de PHP si su aplicación tiene una pérdida de memoria; es posible que necesite reciclar el proceso de envío periódicamente, o incluso mejor , desacople "crear correos electrónicos" y "enviar correos electrónicos" por completo)

Sorprendentemente, esa fue la parte fácil. Lo difícil es enviarlo:

  • Algunos servidores le prohibirán enviar demasiados correos juntos, por lo que deberá barajar y vigilar la cola (por ejemplo, enviar un correo a [email protected] , luego tres a otros dominios, y luego otro a otra direcció[email protected] ). )
  • necesita tener registros PTR, SPF, DKIM correctos
  • Manejo de tiempos de espera de servidores remotos, registros DNS mal configurados y otras bromas de la red.
  • Manejar correos electrónicos no válidos (y no, regex es la herramienta incorrecta para eso )
  • Manejo de cancelaciones de suscripciones (muchos boletines legítimos han sido reclasificados como spam debido a que muchos usuarios frustrados no pudieron darse de baja en un solo paso y en su lugar eligieron "marcarlos como spam"; los filtros de spam aprenden, especialmente con grandes proveedores de correo electrónico).
  • manejo de rebotes y rechazos ("no existe el buzón [email protected] ", "buzón [email protected] lleno")
  • manejo de listas negras y eliminación de listas negras (Claro, no estás enviando spam. Algunos destinatarios no estarán tan seguros; con una lista tan grande, sucederá a veces, sin importar las precauciones que tomes. Algunas personas (por ejemplo, tus no tan (competidores escrupulosos) podrían incluso llegar a denunciar falsamente sus correos como spam; esto sucede. En promedio , se necesitan semanas para que lo eliminen de una lista negra.)

Y para colmo, tendrás que gestionar la parte legal (varias leyes federales, estatales y locales; e incluso diferentes marañas de leyes una vez que envías fuera de los EE. UU. (nota: no tienes forma de saber si joe @hotmail.com vive en el suroeste de Elbonia, el país con las leyes antispam más draconianas del mundo).

Estoy bastante seguro de que me perdí algunas cabezas de esta hidra. ¿Todavía estás seguro de que quieres hacerlo tú mismo? Si es así, habrá otra ola, esta vez simplemente los molestos problemas inherentes al envío de un correo electrónico. (Verá, SMTP es un protocolo de almacenamiento y reenvío, lo que significa que su correo electrónico se distribuirá entre muchos servidores SMTP de Internet, con la esperanza de que el siguiente esté un poco más cerca del destinatario final. Básicamente, el correo electrónico se envía a un servidor SMTP, que lo coloca en su cola de reenvío; cuando llegue el momento, lo reenviará a un servidor SMTP diferente, hasta que llegue al servidor SMTP del dominio determinado. Este reenvío podría ocurrir inmediatamente , o en unos minutos, horas, días o nunca). Por lo tanto, verá los siguientes problemas, la mayoría de los cuales podrían ocurrir tanto en el camino como en el destino:

  • los servidores SMTP remotos no quieren hablar con su servidor SMTP
  • Tus correos electrónicos se marcan como spam ( <blink>no es tu amigo aquí ni lo es <font color=...>).
  • sus correos electrónicos se entregan con días, incluso semanas de retraso (contrariamente a la opinión popular, SMTP está diseñado para hacer un mayor esfuerzo para entregar el mensaje en algún momento en el futuro, no para entregarlo ahora)
  • sus correos electrónicos no se entregan en absoluto (ya enviados desde el servidor de correo electrónico en el salto n.° 4, aún no enviados desde el servidor en el salto n.° 5, el servidor que actualmente contiene el mensaje falla, se pierden datos)
  • sus correos electrónicos son destrozados por algún servidor sin cerebro en el camino (este es algo solucionable con codificación base64, pero luego el tamaño aumenta y el correo electrónico parece más sospechoso)
  • sus correos electrónicos se entregan y los destinatarios parecen no quererlos ("Estoy seguro de que no me registré para esto, recuerdo exactamente lo que hice hace un año" (por supuesto que sí, señor))
  • usuarios con varias versiones de Microsoft Outlook y su manejo especial del correo de Internet
  • modo aprendiz de mago (un ciclo de retroalimentación positiva que se refuerza a sí mismo; en otras palabras, correos electrónicos automatizados como respuestas a correos electrónicos automatizados como respuestas a...; realmente no quieres ser tú quien active esto, ya que enojarías a la mitad de Internet contigo mismo)

y será tu trabajo solucionar este problema (pista: no puedes, en su mayoría). Las personas que dirigen negocios legítimos de envío de correo masivo saben que al final no se puede resolver y que ellos tampoco pueden resolverlo, y tienen las razones bien investigadas, documentadas y delineadas (tal vez incluso como una presentación de PowerPoint). (completo con sonidos y transiciones interesantes) que tus jefes puedan entender), ya que han tenido que explicar esto un millón de veces antes. Además, para los problemas que realmente tienen solución, saben muy bien cómo resolverlos.

Si después de todo esto no te desanimas y aún quieres hacerlo, adelante: incluso es posible que encuentres una manera mejor de hacerlo. Sólo sepa que el camino por delante no será fácil: enviar un correo electrónico es trivial, recibirlo es difícil.

Piskvor left the building avatar Oct 11 '2010 11:10 Piskvor left the building

La gente ha recomendado MailChimp, que es un buen proveedor de correo electrónico masivo. Si está buscando un buen proveedor de correo electrónico transaccional, es posible que pueda ayudarle.

Durante los últimos 6 meses, utilizamos cuatro proveedores SMTP diferentes con el objetivo de descubrir cuál era el mejor.

Aquí hay un resumen de lo que encontramos...

AutenticaciónSMTP

  • Más barato alrededor
  • Sin análisis/informes
  • Sin seguimiento de aperturas/clics
  • Tuve ligeras dudas en algunos envíos.

Matasellos

  • Muy barato, pero no tan barato como AuthSMTP
  • Hermoso cpanel pero sin seguimiento de aperturas/clics
  • Seguimiento de la actividad a nivel de envío para que pueda abrir un único correo electrónico que se envió y ver su aspecto y los datos de entrega.
  • Tienes que usar API. El envío por SMTP se introdujo recientemente pero tiene errores. Por ejemplo, notamos que las comillas (") en la línea de asunto están eliminadas.
  • No se puede enviar ningún archivo adjunto que desee. Debe estar en la lista aprobada de tipos de archivos y tener un tamaño determinado. (10 MB creo)
  • Requiere una lista establecida de nombres/direcciones.

JangoSMTP

  • Caro en relación con los demás – más de 10 veces en algunos casos
  • Panel de control feo pero excelente seguimiento de aperturas/clics con detalles a nivel de correo electrónico
  • A veces tuve dudas al enviar. En dos ocasiones, los envíos tardaron una hora en entregarse.
  • Requiere una lista establecida de nombres/direcciones.

EnviarGrid

  • No es tan barato como AuthSMTP, pero sigue siendo muy barato. Muchos clientes pueden existir con 200 envíos gratuitos por día.
  • Panel de control decente pero sin detalles detallados sobre el seguimiento de aperturas/clics
  • Muchas opciones de API. Las opciones (seguimiento de apertura/clic, etc.) se pueden definir de forma personalizada correo electrónico por correo electrónico. El correo electrónico entrante (de respuesta) se puede publicar en nuestro punto final HTTP.
  • Absolutamente cero dudas en los envíos. Cada correo electrónico enviado llegó a la bandeja de entrada casi de inmediato.
  • Puede enviar desde cualquier nombre/dirección.

Conclusión

SendGrid fue el mejor y Postmark quedó en segundo lugar. Nunca vimos ninguna duda en los tiempos de envío con ninguno de esos dos (en algunos casos enviamos varios cientos de correos electrónicos a la vez) y ambos tienen el mejor retorno de la inversión, dado un sólido conjunto de funciones.

sohtimsso1970 avatar Oct 13 '2010 16:10 sohtimsso1970

Esto es lo que hice recientemente en PHP en uno de mis sistemas más grandes:

  1. El usuario ingresa el texto del boletín y selecciona los destinatarios (lo que genera una consulta para recuperar las direcciones de correo electrónico para más adelante).

  2. Agregue el texto del boletín y la consulta de los destinatarios a una fila en la tabla MySQL llamada *email_queue*

    • (La tabla email_queue tiene las columnas "a" "asunto" "cuerpo" "prioridad")
  3. Creé otro script, que se ejecuta cada minuto como un trabajo cron. Utiliza la clase SwiftMailer . Este script simplemente:

    • durante el horario comercial, envía todos los correos electrónicos con prioridad == 0

    • fuera de horario, enviar otros correos electrónicos por prioridad

Dependiendo de la configuración del host, ahora puedo acelerarlo usando complementos estándar de swiftmailers como antiflood y throttle...

$mailer->registerPlugin(new Swift_Plugins_AntiFloodPlugin(50, 30));

y

$mailer->registerPlugin(new Swift_Plugins_ThrottlerPlugin( 100, Swift_Plugins_ThrottlerPlugin::MESSAGES_PER_MINUTE ));

etcétera etcétera..

Lo he ampliado mucho más allá de este pseudocódigo, con archivos adjuntos y muchas otras opciones configurables, pero funciona muy bien siempre que su servidor esté configurado correctamente para enviar correo electrónico. (Probablemente no funcione en hosting compartido, pero en teoría debería...) Swiftmailer incluso tiene una configuración

$message->setReturnPath

Que ahora uso para rastrear los rebotes...

¡Rastros felices! (¿Correos electrónicos felices?)

ethanpil avatar Oct 25 '2011 08:10 ethanpil