Konfigurera SPX-e-postkryptering på Sophos Firewall

Med Secure PDF Exchange, förkortat SPX, omvandlar Sophos Firewall ett utgående e-postmeddelande med bilagor till en lösenordsskyddad PDF-fil. Mottagaren behöver ingen egen krypteringsklient. Beroende på vald lösenordsmodell får mottagaren ett engångslösenord, använder ett lagrat lösenord eller registrerar själv ett lösenord.

För tillförlitlig drift måste fyra delar fungera tillsammans: en SPX-mall, en entydig utlösare, en säker lösenordskanal och vid behov SPX Reply Portal. Därefter testas ett positivt och ett negativt e-postflöde. Att en PDF levereras bevisar inte i sig att rätt policy utlöstes eller att lösenordsregistrering och säkra svar fungerar.

SPX i åtta steg

1. Kontrollera Email Protection-licensen, MTA-e-postflödet, modellstödet, portalcertifikatet och den separata SMTP TLS-vägen.
2. Bestäm om krypteringen ska utlösas av en skyddad domän, en Data Control-träff eller avsändaren.
3. Skapa en egen mall under Email > Encryption > SPX templates > Add.
4. Välj medvetet lösenordstyp, PDF-kryptering, avisering och Reply Portal.
5. Skydda FQDN, tillåtna nätverk och port under Email > Encryption > SPX portal settings.
6. Konfigurera policyn SMTP route and scan i MTA mode och tilldela mallen; en Default SPX template ersätter inte denna policy.
7. Testa PDF, lösenordskanal, registrering och svar med en extern mottagare.
8. Genomför ett negativt test utan SPX-utlösare och dokumentera Mail logs, MTA-loggar och återställning.

⚠️ Ett tomt fält Allowed networks för SPX Portal betyder inte ”ingen åtkomst” utan återgår till Any. Sophos rekommenderar dessutom en separat port för Reply Portal. Portalens FQDN, certifikat, tillåtna källor och lösenordskanal måste därför vara fastställda före produktionstestet.

När SPX passar

SPX passar när externa mottagare ska få konfidentiellt innehåll som en skyddad PDF utan att installera en krypteringsklient. Det kan användas i både MTA mode och Legacy mode. Den här proceduren använder MTA mode eftersom domän, Data Control och routing då kan kopplas ihop tydligt i SMTP-policyn. Konfigurera Mail Protection i Legacy mode förklarar det transparenta alternativet.

SPX är inte transportkryptering mellan e-postservrar och inte heller end-to-end-kryptering mellan två e-postklienter. Brandväggen behandlar klartexten, skapar PDF-filen och hanterar lösenordet eller registreringen. PDF-filen kan sedan finnas kvar utanför brandväggen i brevlådor, arkiv eller nedladdningar. Mottagarkrets, lagring och lösenordsöverföring ingår därför i säkerhetsdesignen.

SMTP-transportkryptering styrs separat under Email > General settings > SMTP TLS configuration. Require TLS negotiation kräver TLS för valda fjärrvärdar eller nätverk; om SFOS inte kan upprätta TLS-anslutningen kasseras e-post till den destinationen. Skip TLS negotiation tvingar däremot fram en okrypterad SMTP-anslutning. Det TLS certificate som väljs där skyddar SMTP-vägen och är inte certifikatet för SPX-portalerna. Planera därför SPX och SMTP TLS separat och validera sedan båda i det externa e-postflödet.

Förutsättningarna är:

• en giltig Email Protection-licens;
• ett redan testat utgående e-postflöde via Sophos Firewall;
• en dokumenterad extern testmottagare;
• ett betrott FQDN och ett passande certifikat för de SPX-portaler som används;
• en separat säker kanal för lösenord när mottagaren inte registrerar dem;
• en återställningsväg som gör det möjligt att ta bort mall- och policytilldelningar igen.

Enligt aktuell Sophos-hjälp är SPX inte tillgängligt på XGS 87/87w. Fullständigt MTA mode är dessutom inte tillgängligt på XGS 88/88w. Konfigurera Mail Protection i MTA mode förklarar e-postflöde, licens, relay och modellgränser.

