Hur kan jag ta bort e-postadresserna i ett Bcc-fält när jag bara är mottagare?

Behöver väldigt enkla steg-för-steg-instruktioner för någon som inte kodar. Jag har fått ett grupp-e-postmeddelande och vill verkligen se de andra som fick det.

Kommentarer

  • Att inte kunna göra detta är den exakta punkten för Bcc.
  • Jag har en känsla där ’ en uppföljningsfråga som kommer på arbetsplatsen.SE
  • Du måste hacka in SMTP-servern som skickade e-postmeddelandet och dechiffrera inkommande loggar för att se BCC. Du som en genomsnittlig person kommer sannolikt att ha svårt att uppnå detta …
  • @chrylis För att vara rättvis finns det så många fall där information som inte ’ inte är tillgänglig är bara dold, så att jag kan förstå hur en person tror att det kan vara möjligt.
  • Inget enklare. Stämma avsändaren och använd en stämning för att tvinga avslöjandet av det ursprungliga meddelandet.

Svar

Du kan inte ”t. Du kommer helt enkelt inte att ha någon information om Bcc-rubriken när du får e-postmeddelandet, så det finns inget att ”avmaska”.

Sättet för Bcc är designat i RFC 2822 , under avsnitt 3.6.3. För att citera specifikationen:

Fältet ”Bcc:” (där ”Bcc” betyder ”Blind Carbon Copy”) innehåller adresser till mottagare av meddelandet vars adresser inte ska avslöjas för andra mottagare av meddelandet. Det finns tre sätt på vilket fältet ”Bcc:” används. I det första fallet, när ett meddelande som innehåller ett ”Bcc:” -fält är berett att skickas, tas raden ”Bcc:” bort även om alla mottagare (inklusive de som anges i fältet ”Bcc:”) skickas en kopia av meddelandet. I det andra fallet skickas mottagare som anges i raderna ”Till:” och ”Cc:” var och en en kopia av meddelandet med raden ”Bcc:” borttagen enligt ovan, men mottagarna på ”Bcc:” -raden får en separat kopia av meddelandet som innehåller en ”Bcc:” -rad. (När det finns flera mottagaradresser i fältet ”Bcc:” skickar vissa implementeringar faktiskt en separat kopia av meddelandet till varje mottagare med en ”Bcc:” som bara innehåller adressen till den specifika mottagaren.) Slutligen, eftersom ett ”Bcc” : ”fältet får innehålla inga adresser, ett” Bcc: ”-fält kan skickas utan några adresser som indikerar mottagarna att blinda kopior har skickats till någon. Vilken metod som ska användas med ”Bcc:” -fält är beroende av implementering, men se avsnittet ”Säkerhetsöverväganden” i detta dokument för en diskussion om vart och ett.

När ett meddelande är ett svar på ett annat meddelande, brevlådor till författarna till det ursprungliga meddelandet (postlådorna i fältet ”Från:”) eller postlådor som anges i fältet ”Svara till:” (om det finns) KAN visas i fältet ”Till:” i svaret eftersom dessa skulle normalt vara de främsta mottagarna av svaret. Om ett svar skickas till ett meddelande som har destinationsfält är det ofta önskvärt att skicka en kopia av svaret till alla mottagare av meddelandet, förutom författaren. När ett sådant svar bildas, KAN adresser i fälten ”Till:” och ”Cc:” i originalmeddelandet visas i ”Cc:” -fältet i svaret, eftersom dessa normalt är sekundära mottagare av svaret. Om ett ”Bcc:” -fält finns i originalmeddelandet, KAN adresser i det fältet visas i ”Bcc:” -fältet i svaret, men FÅR INTE visas i fälten ”Till:” eller ”Cc:”.

Obs! Vissa e-postapplikationer har automatiska svarskommandon som inkluderar måladresserna för det ursprungliga meddelandet i destinationsadresserna för svaret. Hur dessa svarskommandon beter sig beror på implementeringen och ligger utanför detta dokument. I synnerhet huruvida de ursprungliga destinationsadresserna ska inkluderas eller inte när det ursprungliga meddelandet hade ett ”Svar till:” -fält adresseras inte här.

