Hvordan kan jeg avmaske e-postadressene i et Bcc-felt når jeg bare er mottaker?

Trenger veldig enkle, trinnvise instruksjoner for noen som ikke koder. Jeg har mottatt en gruppe-e-post og vil gjerne se de andre som har fått den.

Kommentarer

  • Å ikke kunne gjøre dette er det nøyaktige punktet med Bcc.
  • Jeg har en følelse der ‘ et oppfølgingsspørsmål som kommer på arbeidsplassen. SE
  • Du må hacke deg inn på SMTP-serveren som sendte deg e-postmeldingen og dechiffrere de innkommende loggene for å se BCC. Du, som en gjennomsnittlig person vil mest sannsynlig ha vanskelig for å oppnå dette …
  • @chrylis For å være rettferdig er det så mange tilfeller der informasjon som ikke skal være ‘ ikke er tilgjengelig bare skjult, for at jeg kan forstå hvordan en person tror det kan være mulig.
  • Ingenting enklere. Saksend avsenderen og bruk en stevning for å tvinge avsløring av den opprinnelige meldingen.

Svar

Du kan ikke «t. Du vil ganske enkelt ikke ha noen informasjon om Bcc-overskriften når du mottar e-posten, så du er ikke noe å «avmaske».

Slik Bcc er designet er spesifisert i RFC 2822 , under avsnitt 3.6.3. For å sitere spesifikasjonen:

Feltet «Bcc:» (der «Bcc» betyr «Blind Carbon Copy») inneholder adressene til mottakerne av meldingen hvis adresser ikke skal avsløres for andre mottakere av meldingen. Det er tre måter «Bcc:» -feltet brukes på. I det første tilfellet, når en melding som inneholder et «Bcc:» -felt er forberedt på å bli sendt, fjernes «Bcc:» -linjen, selv om alle mottakerne (inkludert de som er spesifisert i «Bcc:» -feltet) får en kopi av meldingen. I det andre tilfellet får mottakere spesifisert i linjene «Til:» og «Kopi:» hver en kopi av meldingen med linjen «Bcc:» fjernet som ovenfor, men mottakerne på «Bcc:» -linjen får en separat kopi av meldingen som inneholder en «Bcc:» -linje. (Når det er flere mottakeradresser i «Bcc:» -feltet, sender noen implementeringer faktisk en separat kopi av meldingen til hver mottaker med en «Bcc:» som bare inneholder adressen til den aktuelle mottakeren.) Til slutt, siden en «Bcc»: : «felt kan ikke inneholde adresser, et» Bcc: «-felt kan sendes uten noen adresser som indikerer mottakerne at blinde kopier ble sendt til noen. Hvilken metode som skal brukes med «Bcc:» -felt er implementeringsavhengig, men se delen «Sikkerhetshensyn» i dette dokumentet for en diskusjon av hver.

Når en melding er et svar på en annen melding, postkasser til forfatterne av den opprinnelige meldingen (postkassene i «Fra:» -feltet) eller postkasser spesifisert i «Svar til:» -feltet (hvis den finnes) KAN vises i «Til:» -feltet i svaret siden disse vil normalt være de viktigste mottakerne av svaret. Hvis et svar sendes til en melding som har destinasjonsfelt, er det ofte ønskelig å sende en kopi av svaret til alle mottakerne av meldingen, i tillegg til forfatteren. Når et slikt svar dannes, KAN adresser i «Til:» og «Cc:» -feltene i den opprinnelige meldingen vises i «Cc:» -feltet i svaret, siden disse vanligvis er sekundære mottakere av svaret. Hvis et «Bcc:» -felt er tilstede i den originale meldingen, KAN adresser i det feltet vises i «Bcc:» -feltet i svaret, men SKAL IKKE vises i «Til:» eller «Cc:» -feltene.

Merk: Noen e-postprogrammer har automatiske svarskommandoer som inkluderer destinasjonsadressene til den opprinnelige meldingen i destinasjonsadressene til svaret. Hvordan svarskommandoer oppfører seg er avhengig av implementering og ligger utenfor omfanget av dette dokumentet. Spesielt om ikke de opprinnelige destinasjonsadressene skal inkluderes eller ikke når den originale meldingen hadde et «Svar til:» -felt, adresseres ikke her.

I praktisere tilfellet hvor Til- og kopimottakere mottar ingen Bcc-linje, men hver Bcc-adresse mottar en Bcc-linje som bare inneholder e-postadressen, er vanligst. Dette gir ingen indikasjon på en Bcc til To og Cc-mottakerne, og indikerer Bcc-mottakerne at de fikk tilsendt e-posten via bruk av Bcc uten å avsløre andre Bcc-mottakere.

Kommentarer

  • each Bcc'ed address receives a Bcc line containing only their email address, is most common. Er det? Det ville kreve at du sendte meldingen flere ganger i stedet for en enkelt melding med flere RCPT TO: kommandoer. Hva MUA ville gjort det?
  • @EsaJokinen Hvilket annet valg har MUA når mottakerne er på forskjellige domener? BCC tvinger ganske enkelt den oppførselen.
  • MUA sender den bare en gang til MTA, og MTA begynner å levere den separat til alle de forskjellige domenene.Saken er at MTA-er vant ‘ t pleier ikke å legge til RCPT TO som Bcc:. Det ‘ er mer sannsynlig i en Received: overskrift som for <[email protected]>.
  • At ‘ stemmer: du vet at du var Bcc ‘ d (eller på annen måte ikke oppgitt) fra å ikke være på To & Cc overskrifter. MUA lagrer bare Bcc når den lagrer e-posten til avsenderen Sendt-mappe, men den ‘ er ikke en del av meldingen sendt via SMTP .
  • @EsaJokinen Gmail gjør dette – det inkluderer faktisk Bcc overskriften i meldingen. Jeg vet ikke ‘ om andre som gjør det.

Svar

Vanligvis ikke mulig hvis du ikke har kontroll over avsenderens SMTP-server siden dette feltet ikke overføres til mottakerens SMTP-server.

Når du sender en e-post, sjekker avsenderens SMTP-server BCC-felt og oppretter en kopi for hver mottaker som er oppført, og fjerner listen over andre mottakere. Det er hele poenget med BCC-funksjonalitet.

Svar

Forespørsel om kommentarer (RFC) -standard (publisert av The Internet Engineering Task Force (IETF)) spesifiserer at mottakere av en e-post, sendt til mottakere spesifisert i «BCC» -overskriften, kan motta e-posten, men ikke være klar over andre mottakere nevnt i overskriften. Spesielt «adresser skal ikke avsløres til andre mottakere av meldingen».

Det er en forespørsel (ikke et mandat) til SMTP-servere for å gjenspeile gjeldende praksis (protokoll) for Internetsamfunnet b y Internett-samfunnet.

Imidlertid fant de ikke -kompatible kan være adskilt og hvis det blir funnet å være useriøs, vil det bli utestengt / svartelistet, og til og med straffeforfølgt når funnet å utføre aktiviteter i strid med lovene i jurisdiksjonen.

Så hvis du er mottaker av en e-post fra en kompatibel (e-post) server, vil du ikke motta annen mottakers e-postmeldinger som er nevnt i «BCC» -feltet, med mindre du har kontroll over den sendende (SMTP) serveren, den innkommende (POP, IMAP, osv.) serveren og alle reléservere som rutet IP-pakkene.

Kommentarer

  • » De som ikke er kompatible, kan være adskilt, og hvis de finner seg å være useriøse, vil bli utestengt / svartelistet og til og med tiltalt når det blir funnet å utføre aktiviteter i strid med lover i jurisdiksjonen. » – Jeg vil su ggest dette er et ekstremt usannsynlig resultat for en server som lekker BCC-adresser. Hvis en melding er BCC ‘ d til [email protected] og [email protected], og foo.com og y.com har forskjellige SMTP-servere, vil bar.com dessuten ikke engang motta [email protected] ‘ -adressen som skal lekke, så det ville ikke være noe poeng i » å adskille » det da dets lekkasjer bare påvirker sine egne brukere.
  • Er det lover som krever IETF RFC-samsvar for e-postsystemer nå?
  • @grawity: Du ‘ leter etter lover som foreskriver anvendelse av best practices , allment aksepterte metoder og lignende generiske uttalelser. Jf. GDPR 5.1 (f) » passende tekniske eller organisatoriske tiltak »
  • @MSalters antok antagelig foreskriver i stedet for det motsatte, foreskriver
  • @grawity ikke direkte, men en server som avslørte informasjon til tross for standarder, sier at det ellers ville føre til at operatøren brøt ulike personvernlover ( som GDPR eller CCPA)

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *