Omfattning Ex Libris-autentisering till Almas utgående postrutt
Ex Libris erbjuder flera produkter och leveransarrangemang. Den här guiden täcker Alma-brev och integrationsprofilen Mail Handling som beskrivs i den officiella dokumentationen, inte en universell konfiguration för varje Ex Libris-applikation. Börja med att identifiera om Alma skickar direkt från Ex Libris-molnet, skickar post till ett institutionellt relä eller använder en annan rutt som stöds. Dessa val ändrar vem som kontrollerar sändningsauktorisering, signering och den slutliga utgående anslutningen. En fungerande bibliotekswebbplats eller inkommande brevlåda är inte bevis på att Almas utgående meddelanden är autentiserade.
De Konfigurera Alma Letters dokumentation beskriver relevanta inställningar. Den officiella Konfigurationsartikel för utgående e-post, uppdaterad 24 februari 2026, ger ytterligare direktmoln DKIM detaljer. Bekräfta aktuell hyresgästs tillämplighet innan du ändrar en profil. Inget konto, DNS zon, biblioteksskyddspost eller verkligt meddelande har inspekterats för detta manuskript.
Inventera författarens och kuvertidentiteten separat
Almas dokumentation skiljer den synliga Från-adressen från SMTP EnvelopeFrom. Utvecklarartikeln beskriver en kuvertadress för institutionen, medan brev- och biblioteksinställningar kan tillhandahålla olika synliga författaradresser. Vissa resursdelningsbrev använder bibliotekets föredragna e-postadress, och andra brevkategorier har sina egna undantag. Därför kan en granskning av ett generiskt testbrev inte automatiskt fastställa att varje produktionsmeddelande använder samma författaridentitet.
Skapa en inventering av materialbrevskategorierna, deras effektiva Från-domän och kuvertdomänen som används av den valda transporten. Inkludera operativa undantag såsom resursdelningskorrespondens, anskaffningsmeddelanden och kundmeddelanden där det är relevant. Kopiera inte kundadresser eller cirkulationsdetaljer till inventeringen: syftet är att kartlägga konfiguration och identitetsgränser, inte samla in meddelandeinnehåll. RFC 7208 , avsnitt 2.4 identifierar MAIL FRÅN som en SPF identitet; den synliga Från-domänen är en separat ingång till DMARC inriktning.
Välj integrationsprofil och rutten medvetet
Den dokumenterade sökvägen är Konfiguration, Allmänt, Externa system, Integrationsprofiler, med Mail Handling som integrationstyp. Alma tillåter en integrationsprofil för e-posthantering; en befintlig bör granskas snarare än att anta att en andra oberoende profil kan läggas till för ett litet experiment. Guiden beskriver Skicka direkt från Ex Libris och Skicka med institutionspostrelä, och den listar också ett MS Graph API-alternativ. Den här artikeln konfigurerar inte Graph-program, hemligheter eller behörigheter.
För den institutionella relävägen äger institutionens postoperatörer reläets behörighets- och signeringspolicy. Bekräfta handoff och resulterande identiteter med dem innan du tillämpar molnspecifika DNS instruktioner. För rutten direkt moln, Alma Letters dokumentation kräver SMTP EnvelopeFrom och header.From för att använda samma domän. Kontrollera den exakta domänlikheten för varje effektiv bokstavsförfattaridentitet. Detta är en Alma-implementeringsrestriktion, inte ett påstående om att DMARC generellt kräver exakt likhet: avslappnad DMARC -anpassning kan tillåta olika domäner inom den tillämpliga organisation-domän-relationen. Utvecklarkonfigurationstabellen stöder inte behandling av ett leverantörskuvert med en anpassad författardomän som ett fungerande direktmoln DKIM arrangemang. Bekräfta den aktuella hyresgästen och ruttkraven istället för att anta att en anpassningsmöjlighet på protokollnivå gör en Alma-kombination som inte stöds giltig. Ett godkänt ruttval bör identifiera vem som kan ändra det, vem som kommer att observera leveranskontinuitet och hur den tidigare konfigurationen skulle återställas om ändringen misslyckas. Att publicera en DNS post ändrar inte i sig leveransvägen.
Konfigurera direktmoln DKIM från genererade värden
Alma Letters-guiden beskriver hur du väljer DKIM inställning, erhåller CNAME detaljer, publicera det utfärdade aliaset via institutionens DNS administratör, testa DNS inställningarna och sedan välja DKIM Active efter en lyckad kontroll. Utvecklarartikeln lägger till en viktig förutsättning: nycklar genereras när integrationsprofilen är aktiv, DKIM Setup väljs och profilen sparas. Låt tjänstens dokumenterade genereringsprocess slutföras innan du tolkar en omedelbar frånvaro av nyckeldata som ett permanent fel.
Den publika nyckeln finns i Ex Libris DNS , medan institutionen publicerar den genererade CNAME som pekar på den. Den officiella förklaringen beskriver två nyckelpar som stödjer rotation. Bevara de exakta utfärdade aliasen och målen istället för att uppfinna väljare namn eller kopiering av en annan institutions konfiguration. Att delegera en nyckelplats via CNAME är ett pågående beroende av leverantörens nyckelhantering, inte ett engångsbevis på att alla framtida meddelanden kommer att valideras.
De två källorna använder formuleringarna Testa DKIM DNS Setup och Validera DKIM DNS Setup. Behandla detta som gränssnittsformulering för att bekräfta i det löpande kontot, inte bevis för två olika obligatoriska valideringssystem. DNS validering och DKIM Active är distinkta kontrollpunkter. Ett rekord kan publiceras medan signeringen förblir inaktiv. Omvänt, att aktivera signering reparerar inte en fel DNS ägare eller mål. Behåll den faktiska statusen och dess tid utan att kalla det ett acceptanstest på mottagarnivå.
Granska SPF och justering utan att importera protokollgenvägar
Alma-dokumentationen säger att lämplig SPF inkludering beror på kundens region. Skaffa den tillämpliga regionala auktoriseringen från den aktuella officiella kontokontexten och granska den inom den befintliga policyn. Den här artikeln tillhandahåller inte en antagen universell inkludering eller återanvändbar relä-IP-lista. Håll legitima avsändare representerade tills deras ägande och fortsatta användning har kontrollerats, och undvik att skapa en andra konkurrerande SPF policy hos samma ägare.
RFC 7208 , avsnitt 3.2 och 4.6.4 styra flera SPF rekord och utvärderade DNS-beroende termgränser. Vissa leverantörsförklaringar använder From-terminologin löst; utvärdera SPF mot den faktiska kuvertidentiteten snarare än att tillämpa den stenografin på det synliga författarfältet. RFC 6376 , avsnitt 3.5 definierar signaturens domän och väljare. RFC 9989 , avsnitt 4.4 tillhandahåller anpassningsregeln: ett godkänt autentiseringsresultat måste relatera på lämpligt sätt till författarens domän. En leverantörsägd standardidentitet bevisar inte anpassad domänanpassning.
Behandla Spara och testa som en riktig meddelandeåtgärd
Den officiella dokumentationen förklarar att Spara och testa skickar ett meddelande till den inloggade användarens föredragna e-postadress. Utvecklarartikeln identifierar testbokstaven och säger dess aktiverade tillstånd och adressFrån konfigurationen. Detta är inte en passiv statusuppdatering. Innan en auktoriserad operatör kör det, bekräfta destinationen, använd harmlöst testinnehåll och förstå om åtgärden också sparar en konfigurationsändring.
Ett framgångsrikt test kan ge bevis för den profilen och brevet, men acceptplanen bör innehålla andra väsentligt olika identiteter för produktionsbrev. Använd betrodda mottagarresultat och registrera den faktiska rutten, signeringsdomänen, väljaren och författarens domän. Vidarebefordra inte riktiga kundmeddelanden till en extern diagnostiktjänst bara för att få poäng. Autentiseringsframgång är snävare än placering i inkorgen eller bevis på att en kund har läst ett försenat meddelande. Ingen Save and Test-åtgärd eller annan meddelandeöverföring utfördes här.
Fiktiv diagnos: testbrevet döljer en biblioteksspecifik författare
En fiktiv institution, Cedar Vale Library, validerar sina DKIM alias direkt i molnet och aktiverar signering. Dess allmänna testbrev använder huvudinstitutionens domän, medan ett resursdelningsbrev använder filialbibliotekets föredragna adress på en annan domän. En granskare accepterar initialt hela postportföljen från testresultatet. Identitetsinventeringen avslöjar att filialbrevet låg utanför det testade författare-domänomfånget.
Det föreslagna svaret är att hålla den kategorin olöst, bekräfta dess effektiva adresskälla och besluta om dess identitet ska ändras eller ta emot en autentiseringskonfiguration som stöds separat. Det är inte att anta att en framgångsrik aliassökning täcker varje biblioteksvarumärke. Detta fiktiva fall innehåller ingen riktig hyresgäststatus, beskyddarinformation, meddelandehuvud eller utförd DNS observation.
Tomt arbetsblad för acceptans och frigivningsgräns
- Alma hyresgäst, tillämplig dokumentation och vald transport: ______
- Befintlig posthanteringsprofil och godkänd ändringsomfattning: ______
- Kuvertdomän och effektiva författaredomäner per brevkategori: ______
- Direkt-moln samma-domän KuvertFrån/huvud.Från kontrollera för varje kategori och aktuell Alma-tillämplighet: ______
- Genererade CNAME ägare/målreferenser och DNS ägare: ______
- Profil aktivt/sparatillstånd, DNS validering och DKIM Aktivt bevis: ______
- Regional SPF -auktorisation och fullständig policygranskning: ______
- Godkänd testdestination och ofarlig testbokstavskonfiguration: ______
- Pålitligt bevis för mottagna meddelanden för varje materiell identitet: ______
- Undantag, återställningsägare och beslut om frigivning: ______
Ursprungliga implementeringsbevis, granskning av mänskligt ämne, aktuell tillämplighet, godkännande av produktionsvägar, visuell tillgänglighet och ägarefrigivning förblir öppna. Det bredare katalogkravet behöver fortfarande auktoriserad implementering och meddelandebevis. Denna dokumentärguide med Alma-omfattning hävdar inte att alla Ex Libris-produkter är konfigurerade eller att någon faktisk implementering har godkänts.