Hvordan kan jeg afmaske e-mail-adresserne i et Bcc-felt, når jeg bare er modtager?

Brug for meget enkle, trinvise instruktioner til en person, der ikke koder. Jeg har modtaget en gruppe-e-mail og vil meget gerne se de andre, der har fået den.

Kommentarer

  • At ikke være i stand til dette er det nøjagtige punkt i Bcc.
  • Jeg har en fornemmelse der ‘ et opfølgningsspørgsmål, der kommer på arbejdspladsen. SE
  • Du bliver nødt til at hacke dig ind på SMTP-serveren, der sendte dig e-mailen og dechiffrere de indgående logfiler for at se BCC. Du som en gennemsnitlig person vil sandsynligvis have svært ved at opnå dette …
  • @chrylis For at være retfærdig er der så mange tilfælde, hvor information, der ikke ‘ ikke skal være tilgængelig, er blot skjult, så jeg kan forstå, hvordan en person tror, det kan være muligt.
  • Intet lettere. Sagsøger afsenderen, så brug en stævning for at tvinge afsløringen af den oprindelige besked.

Svar

Du kan ikke “t. Du vil simpelthen ikke have nogen oplysninger om Bcc-overskriften, når du modtager e-mailen, så du er intet at “afmaske”.

Den måde, Bcc er designet på, er angivet i RFC 2822 , under afsnit 3.6.3. For at citere specifikationen:

Feltet “Bcc:” (hvor “Bcc” betyder “Blind Carbon Copy”) indeholder adresser til modtagere af meddelelsen hvis adresser ikke skal afsløres for andre modtagere af meddelelsen. Der er tre måder, hvorpå feltet “Bcc:” bruges. I det første tilfælde, når en meddelelse indeholdende et “Bcc:” -felt er klar til at blive sendt, fjernes linjen “Bcc:”, selvom alle modtagere (inklusive dem, der er specificeret i “Bcc:” -feltet) sendes en kopi af beskeden. I det andet tilfælde sendes modtagere, der er specificeret i linierne “Til:” og “Cc:” hver en kopi af meddelelsen med linjen “Bcc:” fjernet som ovenfor, men modtagerne på “Bcc:” -linjen får en separat kopi af meddelelsen, der indeholder en “Bcc:” -linje. (Når der er flere modtageradresser i feltet “Bcc:”, sender nogle implementeringer faktisk en separat kopi af meddelelsen til hver modtager med en “Bcc:”, der kun indeholder adressen på den pågældende modtager.) Endelig siden en “Bcc” : “felt må muligvis ikke indeholde adresser, et” Bcc: “-felt kan sendes uden nogen adresser, der indikerer til modtagerne, at blinde kopier blev sendt til nogen. Hvilken metode, der skal bruges med “Bcc:” -felter, er implementeringsafhængig, men se afsnittet “Sikkerhedsovervejelser” i dette dokument for en diskussion af hver.

Når en meddelelse er et svar på en anden besked, postkasser til forfatterne af den oprindelige besked (postkasserne i feltet “Fra:”) eller postkasser, der er specificeret i “Svar til” -feltet (hvis den findes) MÅ vises i feltet “Til:” i svaret, da disse ville normalt være de primære modtagere af svaret. Hvis et svar sendes til en besked, der har destinationsfelter, er det ofte ønskeligt at sende en kopi af svaret til alle modtagere af meddelelsen ud over forfatteren. Når et sådant svar dannes, KAN adresser i felterne “Til:” og “Cc:” i den oprindelige meddelelse MÅ vises i “Cc:” -feltet i svaret, da disse normalt er sekundære modtagere af svaret. Hvis der er et “Bcc:” -felt i den oprindelige meddelelse, KAN adresser i dette felt vises i “Bcc:” -feltet i svaret, men SKAL IKKE vises i felterne “Til:” eller “Cc:”.

Bemærk: Nogle mailapplikationer har automatiske svarskommandoer, der inkluderer destinationsadresserne for den oprindelige meddelelse i destinationsadresserne for svaret. Hvordan disse svarskommandoer opfører sig, afhænger af implementeringen og ligger uden for dette dokuments anvendelsesområde. Især hvorvidt de originale destinationsadresser skal medtages eller ikke, når den oprindelige meddelelse havde et “Svar til:” -felt, adresseres ikke her.

I praktiser det tilfælde, hvor Til- og Cc-modtagere ikke modtager nogen Bcc-linje, men hver Bcc-ed-adresse modtager en Bcc-linje, der kun indeholder deres e-mail-adresse, er mest almindelig. Dette giver ingen indikation af en Bcc til Til- og Cc-modtagerne og indikerer at Bcc-modtagere, at de fik tilsendt e-mailen ved hjælp af Bcc uden at afsløre andre Bcc-modtagere.

Kommentarer

  • each Bcc'ed address receives a Bcc line containing only their email address, is most common. Er det? Det kræver, at du sender beskeden flere gange i stedet for en enkelt besked med flere RCPT TO: kommandoer. Hvilken MUA ville gøre det?
  • @EsaJokinen Hvilket andet valg har MUA, når modtagerne er på forskellige domæner? BCC tvinger simpelthen denne adfærd.
  • MUA sender den kun en gang til MTA, og MTA begynder at levere den separat til alle de forskellige domæner.Sagen er, at MTAer vandt ‘ t gider normalt ikke at tilføje RCPT TO som Bcc:. Det ‘ er mere sandsynligt i en Received: header som for <[email protected]>.
  • At ‘ er sandt: du ved, at du var Bcc ‘ d (eller på anden måde ikke afsløret) fra ikke at være på To & Cc overskrifter. MUA gemmer bare Bcc når den gemmer e-mailen til afsenderens Send-mappe, men den ‘ er ikke en del af meddelelsen sendt via SMTP .
  • @EsaJokinen Gmail gør dette – det inkluderer faktisk Bcc header i meddelelsen. Jeg kender ikke ‘ om andre, der gør det.

Svar

Typisk ikke muligt, hvis du ikke har kontrol over afsenderens SMTP-server, da dette felt ikke transmitteres til modtagerens SMTP-server.

Når du sender en mail, kontrollerer afsenderens SMTP-server BCC-felt og opretter en kopi for hver modtager, der er anført, hvor listen over andre modtagere fjernes. Det er hele pointen med BCC-funktionalitet.

Svar

Anmodning om kommentarer (RFC) -standard (offentliggjort af Internet Engineering Task Force (IETF)) specificerer, at modtagere af en e-mail, der sendes til modtagere, der er specificeret i “BCC” -overskriften, muligvis modtager e-mailen, men ikke er opmærksom på andre modtagere, der er nævnt i overskriften. Specifikt skal “adresser ikke afsløres til andre modtagere af meddelelsen”.

Det er en anmodning (ikke et mandat) til SMTP-servere for at afspejle den nuværende praksis (protokol) for Internetsamfundet b y Internetsamfundet.

Men de, der findes ikke kompatible kan være adskilt og hvis det viser sig at være slyngel, vil det blive forbudt / sortlistet og endog retsforfulgt når fundet at udføre aktiviteter i strid med lovgivningen i jurisdiktionen.

Så hvis du er” modtager af en e-mail fra en kompatibel (mail) server, vil du ikke modtage andre modtager-e-mails, der er nævnt i “BCC” -feltet, medmindre du har kontrol over den afsendende (SMTP) server, den indkommende (POP, IMAP osv.) -server og alle de relayservere, der dirigerede IP-pakkerne.

Kommentarer

  • ” De, der ikke overholdes, kan være adskilt, og hvis de viser sig at være slyngelagtige, vil blive forbudt / sortlistet og endog retsforfulgt, når det konstateres, at de udfører aktiviteter i strid med lovgivningen i jurisdiktionen. ” – Jeg vil su ggest dette er et yderst usandsynligt resultat for en server, der lækkede BCC-adresser. Hvis en meddelelse desuden er BCC ‘ d til [email protected] og [email protected], og foo.com og y.com har forskellige SMTP-servere, vil bar.com desuden ikke engang modtage [email protected] ‘ s adresse, der skal lækkes, så der ville ikke være noget punkt i ” adskille ” det, da dets lækager kun påvirker dets egne brugere.
  • Er der love, der kræver IETF RFC-overholdelse for e-mail-systemer nu?
  • @grawity: Du ‘ ville være på udkig efter love, der foreskriver anvendelse af bedste praksis , almindeligt accepterede metoder og lignende generiske udsagn. Jf. GDPR 5.1 (f) ” passende tekniske eller organisatoriske foranstaltninger ”
  • @MSalters antages formentlig ordinere snarere end det modsatte, udskrive …
  • @gravity ikke direkte, men en server, der afslørede oplysninger på trods af standarder, siger ellers ville få sin operatør til at overtræde forskellige love om privatliv som GDPR eller CCPA)

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *