Sử dụng đúng tiêu đề SMTP


20

Ứng dụng web của chúng tôi gửi tin nhắn email cho mọi người khi ai đó đăng nội dung mới. Cả người gửi và người nhận đã chọn nhận email từ ứng dụng của chúng tôi. Khi chuẩn bị một thông báo như vậy, chúng tôi đặt các tiêu đề SMTP sau:

TỪ: tác giả@example.com
ĐẾN: receive@example.com
GỬI: webapp@mycompany.com

Chúng tôi đã chọn sử dụng địa chỉ email của tác giả trong tiêu đề TỪ để cố gắng cung cấp trải nghiệm tốt nhất cho người nhận; Khi họ nhìn thấy thư trong ứng dụng thư của họ, tác giả rõ ràng. Để tránh sự giả mạo, chúng tôi đã thêm tiêu đề SENDER (có địa chỉ email của công ty chúng tôi) để làm rõ rằng chúng tôi đã gửi tin nhắn thay mặt cho tác giả. Sau khi đọc RFC 822 và 2822, đây dường như là mục đích sử dụng của tiêu đề người gửi.

Hầu hết các máy chủ nhận thư dường như xử lý tốt điều này; thư email được gửi bình thường (giả sử hộp thư người nhận tồn tại, không vượt quá dung lượng, v.v.). Tuy nhiên, khi gửi tin nhắn TỪ một địa chỉ trong một tên miền ĐẾN một địa chỉ trong cùng một tên miền, một số tên miền nhận từ chối các tin nhắn có phản hồi như:

571 IP không chính xác - psmtp (trả lời lệnh RCPT TO)

Tôi nghĩ điều này có nghĩa là máy chủ nhận chỉ thấy rằng địa chỉ tiêu đề TỪ nằm trong miền của chính nó và thông báo có nguồn gốc từ máy chủ mà nó không cho phép gửi tin nhắn cho tên miền đó. Nói cách khác, máy chủ nhận đã bỏ qua tiêu đề SENDER.

Chúng tôi có một cách giải quyết: ứng dụng web giữ một danh sách các tên miền dường như bỏ qua tiêu đề SENDER và khi các tiêu đề TỪ và TO đều ở trong một miền như vậy, nó sẽ đặt tiêu đề TỪ thành địa chỉ email của chúng tôi. Nhưng danh sách này yêu cầu bảo trì.

Có cách nào tốt hơn để đạt được trải nghiệm mong muốn? Chúng tôi muốn trở thành một "công dân tốt" của mạng và tất cả các bên liên quan - người gửi và người nhận - muốn tham gia và nhận những tin nhắn này. Một cách khác là luôn luôn sử dụng địa chỉ email của công ty chúng tôi trong tiêu đề TỪ và thêm tên / địa chỉ của tác giả vào chủ đề, nhưng điều này có vẻ hơi vụng về.


Tại sao không sử dụng From: authorthay thế From: author@example.com?
Pacerier

Câu trả lời:


16

Bạn đang nhìn vào những điều sai trái. Đó là những tiêu đề tin nhắn . Bạn nên nhìn vào phong bì SMTP . (Cách phong bì được chỉ định tùy thuộc vào cách chính xác, ứng dụng của bạn đang gửi thư đến hệ thống thư. Trên nhiều hệ thống, phong bì được chỉ định bởi các đối số dòng lệnh cho chương trình tiện ích gửi thư.) Tùy thuộc vào chính xác khi nào trong giao dịch giao thức nó quyết định đưa ra phản hồi 571, máy chủ SMTP Relay có thể thậm chí không nhìn thấy các tiêu đề thư.

Văn bản phản hồi nói rằng quản trị viên của máy chủ Chuyển tiếp SMTP cụ thể mà bạn đang nói chuyện đã hạn chế những gì bạn có thể đặt trong phong bì SMTP. Nó dường như đang phàn nàn về phần người nhận của phong bì. Nhưng nó có thể trì hoãn xác nhận của người gửi phong bì cho đến khi đặc điểm kỹ thuật của người nhận đầu tiên, vì vậy nó có thể phàn nàn về người gửi.

Lưu ý rằng người gửi phong bì là nơi gửi thông điệp trạng thái gửi và bạn sẽ không muốn gửi tin nhắn đến những người ngẫu nhiên trên khắp thế giới. (Ngoài thực tế là nhiều người không thích điều này, sẽ không có ý nghĩa gì khi thông báo trạng thái gửi thư của bạn được gửi lại cho bất kỳ ai trừ bạn.) Chỉ định bạn là người gửi phong bì.

Bằng cách này, việc yêu cầu MXhồ sơ tài nguyên là sai . Một máy chủ chuyển tiếp SMTP có thể được định vị bởi AAAAAcác bản ghi tài nguyên trong trường hợp không có bất kỳ MXbản ghi tài nguyên nào . Xem RFC 5321 § 5.1.


Tôi đã kiểm tra RFC trước khi thực hiện kiểm tra bản ghi MX và đã học được điều tương tự: kiểm tra dự phòng Bản ghi trong trường hợp không có bản ghi MX. Tôi sẽ xem xét phong bì SMTP; cám ơn vì sự gợi ý.
Eric Rath

Tôi đã nghiên cứu phong bì SMTP, đã thử nghiệm điều này. Bạn nói đúng - Tôi giả định không chính xác tất cả kiểm tra nguồn gốc sẽ sử dụng tiêu đề thư "Từ", nhưng có vẻ như phong bì được sử dụng thay thế.
Eric Rath

5

Tôi có thể sai, nhưng nguyên nhân rất có thể gây ra lỗi trên, đặc biệt là trong trường hợp của Postini, là các miền mà bạn đang bị từ chối có chính sách SPF nghiêm ngặt. Hầu hết các máy chủ thư có kiểm tra SPF sẽ chỉ kiểm tra tiêu đề From :, họ sẽ không quan tâm đến tiêu đề Người gửi.

Để kiểm tra xem đây có phải là trường hợp chạy "dig + short TXT domain.com" trong đó domain.com là thông báo lỗi cho bạn. Bạn nên lấy lại một cái gì đó như:

"v = spf1 mx -all"

Phần quan trọng là -all. Điều này có nghĩa là chủ sở hữu tên miền đã tuyên bố rằng họ sẽ chỉ gửi email từ các máy chủ hoạt động như máy chủ thư của họ, tất cả các thư khác sẽ bị từ chối.

May mắn thay, nếu đây là trường hợp, bạn có thể chủ động kiểm tra trước khi gửi email! Nhận WebApp để kiểm tra SPF khi người dùng đặt địa chỉ email của họ. Nếu có một chính sách nghiêm ngặt, hãy thêm tên miền vào danh sách của bạn. Không thiếu thư viện cho tất cả các ngôn ngữ có thể thực hiện kiểm tra SPF.


Cảm ơn, đó là một ý tưởng tốt. Tôi đã kiểm tra (với đào) một số tên miền đã được trình bày với hành vi không mong muốn và một cặp đã có bản ghi SPF với ~ tất cả. Vì vậy, nó không phải là một giải pháp hoàn chỉnh, nhưng tôi nghĩ sẽ khó tìm được giải pháp hoàn chỉnh cho vấn đề này. Tôi nghĩ rằng những người khác đang thực thi logic cơ bản tương tự, nhưng không lưu trữ / xuất bản thông tin trong các bản ghi SPF.
Eric Rath

Ý tưởng của bạn đề xuất một kiểm tra xác thực khác để thực hiện: tên miền của địa chỉ phải có bản ghi MX hợp lệ. Nếu ai đó nhập sai địa chỉ email của họ và lỗi nằm ở phần tên miền của địa chỉ (ví dụ: person@domainn.com), việc gửi sẽ thất bại vì không thể tìm thấy bản ghi MX cho tên miền (giả sử lỗi không dẫn đến khác nhau, nhưng vẫn còn hiệu lực, tên miền).
Eric Rath

Tôi đã thay đổi "người trả lời được chấp nhận" thành JdeBP bên dưới - sự khác biệt giữa tiêu đề thư và tiêu đề phong bì thực sự đóng đinh nó. Nhưng cảm ơn đã phản hồi.
Eric Rath

5
Khắc phục: SPF kiểm tra "MAIL TỪ" trong phong bì, không phải tiêu đề "Từ" hoặc "Người gửi".
Simon East
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.