Fastställ utlösare och prioritet

SPX kan utlösas på tre sätt. Om flera metoder är konfigurerade tillämpar Sophos Firewall följande ordning i MTA mode:

1. Skyddad domän: SPX-mallen som valts under Domains and routing target gäller utgående meddelanden från den matchande skyddade domänen.
2. Data control list: Endast om ingen SPX-mall är inställd på domännivå kan en Data Control-träff använda mallen som valts för listan.
3. Avsändarutlösare: Först när varken domänen eller Data Control ger en mall används avsändarmetoden som konfigurerats under Default SPX template.

En domäntilldelning är bred och passar bara om varje matchande utgående meddelande verkligen ska krypteras. Data Control passar för definierade innehållstyper men måste testas med verkliga positiva och negativa exempel för att hitta falska positiva resultat. Avsändarutlösaren lämnar beslutet till avsändaren men kräver ett tydligt dokumenterat flöde i e-postklienten.

Före konfigurationen fastställs exakt en primär utlösare för varje e-postflöde. En andra metod får inte obemärkt åsidosätta en annan.

Skapa SPX-mallen

Exemplet använder mallen Finance-SPX-Recipient. Namnet är ett dokumentationsvärde och anpassas till syfte och organisation.

Separata mallar med anpassade texter och företagslogotyper kan användas för olika kunddomäner. Det är inte bara en fråga om utseende: mottagarinstruktionerna måste stämma med lösenordsmodellen och den faktiskt tilldelade domänen.

1. Öppna Email > Encryption > SPX templates.
2. Välj Add.
3. Ange exempelvis Finance-SPX-Recipient som namn. SFOS tillåter inte apostrofer, snedstreck, kommatecken, omvända snedstreck eller citattecken i namnet.
4. Ange organisationsnamnet för aviseringarna.
5. Välj Encryption standard och PDF page size enligt de egna kraven.
6. Välj den planerade lösenordsmodellen under Password type.
7. Kontrollera ämnesrad, meddelandetext och mottagarinstruktioner och anpassa dem vid behov.
8. Aktivera Enable SPX reply portal för denna MTA-procedur, enligt kravet i mallhjälpen. Skydda portalåtkomsten enligt beskrivningen nedan före testet.
9. Aktivera Include original body into reply endast om det ursprungliga meddelandet får ingå i svaret.
10. Spara mallen.

Välj lösenordsmodell medvetet

Sophos Firewall erbjuder fyra modeller:

• Specified by sender: Avsändaren anger lösenordet. Brandväggen tar bort det före leverans och lagrar det inte. Lösenordet måste nå mottagaren via en separat säker kanal.
• Generate one-time password for every email: Brandväggen skapar ett nytt lösenord för varje meddelande och skickar det till avsändaren. Avsändaren överför det separat till mottagaren. Lösenordet lagras inte.
• Generated and stored for recipient: Brandväggen skapar ett mottagarspecifikt lösenord, skickar det till avsändaren och återanvänder det tills det löper ut.
• Specified by recipient: En ännu inte registrerad mottagare får en registreringslänk, anger själv ett lösenord och använder det tills det löper ut för fler SPX-meddelanden från organisationen.

Med Specified by recipient skickas det första krypterade meddelandet först efter lösenordsregistreringen; att registreringslänken har kommit fram betyder alltså inte att SPX-PDF-filen har levererats.

För en återkommande partnerrelation är Specified by recipient ofta det enklaste flödet att förstå. Ett engångslösenord kan passa bättre för en enstaka särskilt känslig leverans. Olika lagrade lösenordsmodeller för samma mottagare bör inte blandas oplanerat, eftersom mottagaren annars måste identifiera rätt lösenord för varje meddelande.

Med Specified by sender anges lösenordet i ämnesraden enligt mönstret [secure:<password>]<subject text>. Avsändaren måste sedan överföra lösenordet separat. För Microsoft Outlook tillhandahåller Sophos ett Outlook Add-in under Authentication > Client downloads.

