Udostępnij za pośrednictwem

Jak funkcja EOP weryfikuje adres Od, aby zapobiec wyłudzaniu informacji

Porada

Czy wiesz, że możesz bezpłatnie wypróbować funkcje w planie Ochrona usługi Office 365 w usłudze Microsoft Defender 2? Użyj 90-dniowej wersji próbnej Ochrona usługi Office 365 w usłudze Defender w centrum wersji próbnej portalu Microsoft Defender. Dowiedz się, kto może zarejestrować się i zapoznać się z warunkami wersji próbnej w witrynie Try Ochrona usługi Office 365 w usłudze Microsoft Defender.

Ataki wyłudzające informacje stanowią stałe zagrożenie dla dowolnej organizacji poczty e-mail. Oprócz używania sfałszowanych (sfałszowanych) adresów e-mail nadawcy osoby atakujące często używają wartości w polu Adres od, które naruszają standardy internetowe. Aby zapobiec wyłudzaniu informacji tego typu, Exchange Online Protection (EOP) i Outlook.com wymagają, aby komunikaty przychodzące zawierały adres Z zgodny z RFC zgodnie z opisem w tym artykule.

  • Jeśli regularnie otrzymujesz wiadomości e-mail od organizacji, które mają źle sformułowane adresy Z zgodnie z opisem w tym artykule, zachęć te organizacje do zaktualizowania serwerów poczty e-mail w celu zachowania zgodności z nowoczesnymi standardami zabezpieczeń.

  • Te wymagania nie mają wpływu na powiązane pole nadawcy (używane przez usługę Wyślij w imieniu i listy wysyłkowe). Aby uzyskać więcej informacji, zobacz następujący wpis w blogu: Co mamy na myśli, gdy odwołujemy się do "nadawcy" wiadomości e-mail?.

Omówienie standardów wiadomości e-mail

Standardowa wiadomość e-mail SMTP składa się z koperty wiadomości i zawartości wiadomości. Koperta wiadomości zawiera informacje wymagane do przesyłania i dostarczania komunikatu między serwerami SMTP. Zawartość wiadomości zawiera pola nagłówka wiadomości (łącznie nazywane nagłówkiem komunikatu) i treść komunikatu. Koperta komunikatu jest opisana w dokumencie RFC 5321, a nagłówek komunikatu jest opisany w dokumencie RFC 5322. Adresaci nigdy nie widzą rzeczywistej koperty wiadomości, ponieważ jest ona generowana przez proces transmisji komunikatów i w rzeczywistości nie jest częścią wiadomości.

  • Adres MAIL FROM (znany również jako 5321.MailFrom adres, nadawca P1 lub nadawca koperty) to adres e-mail używany podczas transmisji wiadomości przez protokół SMTP. Ten adres e-mail jest zwykle rejestrowany w polu nagłówek Return-Path w nagłówku wiadomości (chociaż nadawca może wyznaczyć inny adres e-mail ze ścieżką powrotną ).

  • Adres Od (znany również jako 5322.From adres lub nadawca P2) jest adresem e-mail w polu Od nagłówka i jest adresem e-mail nadawcy wyświetlanym w klientach poczty e-mail. Adres Od jest przedmiotem wymagań w tym artykule.

Adres From jest definiowany szczegółowo w kilku punktach Z (na przykład RFC 5322 sekcje 3.2.3, 3.4 i 3.4.1 i RFC 3696). Istnieje wiele odmian dotyczących adresowania i tego, co jest uważane za prawidłowe lub nieprawidłowe. Aby zachować prostotę, zalecamy następujący format i definicje:

From: "Display Name" <EmailAddress>

  • Nazwa wyświetlana: opcjonalna fraza opisująca właściciela adresu e-mail.

    • Zalecamy, aby zawsze umieszczać nazwę wyświetlaną w podwójnym cudzysłowie ("), jak pokazano poniżej. Jeśli nazwa wyświetlana zawiera przecinek, należy ująć ciąg w podwójny cudzysłów na RFC 5322.
    • Jeśli adres Od zawiera nazwę wyświetlaną, wartość EmailAddress musi być ujęta w nawiasy kątowe (<>), jak pokazano poniżej.
    • Firma Microsoft zdecydowanie zaleca wstawienie miejsca między nazwą wyświetlaną a adresem e-mail.

  • EmailAddress: adres e-mail używa formatu local-part@domain:

    • local-part: ciąg identyfikujący skrzynkę pocztową skojarzoną z adresem. Ta wartość jest unikatowa w domenie. Często używana jest nazwa użytkownika lub identyfikator GUID właściciela skrzynki pocztowej.
    • domena: w pełni kwalifikowana nazwa domeny (FQDN) serwera poczty e-mail hostującego skrzynkę pocztową określoną przez lokalną część adresu e-mail.

    Też:

    • Tylko jeden adres e-mail.
    • Zalecamy, aby nie oddzielać nawiasów kątowych spacjami.
    • Nie dołączaj tekstu po adresie e-mail.

Przykłady dobrych i złych adresów

Poniższa tabela zawiera przykłady prawidłowych adresów From:

Adres Komentarze
From: sender@contoso.com OK
From: <sender@contoso.com> OK
From: < sender@contoso.com > OK, ale nie jest to zalecane, ponieważ istnieją spacje między nawiasami kątowymi a adresem e-mail.
From: "Sender, Example" <sender.example@contoso.com> OK
From: "Microsoft 365" <sender@contoso.com> OK
From: Microsoft 365 <sender@contoso.com> OK, ale nie jest to zalecane, ponieważ nazwa wyświetlana nie jest ujęta w podwójny cudzysłów.

Poniższa tabela zawiera przykłady nieprawidłowych adresów From:

Adres Komentarze
Nie z adresu Gdy wiadomość pojawi się na platformie Microsoft 365 lub Outlook.com bez adresu Od, staramy się przypisać adres MAIL FROM do adresu Od, aby upewnić się, że wiadomość jest dostarczana. Obecnie te komunikaty są akceptowane przez usługę, nawet jeśli oryginalny adres Od to From: <>.
From: <firstname lastname@contoso.com> Adres e-mail zawiera spację.
From: Microsoft 365 sender@contoso.com Nazwa wyświetlana jest obecna, ale adres e-mail nie jest ujęty w nawiasy kątowe.
From: "Microsoft 365" <sender@contoso.com> (Sent by a process) Tekst po adresie e-mail.
From: Sender, Example <sender.example@contoso.com> Nazwa wyświetlana zawiera przecinek, ale nie jest ujęta w podwójny cudzysłów.
From: "Microsoft 365 <sender@contoso.com>" Cała wartość jest niepoprawnie ujęta w podwójny cudzysłów.
From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com Nazwa wyświetlana jest obecna, ale adres e-mail nie jest ujęty w nawiasy kątowe.
From: Microsoft 365<sender@contoso.com> Brak miejsca między nazwą wyświetlaną a lewym nawiasem kwadratowym.
From: "Microsoft 365"<sender@contoso.com> Brak miejsca między zamykaniem podwójnego cudzysłowu a lewym nawiasem kwadratowym.

Pomijanie automatycznych odpowiedzi do domen niestandardowych

Nie można użyć wartości From: <> do pominięcia automatycznych odpowiedzi. Zamiast tego należy skonfigurować rekord MX o wartości null dla domeny niestandardowej. Po skonfigurowaniu rekordu MX o wartości null wszystkie odpowiedzi są naturalnie pomijane, ponieważ serwer odpowiedzi nie ma opublikowanego adresu do wysyłania komunikatów.

W przypadku rekordu MX o wartości null wybierz domenę poczty e-mail, która nie może odbierać wiadomości e-mail. Jeśli na przykład domena podstawowa jest contoso.com, możesz wybrać noreply.contoso.com. Rekord MX o wartości null dla tej domeny składa się z jednego okresu. Przykład:

noreply.contoso.com IN MX .

Aby uzyskać więcej informacji na temat konfigurowania rekordów MX, zobacz Create DNS records at any DNS hosting provider for Microsoft 365 (Tworzenie rekordów DNS u dowolnego dostawcy hostingu DNS dla platformy Microsoft 365).

Aby uzyskać więcej informacji na temat publikowania wartości null MX, zobacz RFC 7505.

Zastępowanie z wymuszania adresu

Aby pominąć wymagania dotyczące adresu Od dla przychodzącej poczty e-mail, można użyć listy dozwolonych adresów IP (filtrowania połączeń) lub reguł przepływu poczty (znanych również jako reguły transportu) zgodnie z opisem w artykule Tworzenie list bezpiecznych nadawców na platformie Microsoft 365. Outlook.com nie zezwala na przesłonięcia jakiegokolwiek rodzaju, nawet za pośrednictwem żądań pomocy technicznej.

Nie można zastąpić wymagań dotyczących adresu Od dla wychodzącej poczty e-mail wysyłanej z platformy Microsoft 365 lub Outlook.com.

Inne sposoby zapobiegania cyberprzestępczości i ochrony przed zagrożeniami w usłudze Microsoft 365

Aby uzyskać więcej informacji na temat wzmacniania organizacji przed wyłudzaniem informacji, spamem, naruszeniami danych i innymi zagrożeniami, zobacz Najlepsze rozwiązania dotyczące zabezpieczania planów platformy Microsoft 365 dla firm.