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 ต้องใช้ชื่อผู้ใช้และรหัสผ่านเกือบทุกครั้งก่อนที่คุณจะสามารถเข้าถึงกล่องจดหมายได้ (คุณสามารถหลีกเลี่ยงสิ่งนี้ได้ในทางทฤษฎี บริการอีเมลที่ทำ)