อีเมลที่ส่งถึงฉันถูกส่งไปที่ MAIL@MAIL.COM สิ่งนี้ทำได้อย่างไร


103

ฉันเพิ่งถูกส่งอีเมลหลอกลวงและสำหรับหัวเราะคิกคักฉันเปิดมันขึ้นมาเพื่ออ่านมัน ธรรมดามากและไม่ต้องพยายามมากนัก

ฉันสังเกตเห็นบางสิ่งที่แปลกประหลาด อีเมลนี้ไม่ได้ส่งถึงฉัน ตอนแรกฉันสงสัยว่า CC หรือ BCC แต่ไม่มีที่อยู่ของฉันในจดหมาย ฉันได้ให้ภาพด้านล่าง สิ่งนี้ทำได้อย่างไร

ป้อนคำอธิบายรูปภาพที่นี่


8
โพสต์ส่วนหัวของข้อความแบบเต็ม ... นอกจากนี้คุณอาจมีที่อยู่ SMTP สำรองในเซิร์ฟเวอร์อีเมลที่อาจถูกส่งไปยัง ผู้ดูแลระบบเซิร์ฟเวอร์อีเมลจะสามารถช่วยแนะนำคุณเกี่ยวกับสิ่งนี้ได้ แต่จะแก้ไขคำตอบของคุณและโพสต์รายละเอียดส่วนหัวของข้อความแบบเต็มของข้อความนี้ด้วย
Pimp Juice IT

55
คุณอาจอยู่ในเขตสำเนาคนตาบอดของอีเมล
Mokubai

61
คุณจะไม่ได้ดูรายการ BCC, ที่ "B" ส่วนลินด์ ;)
Ƭᴇcʜιᴇ007

14
@tuskiomi ไม่ไม่ใช่ใน Outlook Gmail มีการแสดงbcc: meบางทีคนอื่นก็ทำเช่นกัน ... แต่ถ้าคุณดูที่ส่วนหัวของข้อความแบบเต็มคุณควรเห็นอีเมลของคุณที่นั่น
wysiwyg

20
@tuskiomi - ไม่คุณจะไม่เห็นใครที่อยู่ใน BCC ไม่ใช่แม้แต่ตัวคุณเอง นอกจากนี้หากเป็นจดหมายขยะอาจไม่มีรายการ BCC จริง สแปมแวร์สามารถจัดการรายชื่อผู้รับได้ตามที่ต้องการและสิ่งที่สำคัญที่สุดคือสิ่งที่บทสนทนาของสแปมแวร์กับเซิร์ฟเวอร์อีเมลมีลักษณะอย่างไรไม่ใช่เนื้อหาของจดหมาย วิธีเดียวที่คุณจะเห็นที่อยู่อีเมลของคุณคือถ้าคุณดูที่ส่วนหัวอินเทอร์เน็ต
Jeff Zeitlin

คำตอบ:


152

ข้อความอีเมลอินเทอร์เน็ตประกอบด้วยสองส่วน เราสามารถดูพวกเขาเป็นซองจดหมายและข้อความน้ำหนักบรรทุกหรือเพียงแค่ข้อความ

ซองจดหมายมีข้อมูลการกำหนดเส้นทาง:โดยหลักแล้วนี่คือที่อยู่ผู้ส่งและที่อยู่ผู้รับหนึ่งรายหรือมากกว่า

ข้อความมีเนื้อหาข้อความ:บรรทัดหัวเรื่องเนื้อหาข้อความสิ่งที่แนบและอื่น ๆ นอกจากนี้ยังมีข้อมูลทางเทคนิคบางอย่างเช่นReceived:ส่วนหัวtrace ( ) ข้อมูล DKIM และอื่น ๆ เช่นเดียวกับการแสดงผู้ส่งและผู้รับที่อยู่ (สิ่งที่คุณเห็นในFrom, ToและCcเขตข้อมูลในไคลเอ็นต์อีเมลของคุณ)

นี่คือปมของมัน: ทั้งสองไม่ต้องเห็นด้วย!

