
Vamos a sumergirnos en los detalles de la configuración de PowerMTA para SparkPost Signals.
Vamos a profundizar en los detalles de configurar PowerMTA para SparkPost Signals. Vas a necesitar:
Un host para ejecutar la versión más reciente de PowerMTA, ya sea una máquina nueva o una existente
Una cuenta de SparkPost con permiso de clave API para “Incoming Events: Write” como se describe aquí
Configuraremos PowerMTA para transmitir eventos a tu cuenta de SparkPost, luego podrás usar lo siguiente:
Primero, instala (o actualiza) a PowerMTA 5.0 r4 o posterior, siguiendo las instrucciones de instalación habituales de v5.0, que son bastante sencillas. Luego trabajaremos en los siguientes pasos:
Configura el conector PowerMTA a SparkPost Signals
Configura el seguimiento de compromiso con un dominio de seguimiento personalizado
Selecciona qué flujos de tráfico de PowerMTA reportar a Signals
Prueba que tus eventos estén llegando a Signals
Revisa cómo usar nombres significativos que se muestren bien en los informes.
También cubriremos los otros aspectos específicos de la configuración de PowerMTA utilizados en nuestra demo de Signals:
Eventos FBL (Spam Complaints) y rebotes remotos (out-of-band)
Configuración de inyección, incluyendo DKIM
Configuración FBL y OOB
Configuración y nombramiento de VirtualMTA (y cómo aparece esto en tus informes de SparkPost Signals)
Finalmente, hay una “función adicional” con código para asegurar que los nombres de tus campañas sean compatibles con las convenciones de nombres PowerMTA X-Job.
Configurar PowerMTA connector
La configuración de Signals se describe en la sección 10.1 de la Guía del Usuario 5.0. Aquí comenzaremos con “Use Case #2”, que habilita Signals para todo el tráfico de este host de PowerMTA y habilita el seguimiento de participación de SparkPost.
# # SparkPost Signals # <signals> api-key ##mi clave API de ingestión aquí## upload-url https://api.sparkpost.com/api/v1/ingest/events log-verbose true min-free-space 1G engagement-tracking sparkpost # esto activa el seguimiento de aperturas y clics en PowerMTA customer-id 123 # Tu número de cuenta de SparkPost aquí </signals> enable-signals true
A continuación se explica qué hace cada atributo:
api-key
Esto es único para tu cuenta de SparkPost, es el valor que obtuviste de SparkPost anteriormente.
upload-url
Esto debe coincidir con la dirección de tu servicio API de SparkPost, ya sea EE.UU. o UE. Para más información, consulta aquí. Los valores habituales son:
SparkPost (EE.UU.): https://api.sparkpost.com/api/v1/ingest/events
SparkPost UE: https://api.eu.sparkpost.com/api/v1/ingest/events
log-verbose
Esta directiva es opcional y, cuando se habilita, proporciona un poco más de información en el archivo pmta.log, lo que puede ser útil durante la configuración para confirmar que todo funciona correctamente. Cada minuto, incluso cuando no hay tráfico, verás:
2019-07-26 11:47:57 Signals: Se descubrieron 0 archivos
Con tráfico, verás algo como:
2019-07-26 11:50:57 Signals: Se descubrió sp1-0000000000003FBD.json 2019-07-26 11:50:57 Signals: sp1-0000000000003FBD.json transferido exitosamente. 2019-07-26 11:50:57 Signals: Se descubrió 1 archivo, se transfirió 1 archivo exitosamente
min-free-space
Esto indica a PowerMTA el umbral de espacio en disco al que debe comenzar a eliminar los archivos de eventos JSON más antiguos de SparkPost para dejar espacio a nuevos archivos cuando el espacio en disco sea escaso.
enable-signals
Esto indica a PowerMTA que suba a Signals, en este caso a nivel global para todo el tráfico (más información aquí, para v5.0). Puedes ser más selectivo sobre qué flujos de tráfico subir si lo deseas.
También puedes marcar un tráfico específico de PowerMTA para que se informe como perteneciente a una subcuenta de SparkPost – esta es otra forma de distinguir un flujo de tráfico particular de otro.
engagement-tracking, customer-id
La solución de Seguimiento de Participación de PowerMTA predetermina al dominio de seguimiento para el servicio alojado por SparkPost en EE.UU. Especificas tu ID numérica de cliente de SparkPost; aquí hay instrucciones para encontrarla.
tracking-domain
Para cuentas de SparkPost UE, agrega la siguiente línea:
tracking-domain pmta.eu.spgo.io # este es el punto de acceso para SparkPost UE
Dominio de seguimiento personalizado
Si prefieres usar tu propio dominio de seguimiento (esto es mejor desde un punto de vista de entregabilidad), haz lo siguiente:
Crea un dominio de seguimiento con tu proveedor de DNS creando un registro CNAME. Esto generalmente será un subdominio de tu dominio de nivel superior, p. ej. track.mycompany.com .
track.mycompany.com CNAME pmta.spgo.io # si tienes una cuenta de SparkPost EE.UU. track.mycompany.com CNAME pmta.eu.spgo.io # si tienes una cuenta de SparkPost UE
También puedes usar dominios de seguimiento HTTPS, aunque esto es más complicado (consulta los pasos de configuración de SparkPost aquí).
Registra el dominio de seguimiento en tu cuenta de SparkPost y verifícalo. Espera unos minutos antes de intentar esto, para permitir que tus cambios de DNS se propaguen a través de Internet, dependiendo de tu proveedor de DNS.
Configura PowerMTA para usar ese dominio en lugar del predeterminado, con
tracking-domain yourdomain.com # Pon tu propio dominio aquí
Puedes verificar que tus correos electrónicos entregados tienen "píxeles de apertura" añadidos y los enlaces envueltos, observando los internos del correo (en Gmail, usa el menú superior derecho y elige "Mostrar Original").

