Email gửi cho tôi được gửi đến MAIL@MAIL.COM. Làm thế nào được thực hiện?

Gần đây tôi đã được gửi một email lừa đảo, và vì những tiếng cười khúc khích tôi đã mở nó ra để đọc nó. Rất đơn giản, và không có nhiều nỗ lực ném vào.

Tôi nhận thấy một cái gì đó đặc biệt; email này không được gửi đến tôi. Lúc đầu, tôi nghi ngờ một CC, hoặc BCC, nhưng không nơi nào có địa chỉ của tôi trên thư. Tôi đã cung cấp một hình ảnh dưới đây. Làm thế nào được thực hiện?

Một tin nhắn e-mail Internet bao gồm hai phần. Chúng ta có thể gọi chúng là phong bì và tin nhắn tải trọng hoặc đơn giản là tin nhắn .

Phong bì có dữ liệu định tuyến: chủ yếu, đây là địa chỉ người gửi và một hoặc nhiều địa chỉ người nhận.

Tin nhắn có nội dung tin nhắn: dòng chủ đề, nội dung tin nhắn, tệp đính kèm, v.v. Nó cũng mang một số thông tin kỹ thuật như Received:tiêu đề dấu vết ( ), dữ liệu DKIM, v.v. cũng như hiển thị người gửi và người nhận địa chỉ (những gì bạn thấy trong From, Tovà Cccác lĩnh vực trong ứng dụng thư của bạn).

Đây là mấu chốt của nó: Hai người không cần phải đồng ý!

Một máy chủ thư sẽ xem xét dữ liệu phong bì để xác định cách gửi thư. Mặt khác, với một vài ngoại lệ, bản thân tin nhắn sẽ được coi là dữ liệu. Đặc biệt, một máy chủ thư hoạt động tốt không nhìn vào To:và Cc:các trường của chính thư để xác định danh sách người nhận, cũng không nhìn vào From:trường để xác định địa chỉ của người gửi.

Khi bạn soạn và gửi e-mail, ứng dụng khách email của bạn sẽ nhận những gì bạn đã nhập vào các trường Đến, Cc và Bcc và dịch nó thành thông tin định tuyến phong bì. Điều này chủ yếu được thực hiện bằng cách xóa bất kỳ tên đầy đủ (chỉ để lại địa chỉ email), nhưng cũng có thể liên quan đến những thứ như viết lại địa chỉ, mở rộng bí danh, v.v. Kết quả là một danh sách các địa chỉ email được cung cấp cho máy chủ thư mà ứng dụng thư khách của bạn đang nói chuyện với tư cách là danh sách người nhận. Danh sách To và Cc được giữ trong e-mail, nhưng Bcc không được chuyển đến máy chủ, khiến nó trở nên vô hình đối với người nhận tin nhắn. Địa chỉ người gửi hoạt động rất giống nhau.

Khi tin nhắn đến đích cuối cùng, dữ liệu phong bì sẽ bị vứt đi hoặc được giữ lại trong các tiêu đề tin nhắn chi tiết. Đó là một phần lý do tại sao Spittin 'IT yêu cầu các tiêu đề thư đầy đủ trong một bình luận cho câu hỏi của bạn.

Ngoài ra, với e-mail Internet, có thể nói chuyện trực tiếp với máy chủ thư và do đó tiêm một thư có sự không khớp giữa dữ liệu phong bì và dữ liệu thư mà một ứng dụng email thông thường, hoạt động tốt sẽ không để bạn sáng tác Ngoài ra, các máy chủ thư thực hiện các mức độ kiểm tra khác nhau đối với địa chỉ người gửi mà họ được cung cấp trong dữ liệu phong bì; một số hầu như không kiểm tra nó ngoài việc đảm bảo đó là một địa chỉ email hợp lệ về mặt cú pháp . Tiêu đề From của dữ liệu tin nhắn phải chịu sự giám sát thậm chí ít hơn.

Vì ứng dụng khách nhận email hiển thị những gì trong các tiêu đề Từ, Đến và Cc, không phải dữ liệu địa chỉ từ phong bì, nên bạn có thể đặt bất cứ thứ gì bạn muốn ở đó và ứng dụng khách nhận email sẽ không cần truy vấn mà phải tin rằng nó là chính xác hợp lý. Đối với thư hợp pháp thường là đủ chính xác; đối với thư rác, nó gần như không bao giờ.