เซิร์ฟเวอร์อีเมลจะดูข้อมูลซองจดหมายเพื่อกำหนดวิธีการส่งข้อความ ในทางกลับกันมีข้อยกเว้นเล็กน้อยข้อความนั้นจะถือว่าเป็นเพียงข้อมูล โดยเฉพาะอย่างยิ่งเซิร์ฟเวอร์เมลที่ทำงานได้ดีจะไม่ดูTo:และCc:ฟิลด์ของข้อความเพื่อกำหนดรายชื่อผู้รับและจะไม่ดูที่From:ฟิลด์เพื่อระบุที่อยู่ของผู้ส่ง

เมื่อคุณเขียนและส่งอีเมลไคลเอ็นต์อีเมลของคุณจะใช้สิ่งที่คุณป้อนในฟิลด์ถึงสำเนาถึงและสำเนาลับถึงและแปลว่าเป็นข้อมูลการกำหนดเส้นทางซองจดหมาย สิ่งนี้ทำได้โดยการลบชื่อเต็ม (ทิ้งที่อยู่อีเมลเท่านั้น) แต่สามารถเกี่ยวข้องกับสิ่งต่าง ๆ เช่นการเขียนที่อยู่การขยายชื่อแทนและอื่น ๆ ผลลัพธ์คือรายการที่อยู่อีเมลที่กำหนดให้กับเซิร์ฟเวอร์อีเมลที่ไคลเอ็นต์อีเมลของคุณกำลังพูดถึงเป็นรายชื่อผู้รับ รายการถึงและสำเนาถึงถูกเก็บไว้ในอีเมล แต่สำเนาลับถึงไม่ได้ส่งต่อไปยังเซิร์ฟเวอร์ทำให้ไม่สามารถมองเห็นผู้รับข้อความได้ ที่อยู่ผู้ส่งทำงานคล้ายกันมาก

เมื่อข้อความมาถึงปลายทางสุดท้ายข้อมูลซองจดหมายจะถูกโยนทิ้งหรือเก็บไว้ในส่วนหัวของข้อความโดยละเอียด นั่นเป็นส่วนหนึ่งของเหตุผลที่ฝ่ายไอทีของ Spittin ขอให้มีส่วนหัวของข้อความแบบเต็มในการแสดงความคิดเห็นต่อคำถามของคุณ

นอกจากนี้ยังมีอีเมลทางอินเทอร์เน็ตก็เป็นไปได้ที่จะพูดคุยโดยตรงกับเซิร์ฟเวอร์อีเมลและทำให้ฉีดข้อความที่มีข้อมูลที่ไม่ตรงกันระหว่างซองจดหมายและข้อมูลข้อความที่ปกติมีความประพฤติดีอีเมลไคลเอ็นต์จะไม่ ให้คุณแต่ง นอกจากนี้เมลเซิร์ฟเวอร์จะตรวจสอบองศาที่แตกต่างกันของที่อยู่ผู้ส่งที่ระบุไว้ในข้อมูลซองจดหมาย บางคนแทบตรวจสอบเลยเพื่อให้แน่ใจว่าเป็นที่อยู่อีเมลที่ถูกต้องsyntactically ส่วนหัว From ของข้อมูลข้อความจะถูกตรวจสอบอย่างละเอียดแม้แต่น้อย

เนื่องจากไคลเอนต์ที่รับอีเมลแสดงสิ่งที่อยู่ในส่วนหัวจากถึงถึงและสำเนาถึงไม่ใช่ข้อมูลที่อยู่จากซองจดหมายจึงเป็นไปได้ที่จะนำสิ่งที่คุณต้องการไปใช้และไคลเอนต์อีเมลที่รับจะไม่มีการขอความช่วยเหลือ มีความแม่นยำพอสมควร สำหรับจดหมายที่ถูกกฎหมายมักจะมีความถูกต้องเพียงพอ สำหรับสแปมมันแทบไม่เคยเป็น

ในโลกของการมีตัวตนวัตถุทางกายภาพที่อาศัยอยู่โดยเราเพียงมนุษย์ผู้ส่งซองจดหมายและซองจดหมายผู้รับสอดคล้องกับที่อยู่ผู้ส่งและผู้รับที่อยู่ตามลำดับที่คุณเขียนที่ด้านนอกของซองจดหมาย; และFrom:และTo:/ และCc:ส่วนหัวจะตรงกับสิ่งที่คุณใส่เป็นที่อยู่ของคุณและผู้รับตามลำดับในจดหมายที่คุณใส่ในซองจดหมาย


8
ฉันหวังว่าผู้คนจะสร้างการเปรียบเทียบในโลกแห่งความเป็นจริงมากขึ้นที่นี่เพื่อคนอื่น ๆ จะเข้าใจว่าอะไรคือความเท่าเทียมกันทางกายภาพ "ผู้ส่ง" ของอีเมลเปรียบเสมือนบุคคลที่ส่งซองจดหมาย ที่อยู่ "จาก" คือที่อยู่ที่ต้องการ เช่นคุณอาจเป็นเลขาส่งในนามของคนอื่น ฯลฯ
Mehrdad

21
@Mehrdad ไม่; ที่อยู่ผู้ส่งซองจดหมาย (SMTP) เป็นเหมือนที่อยู่ผู้ส่งที่ด้านนอกของซองจดหมาย (ซึ่งจะถูกส่งหากไม่สามารถส่งได้) ในขณะที่ที่อยู่ในFromส่วนหัวเป็นสิ่งที่คุณเขียนบนกระดาษที่คุณติดข้างในซองจดหมายและที่บุรุษไปรษณีย์ไม่รู้ด้วยซ้ำ
CVn

ฉันกำลังคิดถึงเฮดเดอร์ผู้ส่ง: เมื่อฉันเขียนมันและมันก็เป็นแค่ตัวอย่าง แค่พูดว่าเป็นการดีที่จะเพิ่มตัวอย่างเช่นนี้ในคำตอบ
Mehrdad

91
ปริมาณของตัวหนาที่นี่มันไม่จำเป็นที่ดีที่สุด และนั่นเป็นเพียงความเห็นของฉัน
JakeGould

3
@SupremeGrandRuler เนื่องจากข้อมูลผู้รับ (ในทางตรงกันข้ามกับผู้ส่งหรือเส้นทางกลับที่เป็นไปได้) ไม่มีอยู่ในอีเมล ลองนึกภาพรายชื่อผู้รับแบบเต็มรวมถึงที่อยู่ที่ MUA ได้รับจากช่องสำเนาลับถึง (จำไว้ว่า: SMTP (โพรโทคอลซองจดหมาย) ไม่ทราบเกี่ยวกับสำเนาลับถึงเพียงรู้เกี่ยวกับผู้รับ) …นั่นเป็นปัญหาความเป็นส่วนตัว เสียพื้นที่มาก) ไม่เพียง แต่ในรายชื่อผู้รับจดหมายขนาดใหญ่ (ดำเนินการตามหลักการเดียวกับที่ Bcc ทำ)
Jonas Schäfer

23

tl; dr ที่ด้านล่าง

โปรโตคอล SMTP ไม่มีแนวคิดของผู้รับ CC หรือ BCC นี่คือการประชุมที่จัดขึ้นโดยไคลเอนต์จดหมาย โดยทั่วไปแล้วเซิร์ฟเวอร์ SMTP จะสนใจเฉพาะข้อมูลเส้นทางและข้อมูลเท่านั้น นี่คือความแตกต่างที่สำคัญเพราะหากไม่มีความสามารถนี้ BCC จะไม่มีอยู่จริง ในฐานะที่เป็นการสื่อสาร BCC ที่ถูกต้องตามกฎหมายให้พิจารณาการถอดเสียงลูกค้าดังต่อไปนี้:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

ในกรณีนี้ Anonymous ได้ส่งข้อความเกี่ยวกับการประชุมนี้ อย่างไรก็ตามเมลเวอร์ชันนี้ไม่ได้ถูกส่งไปที่ Jane Doe; เธอไม่รู้อะไรเลยเกี่ยวกับผู้ไม่ประสงค์ออกนามได้รับแจ้ง ในทางตรงกันข้าม Jane Doe จะได้รับข้อความที่มีเนื้อหาและส่วนหัวที่แตกต่างกัน:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

