Sig godnat
til din sidste
Exchange Server.
SMTP-relayet til Microsoft 365. Dine printere, scannere og apps sender videre, og serveren får endelig lov at sove.
Endnu ikke udgivet. Preview kommer snart.
Sendman er det politikhåndhævende SMTP-relay til Microsoft 365, bygget til alle de printere, scannere og applikationer, der kun taler almindelig SMTP. Det autentificerer dem mod Microsoft Entra ID, afgrænser dem efter IP-adresse og afsenderpolitik og afleverer mailen til Exchange Online eller den leveringstjeneste, du allerede bruger — så den sidste on-premises Exchange Server ikke har mere at lave.
PROBLEMETServeren, der kun findes for printernes skyld
I næsten alle organisationer står der én Exchange Server tilbage. Ingen læser mail på den. Den kører stadig, fordi en scanner, en natlig ERP-eksport og et alarmpanel skal kunne sende, og det eneste, nogen af dem kan, er at åbne en port og autentificere sig.
Fire blindgyder
Alle har prøvet mindst én af dem. Ingen af dem holder.
- 01
Behold Exchange Server i drift
Du patcher en mailserver, så en scanner kan sende en PDF pr. e-mail. Hver Exchange-sikkerhedsadvarsel er nu din weekend.
Blindgyde: Serveren bliver - 02
Åbn et uautentificeret internt relay
Alt, der kan nå connectoren, kan sende som hvem som helst i dit domæne. Ingen identitet, ingen afsenderkontrol, intet at auditere bagefter.
Blindgyde: Kontrollen er væk - 03
Læg én postkasseadgangskode på 200 enheder
Den kan ikke roteres uden at besøge hver enkelt enhed, og en kopi af den sidder på en seddel i kopirummet.
Blindgyde: Kontrollen er væk - 04
Peg alt mod en bulk-afsendelsestjeneste
Leveringen virker. Intet på vejen kontrollerer, hvem der sender som hvem, eller til hvem, og den delte API-nøgle svarer til en sendetilladelse for hele domænet.
Blindgyde: Kontrollen er væk - 05 · Udvejen
Alle fire er den samme byttehandel. Enten holder du en mailserver i live for enhedernes skyld, eller også opgiver du kontrollen over, hvem der må sende som hvem. Sendman er den mulighed, der afviser byttehandlen.
Udvej: Serveren væk, kontrollen beholdt
Erstat relay-funktionen i on-premises Exchange
Routing til Exchange Online eller eksterne leveringstjenester
Ældre SMTP-logins, moderne identiteter
Adskilt routing pr. domæne
Behold din eksisterende opsætning
Én session, fra ende til anden
Sendman sidder i selve SMTP-samtalen, ikke ved siden af den. Der er fem øjeblikke, hvor det træffer en beslutning. Vælg et af dem, og se, hvilken del af udvekslingen det styrer.
Tre politikker. Skift ud, hvem der banker på.
Det her er den rigtige evalueringsrækkefølge, kørt live: tilladelseslisten, derefter de politikker, der gælder for denne identitet og denne adresse, derefter afsenderen og derefter hver modtager for sig. Ændr en hvilken som helst af de fire, og se, hvad relayet svarer.
Politik 10 er afgrænset til svc-scan@contoso.com fra 198.51.100.24. scan@contoso.com matcher dens tilladte afsendere, og accounting@contoso.com matcher dens tilladte modtagere, så Sendman åbner sin egen session til backenden og afleverer beskeden uændret.
De politikker, der evalueres
Global tilladelsesliste: 198.51.100.16 – 198.51.100.31, 192.0.2.128 – 192.0.2.143
svc-scan@contoso.com, fra hovedkontoret
senders: scan@contoso\.com
receivers: .*@contoso\.com
mfp-3f, fra hvor som helst på tilladelseslisten
senders: .*@contoso\.com
receivers: .*@contoso\.com
Enhver enhed på hovedkontoret, uden login
senders: noreply@contoso\.com
receivers: .*@contoso\.com
Politikker udvælges efter scope og reduceres derefter til det laveste prioritetsnummer, der gælder. Politikker med samme prioritet flettes, så en enhed kan få rettigheder fra flere regler på én gang.
Exchanges sidste opgave, plus kontrol
Ældre enheder har brug for tre ting for at blive ved med at virke: en port at tale til, en autentificeringsmekanisme, de forstår, og tilladelse. Sendman giver dem alle tre og lægger den tredje under din kontrol.
Entra ID-autentificering
Brugernavne og adgangskoder virker videre, som de er, valideret mod Microsoft Entra ID, uden app-registrering, uden samtykke, uden ændringer i din tenant og uden et directory, der skal synkroniseres.
Hybride logins virker, som de er
En enhed, der blev konfigureret med
CONTOSO\svc-scanfor år tilbage, virker stadig. Sendman oversætter domæne-loginet til den rigtige Entra-bruger, så intet skal tastes om på enheden, og ingen behøver gå ud til printeren.
Din egen credential vault
Til enheder, der ikke bør have en directory-identitet, udsteder du i stedet en Sendman-credential. Gemt med AES-256-GCM, sammenlignet i konstant tid, aldrig vist igen, og det samme gælder din backend-adgangskode.
LOGIN, PLAIN og NTLM
De tre mekanismer, gammel hardware faktisk implementerer, inklusive NTLM, som næsten intet andet foran Microsoft 365 stadig taler. Hver enkelt kan slås fra uafhængigt.
En global IP-tilladelsesliste
Områderne evalueres i samme øjeblik, en forbindelse accepteres, før SMTP-hilsnen og på port 465 endda før TLS-handshaket. Alt andet når aldrig frem til samtalen, endsige autentificeringen.
Politikker med prioriteter
Afgræns en regel til et brugernavn, et IP-område eller begge dele. Det laveste prioritetsnummer, der gælder, vinder; regler med samme prioritet flettes, så en enhed kan arve rettigheder fra mere end én.
Afsender- og modtagerkontrol
Regulære udtryk på begge sider, håndhævet ved
MAIL FROMog ved hverRCPT TO. Ingen sender som direktøren, og intet bliver et åbent relay ved et uheld.
Anonymt relay, med vilje
Nogle enheder kan simpelthen ikke autentificere sig. De får en smal bane, der skal slås til bevidst, er afgrænset til et IP-område og stadig er bundet af afsender- og modtagerregler.
TLS på alle porte
Implicit TLS på 465, STARTTLS på 25 og 587, med et certifikat udstedt til dig eller et, du selv medbringer, fornyet uden genstart. Videre til backenden er sessionen krypteret overalt, hvor backenden understøtter det.
Enhver backend, du sender igennem
Exchange Online uden SMTP AUTH, upåvirket af Microsofts udfasning af Basic Authentication, eller Azure Communication Services og andre transporttjenester. At skifte er en indstilling, ikke en ny udrulning.
Aktiv ved næste forbindelse
Konfigurationen læses forfra for hver session, der åbnes. Redigér en politik, og den næste enhed, der forbinder, er allerede omfattet af den. Ingen genstart, intet ændringsvindue, ingen cache at vente på.
Metrikker, du kan alarmere på
Hver session efterlader et spor: autentificeringer, leveringer, sessionstider, søgbare i portalen og klar til alarmer. En enhed, der er holdt op med at sende, er en forespørgsel væk, ikke en supportsag.
Roller, der betyder det, de siger
Viewers ser alle regler og ændrer ingen; admins ændrer konfigurationen. Håndhævet af tjenesten ved hver forespørgsel, og hver post registrerer, hvem der oprettede den. Politikker registrerer også, hvem der sidst ændrede dem.
Søgbar hændelseslog
Hver autentificeringsfejl og politikovertrædelse, filtrerbar efter bruger, adresse, afsender og modtager, med den regel, der afviste den, navngivet i posten. ”Hvorfor bouncede den” kræver én søgning.
På roadmappetSniff Mode
Åbn et capture-vindue, og se præcis, hvad en enhed præsenterer: kildeadressen, det brugernavn, den tilbyder, den afsender, den hævder at være. Til den printer, ingen har adgangskoden til, og ingen leverandør længere understøtter.
Specifikationer
De navne og tal, en admin spørger om før den første testmail.
Forbindelse
- Porte
- 25 og 587 med STARTTLS, 465 med implicit TLS
- Certifikat
- Udstedt til dig eller medbring dit eget, fornyet uden genstart
- Tilladelsesliste
- IPv4-adresseområder, op til 16.384 adresser hver
Autentificering
- Mekanismer
- LOGIN, PLAIN, NTLM
- Identitetskilder
- Microsoft Entra ID (inklusive hybride DOMAIN\user-logins), Sendman credential vault
- Vault-kryptering
- AES-256-GCM
Politikker
- Scope
- Brugernavn, IP-område eller begge dele
- Prioriteter
- Laveste nummer vinder, lige prioriteter flettes
- Afsender- og modtagerregler
- Regulære udtryk, håndhævet ved MAIL FROM og hver RCPT TO
- Anonymt relay
- Pr. politik, bundet til et IP-område
Levering
- Backends
- Exchange Online (uden SMTP AUTH), Azure Communication Services, andre SMTP-transporttjenester
- Beskedstørrelse
- Op til 25 MB pr. besked (din backend tillader muligvis mindre)
- Håndtering
- Sendes uændret videre, ingen kø, ingen kopi gemt
Drift
- Konfiguration
- Platform Portal, aktiv ved næste forbindelse
- Roller
- Viewer, admin
- Telemetri
- Søgbar i portalen
- Inkluderet
- Alle opdateringer, incident-support
- Certificering
- Vores udviklings- og driftsteams er certificerede efter ISO 27001
Hvorfor pensionere den sidste Exchange Server
Når Sendman har overtaget relayet, kan serveren gå. Her er, hvad du vinder.
En mindre angrebsflade
On-premises Exchange er en af de mest angrebne workloads, der findes. Når den sidste server er væk, er der ingen Exchange-CVE tilbage at patche i weekenden og ingen zero-day rettet mod din perimeter.
Intet tilbage på internettet
OWA, ECP, Autodiscover og Exchange-webtjenesterne forsvinder fra din edge. Ét indgangspunkt mindre til initial access, ét mål mindre for remote code execution.
Ikke mere Exchange-patching
Ingen kumulative opdateringer og sikkerhedsopdateringer at teste, installere og overvåge, ingen vedligeholdelsesvinduer til dem, og ingen Exchange Server tilbage, der kan komme bagud, når den næste kritiske rettelse lander.
Ingen næste migrering
Exchange 2016 og 2019 mistede support i oktober 2025, og Subscription Edition er den næste opgradering i kalenderen. Uden en server er der ingen næste migrering at planlægge, finansiere eller overleve.
Ét privilegeret system mindre
Exchange er dybt forankret i AD og højt privilegeret. At fjerne det tager et primært mål for credential-tyveri af bordet, og efter SOA-overførslen forlader det meste af dets aftryk også AD.
Mindre at drive
Ingen overvågning, backup, certifikater, storage eller VM'er at køre for Exchange, og intet separat disaster recovery-koncept at skrive, teste og holde opdateret. Én workload mindre på hver tjekliste.
En renere arkitektur
Messaging er Exchange Online, punktum. Intet hybrid-særtilfælde og færre komponenter at tjekke, når mailflow, Autodiscover, modtagere eller autentificering driller.
Mindre viden at holde på
Ekspertise i on-premises Exchange bliver sjældnere og dyrere. Uden en server at passe behøver du hverken fastholde den eller købe den ind, når den ene person, der har den, er på ferie.
Klarere roller, lavere omkostninger
Mindre infrastruktur, drift, backup, overvågning og administration. Microsoft driver platformen, du administrerer Exchange Online, og grænsen mellem de to er endelig klar.
Tre trin, og én server du kan slukke
- Peg Sendman mod din backendPeg Sendman mod din backendVælg Exchange Online, Azure Communication Services eller den host, du allerede sender igennem, og indtast det, den har brug for. Én formular i portalen og ingen ny udrulning, når den ændres.
- Luk enhederne ind, og fortæl, hvad de måLuk enhederne ind, og fortæl, hvad de måTilføj de områder, de forbinder fra, udsted vault-credentials til de enheder, der ikke bør have en directory-identitet, og skriv derefter politikkerne for, hvem der må sende som hvad, og til hvem.
- Ompeg DNS, pensionér serverenOmpeg DNS, pensionér serverenPeg det hostnavn, dine enheder sender til, mod Sendman i stedet for Exchange Server. Ideelt set er det alt, der skal til. Ikke en eneste enhed røres, og Exchange Server har ikke mere at lave.
De spørgsmål, der kommer først
Det, admins spørger om, før den første testmail går igennem.
01Gemmer Sendman vores e-mail?
Nej. Det proxyer SMTP-sessionen og sender den videre, som den ankommer. Der er ingen postkasse, ingen kø, ingen spool og intet arkiv, og selve beskeden sendes uændret videre, headers inklusive. Det eneste, Sendman gemmer, er din konfiguration.
02Skal vi registrere noget i vores Entra-tenant?
Nej. Sendman validerer enhedernes legitimationsoplysninger mod Microsoft Entra ID uden app-registrering, uden samtykke og uden at ændre noget i din tenant. Hybride logins som CONTOSO\svc-scan virker, som de er.
03Hvad med multifaktorautentificering på de konti?
Ingen af delene kommer i vejen. En vault-credential rører aldrig dit directory, så der er intet at bede om. Entra ID-konti virker også: multifaktorautentificering og Conditional Access står ikke i vejen, selv med strikse politikker, og enheden ser aldrig en prompt. Hvad en konto må sende som, og til hvem, er ikke en postkassetilladelse i Exchange Online, men en Sendman-politik: afsender- og modtagerregler afgør det, for vault-credentials og Entra ID-konti på samme måde.
04Hvad hvis en enhed slet ikke kan TLS?
Den kan stadig forbinde på en ukrypteret port, og identitet, IP og politik håndhæves på præcis samme måde. Om du accepterer et ukrypteret første hop fra den enhed, er din beslutning; tilladelseslisten begrænser det til dine egne egress-adresser, og fra Sendman og videre er sessionen krypteret overalt, hvor backenden understøtter det.
05Hvad sker der med SPF, DKIM og DMARC?
De hører til det domæne, du sender fra, og håndteres af den backend, der faktisk leverer, Exchange Online eller Azure Communication Services. Sendman omskriver hverken din envelope eller dine headers, så det, du har sat op for den backend, virker præcis som i dag.
06Hvad sker der, hvis Sendman ikke kan nå sin konfiguration?
Forbindelser afvises med et midlertidigt ”service not available”-svar, der fortæller en velopdragen afsender, at den skal holde på beskeden og prøve igen, så et storage-hikke forsinker mail i stedet for at miste den.
07Kan vi beholde Exchange Online som backend?
Ja. Mange organisationer beholder Exchange Online som leveringsvej og bruger Sendman til det autentificerings- og politiklag, deres enheder har brug for. Backenden kan ændres senere uden at røre en eneste enhed.
08Hvor ligger vores konfiguration, og hvem kan se den?
I storage, der er isoleret til din tenant. Legitimationsoplysninger krypteres, før de skrives. Adgang til portalen kommer fra din platform-tenant, viewers ser alle regler og ændrer ingen, admins ændrer konfigurationen, og hver post på tilladelseslisten, hver politik og hver credential registrerer, hvem der oprettede den.
09Hvordan finder vi ud af, hvad en enhed faktisk sender?
Hver autentificeringsfejl og politikovertrædelse lander i den søgbare hændelseslog med den regel, der afviste den, navngivet i posten, og det svar, enheden modtager, fortæller dig, hvilket trin der afviste den. Sniff Mode, et capture-vindue, der viser præcis, hvad en enhed præsenterer, dens kildeadresse, det brugernavn, den tilbyder, og den afsender, den hævder at være, er på roadmappet.
Mød os personligt
Sendman er på farten i efteråret. Kig forbi, tag din printerhistorie med, og se relayet i aktion.
Workplace Ninja Summit
Community-konference i Baden om Microsoft Endpoint Management og Security
it-sa
Mød os igen i år på Europas førende messe for IT-sikkerhed
Cloud-baseret RADIUS-tjeneste RADIUSaaS
Cloud-native certifikatmyndighed SCEPman
