Publiceer MTA-STS en TLS-RPT eerst in testmodus

SPF, DKIM en DMARC voorkomen dat anderen uw naam vervalsen (u kunt uw DMARC-record controleren), maar geen van drieën voorkomt dat een verzendende server mail in platte tekst bij u aflevert. Met MTA-STS publiceert u een beleid waarin staat dat uw mailservers geauthenticeerde TLS ondersteunen, en TLS-RPT laat u weten wanneer afzenders dat niet kregen. U kunt beide uitrollen met twee DNS-records en één tekstbestand, en u kunt beginnen in een modus die bedoeld is voor een zachte uitrol.

Wat STARTTLS openlaat

Versleuteling van mail tussen servers gebruikt de STARTTLS-extensie en is opportunistisch. RFC 8461 beschrijft het zwakke punt: een aanvaller die het antwoord "250 STARTTLS" uit de SMTP-sessie kan verwijderen, of de sessie kan omleiden door het opgeloste MX-record te overschrijven, kan een downgrade afdwingen of de sessie onderscheppen.

DANE is de andere oplossing, gedefinieerd in RFC 7672, maar daarvoor is DNSSEC nodig. MTA-STS steunt in plaats daarvan op certificeringsinstanties en heeft geen DNSSEC nodig, "ten koste van het risico op kwaadwillende downgrades", in de eigen woorden van de RFC. Als u al DANE gebruikt, botsen de twee niet: afzenders die MTA-STS implementeren mogen het niet laten prevaleren boven een mislukte DANE-validatie.

De NCSC-richtlijn voor e-mailbeveiliging stelt dat uw dienst e-mail moet kunnen verzenden en ontvangen via TLS, en dat u al uw domeinen moet beschermen, ook die bij cloudproviders zoals Google G Suite en Microsoft O365.

Stap één: het beleid, in testmodus

MTA-STS bestaat uit twee delen. Een TXT-record op _mta-sts.example.com kondigt aan dat er een beleid is en welke versie dat is:

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

De id bestaat uit letters en cijfers, maximaal 32 tekens, en moet deze versie van het beleid uniek identificeren. Er is geen impliciete volgorde, dus een tijdstempel is een gewoonte en geen vereiste. Publiceer precies één zo'n record: afzenders negeren records die niet met v=STSv1; beginnen, en als het aantal daarna niet één is, gaan ze ervan uit dat u geen beleid hebt.

Het beleid zelf wordt via HTTPS opgehaald van een vast adres, opgebouwd door mta-sts voor uw domein te zetten:

https://mta-sts.example.com/.well-known/mta-sts.txt

Lever het uit als text/plain, want afzenders moeten het mediatype controleren. Het bestand ziet er zo uit:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Elke mx:-regel is een eigen item, ofwel een volledige hostnaam ofwel een wildcard-achtervoegsel zoals *.example.net. Vermeld elke host uit uw actieve MX-records, ook die van een cloudprovider.

De drie modi zijn enforce, testing en none. De RFC beschrijft testing als een optionele modus waarmee zachte uitrol mogelijk is om beleidsfouten op te sporen, en daarom begint u daar.

De max_age is in seconden, tot maximaal 31557600, en 604800 (een week) is het eigen voorbeeld van de RFC. De RFC verwacht voor productie waarden die doorgaans in de orde van weken of meer liggen. Mijn advies: houd het tijdens het testen op een week of minder, zodat een gecorrigeerd beleid snel bij afzenders aankomt, en verhoog het zodra enforce stabiel draait.

Stap twee: schakel TLS-RPT in

Detectie werkt alleen als afzenders u vertellen wat ze zagen. U publiceert een TXT-record op _smtp._tls.example.com:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"

De rua kan ook een https-URI zijn, in welk geval afzenders het rapport ernaartoe POSTen, en een kommagescheiden lijst is toegestaan. Net als bij het MTA-STS-record moet precies één TXT-record met v=TLSRPTv1; beginnen, anders gaan afzenders ervan uit dat u het niet implementeert.