ที่นี่เนื่องจาก Anonymous อยู่ใน BCC ข้อความที่ส่งถึง Jane Doe จึงไม่รวมรายชื่อผู้รับ BCC เนื่องจากการประชุม BCC ซองจดหมายอาจไม่รวมผู้รับที่ได้รับข้อความจริงและอาจรวมถึงผู้รับที่ไม่ปรากฏในส่วนหัวของข้อความ

ตามที่กล่าวไว้โดย@JonasWielickiซึ่งฉันตั้งใจจะรวมไว้ก็คือ MUA (Mail User Agent) มักจะรับผิดชอบในการส่งอีเมลหลายฉบับที่จำเป็นต้องใช้งาน BCC เซิร์ฟเวอร์อีเมลไม่รู้อะไรเกี่ยวกับ BCC ดังนั้น MUA จะต้องใช้งาน BCC โดยส่งอีเมลหลายฉบับด้วยเส้นทางอีเมลที่แตกต่างกันที่ระบุไว้ในส่วนหัวซองจดหมาย ด้วยเหตุผลนี้ BCC มักจะใช้เวลาในการส่งนานกว่าอีเมลปกติเนื่องจากต้องสร้างและส่งเนื้อหาข้อความที่แตกต่างกัน

นอกจากนี้ยังช่วยให้มีกฎการปฏิบัติตามอีเมลบางอย่าง ตัวอย่างเช่นเซิร์ฟเวอร์อีเมลอาจมีกฎที่กำหนดค่าให้ BCC เป็นเซิร์ฟเวอร์อีเมลเก็บถาวรโดยอัตโนมัติ (อีเมลทั้งหมดที่ส่งถึงจะถูกเก็บถาวรด้วย) ซึ่งในกรณีนี้เซิร์ฟเวอร์อีเมลอาจไม่ได้เป็นผู้รับจริง

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

ที่นี่ผู้รับเป็นอีกฝ่ายหนึ่งที่ไม่เปิดเผยต่อผู้รับหรือแม้แต่ผู้ส่ง นี่คือคุณสมบัติของโปรโตคอลซึ่งโดยปกติจะใช้ในการส่งต่อหรือเก็บข้อความ

สิ่งที่ข้อความสแปมทำคือใช้ประโยชน์จากพฤติกรรมดังกล่าว เป็นช่องโหว่มาตรฐานที่ทางเทคนิคควรทำงานกับเซิร์ฟเวอร์อีเมลที่สอดคล้องกัน แน่นอนเซิร์ฟเวอร์ที่อัปเดตจำนวนมากใช้ "ส่วนขยาย" เช่น DKIM เพื่อยืนยันว่าอีเมลดังกล่าวเป็นของแท้ แต่ก็ยังมีเซิร์ฟเวอร์อีเมลเก่าอีกหลายตัวที่ไม่สนใจเพราะเพียงเพราะมันเป็นการล่อลวงที่จะไม่แก้ไขสิ่งที่ไม่ขาด

โปรดทราบด้วยว่าฉันได้ระบุส่วนหัววันที่อย่างไร นี่อาจเป็นค่าใดก็ได้ (แต่มีรูปแบบที่ดี) ลูกค้าหลายคนจะแสดงช่วงวันที่ตามกฎหมายอย่างมีความสุขตั้งแต่อดีตอันไกลโพ้นไปจนถึงอนาคตไกล ฉันได้ส่งอีเมลส่วนตัวถึงตัวเองเมื่อหลายปีก่อนที่จะยังคงอยู่ที่ด้านบนของกล่องจดหมายของฉันนานหลังจากที่คาดหวังในชีวิตของฉันเช่นเดียวกับอีเมลที่มีมาก่อนบัญชีอีเมลของฉันและเกิดของฉันเอง

TL; DR