I öva det fall där Till- och CC-mottagare inte får någon Bcc-rad, men varje Bcc-adress får en Bcc-rad som endast innehåller deras e-postadress, är vanligast. Detta ger ingen indikation på en Bcc till Till- och Cc-mottagarna och indikerar att Bcc-mottagarna att de fick e-postmeddelandet via Bcc utan att avslöja andra Bcc-mottagare.

Kommentarer

  • each Bcc'ed address receives a Bcc line containing only their email address, is most common. Är det? Det kräver att du skickar meddelandet flera gånger istället för ett enda meddelande med flera RCPT TO: -kommandon. Vilken MUA skulle göra det?
  • @EsaJokinen Vilket annat val har MUA när mottagarna är på olika domäner? BCC tvingar helt enkelt det beteendet.
  • MUA skickar det bara en gång till MTA och MTA börjar leverera det separat till alla olika domäner.Saken är att MTA vant ’ t brukar bry sig om att lägga till RCPT TO som Bcc:. Det ’ är mer troligt i en Received: rubrik som for <[email protected]>.
  • Att ’ är sant: du vet att du var Bcc ’ d (eller på annat sätt ej avslöjad) från att inte vara på To & Cc rubriker. MUA sparar bara Bcc när e-posten sparas till avsändarens mapp, men den ’ är inte en del av meddelandet som skickas via SMTP .
  • @EsaJokinen Gmail gör detta – det innehåller faktiskt rubriken Bcc i meddelandet. Jag vet inte ’ om andra som gör det.

Svar

Vanligtvis inte möjligt om du inte har kontroll över avsändarens SMTP-server eftersom detta fält inte överförs till mottagarens SMTP-server.

När du skickar ett e-postmeddelande kontrollerar avsändarens SMTP-server BCC-fält och skapar en kopia för varje listad mottagare och tar bort listan över andra mottagare. Det är hela poängen med BCC-funktionalitet.

Svar

RFC-standard (Request For Comments) (publicerad av Internet Engineering Task Force (IETF)) anger att mottagare av ett e-postmeddelande som skickas till mottagare som anges i rubriken ”BCC” får ta emot e-postmeddelandet men inte känner till någon annan mottagare som nämns i rubriken. Specifikt, ”adresser ska inte avslöjas för andra mottagare av meddelandet”.

Det är en begäran (inte ett mandat) till SMTP-servrar för att återspegla aktuell praxis (protokoll) för Internetsamhället b y Internet Society.

De som befanns vara dock inte kompatibla får vara segregerad och om den visar sig vara oseriös kommer den att förbjudas / svartlistas och till och med åtalas när visat sig bedriva verksamhet i strid med lagar i jurisdiktionen.

Så om du är mottagare av ett e-postmeddelande från en kompatibel (e-post) server, kommer du inte att få andra mottagarens e-postmeddelanden som nämns i fältet ”BCC”, såvida du inte har kontroll över den sändande (SMTP) servern, den inkommande (POP, IMAP, etc) servern och alla relayservrar som dirigerade IP-paketen.

Kommentarer

  • ” De som inte överensstämmer kan separeras och om de visar sig vara oseriösa, kommer att förbjudas / svartlistas och till och med lagföras när de visar sig bedriva verksamhet i strid med lagar i jurisdiktionen. ” – Jag skulle vilja ggest detta är ett extremt osannolikt resultat för en server som läckt BCC-adresser. Om ett meddelande dessutom är BCC ’ d till [email protected] och [email protected], och foo.com och y.com har olika SMTP-servrar, kommer bar.com dessutom inte ens ta emot [email protected] ’ -adressen att läcka, så det skulle inte vara någon mening att ” segregera ” eftersom dess läckage bara påverkar sina egna användare.
  • Finns det lagar som kräver IETF RFC-överensstämmelse för e-postsystem nu?
  • @grawity: Du ’ jag letar efter lagar som föreskriver tillämpning av bästa metoder , allmänt accepterade metoder och liknande generiska uttalanden. Jfr. GDPR 5.1 (f) ” lämpliga tekniska eller organisatoriska åtgärder ”
  • @MSalters menade antagligen förskriv snarare än motsatsen, föreskriv …
  • @gravity inte direkt utan en server som avslöjade information trots att standarder säger att annars skulle få operatören att bryta mot olika sekretesslagar ( som GDPR eller CCPA)

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *