Czy mogę odzyskać adresy e-mail z UDW?

Nie możesz. Po prostu nie będziesz mieć żadnych informacji o nagłówku UDW po odebraniu wiadomości, więc nie ma nic do „zdemaskowania”.

Sposób zaprojektowania UDW jest określony w RFC 2822 , w sekcji 3.6.3. Cytując specyfikację:

Pole „UDW:” (gdzie „UDW” oznacza „Ukrytą kopię”) zawiera adresy odbiorców wiadomości których adresy nie mają być ujawniane innym odbiorcom wiadomości. Istnieją trzy sposoby wykorzystania pola „UDW:”. W pierwszym przypadku, gdy przygotowywana jest do wysłania wiadomość zawierająca pole „UDW:”, wiersz „UDW:” jest usuwany, mimo że do wszystkich odbiorców (w tym określonych w polu „UDW:”) zostanie wysłany kopię wiadomości. W drugim przypadku do adresatów określonych w wierszach „Do:” i „DW:” wysyłana jest kopia wiadomości z linią „UDW:” usuniętą jak powyżej, ale adresaci w wierszu „UDW:” otrzymują oddzielna kopia wiadomości zawierająca wiersz „UDW:”. (Jeśli w polu „UDW:” znajduje się wiele adresów odbiorców, niektóre implementacje wysyłają osobną kopię wiadomości do każdego odbiorcy z „UDW:” zawierającym tylko adres tego konkretnego odbiorcy). Wreszcie, ponieważ „UDW:” : „pole może nie zawierać adresów, pole” UDW: „może zostać wysłane bez adresów wskazujących odbiorcom, że ktoś wysłał ukryte kopie. Wybór metody z polami „UDW:” zależy od implementacji, ale omówienie każdego z nich można znaleźć w sekcji „Zagadnienia dotyczące bezpieczeństwa” w tym dokumencie.

Gdy wiadomość jest odpowiedzią na inną wiadomość, skrzynki pocztowe autorów oryginalnej wiadomości (skrzynki w polu „Od:”) lub skrzynki pocztowe określone w polu „Odpowiedź do:” (jeśli istnieje) MOGĄ pojawić się w polu „Do:” odpowiedzi, ponieważ zwykle byliby głównymi odbiorcami odpowiedzi. Jeśli odpowiedź jest wysyłana na wiadomość, która ma pola docelowe, często pożądane jest wysłanie kopii odpowiedzi do wszystkich odbiorców wiadomości, oprócz autora. Po utworzeniu takiej odpowiedzi adresy w polach „Do:” i „DW:” oryginalnej wiadomości MOGĄ pojawić się w polu „Cc:” odpowiedzi, ponieważ są to zazwyczaj drugorzędni odbiorcy odpowiedzi. Jeśli w oryginalnej wiadomości znajduje się pole „UDW:”, adresy z tego pola MOGĄ pojawić się w polu „UDW:” odpowiedzi, ale NIE POWINNY pojawiać się w polach „Do:” lub „DW:”.

Uwaga: Niektóre aplikacje pocztowe mają automatyczne polecenia odpowiedzi, które zawierają adresy docelowe oryginalnej wiadomości w adresach docelowych odpowiedzi. Sposób zachowania tych poleceń odpowiedzi zależy od implementacji i wykracza poza zakres tego dokumentu. W szczególności nie dotyczy to tego, czy uwzględniać oryginalne adresy docelowe, gdy oryginalna wiadomość miała pole „Odpowiedź do:”.

W przećwiczyć przypadek, w którym odbiorcy Do i DW nie otrzymują linii UDW, ale każdy adres UDW otrzymuje wiersz UDW zawierający tylko ich adres e-mail, jest to najbardziej powszechne. To nie zapewnia wskazania UDW odbiorcom Do i DW i wskazuje, że adresaci UDW, do których wysłano im wiadomość e-mail za pomocą UDW bez ujawniania innych adresatów UDW.

Komentarze

• each Bcc'ed address receives a Bcc line containing only their email address, is most common. Czy to prawda? Wymagałoby to wielokrotnego wysyłania wiadomości zamiast pojedynczej z wieloma poleceniami RCPT TO:. Jaki MUA by to zrobił?
• @EsaJokinen Jaki inny wybór ma MUA, gdy odbiorcy są w różnych domenach? BCC po prostu wymusza takie zachowanie.
• MUA wysyła je tylko raz do MTA, a MTA zaczyna dostarczać je oddzielnie do wszystkich różnych domen.Chodzi o to, że MTA wygrały ', zwykle nie kłopocząc się dodaniem RCPT TO jako Bcc:. Jest to ' bardziej prawdopodobne w nagłówku Received: jako for <[email protected]>.
• To ' jest prawdą: wiesz, że jesteś UDW ' d (lub w inny sposób nieujawniony), ponieważ nie byłeś na To & Cc nagłówki. MUA po prostu zapisuje Bcc podczas zapisywania wiadomości w folderze Wysłane nadawców, ale nie jest to ' część wiadomości wysłanej przez SMTP .
• @EsaJokinen Gmail robi to – w rzeczywistości zawiera nagłówek Bcc w wiadomości. Nie ' nie znam innych osób, które to robią.

Standard Request For Comments (RFC) (opublikowany przez The Internet Engineering Task Force (IETF)) określa, że odbiorcy wiadomości e-mail wysłanej do adresatów określonych w nagłówku „BCC” mogą otrzymać wiadomość e-mail, ale nie są świadomi innych adresatów wymienionych w nagłówku. W szczególności „adresy nie powinny być ujawniane innym odbiorcom wiadomości”.

Jest to żądanie (nie upoważnienie) do serwerów SMTP w celu odzwierciedlenia bieżącej praktyki (protokołu) społeczność internetowa b y Towarzystwo internetowe.

Jednak te, które okazały się niezgodne z może zostać oddzielony, a jeśli zostanie uznany za nielegalnego, zostanie zbanowany / umieszczony na czarnej liście, a nawet ścigany , gdy uznano, że prowadzi działalność niezgodną z prawem w danej jurysdykcji.

Jeśli więc„ jesteś odbiorcą wiadomości e-mail z serwera (pocztowego) zgodnego ”, nie otrzymasz innego adresatów e-maili wymienionych w polu „UDW”, chyba że kontrolujesz serwer wysyłający (SMTP), serwer poczty przychodzącej (POP, IMAP itp.) oraz wszystkie serwery przekazujące, które kierowały pakiety IP.

Komentarze

• ” Te, które nie są zgodne, mogą zostać oddzielone, a jeśli okaże się, że są nieuczciwe, zostanie zbanowany / umieszczony na czarnej liście, a nawet ścigany, jeśli zostanie uznany za prowadzącego działalność niezgodną z prawem w danej jurysdykcji. ” – su ggest jest to wyjątkowo mało prawdopodobny wynik dla serwera, który ujawnił adresy BCC. Ponadto, jeśli wiadomość to UDW ' d do [email protected] i [email protected], a foo.com i y.com mają różne serwery SMTP, bar.com będzie nawet nie otrzyma adresu [email protected] ' do wycieku, więc nie ma sensu w ” segregować „, ponieważ jego wycieki wpływają tylko na jego własnych użytkowników.
• Czy istnieją obecnie przepisy wymagające zgodności systemów poczty e-mail z IETF RFC?
• @grawity: You ' d szukać praw zabraniających stosowania najlepszych praktyk , ogólnie przyjętych metod i podobnych ogólnych stwierdzeń. Por. RODO 5.1 (f) ” odpowiednie środki techniczne lub organizacyjne ”
• @MSalters prawdopodobnie oznaczały przepisać zamiast czegoś przeciwnego, zakazuj …
• @grawity nie bezpośrednio, ale serwer, który ujawniłby informacje pomimo standardów mówiących inaczej, spowodowałby, że jego operator naruszyłby różne prawa dotyczące prywatności ( np. RODO lub CCPA)