Agent för meddelandeinlämning

En meddelandesubmissionsagent ( MSA ), eller postsubmissionsagent , är ett datorprogram eller mjukvaruagent som tar emot e- postmeddelanden från en e-postanvändaragent (MUA) och samarbetar med en e-postöverföringsagent (MTA) för leverans av posten. Den använder ESMTP, en variant av Simple Mail Transfer Protocol (SMTP), som specificeras i RFC 6409.

Många MTA:er utför funktionen som en MSA också, men det finns även program som är speciellt utformade som MSA utan full MTA-funktionalitet. ^{den officiella porten Historiskt sett} använder både MTA- och MSA-funktioner portnummer 25 i Internetpost , men för MSA är 587. MTA:n accepterar en användares inkommande post, medan MSA accepterar en användares utgående post.

Datorn som kör en MSA är också känd som servern för utgående e-post .

Fördelar

Separation av MTA- och MSA-funktionerna ger flera fördelar.

En fördel är att en MSA, eftersom den interagerar direkt med författarens MUA, kan korrigera mindre fel i ett meddelandes format (som ett saknat datum , meddelande-ID , till- fält eller en adress med ett saknat domännamn) och/ eller omedelbart rapportera ett fel till författaren så att det kan korrigeras innan det skickas till någon av mottagarna. En MTA som accepterar ett meddelande från en annan sida kan inte på ett tillförlitligt sätt göra den typen av korrigeringar, och eventuella felrapporter som genereras av en sådan MTA kommer att nå författaren (om ens alls) först efter att meddelandet redan har skickats.

En ytterligare fördel är att med ett dedikerat portnummer, 587, är det alltid möjligt för användare att ansluta till sin domän för att skicka ny e-post. För att bekämpa skräppost (inklusive skräppost som skickas omedvetet av ett offer för ett botnät ) begränsar många internetleverantörer och institutionella nätverk möjligheten att ansluta till fjärranslutna MTA:er på port 25. Tillgängligheten för en MSA på port 587 gör det möjligt för nomadanvändare (till exempel de som arbetar) på en bärbar dator) för att fortsätta skicka e-post via deras föredragna inlämningsservrar även från andras nätverk. Att använda en specifik inlämningsserver är ett krav när avsändarpolicyer eller signeringsmetoder tillämpas.

En annan fördel är att separering av MTA- och MSA-funktionerna gör det lättare för en MTA att neka vidarebefordran, det vill säga att neka all post som inte är adresserad till en mottagare på en domän som serveras lokalt. Detta är en strategi som används av Internetleverantörer för att förhindra att skräppost skickas från virusinfekterade klientdatorer. Däremot måste en MSA i allmänhet acceptera e-post för alla mottagare på Internet, även om den bara accepterar sådan e-post från författare som är auktoriserade att använda den MSA och som har fastställt sin identitet till MSA via autentisering. I tider då både e-postinlämning och acceptans av inkommande e-post vanligtvis åstadkoms med samma protokoll och samma server, gjorde möjligheten att skicka e-post till godtyckliga destinationer utan autentisering det möjligt för spammare att använda MTA:er som ett sätt att distribuera skräppost (eftersom en enda meddelandetransaktion kan begära att en MTA vidarebefordrar ett meddelande till ett stort antal mottagare), och gjorde det också svårare att spåra ett meddelande till dess ursprung.

Ytterligare en fördel är att MSA och MTA kan ha olika policyer för filtrering av skräppost. De flesta MSA kräver autentisering i form av ett användarnamn och lösenord som tillhandahålls av författaren. Alla meddelanden som tas emot av en sådan MSA kan därför spåras till en författare som har en direkt relation till MSA och som kan hållas ansvarig för sina handlingar. Detta gör att MSA har antingen ingen skräppostfiltrering eller mer tillåtande skräppostfiltrering än en MTA som finns i syfte att acceptera inkommande e-post från andra domäner. Det är svårt att etablera förtroende för post som skickas mellan godtyckliga domäner, eftersom det i allmänhet inte finns något direkt samband mellan dessa domäner genom vilket förtroende, eller till och med identitet, kan etableras. I avsaknad av sådant förtroende måste en MTA i allmänhet förlita sig på heuristik och tredjeparts ryktestjänster för att skilja spam från legitim trafik, och båda dessa mekanismer har en historia av att vara felbenägna. Separationen av MSA och MTA undviker därför användningen av opålitliga skräppostigenkänningsmekanismer under sändning av e-post, och ökar sannolikheten för att legitim e-post ska levereras framgångsrikt.

Protokoll

Konfiguration

Medan nyare e-postklienter använder port 587 som standard, föreslår äldre fortfarande port 25. Användare måste ändra portnumret manuellt i det senare fallet. Det är också möjligt att MUA automatiskt upptäcker vilken server som tillhandahåller MSA för en given domän och letar upp SRV-posterna för den domänen. Domän example.com kan publicera sin post så här:

_submission._tcp.example.com. SRV 0 1 587 mail.example.com.

Obligatorisk autentisering

RFC 6409 kräver att klienter är auktoriserade och autentiserade att använda e-posttjänsten, t.ex. enligt beskrivningen i SMTP-AUTH (ESMTPA), eller på annat sätt som RADIUS , certifikat med offentliga nyckel eller (den mestadels föråldrade ) POP före SMTP .

Genomförande av policy

MSA måste kontrollera att den skickade e-posten är syntaktisk giltig och överensstämmer med relevanta webbplatspolicyer. RFC 6409 innehåller några valfria funktioner:

Genomtvinga inlämningsrättigheter garanterar att kuvertets avsändaradress är giltig och auktoriserad med den använda autentiseringen. Detta överensstämmer i huvudsak med SPF -modellen som specificeras i RFC 7208.
Kan lägga till avsändartillstånd för att lägga till ett rubrikfält för avsändaradress om kuvertets avsändaradress inte matchar någon författares adress i rubrikfältet "Från". Detta överensstämmer ungefär med avsändar-ID- modellen som specificeras i RFC 4406 – ignorerar det knepiga fallet med Resent-From-huvudfält som inte täcks av RFC 6409.

Se även

Klensin, J. (april 2001). Simple Mail Transfer Protocol . IETF . doi : 10.17487/RFC2821 . RFC 2821 . Hämtad 14 november 2013 .
"SMTP är inte säkert" . Kasoft Central . Hämtad 2008-06-14 .