Efter att installationen har kontrollerats väljs Encrypt i Outlook för meddelandet som ska krypteras. Att bara installera tillägget utlöser inte krypteringen.

Installera Outlook Add-in kontrollerat

Användare utan WebAdmin-åtkomst öppnar Download client i User Portal och väljer Download Sophos Outlook Add-in. Det nedladdade arkivet packas upp i en tillfällig mapp; för en interaktiv installation startas setup.exe därifrån. Den administrativa nedladdningen under Authentication > Client downloads är en separat åtkomstväg.

Kontrollera MSI-filnamnet före distribution: Hjälpen för User Portal i SFOS 22 och 23 anger SophosOutlookAddInSetup.msi; SPX-installationsbeskrivningen anger däremot SophosOutlookAddInSetupUTM.msi, som i det befintliga exemplet nedan. Det är inte bekräftat att dessa namn är utbytbara. Det faktiska MSI-filnamnet måste kontrolleras i det uppackade paketet. Följande exempel gäller endast om filen verkligen heter SophosOutlookAddInSetupUTM.msi. Om paketet innehåller SophosOutlookAddInSetup.msi används exakt det befintliga namnet som argument till /i; de dokumenterade växlarna /qr /i och T=1 EC=3 C=1 I=1 lämnas oförändrade. Om den förväntade MSI-filen saknas eller det inte entydigt framgår vilket paket det är, stoppas distributionen tills paketet har klarlagts, i stället för att byta namn på en fil eller anta stöd för moderna plattformar.

För en interaktiv installation körs setup.exe från paketet som hämtats från den aktiva brandväggen. Sophos dokumenterar följande kommando för en obevakad distribution:

msiexec /qr /i SophosOutlookAddInSetupUTM.msi T=1 EC=3 C=1 I=1

Den offentliga kompatibilitetslistan är påfallande gammal: SFOS-hjälpen dokumenterar följande historiska förutsättningar för obevakad installation av SPX Outlook Add-in: Windows XP, Windows Vista, Windows 7 eller Windows 8, samtliga i både 32-bitars- och 64-bitarsversion; Microsoft Outlook 2007 SP3, 2010 eller 2013, även dessa samtliga i både 32-bitars- och 64-bitarsversion; Microsoft .NET Framework 4 Client Profile samt Microsoft Visual Studio 2010 Tools for Office Runtime 4.0. Av detta går det inte att dra slutsatsen att aktuella Microsoft 365 Apps eller moderna Windows-versioner stöds. Före en bred utrullning kontrolleras därför det faktiskt hämtade paketet, Windows- och Outlook-versionerna inklusive respektive bitversion, en positiv och en negativ SPX-utlösare samt avinstallationen på en pilotenhet. De MSI-parametrar som inte förklaras ändras inte på måfå.

Den aktuella Sophos-hjälpen använder två olika stavningar av headern för andra e-postklienter: X-Sophos-SPXEncrypt: yes på mallsidan och X-Sophos-SPX-Encrypt: yes på den allmänna Encryption-sidan. Den här skillnaden behandlas inte som ett färdigt copy-paste-recept. Före produktionsutrullning måste det verifieras vilken stavning som fungerar på den använda SFOS-builden. Där det är möjligt är en policy, Data Control eller Sophos Outlook Add-in en mer spårbar utlösare.

Utforma aviseringen utan att skapa ytterligare en dataläcka

Tillgängliga aviseringsvariabler omfattar bland annat:

• %ENVELOPE_TO%: mottagare av lösenordet.
• %PASSWORD%: lösenord för att öppna SPX-PDF-filen.
• %ORGANIZATION_NAME%: organisationsnamn som angetts i mallen.
• %SENDER%: avsändare av e-postmeddelandet.
• %REG_LINK%: länk för lösenordsregistrering.

Enkel HTML-formatering och länkar stöds. Texten måste förklara vem som skickade meddelandet, hur lösenordet hämtas säkert och hur länge registrering eller svar är möjliga. Inloggningsuppgifter eller konfidentiellt e-postinnehåll ska inte dessutom placeras i en oskyddad avisering.