Notarás los píxeles de apertura al principio y al final del HTML en el correo electrónico. Cada enlace HTML también se cambia para tener REF apuntando al dominio de seguimiento.

Eso es todo lo que necesitas para que SparkPost Signals funcione con el Seguimiento de Participación incorporado de PowerMTA.
Evitar que se rastreen enlaces específicos en tu correo electrónico html
Puedes evitar que PowerMTA rastree enlaces específicos, estableciendo el atributo personalizado data-msys-clicktrack a "0" :
<a href="#" data-msys-clicktrack="0">Ejemplo</a>
PowerMTA no envolverá el enlace. También eliminará ese atributo antes de transmitir el mensaje a tu destinatario.
Seleccione qué flujos de tráfico de PowerMTA informar a Signals
Probando que tus eventos están llegando a Signals
Aquí tienes una vista de SparkPost Signals, conectado a PowerMTA. Puedes ver que la puntuación de salud está variando.

Los nombres de las Campañas están disponibles como facetas de informes, junto con Subaccount, IP Pool, Mailbox Provider, y Sending Domain.
Además de mirar los registros de PowerMTA, puedes verificar que los datos de eventos están llegando a SparkPost mirando la pantalla de Integración de Signals.

En tu pantalla de Búsqueda de Eventos de SparkPost, deberías ver los eventos aparecer en pocos minutos. Estos incluirán eventos de Injection y Delivery, así como Bounce, y potencialmente Out-of-Band Bounce y eventos de Spam Complaint, si ya has configurado PowerMTA para manejarlos por ti.
Si tienes el Seguimiento de Engagement habilitado, también verás eventos de open, initial_open, y click.
Usando nombres significativos que aparezcan bien en los informes
Configurar los nombres de los PowerMTA VirtualMTA Pool y los nombres de los trabajos para que sean significativos y fáciles de leer vale la pena. Estos aparecen directamente en sus facetas de SparkPost Signals y el informe de resumen.
Como se mencionó anteriormente, no necesita crear estos pools en su cuenta de SparkPost. SparkPost los recoge de su configuración de PowerMTA.
Aquí se muestra cómo los términos de configuración de PowerMTA se traducen a términos de SparkPost.
Término de PowerMTA / Término de Informes de SparkPost / SignalsDominio del destinatario
(parte del dominio del campo “rcpt” en el archivo de contabilidad).Dominio del destinatarioLa parte del dominio del encabezado “Sender” o “From” en el mensaje retransmitido por PowerMTA.
(parte del dominio de “orig” en el archivo de contabilidad).Dominio de envíoVirtualMTA (nombre)—VirtualMTA Pool (nombre)
(“vmtaPool” en el archivo de contabilidad)IP Pool (nombre)smtp-source-host a.b.c.d
(“dlvSourceIp” en el archivo de contabilidad)IP de envío a.b.c.dTrabajo (nombre)
(“jobId” en el archivo de contabilidad)Campaign ID (nombre)—Plantilla (nombre)“Subaccount” no es un concepto nativo de PowerMTA.
Sin embargo, PowerMTA puede etiquetar virtualMTAs, virtual MTA Pools, o dominios de Sender-or-From con un subaccount ID para propósitos de informes de SparkPost.
ID de subcuenta (número)FBL (evento)Queja de spam (evento)Bote remoto (evento)Rebote fuera de banda (evento)
Configurar al menos una dirección de smtp-source-host también le permite a SparkPost identificar correctamente la dirección IP de envío para que aparezca en los eventos de inyección y entrega, así como en la vista del informe de resumen.
Los nombres de trabajos se establecen en PowerMTA a través de un encabezado en el mensaje inyectado. Además de permitir el control individual del trabajo (pausa/reanudar, etc.), que es útil en sí mismo, PowerMTA pasa los nombres a los informes de SparkPost Signals como “campaign ID”. Consulte la Guía del usuario v5.0 sección 12.8 “Seguimiento de una campaña en PowerMTA con un JobID”.
Hay algunas cosas que debe tener en cuenta con respecto a la nomenclatura de trabajos. Mientras que SparkPost (con formato JSON y escape de JSON) permite caracteres como <ESPACIO> en los nombres de las campañas, los encabezados de correo son más restrictivos. Los caracteres válidos permitidos en el encabezado X-Job son:
A-Za-z0-9!#$%&'()*+,-./:;<=>?@[\]^_{|}~
En otras palabras, los caracteres no permitidos incluyen <ESPACIO>, comillas dobles “ y la tilde inversa `. Si está acostumbrado a trabajar con nombres X-Job, esto no será sorprendente, y los nombres de sus ID de campaña “funcionarán” en los informes de SparkPost. Si, como yo, aprendió SparkPost primero, es posible que desee una herramienta para garantizar que sus valores de X-Job sean seguros; vea la característica adicional al final de este artículo.
Eventos FBL (Spam Complaints) y rebotes remotos (fuera de banda)
PowerMTA puede recibir y procesar eventos FBL (conocidos en SparkPost como eventos de queja por spam) y devoluciones remotas (conocidas en SparkPost como devoluciones fuera de banda, porque la respuesta llega un tiempo después, en lugar de durante la conversación SMTP).
Hay artículos en el Foro de Soporte de Port25 sobre cómo configurar el Procesador de Rebotes y el Procesador de FBL. Si ya eres un usuario de PowerMTA, probablemente ya los tengas.
Aquí está la configuración que hice para una demostración, basada en estos artículos y orientada a alojar PowerMTA en Amazon EC2.
Si estás familiarizado con la configuración de PowerMTA en esta área, puedes saltarte esta parte y pasar a la siguiente línea horizontal.
Configuración de inyección
Usaremos el puerto 587 para mensajes inyectados, que llegarán a través de Internet público desde otro host. Necesitamos evitar que actores malintencionados descubran y abusen de este servicio, por lo que aplicamos autenticación de nombre de usuario/contraseña y TLS opcional, similar a los puntos de inyección SMTP de SparkPost.
Queremos poder enviar mensajes desde fuentes que estén debidamente autenticadas a cualquier destino. También queremos un oyente separado en el puerto 25 para respuestas de FBL y rebotes remotos que no requieren autenticación.
# # Dirección IP y puerto en los que escuchar conexiones entrantes de SMTP # smtp-listener 0.0.0.0:587 smtp-listener 0.0.0.0:25
En las siguientes declaraciones <source>, usamos autenticación de nombre de usuario/contraseña y TLS opcional para defendernos contra la inyección de mensajes maliciosos. También establecemos límites de velocidad en conexiones que realizan intentos fallidos de contraseña.
Tu configuración puede ser diferente; por ejemplo, si tienes una red privada entre el inyector y PowerMTA, no necesitarás autenticación de contraseña.
# Una regla de origen para toda inyección, interna o externa. Aplicar autenticación, excepto para rebotes y FBLs # <source 0/0> log-connections false log-commands false # ADVERTENCIA: ¡muy detallado! solo para desarrollo log-data false # ADVERTENCIA: ¡aún más detallado! smtp-service true # permitir servicio SMTP smtp-max-auth-failure-rate 1/min allow-unencrypted-plain-auth false allow-starttls true rewrite-list mfrom </source> <source {auth}> always-allow-relaying yes # solo si la autenticación tiene éxito default-virtual-mta default process-x-job true </source>
La declaración <source {auth}> (ver aquí. v5.0) se aplica una vez pasada la autenticación. Aquí, permite el reenvío, configura el grupo MTA virtual predeterminado a usar y agrega el encabezado X-Job (que será reportado por SparkPost Signals como campaign_id).
La lista de reescritura asigna mensajes inyectados para usar un dominio específico de MAIL FROM (también conocido como dominio de rebote o Return-Path:).
# # Reescribir la dirección MAIL FROM para que coincida con el dominio de rebote # <rewrite-list mfrom> mail-from *@pmta.signalsdemo.trymsys.net *@bounces.pmta.signalsdemo.trymsys.net </rewrite-list>
Luego configuramos nuestra configuración de TLS y nombre de usuario / contraseña de SMTP, de acuerdo con las recomendaciones actuales.
# # Asegura el servicio entrante con nombre de usuario, contraseña y TLS. SMT 2020-06-15 # smtp-server-tls-certificate /etc/pmta/pmtasignalsdemo.pem smtp-server-tls-allow-tlsv1 false smtp-server-tls-allow-tlsv1.1 false smtp-server-tls-allow-tlsv1.2 true smtp-server-tls-allow-tlsv1.3 true # # Usuarios SMTP (autenticados mediante SMTP AUTH) # <smtp-user SMTP_Injection> password ##PON TU CONTRASEÑA AQUÍ## authentication-method password </smtp-user>
Podemos verificar que el TLS v1.0 (inseguro, obsoleto) no es aceptado usando mi herramienta favorita de pruebas SMTP, swaks.
swaks --server pmta.signalsdemo.trymsys.net --port 587 --to test@trymsys.net --from any@sparkpost.com --tls --tls-protocol tlsv1
Vemos:
*** Fallo de inicio de TLS (connect(): error:00000000:lib(0):func(0):reason(0)) *** STARTTLS intentado pero fallido
Igualmente para –tls-protocol tlsv1_1.
Apliquemos también la firma DKIM en nuestros mensajes salientes, ya que es una buena práctica (seguí estas instrucciones para configurar la clave).
# # DKIM # domain-key mypmta, pmta.signalsdemo.trymsys.net, /etc/pmta/mypmta.pmta.signalsdemo.trymsys.net.pem
FBL and OOB configuración
Ahora... finalmente... declaramos qué dominios específicos están abiertos para rebote remoto y respuestas FBL. No queremos retransmitirlos a ninguna parte (para prevenir ataques de backscatter), solo procesar esas respuestas internamente.
# # Habilitar el procesamiento de Rebotes y FBL en dominios específicos # relay-domain pmta.signalsdemo.trymsys.net relay-domain bounces.pmta.signalsdemo.trymsys.net relay-domain fbl.pmta.signalsdemo.trymsys.net <bounce-processor> deliver-unmatched-email no deliver-matched-email no <address-list> domain pmta.signalsdemo.trymsys.net domain bounces.pmta.signalsdemo.trymsys.net </address-list> </bounce-processor> <feedback-loop-processor> deliver-unmatched-email no deliver-matched-email no <address-list> domain fbl.pmta.signalsdemo.trymsys.net </address-list> </feedback-loop-processor>
Puedes ver que configuré dos dominios de rebote, ya que estaba experimentando con usar/no usar la regla de reescritura mfrom.
El dominio FBL generalmente se registra con servicios externos como Microsoft SNDS; ver este artículo para más información. Para esta demostración, los FBL vendrán del Bouncy Sink, por lo que no es necesario registrarse.
Probando el SMTP listener
Es importante probar que tu oyente SMTP está requiriendo autorización para cualquier destino general, rechazando cualquier mensaje que no esté específicamente dirigido a los dominios de FBL y rebote remoto.
swaks --server pmta.signalsdemo.trymsys.net --port 25 --to test@strange.pmta.signalsdemo.trymsys.net --from any@sparkpost.com
La respuesta, como se esperaba, muestra que el reenvío está denegado:
550 5.7.1 reenvío denegado para el destinatario en "RCPT TO:<test@strange.pmta.signalsdemo.trymsys.net>
(Fin de la descripción de la configuración de demostración).
Configuración y nombramiento de VirtualMTA
Los VirtualMTAs de PowerMTA (y los grupos de VirtualMTA) son funciones potentes para gestionar flujos de mensajes, y las funciones de informes PowerMTA / SparkPost Signals funcionan mejor con estos activos.
# # Envía todo el tráfico saliente a través de este mta virtual / grupo. # Declara la dirección IP de entrega aquí, para que los eventos de inyección de señales SparkPost (también conocidos como "recepción") lleven el atributo sending_IP correcto # <virtual-mta mta1> smtp-source-host 172.31.25.101 pmta.signalsdemo.trymsys.net </virtual-mta> <virtual-mta-pool default> virtual-mta mta1 <domain *> max-smtp-out 20 # máx. conexiones *por dominio* bounce-after 4d12h # 4 días, 12 horas retry-after 10m # 10 minutos dkim-sign sí </domain> </virtual-mta-pool>
La configuración virtual-mta-pool se informa en SparkPost como "IP Pool", y está disponible como un elemento de informe de SparkPost Signals (el menú desplegable debajo de los gráficos).

El Informe de Resumen también muestra IP Pool como un elemento de informe "Agrupar por".

Como se señaló anteriormente en este artículo, configurar al menos una dirección smtp-source-host también permite a SparkPost identificar correctamente la dirección IP de envío, para que aparezca en los eventos de Inyección y Entrega, y en el Informe de Resumen:

Eso es todo lo que necesitas para que una integración básica funcione entre PowerMTA y SparkPost Signals. Encontrarás el ejemplo completo del archivo de configuración aquí.
Antes de que te vayas, aquí está la función adicional que mencioné.
Función adicional: comprobación/filtrado de X-Job name
Para asegurar que cualquier cadena de caracteres sea segura para usar como un nombre de PowerMTA X-Job, aquí hay una función simple de Python para mapear cualquier carácter no seguro a un guion bajo “_”
import re def pmtaSafeJobID(s): """ :param s: str :return: str Mapear una cadena arbitraria de ID de campaña en caracteres permitidos para el encabezado de PMTA X-Job. Ver https://download.port25.com/files/UsersGuide-5.0.html#tracking-a-campaign-in-powermta-with-a-jobid Específicamente no permitir <sp> " ` pero permitir la mayoría de los otros caracteres. """ # Nota: se debe escapar ' - [ ] y doble escapar \ - ver https://docs.python.org/3/library/re.html disallowedChars = '[^A-Za-z0-9!#$%&\'()*+,\-./:;<=>?@\[\\\\\]^_{|}~]' return re.sub(disallowedChars, '_', s)
Esto utiliza expresiones regulares de Python de una manera específica. Declara el conjunto de caracteres no permitidos usando el operador “complemento del conjunto” ^ en lugar de listar todos los caracteres permitidos. Eso significa que capturamos (y hacemos seguros) caracteres más allá del conjunto usual de 7 bits. Podemos mostrar eso usando este fragmento de prueba:
s='' for i in range(32, 256): s += chr(i) print(pmtaSafeJobID(s))
Resultando en
_!_#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^__abcdefghijkl mnopqrstuvwxyz{|}~___________________________________________________________ ______________________________________________________________________
Puede ver que <ESPACIO>, comillas dobles “, y acento grave `, así como todos los caracteres más allá de ~ se mapean a guion bajo.