Zanurzmy się w szczegóły konfigurowania PowerMTA dla sygnałów SparkPost.
Przyjrzyjmy się szczegółom konfiguracji PowerMTA dla SparkPost Signals. Będziesz potrzebować:
Hosta do uruchomienia najnowszej wersji PowerMTA – może to być nowa lub istniejąca maszyna
Konto SparkPost z uprawnieniami klucza API do „Incoming Events: Write” opisanymi tutaj
Skonfigurujemy PowerMTA do przesyłania wydarzeń do Twojego konta SparkPost, a następnie będziesz mógł korzystać z następujących funkcji:
Najpierw zainstaluj (lub zaktualizuj) PowerMTA 5.0 r4 lub nowszą, postępując zgodnie z zwykłymi instrukcjami instalacji v5.0 które są dość proste. Następnie przejdziemy przez następujące kroki:
Skonfiguruj łącznik PowerMTA do SparkPost Signals
Ustaw śledzenie zaangażowania z niestandardową domeną śledzącą
Wybierz, które strumienie ruchu PowerMTA zgłaszać do Signals
Testowanie, czy Twoje wydarzenia docierają do Signals
Sprawdź, jak używać znaczących nazw, które dobrze wyglądają w raportowaniu.
Omawiamy również inne szczególne aspekty konfiguracji PowerPMTA używane w naszym pokazie Signals:
Wydarzenia FBL (skargi na spam) i zdalne (out-of-band) bounces
Konfiguracja zastrzyków, w tym DKIM
Konfiguracja FBL i OOB
Konfiguracja i nazewnictwo VirtualMTA (i jak to pojawia się w raportach SparkPost Signals)
Na koniec jest „dodatkowa funkcja” z kodem zapewniającym zgodność nazw kampanii z konwencjami nazw PowerMTA X-Job .
Skonfiguruj PowerMTA connector
The Signals configuration is described in the 5.0 User Guide section 10.1. Here we’ll start with “Use Case #2”, which enables Signals for all traffic from this PowerMTA host, and enable SparkPost engagement tracking.
# # SparkPost Signals # <signals> api-key ##my ingest API key here## upload-url https://api.sparkpost.com/api/v1/ingest/events log-verbose true min-free-space 1G engagement-tracking sparkpost # this turns on the open and click tracking in PowerMTA customer-id 123 # Your SparkPost account number here </signals> enable-signals true
Here’s what each attribute does:
api-key
This is unique to your SparkPost account, it’s the value you got from SparkPost earlier.
upload-url
This needs to match the address of your SparkPost API service, whether it’s US or EU. For more info see here. The usual values are:
SparkPost (US): https://api.sparkpost.com/api/v1/ingest/events
SparkPost EU: https://api.eu.sparkpost.com/api/v1/ingest/events
log-verbose
This directive is optional and when enabled, gives a bit more info in the pmta.log file, which can be useful during setup to confirm that everything’s working correctly. Each minute, even when there’s no traffic, you’ll see:
2019-07-26 11:47:57 Signals: Discovered 0 files
With traffic, you’ll see something like:
2019-07-26 11:50:57 Signals: Discovered sp1-0000000000003FBD.json 2019-07-26 11:50:57 Signals: Transferred sp1-0000000000003FBD.json successfully. 2019-07-26 11:50:57 Signals: Discovered 1 file, transferred 1 file successfully
min-free-space
This tells PowerMTA the disk space threshold at which it should start to delete the oldest SparkPost JSON event files to make space for new files when disk space is running low.
enable-signals
This tells PowerMTA to upload to Signals, in this case globally for all traffic (more info here, for v5.0). You can be more selective about what traffic streams to upload if you wish.
You can also mark particular PowerMTA traffic to be reported as belonging to a SparkPost subaccount – this is another way to distinguish one particular traffic stream from another.
engagement-tracking, customer-id
PowerMTA’s Engagement Tracking solution defaults to the tracking domain for the SparkPost US-hosted service. You specify your SparkPost numeric customer ID; here’s instructions for finding it.
tracking-domain
For SparkPost EU accounts, add the following line:
tracking-domain pmta.eu.spgo.io # this is the endpoint for SparkPost EU
Custom Tracking domain
If you would prefer to use your own tracking domain (this is better from a deliverability standpoint), do the following:
Create tracking domain with your DNS provider by creating a CNAME record. This will usually be a subdomain of your top-level domain, e.g. track.mycompany.com .
track.mycompany.com CNAME pmta.spgo.io # if you have a SparkPost US account track.mycompany.com CNAME pmta.eu.spgo.io # if you have a SparkPost EU account
You can also use HTTPS tracking domains, although this is more involved (see SparkPost configuration steps here).
Register tracking domain in your SparkPost account, and verify it. Wait a few minutes before trying this, to allow your DNS changes to propagate through the Internet, depending on your DNS provider.
Configure PowerMTA to use that domain instead of the default, with
tracking-domain yourdomain.com # Put your own domain here
You can check that your delivered emails have “open pixels” added and the links wrapped, by looking at the internals of the mail (in Gmail, use the menu top-right and choose “Show Original”).
You’ll notice the open pixels at the beginning and end of the HTML in the email. Each HTML link is also changed to have REF pointing to the tracking domain.
That’s all you need to get SparkPost Signals working with PowerMTA’s built-in Engagement Tracking.
Preventing specific links in your html email from being tracked
You can prevent PowerMTA from tracking specific links, by setting the custom attribute data-msys-clicktrack to “0” :
<a href="#" data-msys-clicktrack="0">Example</a>
PowerMTA will not wrap the link. It will also remove that attribute prior to transmitting the message to your recipient.
Wybierz, które strumienie ruchu PowerMTA raportować do Signals
Testowanie, czy Twoje wydarzenia docierają do Signals
Here’s a view of SparkPost Signals, connected to PowerMTA. You can see that the health score is varying.
The Campaign names are available as reporting facets, along with Subaccount, IP Pool, Mailbox Provider, and Sending Domain.
As well as looking at the PowerMTA logs, you can check that events data is reaching SparkPost by looking at the Signals Integration screen.
In your SparkPost Events Search screen, you should see events appear within a few minutes. These will include Injection and Delivery events, as well as Bounce, and potentially Out-of-Band Bounce and Spam Complaint events, if you’ve already configured PowerMTA to handle those for you.
If you have Engagement Tracking enabled, you will also see open , initial_open , and click events.
Używanie znaczących nazw, które dobrze wyglądają w raportowaniu
Setting up the PowerMTA VirtualMTA Pool names and Job names to be meaningful and human-readable is well worth doing. These show up directly in your SparkPost Signals facets and the Summary report.
As mentioned earlier, you don’t need to create these pools in your SparkPost account. SparkPost picks them up from your PowerMTA configuration.
Here’s how PowerMTA configuration terms translate to SparkPost terms.
PowerMTA termSparkPost Reports / Signals termRecipient Domain
(domain portion of “rcpt” field in Accounting file).Recipient DomainThe domain portion of the “Sender” or “From” header in the message relayed by PowerMTA.
(domain portion of “orig” in Accounting file).Sending DomainVirtualMTA (name)—VirtualMTA Pool (name)
(“vmtaPool” in accounting file)IP Pool (name)smtp-source-host a.b.c.d
(“dlvSourceIp” in accounting file)Sending IP a.b.c.dJob (name)
(“jobId” in accounting file)Campaign ID (name)—Template (name)“Subaccount” is not a native PowerMTA concept.
However, PowerMTA can tag virtualMTAs, virtual MTA Pools, or Sender-or-From domains with a subaccount ID for SparkPost reporting purposes.
Subaccount ID (number)FBL (event)Spam Complaint (event)Remote Bounce (event)Out-of-Band bounce (event)
Setting up at least one smtp-source-host address also enables SparkPost to correctly identify the sending IP address so that it shows up on Injection and Delivery events, as well as in the Summary report view.
Job names are set in PowerMTA via a header in the injected message. As well as enabling individual job control (pause/resume etc) which is useful in itself, PowerMTA passes the names through to SparkPost Signals reporting as “campaign ID”. See User Guide v5.0 section 12.8 “Tracking a campaign in PowerMTA with a JobID”.
There are a few things to be aware of regarding job naming. While SparkPost (with JSON format, and JSON escaping) allows characters such as <SPACE> in campaign names, mail headers are more restrictive. Valid characters allowed in the X-Job header are:
A-Za-z0-9!#$%&'()*+,-./:;<=>?@[\]^_{|}~
In other words, disallowed characters include <SPACE>, double-quotes “ and backtick `. If you’re used to working with X-Job names, this won’t be surprising, and your campaign ID names will “just work” on SparkPost reporting. If like me, you learned SparkPost first, you might want a tool to ensure your X-Job values are safe; see the bonus feature at the end of this article.
FBL zdarzenia (Spam Complaints) i zdalne (out-of-band) bounces
PowerMTA może odbierać i przetwarzać wydarzenia FBL (znane w SparkPost jako wydarzenia zgłoszenia spamu) oraz zdalne odbicia (znane w SparkPost jako odbicia poza pasmem, ponieważ odpowiedź wraca jakiś czas później, a nie podczas rozmowy SMTP).
W Port25 Support Forum znajdują się artykuły na temat konfigurowania Bounce Processor i FBL Processor. Jeśli jesteś istniejącym użytkownikiem PowerMTA, prawdopodobnie już je masz.
Oto konfiguracja, którą zrobiłem na potrzeby demonstracji, na podstawie tych artykułów i zorientowana na hosting PowerMTA w Amazon EC2.
Jeśli znasz konfigurację PowerMTA w tym obszarze, możesz pominąć tę część, aż do następnej poziomej linii.
Konfiguracja Injection
Będziemy używać portu 587 do wiadomości wstrzykiwanych, które będą pochodzić z publicznego Internetu z innego hosta. Musimy zatrzymać złych aktorów przed odkrywaniem i nadużywaniem tej usługi, dlatego stosujemy uwierzytelnianie nazwą użytkownika i hasłem oraz opcjonalnie TLS, podobnie jak w punktach końcowych wstrzykiwania SparkPost SMTP.
Chcemy być w stanie wysyłać wiadomości z odpowiednio uwierzytelnionych źródeł do dowolnego miejsca docelowego. Chcemy również osobnego nasłuchu na porcie 25 dla FBL i zdalnych odpowiedzi odbijających, które nie wymagają uwierzytelniania.
# # Adres(y) IP i port(y), na którym nasłuchujemy przychodzących połączeń SMTP # smtp-listener 0.0.0.0:587 smtp-listener 0.0.0.0:25
W poniższych deklaracjach <source> używamy uwierzytelniania nazwą użytkownika i hasłem oraz opcjonalnego TLS w celu obrony przed nieuczciwym wstrzykiwaniem wiadomości. Ustanawiamy również limity szybkości połączeń, które powodują nieudane próby wprowadzenia hasła.
Twoja konfiguracja może być inna; na przykład, jeśli masz prywatną sieć pomiędzy iniektorami a PowerMTA, nie będziesz potrzebować uwierzytelniania hasłem.
# Jedna zasada źródłowa dla całego wstrzykiwania, wewnętrznego lub zewnętrznego. Egzekwuj uwierzytelnianie, z wyjątkiem odbijanych wiadomości i FBLs # <source 0/0> log-connections false log-commands false # OSTRZEŻENIE: szczegółowe! tylko do dev log-data false # OSTRZEŻENIE: jeszcze bardziej szczegółowe! smtp-service true # pozwól na usługę 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 # tylko jeśli uwierzytelnianie się powiedzie default-virtual-mta default process-x-job true </source>
Deklaracja <source {auth}> (zobacz tutaj. v5.0) ma zastosowanie po pomyślnym uwierzytelnieniu. Tutaj pozwala na przekazywanie dalej, ustawia używaną domyślną grupę MTA wirtualnego i dodaje nagłówek X-Job (który będzie zgłaszany przez SparkPost Signals jako campaign_id).
Lista przepisów mapuje wstrzykiwane wiadomości do użycia określonej domeny MAIL FROM (znana również jako domena odbijania lub Return-Path:).
# # Przepisz adres MAIL FROM, aby pasował do domeny odbijania # <rewrite-list mfrom> mail-from *@pmta.signalsdemo.trymsys.net *@bounces.pmta.signalsdemo.trymsys.net </rewrite-list>
Następnie konfigurujemy konfigurację TLS i nazwę użytkownika / hasło SMTP, zgodnie z aktualnymi zaleceniami.
# # Zabezpiecz usługę przychodzącą za pomocą nazwy użytkownika, hasła i 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 # # Użytkownicy SMTP (uwierzytelniani przez SMTP AUTH) # <smtp-user SMTP_Injection> password ## PUT YOUR PASSWORD HERE## authentication-method password </smtp-user>
Możemy sprawdzić, że (niezabezpieczona, przestarzała) TLS v1.0 nie jest akceptowana przy użyciu mojego ulubionego narzędzia testowego SMTP, swaks.
swaks --server pmta.signalsdemo.trymsys.net --port 587 --to test@trymsys.net --from any@sparkpost.com --tls --tls-protocol tlsv1
Widzimy:
*** Rozpoczęcie TLS nie powiodło się (connect(): error:00000000:lib(0):func(0):reason(0)) *** STARTTLS podjęto, ale nie powiodło się
Podobnie dla –tls-protocol tlsv1_1.
Stosujmy również podpisywanie DKIM w naszych wychodzących wiadomościach, ponieważ to dobra praktyka (Skorzystałem z tych instrukcji, aby skonfigurować klucz).
# # DKIM # domain-key mypmta, pmta.signalsdemo.trymsys.net, /etc/pmta/mypmta.pmta.signalsdemo.trymsys.net.pem
Konfiguracja FBL i OOB
Teraz ... wreszcie ... deklarujemy, które konkretne domeny są otwarte na zdalne odpowiedzi typu bounce i FBL. Nie chcemy ich przesyłać nigdzie (aby zapobiec atakom typu backscatter), tylko wewnętrznie przetwarzać te odpowiedzi.
# # Włącz przetwarzanie Bounce i FBL dla konkretnych domen # 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>
Możesz zobaczyć, że ustawiłem dwie domeny bounce, gdyż bawiłem się korzystaniem z reguły mfrom rewrite.
Domena FBL jest zazwyczaj rejestrowana z zewnętrznymi usługami takimi jak Microsoft SNDS; zobacz ten artykuł po więcej informacji. W tym demie, FBLs będą pochodzić z Bouncy Sink, więc nie ma potrzeby rejestracji.
Testowanie nasłuchiwacza SMTP
Ważne jest, aby przetestować, czy Twój nasłuchiwacz SMTP wymaga autoryzacji dla jakichkolwiek ogólnych miejsc docelowych, odrzucając wszelkie wiadomości, które nie są specjalnie zaadresowane do domen FBL i remote-bounce.
swaks --server pmta.signalsdemo.trymsys.net --port 25 --to test@strange.pmta.signalsdemo.trymsys.net --from any@sparkpost.com
Odpowiedź, zgodnie z oczekiwaniami, pokazuje, że przesyłanie dalej jest zabronione:
550 5.7.1 przesyłanie dalej zabronione dla odbiorcy w "RCPT TO:<test@strange.pmta.signalsdemo.trymsys.net>
(Koniec opisu konfiguracji demo).
Konfiguracja i nazewnictwo VirtualMTA
PowerMTA VirtualMTAs (and VirtualMTA pools) are powerful features for managing message streams, and PowerMTA / SparkPost Signals reporting features work best with these active.
# # Route all outgoing traffic through this virtual mta / pool. # Declare the delivery IP address here, so that SparkPost signals ingest injection (aka "reception") events # will carry the correct sending_IP attribute # <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 # max. connections *per domain* bounce-after 4d12h # 4 days, 12 hours retry-after 10m # 10 minutes dkim-sign yes </domain> </virtual-mta-pool>
The virtual-mta-pool setting is reported in SparkPost as “IP Pool”, and is available as a SparkPost Signals reporting facet (the drop-down menu underneath the charts).
The Summary Report also shows IP Pool as a “Group By” reporting facet.
As noted earlier in this article, setting up at least one smtp-source-host address also enables SparkPost to correctly identify the sending IP address, so that it shows up on Injection and Delivery events, and on the Summary Report:
That’s all you need to get a basic integration working between PowerMTA and SparkPost Signals. You’ll find the full config file example here.
Before you go, here’s the bonus feature I mentioned.
Funkcja bonusowa: X-Job name checking/filtering
Aby zapewnić, że dowolny ciąg znaków jest bezpieczny do użycia jako nazwa X-Job w PowerMTA, oto prosta funkcja Python do zamiany niebezpiecznych znaków na podkreślenie „_”
import re def pmtaSafeJobID(s): """ :param s: str :return: str Przekształć dowolny identyfikator kampanii na dozwolone znaki dla nagłówka PMTA X-Job. Zobacz https://download.port25.com/files/UsersGuide-5.0.html#tracking-a-campaign-in-powermta-with-a-jobid Konkretne zabronienia <sp> " ` ale pozwól na większość innych znaków. """ # Zauważ, że trzeba uciekać ' - [ ] i podwójnie uciekać \ - zobacz https://docs.python.org/3/library/re.html disallowedChars = '[^A-Za-z0-9!#$%&\'()*+,\-./:;<=>?@\[\\\\\]^_{|}~]' return re.sub(disallowedChars, '_', s)
To wykorzystuje regularne wyrażenia Pythona w specyficzny sposób. Deklaruje zbiór zabronionych znaków używając operatora „dopełnienie zbioru” ^, zamiast wymieniać wszystkie dozwolone znaki. To oznacza, że przechwytujemy (i zabezpieczamy) znaki poza zwykłym zestawem 7-bitowym. Możemy to pokazać za pomocą tego fragmentu testowego:
s='' for i in range(32, 256): s += chr(i) print(pmtaSafeJobID(s))
Daje
_!_#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^__abcdefghijkl mnopqrstuvwxyz{|}~___________________________________________________________ ______________________________________________________________________
Możesz zobaczyć, że <SPACE>, podwójne cudzysłowy „, i backtick `, jak również wszystkie znaki poza ~ są zamieniane na podkreślenie.