ดังนั้นโดยสรุปผู้ส่งหลอกอีเมลเซิร์ฟเวอร์ต้นทางที่ได้รับการยอมรับ / ถ่ายทอดมันเซิร์ฟเวอร์อีเมลของคุณยอมรับและเก็บไว้ในกล่องจดหมายของคุณและลูกค้าของคุณแสดงข้อมูลที่อยู่ในกล่องจดหมายของคุณอย่างซื่อสัตย์โดยไม่ต้องหลีกเลี่ยง ความปลอดภัยใด ๆ ความปลอดภัย "การส่ง" มักจะถูก จำกัด ความปลอดภัยน้อยกว่า "การรับ" ในมุมมองนั้นเนื่องจาก POP3 ต้องใช้ชื่อผู้ใช้และรหัสผ่านเกือบทุกครั้งก่อนที่คุณจะสามารถเข้าถึงกล่องจดหมายได้ (คุณสามารถหลีกเลี่ยงสิ่งนี้ได้ในทางทฤษฎี บริการอีเมลที่ทำ)


3
คุณควรทราบว่าการลอก Bcc โดยทั่วไปจะไม่ได้รับการจัดการโดยเมลเซิร์ฟเวอร์ (การถอดเสียง SMTP ที่คุณให้ไว้จะแนะนำเป็นอย่างอื่นเนื่องจาก HELO จะฟังดูเหมือนเซิร์ฟเวอร์อีเมลไม่ใช่ MUA) หากต้องการส่งสำเนาที่มีส่วนหัวสำเนาลับถึงแก่บุคคลที่ระบุในส่วนหัวนั้นต้องทำงานพิเศษโดย MUA โดยส่งอีเมลสองฉบับแยกกัน
Jonas Schäfer

@ JonasWielicki นั่นเป็นจุดที่ดี ฉันได้เพิ่มการแก้ไขลงในเอฟเฟกต์นั้นแล้ว
phyrfox

5
ถ้าคุณเพิ่มบรรทัดสำเนาลับไปยังอีเมลส่งมันไม่ได้เป็นคนตาบอดอีกต่อไป :)
Eckes

1
ที่จริงแล้วลูกค้าต้องการให้ส่งหลายข้อความในกรณีของ BCC ไม่ถูกต้อง มันเป็นเสียงที่สมบูรณ์แบบในการส่งข้อความเพียงครั้งเดียว ไคลเอ็นต์ SMTP สามารถแสดงรายการRCPT TOคำสั่งได้หลายคำสั่ง ข้อกำหนดเพียงอย่างเดียวคือเซิร์ฟเวอร์ SMTP ที่ได้รับนั้นเป็นเซิร์ฟเวอร์ที่มีสิทธิ์สำหรับผู้รับทั้งสองหรือยินดีที่จะส่งต่อสิ่งที่มันไม่ได้เป็น
Patrick

6

SMTP และอีเมลเป็นบริการอินเทอร์เน็ตที่เก่าแก่มากในยุคที่การรักษาความปลอดภัยและการรับรองความถูกต้องได้รับความสนใจน้อยมาก (DNS เป็นอีกตัวอย่างหนึ่ง) การออกแบบโพรโทคอลไม่มีความพยายามในการตรวจสอบความถูกต้องของที่อยู่ผู้ส่งและตรวจสอบความถูกต้องของที่อยู่ผู้รับตราบเท่าที่มั่นใจว่าอีเมลนั้นสามารถส่งมอบได้

อีเมลถูกส่งผ่านโปรโตคอล SMTP โปรโตคอล SMTP นั้นค่อนข้างโง่ มันให้ความสะดวกในการส่งข้อความธรรมดาไปยังที่อยู่อีเมลและน้อยมาก โครงสร้างของธรรมดานี้จะถูกกำหนดโดยRFC 5322 แนวคิดทั่วไปคือข้อความอีเมลมีข้อมูลเมตาที่เรียกว่าส่วนหัวและเนื้อหาข้อความจริงของข้อความ ส่วนหัวอีเมลนี้สร้างโดยผู้ส่ง (ไม่มีส่วนใดที่เชื่อถือได้) และมีฟิลด์เช่น "ถึง:", "จาก:", "หัวเรื่อง:", ฯลฯ ...