Reset återställer standardaviseringen. Spara anpassade texter först; kontrollera ämnesrad, meddelandetext och mottagarinstruktioner igen efter återställningen.

Ange giltighetstider och felaviseringar

Tider och mottagare av felaviseringar anges under Email > Encryption > SPX configuration, inte under SPX portal settings:

• Keep unused password for: Giltighet för ett lagrat lösenord när inget SPX-meddelande skickas till den mottagaren. Med tre dagar anger hjälpen exempelvis att lösenordet löper ut vid midnatt i slutet av den tredje dagen. Detta är en inaktivitetsperiod, inte en generell livslängd för varje PDF.
• Allow secure reply for: Antal dagar då mottagaren kan svara via SPX Reply Portal; inställningen hör till MTA-proceduren.
• Allow password registration for: Period efter vilken registreringslänken löper ut. Den är skild från perioden för lagrade lösenord.
• Send error notification to: Ansvariga mottagare av SPX-felaviseringar. Felmeddelandena visas också i SMTP-loggen.

Välj tider utifrån organisationens behov av svar och säkerhetsregler. Testa registrering, lösenordsinaktivitet och svarsfrist separat i piloten. Att något löper ut på brandväggen bevisar inte att en redan levererad PDF har raderats eller inte längre går att öppna.

Skydda SPX-portalerna

Lösenordsregistrering och portalåtkomst definieras under Email > Encryption > SPX portal settings:

1. Ange under Hostname det FQDN som externa mottagare faktiskt använder för att nå portalen.
2. Ange endast nödvändiga källnätverk under Allowed networks. Any är bara lämpligt när valfria externa mottagare måste nå portalen och risken medvetet accepteras.
3. Dokumentera porten. Password Registration Portal använder som standard TCP 8094.
4. Använd en separat port för SPX Reply Portal.

Om Allowed networks lämnas tomt använder SFOS Any, eftersom SPX Reply Portal är aktiverat som standard i WAN-zonen. Om Reply Portal inte behövs beskriver Sophos som avstängningsmetod att ange en oanvänd betrodd privat adress, exempelvis 169.254.0.1, som enda tillåtna nätverk. Detta dokumentationsvärde får inte motsvara en adress som används i produktion.

CAPTCHA är alltid aktivt på SPX Portal och kan inte inaktiveras. Hantera CAPTCHA på Sophos Firewall medvetet förklarar gränserna för CAPTCHA-inställningarna på andra portaler.

WebAdmin, User Portal, VPN Portal, Captive Portal och båda SPX-portalerna använder samma centrala certifikatval. En ändring kan därför påverka flera tjänster samtidigt. Planera certifikat, SAN, återställningsväg och verklig portal-URL enligt Hantera certifikat på Sophos Firewall. Ett Let’s Encrypt-certifikat på Sophos Firewall kan passa ett publikt namn.

Valet finns under Administration > Admin and user settings > Admin console and end-user interaction > Certificate. Certifikatidentiteten i SAN eller CN måste matcha portalens FQDN som anges under Hostname, och hela CA-kedjan måste finnas på brandväggen. Behandla därför inte ett certifikatbyte som en ren SPX-ändring: kontrollera även WebAdmin och de andra portalerna efter bytet.

Koppla mallen till SMTP-policyn

För MTA mode väljs SPX-mallen i den matchande policyn SMTP route and scan under Email > Policies and exceptions.

Använd en domän som utlösare

Under Domains and routing target tilldelas mallen den skyddade domänen. Därefter gäller den för matchande utgående meddelanden. En bred domäntilldelning testas först med en pilotavsändare och en extern testmottagare.

Använd Data Control som utlösare

En Data Control List är inte en fritt formulerad innehållsregel. Den byggs av Sophos Content Control Lists, eller CCL:er, för definierade datamönster. När listan skapas filtreras CCL:erna efter Type och Region. I piloten ingår bara de mönster som faktiskt behövs, så att ett för brett urval inte utlöser SPX-leverans i onödan.

