Główna » jak » Dlaczego pośredni serwer SMTP musi wysyłać pocztę?

    Dlaczego pośredni serwer SMTP musi wysyłać pocztę?

    Jako osoba dowiaduje się więcej o tym, jak działają klienci poczty, serwery SMTP i cały system poczty online, mogą być ciekawi, dlaczego pośredni serwer SMTP jest nawet potrzebny. Mając to na uwadze, dzisiejszy post pytań i odpowiedzi dla SuperUser zawiera odpowiedzi na ciekawe pytania czytelnika.

    Dzisiejsza sesja pytań i odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, opartego na społecznościach grupowania witryn z pytaniami i odpowiedziami.

    Zdjęcie dzięki uprzejmości Davida Schroedera (Flickr).

    Pytanie

    Czytnik SuperUser Tobia chce wiedzieć, dlaczego do wysyłania poczty potrzebny jest pośredni serwer SMTP:

    Dlaczego potrzebuję pośredniego serwera SMTP do wysyłania poczty? Dlaczego mój klient poczty (Outlook lub Thunderbird) nie może wysyłać wiadomości bezpośrednio do domeny SMTP odbiorcy?

    Na przykład, jeśli muszę wysłać pocztę do [email protected] z moim kontem Gmail, wysyłam je do smtp.gmail.com serwer; następnie ten serwer wysyła moją wiadomość do serwera MX example.com.

    Dlaczego potrzebny jest pośredni serwer SMTP do wysyłania poczty?

    Odpowiedź

    Superuser contrybutor davidgo ma dla nas odpowiedź:

    Jest technicznie możliwe wysyłanie poczty bezpośrednio do serwera SMTP odbiorcy z twojego komputera.

    Patrząc na to z historycznego punktu widzenia, jeśli zdalny serwer SMTP jest wyłączony, chcesz, aby system automatycznie go obsługiwał i kontynuował próbę, dlatego masz serwer SMTP. Podobnie, w dawnych czasach nie wszystkie serwery pocztowe były przez cały czas połączone (łącza dalekosiężne były drogie), więc poczta była umieszczana w kolejce i wysyłana po ustanowieniu połączenia.

    Przechodząc do miejsca, w którym usługi internetowe są tanie, nadal przydatne są mechanizmy ponownej próby wysłania poczty, jeśli serwer jest niedostępny. Nie jest idealna, aby ta funkcja była zapisana w MUA (program pocztowy użytkownika poczty / użytkownika końcowego). Te funkcje mieszczą się w MTA (serwer poczty / serwer SMTP).

    Ale robi się gorzej - spamerzy. Większość wiadomości (ponad 80 procent) to spam. Dostawcy poczty robią, co mogą, aby zmniejszyć ten problem, a wiele technik tworzy założenia dotyczące sposobu dostarczania poczty. Ważne są następujące kwestie:

    1. Szara lista: Niektórzy dostawcy automatycznie zrzucają połączenie pocztowe, jeśli nadawca i odbiorca nie powiadomili się wcześniej i oczekują, że spróbują po raz drugi. Spamerzy często nie próbują ponownie, podczas gdy serwer SMTP zawsze powinien. Zmniejsza to objętość spamu o około 80 procent, ale jest to jednak konieczne.

    2. Reputacja: Jest o wiele bardziej prawdopodobne, że ktoś wysyłający pocztę za pośrednictwem renomowanego, znanego serwera SMTP jest legalny w porównaniu do serwera "po nocy". Aby poczuć reputację, dostawcy robią różne rzeczy:

    • Blokuj adresy dynamiczne / klientów (nie w 100%, ale duże fragmenty internetu zostały zmapowane).
    • Sprawdź, czy odwrotny DNS odpowiada przyszłemu DNS. Nie jest to trudne, ale pokazuje pewien poziom odpowiedzialności i znajomości najlepszych praktyk (coś, czego nie ma wiele bloków adresów klienckich).
    • Sprawdź reputację. Podczas komunikacji z innymi serwerami SMTP wielu dostawców śledzi ilość spamu i ilość wysłanych wiadomości. Mogą zmniejszyć ilość spamu, ograniczając połączenia i kontrolując te parametry. Jest na to wiele sposobów, nie wszystkie są oczywiste, ale wymagają znanego nadawcy.
    • SPF i DKIM. Mechanizmy te wiążą zasoby DNS z nazwą domeny, aby utrudnić tworzenie poczty i byłyby trudne, ale niekoniecznie niemożliwe do wdrożenia, jeśli program pocztowy (MUA) odpowiada za wychodzące wiadomości.

    Prawdopodobnie istnieją inne drobne problemy, ale byłyby to najważniejsze.


    Czy masz coś do dodania do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych użytkowników Stack Exchange, którzy znają się na technologii? Sprawdź cały wątek dyskusji tutaj.