Agent przesyłania wiadomości — Message submission agent

Środek złożenie wiadomość ( MSA ) lub Mail Submission Agent , to program komputerowy lub agenta oprogramowania , który odbiera pocztę elektroniczną wiadomości z programu pocztowego (MUA) i współpracuje z agenta transferowego poczty (MTA) dla dostarczania poczty. Używa ESMTP, wariantu Simple Mail Transfer Protocol (SMTP), jak określono w RFC 6409.

Wiele MTA pełni również funkcję MSA, ale istnieją również programy, które są specjalnie zaprojektowane jako MSA bez pełnej funkcjonalności MTA. Historycznie rzecz biorąc, w poczcie internetowej zarówno funkcje MTA, jak i MSA używają portu o numerze 25, ale oficjalnym portem dla MSA jest 587. MTA akceptuje pocztę przychodzącą użytkownika, podczas gdy MSA akceptuje pocztę wychodzącą użytkownika.

Komputer, na którym działa program MSA, jest również nazywany serwerem poczty wychodzącej .

Korzyści

Rozdzielenie funkcji MTA i MSA daje kilka korzyści.

Jedną z korzyści jest to, że MSA, ponieważ wchodzi w bezpośrednią interakcję z MUA autora, może poprawić drobne błędy w formacie wiadomości (takie jak brakująca data , identyfikator wiadomości , pola Do lub adres z brakującą nazwą domeny) i/ lub natychmiast zgłoś błąd autorowi, aby można go było poprawić, zanim zostanie wysłany do któregokolwiek z odbiorców. MTA przyjmujące wiadomość z innej strony nie może rzetelnie dokonywać tego rodzaju poprawek, a wszelkie raporty o błędach generowane przez takie MTA dotrą do autora (jeśli w ogóle) dopiero po wysłaniu wiadomości.

Kolejną korzyścią jest to, że dzięki dedykowanemu numerowi portu 587 użytkownicy mogą zawsze połączyć się z ich domeną w celu przesłania nowej poczty. W celu zwalczania spamu (w tym spamu wysyłanego nieświadomie przez ofiarę botnetu ) wielu dostawców usług internetowych i sieci instytucjonalnych ogranicza możliwość łączenia się ze zdalnymi agentami MTA na porcie 25. Dostępność MSA na porcie 587 umożliwia użytkownikom nomadycznym (na przykład pracującym na laptopie), aby nadal wysyłać pocztę za pośrednictwem preferowanych serwerów przesyłania, nawet z sieci innych osób. Korzystanie z określonego serwera przesyłania jest wymagane, gdy wymuszane są zasady nadawcy lub praktyki podpisywania .

Inną korzyścią jest to, że oddzielenie funkcji MTA i MSA ułatwia MTA odmowę przekazywania, czyli odrzucanie każdej poczty, która nie jest adresowana do odbiorcy w domenie obsługiwanej lokalnie. Jest to strategia stosowana przez dostawców usług internetowych w celu zapobiegania wysyłaniu spamu z komputerów klienckich zainfekowanych wirusami. W przeciwieństwie do tego, MSA musi ogólnie akceptować pocztę od dowolnego odbiorcy w Internecie, chociaż akceptuje tylko taką pocztę od autorów, którzy są upoważnieni do używania tego MSA i którzy ustalili swoją tożsamość w MSA poprzez uwierzytelnienie. W czasach, gdy zarówno przesyłanie, jak i akceptowanie poczty przychodzącej odbywało się zwykle przy użyciu tego samego protokołu i tego samego serwera, możliwość wysyłania poczty do dowolnych miejsc bez uwierzytelnienia pozwalała spamerom na używanie MTA jako środka dystrybucji spamu (ponieważ pojedyncza transakcja wiadomości może zażądać, aby MTA przekazał wiadomość dużej liczbie odbiorców), a także utrudniło śledzenie wiadomości do jej pochodzenia.

Kolejną korzyścią jest to, że umowy MSA i MTA mogą mieć różne zasady filtrowania spamu. Większość MSA wymaga uwierzytelnienia w postaci nazwy użytkownika i hasła dostarczonego przez autora. Wszelkie wiadomości otrzymane przez takie MSA są zatem identyfikowalne do autora, który ma bezpośredni związek z MSA i który może zostać pociągnięty do odpowiedzialności za swoje działania. Pozwala to MSA na brak filtrowania spamu lub bardziej liberalne filtrowanie spamu niż MTA, który istnieje w celu przyjmowania wiadomości przychodzących z innych domen. Trudno jest ustanowić zaufanie w poczcie wysyłanej między dowolnymi domenami, ponieważ generalnie nie ma bezpośredniej relacji między tymi domenami, za pośrednictwem której można ustanowić zaufanie, a nawet tożsamość. W przypadku braku takiego zaufania, MTA musi generalnie polegać na heurystyce i zewnętrznych usługach reputacji, aby odróżnić spam od legalnego ruchu, a oba te mechanizmy są podatne na błędy. Oddzielenie MSA i MTA pozwala zatem uniknąć stosowania zawodnych mechanizmów rozpoznawania spamu podczas przesyłania poczty i zwiększa prawdopodobieństwo pomyślnego dostarczenia legalnej poczty.

Protokół

Konfiguracja

Podczas gdy nowi klienci poczty e-mail domyślnie używają portu 587, starsze nadal proponują port 25. W tym drugim przypadku użytkownicy muszą ręcznie zmienić numer portu. Możliwe jest również, że MUA może automatycznie wykryć, który serwer udostępnia MSA dla danej domeny, wyszukując rekordy SRV dla tej domeny. Domena example.com może opublikować swój rekord w następujący sposób: 

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

Uwierzytelnianie obowiązkowe

Główny artykuł: Uwierzytelnianie SMTP

RFC 6409 wymaga, aby klienci byli autoryzowani i uwierzytelniani do korzystania z usługi przesyłania poczty, np. jak opisano w SMTP-AUTH (ESMTPA) lub za pomocą innych środków, takich jak RADIUS , certyfikaty klucza publicznego lub (najczęściej przestarzały) POP przed SMTP .

Egzekwowanie zasad

MSA musi sprawdzić, czy przesłana poczta jest poprawna składniowo i jest zgodna z odpowiednimi zasadami witryny. RFC 6409 zawiera kilka opcjonalnych funkcji:

  • Egzekwowanie uprawnień do przesyłania gwarantuje, że adres nadawcy w kopercie jest poprawny i autoryzowany przy użyciu używanego uwierzytelniania. Zasadniczo jest to zgodne z modelem SPF określonym w RFC 7208.
  • Może dodać nadawcę zezwala na dodanie pola nagłówka Adres nadawcy, jeśli adres nadawcy w kopercie nie pasuje do żadnego adresu autora w polu nagłówka „Od”. Jest to z grubsza zgodne z modelem Sender ID określonym w RFC 4406 – ignorując trudny przypadek pól nagłówka Resent-From, które nie zostały uwzględnione w RFC 6409.

Zobacz też

Bibliografia

  • Klensin, J. (kwiecień 2001). Prosty protokół przesyłania poczty . IETF . doi : 10.17487/RFC2821 . RFC 2821 . Źródło 14 listopada 2013 .
  • „SMTP nie jest bezpieczny” . Kasoft Centralny . Źródło 2008-06-14 .