Trong thế giới của hữu hình, đối tượng vật lý nơi sinh sống của chúng ta chỉ là con người, các phong bì gửi và nhận trên phong bì tương ứng với địa chỉ trả lại và nhận địa chỉ, tương ứng, mà bạn viết ở bên ngoài của phong bì; và tiêu đề From:và To:/ Cc:tương ứng với bất cứ thứ gì bạn đặt làm địa chỉ của bạn và người nhận, tương ứng, trong thư bạn đặt trong phong bì.

tl; dr ở dưới cùng.

Giao thức SMTP không có khái niệm về người nhận CC hoặc BCC; đây là một hội nghị được tổ chức bởi các khách hàng thư. Máy chủ SMTP thường chỉ quan tâm đến việc định tuyến thông tin và dữ liệu. Đây là một sự khác biệt quan trọng, vì không có khả năng này, BCC không thể tồn tại. Là một giao tiếp BCC hợp pháp, hãy xem xét bảng điểm khách hàng sau đây:

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.

.

Bây giờ, trong trường hợp này, Anonymous đã được gửi một tin nhắn về cuộc họp này. Tuy nhiên, phiên bản thư này không được chuyển đến Jane Doe; cô ấy không biết gì về việc Ẩn danh được thông báo. Ngược lại, Jane Doe sẽ được gửi tin nhắn với nội dung và tiêu đề khác:

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.

.

Ở đây, vì Anonymous đã ở BCC, tin nhắn được gửi cho Jane Doe không bao gồm danh sách người nhận BCC. Do quy ước BCC, phong bì email có thể không bao gồm những người nhận thực sự nhận được tin nhắn và nó cũng có thể bao gồm những người nhận không xuất hiện trong tiêu đề thư.

Như @JonasWielicki đã đề cập , mà tôi cũng muốn nói đến, đó là MUA (Tác nhân người dùng thư) thường chịu trách nhiệm gửi nhiều email được yêu cầu để triển khai BCC. Máy chủ email không biết gì về BCC và vì vậy MUA phải triển khai BCC bằng cách gửi nhiều email với các tuyến email khác nhau được chỉ định trong tiêu đề phong bì. Vì lý do này, BCC thường mất nhiều thời gian hơn so với email thông thường, bởi vì các nội dung thư khác nhau phải được xây dựng và gửi riêng lẻ.

Điều này cũng giúp với một số quy tắc tuân thủ email. Ví dụ: máy chủ thư có thể có các quy tắc được định cấu hình để tự động BCC một máy chủ email lưu trữ (tất cả các email được gửi tới nó cũng được lưu trữ), trong trường hợp đó, máy chủ thư thậm chí có thể không phải là người nhận thực.

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.

.

Ở đây, người nhận là một bên khác hoàn toàn không được tiết lộ cho bất kỳ người nhận hoặc thậm chí người gửi. Đây là một tính năng của giao thức, thường được sử dụng trong chuyển tiếp hoặc lưu trữ tin nhắn.

Những gì tin nhắn rác này đã làm là tận dụng hành vi đó. Đó là một lỗ hổng tiêu chuẩn mà về mặt kỹ thuật nên hoạt động với bất kỳ máy chủ thư tuân thủ nào. Tất nhiên, nhiều máy chủ được cập nhật sử dụng các "tiện ích mở rộng" như DKIM để xác minh rằng một email như vậy là xác thực, nhưng vẫn còn nhiều máy chủ thư cũ không quan tâm, đơn giản là vì nó không thể sửa những thứ không bị hỏng.

Cũng lưu ý cách tôi đã chỉ định một tiêu đề Ngày. Đây có thể là bất kỳ giá trị tùy ý (nhưng được định dạng tốt); nhiều khách hàng sẽ vui vẻ hiển thị bất kỳ phạm vi ngày hợp pháp nào từ quá khứ xa đến tương lai xa. Cá nhân tôi đã gửi một email cho chính mình nhiều năm trước, nó sẽ vẫn ở đầu hộp thư của tôi rất lâu sau tuổi thọ của tôi, cũng như một email có trước tài khoản email và ngày sinh của tôi.

tl; dr