Kiest u voor mailto, gebruik dan een speciale mailbox. Afzenders leveren deze rapporten ook af als TLS mislukt, dus een rapport kan onversleuteld binnenkomen. Rapporten die per e-mail worden verstuurd moeten een geldige DKIM-handtekening van het rapporterende domein dragen, en volgens de RFC moeten ontvangers rapporten zonder handtekening negeren. Gooi ongetekende rapporten weg in plaats van erop te handelen.

Controleer wat afzenders zien

Vraag beide records op en haal het beleidsbestand van buiten uw netwerk op:

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

De dig-uitvoer hoort elk één record te tonen, met het voorvoegsel v= vooraan. De curl-uitvoer hoort een 200, Content-Type: text/plain en de inhoud van het beleid te tonen, dus controleer of mode en elke mx:-regel zijn zoals bedoeld. Los elke certificaatfout die curl meldt op voordat u het TXT-record publiceert.

De rapporten lezen

Rapporten zijn JSON-bestanden over een tijdsperiode, met een afleveringsoverzicht van aantallen successen en mislukkingen. De RFC deelt mislukkingen in naar onderhandelings-, beleids-, algemene en tijdelijke fouten. Rapporten kunnen gecomprimeerd binnenkomen (de RFC definieert application/tlsrpt+gzip), dus pak ze eerst uit:

gzip -dc report.json.gz | jq .

De veldnamen zijn gedefinieerd in sectie 4.4 van RFC 8460. Lees eerst de samenvattende aantallen en daarna de foutvermeldingen.

Een rapport met veel successen en geen fouten is wat u wilt zien. De RFC merkt op dat een rapport kan dienen als hartslag die laat zien dat TLS naar verwachting wordt onderhandeld, en een gestage reeks schone rapporten is uw bewijs om door te gaan. Fouten waarin een van uw eigen MX-hosts wordt genoemd, wijzen op een certificaat of mx-patroon dat u moet herstellen. Eén afzender met een kapotte stack is hun probleem.

Een plotselinge toename van STARTTLS-fouten die u niet aan een wijziging kunt koppelen, hoort bij degene die incidenten afhandelt, of bij ons incident response-team als u niemand hebt.

Overstappen naar enforce

Wacht tot de rapporten schoon zijn over uw normale mailpatronen heen, inclusief stille afzenders zoals maandelijkse factuursystemen. Wijzig dan mode: testing in mode: enforce en wijzig de id in het TXT-record, omdat afzenders die vergelijken met hun gecachete kopie om te zien dat er iets is veranderd.

Afzenders mogen een beleid tot max_age na de laatste ophaalactie cachen, dus een fout kan blijven hangen. Het verwijderen van het TXT-record haalt een gecachet beleid ook niet weg, zoals de RFC aangeeft. RFC 8461 sectie 8.3 behandelt verwijdering, en die leest u beter voordat u haar nodig hebt.

Waar u begint

1. Maak een lijst van uw actieve MX-hosts, ook die van een eventuele cloudprovider, en controleer dat elk een geldig certificaat presenteert dat bij de naam past.
2. Richt de mta-sts-host in via HTTPS en lever het beleidsbestand uit als text/plain met mode: testing.
3. Publiceer het enige _mta-sts TXT-record met een nieuwe id en voer daarna de dig- en curl-controles hierboven uit.
4. Publiceer het _smtp._tls TXT-record dat naar een speciale mailbox of HTTPS-endpoint wijst, en controleer uw totale opzet met onze e-mailbeveiligingscheck.
5. Beoordeel de rapporten over minstens één volledige bedrijfscyclus, inclusief maandeindeverwerkingen (voor de meeste organisaties een maand). Los elke fout op die van u is, schakel dan over naar enforce en wijzig de id.