1. Skapa en tydligt namngiven lista under Email > Data control list eller kontrollera den befintliga listan.
2. Aktivera Data protection i policyn SMTP route and scan och välj exakt denna lista under Data control list.
3. Ställ in Data control list action på Accept with SPX och välj planerad SPX template. Accept levererar utan SPX, medan Drop kasserar meddelandet utan att avisera avsändaren.
4. Genomför ett positivt innehållstest och ett liknande negativt test.

Om en SPX-mall redan är inställd under Domains and routing target har den företräde framför Data Control-mallen. En träff i Data Control List bevisar dessutom bara den konfigurerade innehållsmatchningen. Det verkliga e-postflödet måste visa om rätt meddelande krypterades.

Använd en avsändarutlösare

Välj en Default SPX template under Email > Encryption > SPX configuration. Den gäller endast avsändarutlöst SPX-kryptering om SMTP-policyn inte redan ger en mall på domän- eller Data Control-nivå. None inaktiverar denna standardväg.

För MTA mode kräver hjälpen uttryckligen en konfigurerad SMTP route and scan-policy och att mallen väljs under Domains and routing target eller Data control list. Den anger example.com som dummy-domän om ingen skyddad domän ska anges. Detta är ett dokumentationsexempel, inte en produktiv e-postdomän eller ett generellt tillstånd för relay eller routing. Policytilldelningen och båda testfallen måste vara korrekta även i detta specialfall. Den allmänna beskrivningen av standardmallen bevisar inte att MTA kan fungera utan SMTP-policy. None inaktiverar bara standardvägen, inte en SPX-tilldelning i en policy.

Automatisera SPX via XML API

Vid återkommande ändringar kartläggs först e-postläge, befintliga mallar och deras policy- respektive standardtilldelningar. XML-referenserna för SFOS 22 och 23 skiljer mellan Legacy- och MTA-objekt; identiska fältnamn gör inte deras payloads utbytbara. Uppgifterna nedan förklarar det dokumenterade kontraktet, men utgör varken en körbar skrivbegäran eller bevis på ett laboratorietest. Tillåtna källor, ett tjänstekonto med minimala behörigheter, TLS-kontroll, explicit operation, säkerhetskopiering och utvärdering av XML-status i stället för HTTP-status beskrivs under Begränsa XML API-åtkomst säkert och kontrollera svar. Bekräfta det fullständiga objektkontraktet i API help för den installerade builden före skrivning; olösta motsägelser får inte överbryggas med en gissad payload.

Global konfiguration: skilj mellan Legacy och MTA

Legacy: Det dokumenterade exemplet nästlar SPXConfiguration två gånger: ett yttre SPXConfiguration som innehåller ytterligare ett SPXConfiguration. Det inre elementet innehåller SPXGlobalTemplate med DefaultSPXTemplate; bredvid finns HostName, AllowedNetworks med upprepningsbara Network-poster, Port, KeepUnusedPassFor, AllowPassRegistrationFor och SendNotifcationErrorTo. Ta inte bort den dubbla nivån som ett förmodat skrivfel och använd inte exemplet som ett generellt MTA-schema.

MTA: Det separata objektet heter MTASPXConfiguration. Dess exempel innehåller direkt SPXGlobalTemplate med DefaultSPXTemplate samt värdnamn, port, lösenordsfrister och felavisering, utan den dubbla Legacy-nästlingen. För båda kontrakten anger parametertabellen Network, DefaultSPXTemplate och HostName som valfria strängarrayer; detta bekräftar inte någon godtyckligt konstruerad arraystruktur. Portalens FQDN och tillåtna källor stäms av mot portal- och certifikatkontrollerna ovan. MTA-exemplets värde None för HostName bevisar inte att läget är säkert avstängt.

De obligatoriska parametrarna är KeepUnusedPassFor (antal dagar dokumenterat som en sträng, standardvärde 30), AllowPassRegistrationFor (antal dagar som heltal, standardvärde 10), Port (heltal, standardvärde 8094, intervall 1025 till 65535) och SendNotifcationErrorTo. Stavningen SendNotifcationErrorTo lämnas oförändrad trots den saknade bokstaven. Tillåtna token är SenderOnly och Nobody; Legacy-exemplet och visningen av standardvärdet anger däremot Sender Only. Normalisera inte denna avvikelse utan att påtala den och dra inte slutsatsen att något av de två värdena är ett testat XML-värde enbart utifrån visningen. Stoppa skrivjobbet om kontraktet för den använda builden är oklart.

Endast MTA-tabellen anger dessutom AllowSecureReplyfor som ett obligatoriskt fält för svarsfristen (antal dagar som sträng, standardvärde 30). Just detta fält saknas i MTA-exemplet. Exemplet är därför inte ett fullständigt belägg för en produktionsklar begäran; utelämna inte svarsfristen utan kontroll och hitta inte på en stavning med andra versaler eller gemener. Global mall, lösenordsinaktivitet, registrering och svarsfrist förblir separata beslut; inget av dem ersätter SMTP-policytilldelningen.

För Update SPX Configuration i Legacy-kontraktet dokumenteras följande XML-statusmappningar:

MTA-kontraktet för samma operation anger däremot 200 med Operation Successful. och 500 med Operation Fail.. Presentera inte Legacy-koden 541 som ett MTA-svar dokumenterat där. Vid Legacy-mappningen 541 ska den faktiska portanvändningen och den lagrade portalporten kontrolleras först, i stället för att upprepa jobbet oförändrat eller ändra SMTP TLS.

Mallar: skydda identitet, värden och avisering

För Legacy dokumenteras SPXTemplates, för MTA MTASPXTemplates. Name är den obligatoriska unika mallidentiteten med högst 255 tecken och stäms av exakt mot det befintliga objektet före uppdatering eller borttagning. Description och OrganizationName är valfria strängar; även för OrganizationName gäller högst 255. En ny beskrivningstext är inget skäl att blint skapa ett nytt objekt med samma namn.

Båda kontrakten kräver PDFEncryption, PageSize och PasswordType. De exakta valbara värdena är:

• PDFEncryption: AES/128 eller AES/256.
• PageSize: A/4, Letter eller Legal. Det visade standardvärdet A4 är inte det dokumenterade valbara tokenvärdet A/4.
• PasswordType: SpecifiedBySender, GeneratedOneTimePasswordForEveryEmail, GeneratedAndStoredForRecipient eller SpecifiedByRecipient. Det visade standardvärdet Specified by sender är ingen rekommendation om XML-token.

NotificationSubject, NotificationBody och InstructionsForRecipient är valfria strängar. Enligt kontraktet är de två aviseringsfälten endast tillämpliga på modeller med genererade lösenord respektive lösenord som registreras av mottagaren, inte på SpecifiedBySender. Endast MTA-mallen lägger till SPXReplyPortal och IncludeOriginalBodyIntoReply: båda är valfria, med standardvärdet Disabled och de tillåtna värdena Disabled eller Enable. Exemplet Enable/Disabled är en notation för valalternativ, inte ett enskilt värde som ska skickas. Förväxla inte kravet på Reply Portal i MTA-GUI-proceduren ovan med det valfria API-fältet och dess standardvärde.

Aviseringstexter lokaliseras, medan tekniska platshållare bevaras oförändrade. API-exemplen visar dessutom %CURRENT_RECIPIENT% samt i ämnesraden %%ENVELOPE_TO%% respektive %%ORGANIZATION_NAME%%; skriv inte automatiskt om dessa till variablerna med enkla procenttecken som anges ovan. Säkerhetskopiera den faktiskt lagrade mallen före en ändring och kontrollera variabelersättningen med ett nytt testmeddelande. Standard-HTML, historiska anvisningar om PDF-läsare och exempellösenord från referensen är ingen obligatorisk förlaga för egna aviseringar. HTML, citattecken och radbrytningar måste serialiseras kontrollerat och verifieras efter att de sparats. Använd inte heller |n, som syns i MTA-exemplet, som en universell escape-metod utan buildspecifik bekräftelse.

För Legacy- och MTA-mallar överensstämmer de dokumenterade mappningarna:

Message.*-identifierarna förblir oupplösta meddelandenycklar i referensen, inte verifierade texter som visas vid körning. Vid 502 ska den exakta identiteten och det befintliga innehållet kontrolleras; växla inte automatiskt från Add till Update. Vid Update-541 ska de faktiska Spam-/Data Control- och SPX-tilldelningarna undersökas, utan att härleda en universell konfliktmekanism från symbolen. Vid Delete-504 ska referenserna i policyer och global konfiguration klarläggas först; återställningsordningen nedan gäller fortfarande. Stäm av svaret mot det faktiskt lagrade tillståndet före varje nytt försök och kontrollera målobjektet även efter 200. Först med ett nytt positivt och ett nytt negativt testmeddelande samt lösenords- och svarstest kan effekten i drift godkännas.

Validera det krypterade e-postflödet

Notera testtid, avsändare, mottagare, ämne och förväntad utlösare. Testa sedan minst följande fall:

1. Positivt test: Ett utgående meddelande utlöser exakt den planerade SPX-mallen.
2. Lösenordstest: Mottagaren får lösenordet eller registreringslänken via den planerade kanalen och kan öppna PDF-filen.
3. Innehållstest: Ämne, meddelandetext och bilagor finns i PDF-filen som förväntat och är läsbara.
4. Svarstest: Om funktionen är aktiverad leder svarslänken till förväntat FQDN och ett testsvar når den ursprungliga avsändaren.
5. Negativt test: Ett liknande meddelande utan utlösare skickas inte som SPX-PDF.
6. Utgångstest: Registrering, lagrat lösenord och svarsperiod beter sig förutsägbart efter den angivna giltighetstiden.
7. Certifikattest: Webbläsaren och den externa mottagaren får en fullständig betrodd certifikatkedja för det portal-FQDN som används.

Börja korrelationen under Email > Mail logs. Under Reason identifierar SPX encryption SPX-krypterade meddelanden och SPX failure SPX-meddelanden som inte levererats; under Result kan man filtrera vidare på exempelvis Delivered, Dropped eller Quarantined. Matcha avsändare, mottagare, ämne och tidsintervall mot testanteckningen. För detaljfel fortsätter man med Log Viewer och MTA-filerna smtpd_main.log, smtpd_error.log och smtpd_panic.log. Sophos Firewall-tjänster och loggar beskriver åtkomst och ytterligare loggfiler.

SPX failure är inte ett annat namn för SMTP-karantän. Ett meddelande visas under Email > SMTP quarantine endast om en Spam-, Malware-, Unscannable-, DKIM- eller annan policyåtgärd faktiskt har satt det i karantän. Frisläpp inte ett meddelande under testet innan orsak och utlösande policy har dokumenterats; annars kan ett skannings- eller policyfel förväxlas med ett SPX-fel.

I HA finns loggarna på den nod som behandlade trafiken. Efter en kontrollerad failover testas ett nytt SPX-meddelande, lösenordsregistrering och svar separat. Utgå inte från att en befintlig portalsession eller en pågående registrering fortsätter utan avbrott. Grunderna finns i Sophos Firewall HA-kluster.

Avgränsa fel systematiskt

Meddelandet krypteras inte

Kontrollera riktning, skyddad domän, den SMTP route and scan-policy som faktiskt används och utlösarprioritet. För Data Control kontrolleras även Data protection, vald Data control list, Data control list action: Accept with SPX och tillhörande SPX template. För en avsändarutlösare måste en standardmall vara inställd och får inte åsidosättas av en domän- eller Data Control-mall. De två dokumenterade headerstavningarna är ingen anledning att distribuera båda otestade i produktion.

Mail logs visar SPX failure

Avgränsa den berörda raden under Email > Mail logs efter tid, avsändare, mottagare och ämne och bekräfta Reason: SPX failure. Korrelera det visade felet med smtpd_main.log, smtpd_error.log och vid allvarliga processfel smtpd_panic.log vid samma tidpunkt. Ändra först därefter lösenordsmodell, mall, leverans eller portalväg. Om Result i stället är Quarantined undersöks den utlösande skannings- eller policyåtgärden under Email > SMTP quarantine.

Registreringslänken eller portalen går inte att nå

Kontrollera FQDN, publik DNS-upplösning, port, certifikat, Allowed networks och länkens giltighet. Ett tomt Allowed Networks-värde behandlas som Any och är därför inte ett säkert avstängt läge. Om klienten når en annan värd eller portal stämmer URL, NAT eller certifikattilldelning inte med den planerade vägen.

PDF-filen går inte att öppna

Matcha först lösenordstypen med det specifika meddelandet. Ett engångslösenord gäller bara för detta e-postmeddelande. För lagrade eller registrerade lösenord kan utgång eller flera lösenordsmodeller vara orsaken. Efter en SPX Password Reset måste avsändaren på nytt överföra det nya lösenordet säkert till mottagaren.

För en riktad återställning anges den berörda mottagarens e-postadress under Email > Encryption > SPX password reset och kontrolleras innan återställningen startas. Samordna återställningen och den säkra överföringen av det nya lösenordet med avsändare och mottagare och öppna därefter ett nytt SPX-testmeddelande. Detta garanterar inte att äldre PDF-filer kan öppnas med det nya lösenordet.

Det säkra svaret kommer inte fram

Kontrollera Enable SPX reply portal i mallen, svarsperiod, portal-FQDN, port, certifikat och tillåtna källor. Kontrollera därefter Mail logs och MTA-loggar för det konkreta svaret. Att PDF-filen öppnas korrekt bevisar inte att returkanalen fungerar.

DKIM-validering misslyckas efter SPX

SPX ändrar meddelandetext och bilagor. Om ett meddelande signeras före denna ändring kan signaturen bli ogiltig hos mottagaren. Fastställ om den interna e-postservern, Sophos Firewall eller en senare gateway signerar efter alla planerade ändringar. Behandlingskedjan och ett externt test måste valideras tillsammans.

Återställ säkert

1. Ta först bort den specifika SPX-tilldelningen från Domains and routing target. För en Data Control-utlösare återställs Data control list action i SMTP-policyn från Accept with SPX till den dokumenterade föregående åtgärden.
2. Ställ vid behov in Default SPX template på None.
3. Genomför ett utgående negativt test och bekräfta att ingen ny SPX-PDF skapas.
4. Ta bara bort Reply och Registration Portal om ingen annan aktiv SPX-policy är beroende av dem.
5. Återställ tillfällig publik port-, DNS- eller portalåtkomst till dokumenterat tidigare läge. Återställ separat ändrade SMTP TLS-krav endast mot deras eget dokumenterade tidigare läge.
6. Ta bort mallen först när ingen policy eller aktiv driftprocess längre refererar till den.
7. Bevara Mail logs och MTA-loggar för det sista krypterade och första okrypterade testet.

Skapa en aktuell Sophos Firewall-säkerhetskopia innan produktionsvägar för e-post och portaler ändras. SPX kan fortsätta fungera i airgap-miljöer, men externa DNS-, certifikat- och portalberoenden måste vara nåbara separat. Produktgränserna beskrivs i SFOS-funktioner utan internetåtkomst.

Checklista för drift

• Licens, modell, MTA-e-postflöde och extern mottagare har kontrollerats.
• Utlösare och utlösarprioritet är dokumenterade.
• Lösenordstyp och säker överföringskanal passar användningsfallet.
• Portal-FQDN, centralt portalcertifikat, port och Allowed Networks är snävt avgränsade; SMTP TLS dokumenteras separat.
• Domän-, Data Control- eller standardtilldelningen är entydig.
• Positiva, negativa, lösenords-, PDF- och svarstester har godkänts.
• Filtren SPX encryption och SPX failure i Mail logs samt MTA-loggarna kan korreleras med testmeddelandet; karantänåtgärder skiljs från dem.
• HA-failover och nodlokala loggar ingår i driftsrutinen.
• Ansvarig, giltighetstider, granskningsdatum och återställning är dokumenterade.

FAQ