Kan ik e-mailadressen ophalen van BCC?

Je kunt “t. Je hebt gewoon geen informatie over de Bcc-header wanneer je de mail ontvangt, dus je hoeft niets te “ontmaskeren”.

De manier waarop Bcc is ontworpen, wordt gespecificeerd in RFC 2822 , onder sectie 3.6.3. Om de specificatie te citeren:

Het veld “Bcc:” (waarbij de “Bcc” “Blind Carbon Copy” betekent) bevat adressen van ontvangers van het bericht wiens adressen niet mogen worden onthuld aan andere ontvangers van het bericht. Er zijn drie manieren waarop het veld “Bcc:” wordt gebruikt. In het eerste geval, wanneer een bericht met een “Bcc:” -veld wordt voorbereid om te worden verzonden, wordt de “Bcc:” -regel verwijderd, hoewel alle ontvangers (inclusief degene die zijn gespecificeerd in het “Bcc:” -veld) een kopie van het bericht. In het tweede geval wordt aan de ontvangers die zijn gespecificeerd in de regels “Aan:” en “Cc:” elk een kopie van het bericht gestuurd met de regel “Bcc:” verwijderd zoals hierboven beschreven, maar de ontvangers op de regel “Bcc:” krijgen een aparte kopie van het bericht met een “Bcc:” -regel. (Als er meerdere adressen van ontvangers in het veld Bcc: staan, sturen sommige implementaties in feite een afzonderlijke kopie van het bericht naar elke ontvanger met een Bcc: die alleen het adres van die specifieke ontvanger bevat.) Ten slotte, aangezien een Bcc : “veld mag geen adressen bevatten, een” Bcc: “veld kan worden verzonden zonder adressen die aan de ontvangers aangeven dat er blinde kopieën naar iemand zijn gestuurd. Welke methode te gebruiken met “Bcc:” -velden is afhankelijk van de implementatie, maar raadpleeg de sectie “Beveiligingsoverwegingen” van dit document voor een bespreking van elk.

Wanneer een bericht een antwoord is op een ander bericht, mailboxen van de auteurs van het originele bericht (de mailboxen in het veld “Van:”) of mailboxen gespecificeerd in het veld “Antwoord aan:” (indien aanwezig) KUNNEN verschijnen in het veld “Aan:” van het antwoord, aangezien deze normaal gesproken de primaire ontvangers van het antwoord zijn. Als een antwoord wordt verzonden op een bericht met bestemmingsvelden, is het vaak wenselijk om naast de auteur ook een kopie van het antwoord naar alle ontvangers van het bericht te sturen. Wanneer een dergelijk antwoord wordt gevormd, kunnen adressen in de velden “Aan:” en “Cc:” van het originele bericht verschijnen in het veld “Cc:” van het antwoord, aangezien dit normaal gesproken secundaire ontvangers van het antwoord zijn. Als een “Bcc:” -veld aanwezig is in het oorspronkelijke bericht, KUNNEN adressen in dat veld verschijnen in het “Bcc:” -veld van het antwoord, maar MOETEN NIET verschijnen in de “Aan:” – of “Cc:” -velden.

Opmerking: sommige mailtoepassingen hebben automatische antwoordopdrachten die de bestemmingsadressen van het originele bericht opnemen in de bestemmingsadressen van het antwoord. Hoe deze antwoordopdrachten zich gedragen, is afhankelijk van de implementatie en valt buiten het bestek van dit document. Met name het al dan niet opnemen van de oorspronkelijke bestemmingsadressen wanneer het oorspronkelijke bericht een “Reply-To:” -veld had, wordt hier niet vermeld.

In praktijk waarbij de ontvangers Aan en Cc geen Bcc-regel ontvangen, maar elk Bcc-adres een Bcc-regel ontvangt die alleen hun e-mailadres bevat, is het meest gebruikelijk. Dit geeft geen indicatie van een Bcc voor de ontvangers Aan en Cc, en geeft aan dat de Bcc “ed-ontvangers dat ze de e-mail hebben ontvangen via het gebruik van Bcc zonder andere Bcc-ontvangers te onthullen.