Vì vậy, tóm lại, người gửi đã giả mạo một email, máy chủ thư gốc đã chấp nhận / chuyển tiếp nó, máy chủ email của bạn chấp nhận và lưu trữ nó trong hộp thư đến của bạn và khách hàng của bạn hiển thị một cách trung thực dữ liệu trong hộp thư đến của bạn, mà không cần tránh né bất kỳ bảo mật. Bảo mật "Gửi" thường bị hạn chế ít hơn nhiều so với bảo mật "nhận" trong phối cảnh đó, vì POP3 hầu như luôn yêu cầu tên người dùng và mật khẩu trước khi bạn có thể truy cập hộp thư (về mặt lý thuyết bạn có thể phá vỡ điều này, nhưng tôi không biết về bất kỳ điều gì hợp pháp dịch vụ mail mà làm).

SMTP và email là những dịch vụ Internet rất cũ từ thời đại mà bảo mật và xác thực được coi trọng ít hơn nhiều (DNS là một ví dụ khác). Thiết kế của giao thức không nỗ lực xác minh tính xác thực của địa chỉ người gửi và chỉ xác nhận địa chỉ người nhận trong chừng mực vì nó đảm bảo rằng thư có thể gửi được.

Email được truyền qua giao thức SMTP. Giao thức SMTP tương đối ngu ngốc; nó cung cấp một phương tiện để truyền bản rõ đến một địa chỉ email và rất ít nữa. Cấu trúc của bản rõ này được xác định bởi RFC 5322 . Ý tưởng chung là văn bản email có siêu dữ liệu được gọi là tiêu đề và nội dung văn bản thực sự của thư. Tiêu đề email này được tạo bởi người gửi (không ai có thể tin cậy được) và chứa các trường như "đến:", "từ:", "chủ đề:", v.v ...

Giao thức SMTP không (và không được coi là) xác nhận rằng các tiêu đề email khớp với bất kỳ một vài điều được xác định trong giao thức SMTP, về cơ bản là địa chỉ email của bạn và địa chỉ email người gửi không bao giờ được xác thực theo bất kỳ cách nào.

Hầu như tất cả mọi thứ trong một email có thể là giả mạo.

Điều duy nhất thậm chí đáng tin cậy từ xa về nội dung email ngày nay là chữ ký DKIM, chứng minh rằng email đã được xử lý thông qua một máy chủ email bị người đăng ký tên miền xử phạt. Tìm hiểu sâu hơn, bạn sẽ thấy rằng email lừa đảo này không có chữ ký DKIM.

Địa chỉ Totrong tiêu đề email là dành cho mục đích thông tin và nó được hiển thị bởi ứng dụng email. Địa chỉ người nhận thực sự được cung cấp RCPT TOtrong SMTP. Điều này cũng tương tự nếu bạn viết thư, đặt trong phong bì, viết Địa chỉ-1 trên phong bì. Sau đó đi chuyển phát nhanh, cho một Địa chỉ khác-2. Chuyển phát nhanh đặt phong bì của bạn trong phong bì lớn hơn với Địa chỉ-2 và lô hàng sẽ đến đó. Thư ký của bạn (phần mềm ứng dụng email) đặt phong bì bên ngoài vào thùng rác và hiển thị cho bạn phong bì nội bộ với Địa chỉ-1. Bạn có thể thấy điều này với chế độ xem RAW của thông điệp email.

Đây là một cái nhìn hơi khác nhau, dựa trên việc kiểm tra các tiêu đề. Các câu trả lời khác xử lý các chi tiết của SMTP tốt hơn tôi có thể.

Nếu bạn có thể nhận được đầy đủ các tiêu đề của tin nhắn, sau đó tìm kiếm chúng cho địa chỉ của bạn, bạn có thể tìm thấy nó trong một trường được gọi là Envelope-to, Delivered-tohoặc X-Apparently-to. Cái đầu tiên được sử dụng bởi nhà cung cấp thư của tôi, cái thứ hai bởi Gmail; Tôi đã thấy thứ ba được sử dụng là tốt. Đây là các lĩnh vực khác nhau nhưng cho mục đích của chúng tôi có xu hướng có cùng một ý nghĩa: hộp thư để thực sự gửi thư vào. Tôi đã kiểm tra bằng cách gửi từ triển vọng (phiên bản máy tính để bàn) với người nhận BCCed.

Nhà cung cấp thư của tôi cũng sử dụng Delivered-Totrường nhưng cho tên hộp thư trên máy chủ của họ. Đây không phải là địa chỉ email của tôi mặc dù nó trông giống như một địa chỉ (nghĩ ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Mặt khác, Outlook (kết hợp với máy chủ trao đổi) không bao gồm trong các tiêu đề một trường duy nhất có địa chỉ email của người nhận nếu bạn được liệt kê là BCC.