โปรโตคอล SMTP ไม่ได้ (และไม่ควร) ตรวจสอบว่าส่วนหัวของอีเมลตรงกับสิ่งใด ๆ ที่กำหนดไว้ในโปรโตคอล SMTP ซึ่งเป็นที่อยู่อีเมลของคุณและที่อยู่อีเมลของผู้ส่งซึ่งไม่ได้รับการตรวจสอบ แต่อย่างใด

เกือบทุกอย่างในข้อความอีเมลอาจเป็นของปลอม

สิ่งเดียวที่เชื่อถือได้ในระยะไกลเกี่ยวกับเนื้อหาอีเมลในวันนี้คือลายเซ็น DKIM ซึ่งพิสูจน์ว่าอีเมลได้รับการดำเนินการผ่านเซิร์ฟเวอร์อีเมลที่ถูกลงโทษโดยผู้จดทะเบียนโดเมน คุณจะพบว่าอีเมลหลอกลวงนี้ไม่มีลายเซ็น DKIM


ฉันจะเพิ่มReceived:ส่วนหัวสุดท้ายที่เพิ่มโดยระบบของคุณเองในส่วนที่น่าเชื่อถือ
Hagen von Eitzen

3

ที่อยู่Toในส่วนหัวของอีเมลมีวัตถุประสงค์เพื่อให้ข้อมูลและจะแสดงโดยไคลเอนต์อีเมล ที่อยู่ผู้รับที่แท้จริงจะได้รับRCPT TOใน SMTP มันจะเหมือนกันถ้าคุณเขียนจดหมายใส่ซองจดหมายเขียนที่อยู่ 1 ลงบนซองจดหมาย จากนั้นไปที่ผู้ให้บริการจัดส่งให้ที่อยู่อื่น 2 ผู้ให้บริการจัดส่งซองจดหมายของคุณในซองจดหมายขนาดใหญ่ที่มีที่อยู่ 2 และการจัดส่งจะไปที่นั่น เลขาของคุณ (ซอฟต์แวร์ไคลเอนต์อีเมล) วางซองจดหมายภายนอกไปที่ถังขยะและแสดงซองจดหมายภายในด้วย Address-1 คุณสามารถเห็นสิ่งนี้ได้ด้วยมุมมอง RAW ของข้อความอีเมล


2

นี่เป็นรูปลักษณ์ที่แตกต่างกันเล็กน้อยโดยอิงจากการตรวจสอบส่วนหัว คำตอบอื่น ๆ จัดการกับรายละเอียดของ SMTP ได้ดีกว่าที่ฉันสามารถทำได้

ถ้าคุณได้รับส่วนหัวเต็มรูปแบบของข้อความของคุณแล้วค้นหาพวกเขาสำหรับที่อยู่ของคุณคุณอาจพบว่าในเขตที่เรียกว่าEnvelope-to, หรือDelivered-to X-Apparently-toผู้ให้บริการอีเมลรายแรกของฉันถูกใช้งานครั้งที่สองโดย Gmail ฉันเคยเห็นที่สามใช้เช่นกัน เหล่านี้เป็นเขตข้อมูลที่แตกต่างกัน แต่สำหรับวัตถุประสงค์ของเรามักจะหมายถึงสิ่งเดียวกัน: กล่องจดหมายเพื่อส่งข้อความจริง ฉันทดสอบโดยการส่งจาก outlook (เวอร์ชันเดสก์ท็อป) กับผู้รับ BCCed

ผู้ให้บริการอีเมลของฉันยังใช้Delivered-Toฟิลด์ แต่สำหรับชื่อกล่องจดหมายบนเซิร์ฟเวอร์ของพวกเขา นี่ไม่ใช่ที่อยู่อีเมลของฉันแม้ว่าจะดูเหมือน (คิดChrisH-$ACCOUNTNAME@$SERVER.mail.com)

Outlook (รวมกับเซิร์ฟเวอร์การแลกเปลี่ยน) ในทางกลับกันจะไม่รวมอยู่ในส่วนหัวของเขตข้อมูลเดียวด้วยที่อยู่อีเมลของผู้รับหากคุณอยู่ในรายการ BCC

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.