Opmerkingen

• each Bcc'ed address receives a Bcc line containing only their email address, is most common. Is het? Dat zou betekenen dat het bericht meerdere keren moet worden verzonden in plaats van een enkel bericht met meerdere RCPT TO: -opdrachten. Welke MUA zou dat doen?
• @EsaJokinen Welke andere keuze heeft de MUA als de ontvangers zich op verschillende domeinen bevinden? BCC dwingt dat gedrag gewoon af.
• De MUA stuurt het slechts één keer naar de MTA, en de MTA begint het afzonderlijk aan alle verschillende domeinen te bezorgen.Het punt is dat MTAs ‘ meestal niet de moeite nemen om RCPT TO toe te voegen als Bcc:. Het ‘ is waarschijnlijker in een Received: header als for <[email protected]>.
• Dat ‘ is waar: je weet dat je Bcc ‘ d was (of anderszins niet bekendgemaakt) omdat je niet op de To & Cc kopteksten. MUA slaat alleen de Bcc op bij het opslaan van de e-mail in de Sent-map van de afzender, maar ‘ maakt geen deel uit van het bericht dat via SMTP is verzonden .
• @EsaJokinen Gmail doet dit – het bevat eigenlijk de Bcc koptekst in het bericht. Ik ‘ weet niet van anderen die het doen.

Request For Comments (RFC) -standaard (gepubliceerd door The Internet Engineering Task Force (IETF)) specificeert dat ontvangers van een e-mail, verzonden naar ontvangers die zijn gespecificeerd in de “BCC” -header, de e-mail mogen ontvangen, maar niet op de hoogte zijn van andere ontvangers vermeld in de koptekst. Meer specifiek “adressen mogen niet worden onthuld aan andere ontvangers van het bericht”.

Het is een verzoek (geen mandaat) aan SMTP-servers om de huidige praktijk (protocol) weer te geven voor de internetgemeenschap b y De internetmaatschappij.

Die zijn echter niet compatibel kan worden gescheiden en als het bedrieglijk wordt bevonden, wordt het verbannen / op de zwarte lijst gezet en zelfs vervolgd wanneer blijkt activiteiten te ontplooien die in strijd zijn met de wetten in de jurisdictie.

Dus als u” een ontvanger bent van een e-mail van een compatibele (mail) server, zult u geen andere e-mails van ontvangers vermeld in het veld “BCC”, tenzij je de controle hebt over de verzendende (SMTP) server, de inkomende (POP, IMAP, enz.) server en alle relay-servers die de IP-pakketten hebben gerouteerd.

Reacties

• ” De reacties die niet aan de regels voldoen, kunnen worden gescheiden en als ze als frauduleus worden beschouwd, wordt verbannen / op de zwarte lijst gezet en zelfs vervolgd wanneer wordt betrapt op activiteiten die in strijd zijn met de wetten in de jurisdictie. ” – Ik zou aanklagen ggest dit is een uiterst onwaarschijnlijke uitkomst voor een server die BCC-adressen heeft gelekt. Bovendien, als een bericht BCC ‘ d naar [email protected] en [email protected] is, en foo.com en y.com verschillende SMTP-servers hebben, zal bar.com zelfs niet het adres van [email protected] ‘ ontvangen om te lekken, dus het zou geen zin hebben om ” te scheiden ” aangezien zijn lekken alleen zijn eigen gebruikers treffen.
• Zijn er wetten die IETF RFC-conformiteit voor e-mailsystemen vereisen?
• @grawity: You ‘ zou op zoek zijn naar wetten die het toepassen van best practices , algemeen aanvaarde methoden en vergelijkbare algemene verklaringen verbieden. Cf. GDPR 5.1 (f) ” passende technische of organisatorische maatregelen ”
• @MSalters bedoelde vermoedelijk voorschrijven in plaats van het tegenovergestelde, verbieden …
• @grawity niet rechtstreeks, maar een server die informatie openbaarde ondanks standaarden die anders beweren dat de operator verschillende privacywetten zou overtreden ( zoals GDPR of CCPA)