Czy zabezpieczenie SPF poprawnie działa z przesyłaniem poczty dalej (forward)?

Rekord SPF, czyli zabezpieczenie poczty wychodzącej, jest odpowiedzialny za weryfikację, czy serwer z którego wysyłana jest wiadomość, jest uprawniony do wysyłki w danej domenie. Mechanizm ten jest stosowany, aby wyeliminować możliwość podszycia się pod cudzy adres e-mail. Więcej na ten temat można przeczytać w artykule SPF i DKIM – zabezpieczenia przed spamem

Co jednak stałoby się, gdy będziemy chcieli przesłać dalej (forwardować) wiadomość od nadawcy A, na adres C? 

  • Nadawcą wiadomości jest A, 
  • Wiadomość zostaje przesłana dalej z serwera B (nieuprawnionego przez rekord SPF do wysyłki z domeny A) na adres C.

W tym wypadku mechanizm SPF zweryfikuje, że wiadomość od nadawcy A jest wysłana z naszego serwera, który nie ma uprawnienia do wysyłki z tej domeny. Serwer pocztowy adresu C najpewniej uzna go za spam. Lub co gorsze, wiadomość w ogóle nie dotrze do odbiorcy! 

Aby do tego nie doszło, wykorzystujemy mechanizm SRS.

SRS (Sender Rewriting Scheme) – czym jest i jak działa?

SRS jest schematem używanym przy przesyłaniu wiadomości dalej. Jego zadaniem jest zmienić adres domeny nadawcy na taką, z której rzeczywiście będzie wysyłana wiadomość. W jakim celu? 

Patrząc na problem opisany wyżej: 

  • Nadawcą wiadomości jest A,
  • Mechanizm SRS podmienia domenę nadawcy A na B,
  • Wiadomość zostaje wysłana z serwera B na serwer C,
  • Mechanizm SPF pomyślnie weryfikuje wiadomość, ponieważ serwer B posiada uprawnienie do wysyłki z domeny B.

Praktyczny przykład.

Z naszego adresu A – naszemail@smarthost.pl wysyłamy wiadomość na adres firmy B – kontakt@domena-klienta.pl. Adres na który wysłaliśmy wiadomość, posiada automatyczne przekierowanie wiadomości na skrzynkę właściciela firmy C – wlasciciel@gmail.com.

W nagłówku wiadomości znajdziemy takie informacje:

Return-Path: <SRS0=3l6Yp4=QZ=smarthost.pl=naszemail@domena-klienta.pl>
Delivered-To: kontakt@domena-klienta.pl
Received: from s39.smarthost.pl
    by s39.smarthost.pl with LMTP
    id sLOUDA5ysGHfkgAANib7SA
    (envelope-from <SRS0=3d6Xp4=QZ=smarthost.pl=naszemail@domena-klienta.pl>
    for <kontakt@domena-klienta.pl>; Wed, 12 Dec 2021 21:25:21 +0100
Return-path: <SRS0=3l6Yp4=QZ=smarthost.pl=naszemail@domena-klienta.pl>
Envelope-to: kontakt@domena-klienta.pl
Delivery-date: Wed, 08 Dec 2021 09:51:26 +0100
Received: from static-ac29.rev.smarthost.pl ([91.211.222.29]:60751)
    by s39.smarthost.pl with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    (Exim 4.94.2)
    (envelope-from <SRS0=3d6Xp4=QZ=smarthost.pl=naszemail@domena-klienta.pl>)
    id 1musfb-0008X8-BV
    for kontakt@domena-klienta.pl.; Wed, 08 Dec 2021 09:51:27 +0100
Received: from mail.smarthost.pl ([192.36.61.58]:54850)
    by mx.google.com with ESMTPS id u25is5268113cze.366
     (envelope-from <naszemail@smarthost.pl>)
    for wlasciciel@gmail.com; Wed, 08 Dec 2021 09:51:22 +0100

Pojawiają się w nim zapisy SRS (<SRS0=3l6Yp4=QZ=smarthost.pl=naszemail@domena-klienta.pl>).

Mówią nam one, że domena nadawcy smarthost.pl została zmieniona na domena-klienta.pl, czyli domeny z której wiadomość jest przekazywana dalej. Dzięki temu, mechanizm SPF może potwierdzić autentyczność wiadomości przesyłanej przez auto forwarder.

Podsumowanie

Dzięki mechanizmowi SRS, poczta przesyłana dalej może być poprawnie autoryzowana przez SPF. Mechanizm jest włączony na wszystkich serwerach Smarthost.

Smarthost

Dodaj komentarz