Các vấn đề tiềm năng khi sử dụng địa chỉ "từ" của thành viên và tiêu đề "người gửi"

Question

Một thành phần chính của ứng dụng của chúng tôi sẽ gửi email đến các thành viên thay mặt cho các thành viên khác. Hiện tại, chúng tôi đặt địa chỉ "Từ" đến địa chỉ hệ thống của chúng tôi và sử dụng tiêu đề "Trả lời" với địa chỉ của thành viên. Vấn đề là các thư trả lời từ một số ứng dụng email (và trả lời tự động/trả lại) không tôn trọng tiêu đề "Trả lời" để được gửi tới địa chỉ hệ thống của chúng tôi, gửi chúng đến lỗ đen một cách hiệu quả. Chúng tôi đang xem xét việc đặt địa chỉ "Từ" đến địa chỉ của thành viên của chúng tôi và địa chỉ "Người gửi" vào địa chỉ hệ thống của chúng tôi. Nó xuất hiện theo cách này sẽ vượt qua kiểm tra SPF và Sender-ID.

Có bất kỳ lý do nào không chuyển sang phương pháp này không? Có bất kỳ vấn đề tiềm năng nào khác không?

---

Dưới đây là cách chi tiết hơn có thể bạn cần:

Khi ứng dụng được phát triển đầu tiên, chúng tôi chỉ thay đổi "từ" địa chỉ để được rằng các thành viên gửi như đó là thực tế phổ biến tại thời gian (điều này đã được nhiều năm trước). Sau đó chúng tôi thay đổi đó để có "từ" địa chỉ có tên của thành viên và địa chỉ của chúng tôi, tức là,

From: "Mary Smith" <messages@company.example>

Với "reply-to" tiêu đề thiết lập để địa chỉ của thành viên:

Reply-To: "Mary Smith" <marysmith@memberisp.example>

này giúp với những thông điệp được được phân loại sai là spam. Như SPF trở nên phổ biến hơn, chúng tôi đã thêm một tiêu đề bổ sung mà sẽ làm việc kết hợp với các bản ghi SPF của chúng tôi:

Tên người gửi: <messages@company.example>

điều cần làm việc OK, nhưng nó chỉ ra rằng, trong thực tế, một số khách hàng email và hầu hết các MTA không tôn trọng tiêu đề "Trả lời". Bởi vì điều này, nhiều thành viên gửi tin nhắn đến messages@company.example thay vì thành viên mong muốn. Vì vậy, tôi bắt đầu hình dung các sơ đồ khác nhau để thêm dữ liệu về người gửi vào tiêu đề email hoặc mã hóa nó trong địa chỉ email "từ" để chúng tôi có thể xử lý phản hồi và chuyển hướng một cách thích hợp. Ví dụ,

From: "Mary Smith" <messages+ca54bb7482ace09f@company.example>

nơi chuỗi sau "thông điệp" là một hash đại diện cho thành viên Mary Smith trong hệ thống của chúng tôi. Tất nhiên, con đường đó có thể dẫn đến rất nhiều đau đớn khi chúng ta cần phát triển chức năng MTA cho địa chỉ hệ thống của chúng ta. Tôi đang tìm kiếm một lần nữa tại các tài liệu SPF và tìm thấy trang này thú vị:

http://www.openspf.org/Best_Practices/Webgenerated

Họ thấy hai ví dụ, đó là evite.com và của egreetings.com. Về cơ bản, evite.com đang làm theo cách chúng ta đang làm. Ví dụ egreetings.com sử dụng thành viên từ địa chỉ với tiêu đề "Người gửi" được thêm vào.

Vì vậy, câu hỏi đặt ra là, có bất kỳ vấn đề tiềm ẩn nào khi sử dụng phương thức egreetings của thành viên từ địa chỉ với tiêu đề người gửi không? Điều đó sẽ loại bỏ các câu trả lời mà khách hàng xấu gửi đến địa chỉ hệ thống. Tôi không tin rằng nó giải quyết vấn đề thư bị trả lại/kỳ nghỉ/danh sách trắng vì những thư này thường gửi tới MAIL FROM ngay cả khi Đường dẫn trả lại được chỉ định.

Answer 1

Vì vậy, tôi quyết định trả lời câu hỏi của riêng mình vì không có ai khác trả lời. Có lẽ những người khác sẽ tìm thấy mục này khi tìm kiếm.

Điều chúng tôi đang làm cuối cùng là:

Đặt tiêu đề Từ thành địa chỉ email thực tế của người dùng.

From: "Mary Smith" <marysmith@memberisp.example> 

Sử dụng tiêu đề Người gửi với địa chỉ email hệ thống rộng.

Sender: <messages@company.example> 

Cuối cùng, người gửi thực tế mà xuất hiện trong máy chủ MAIL cung cấp TỪ/Return tiêu đề Con đường được thiết lập với một định danh duy nhất, tức là,

Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example> 

đó cho phép một chương trình chạy ở thông điệp @ công ty .example để chặn các thư trả lời tự động đó và chuyển tiếp chúng đến người mà chúng được dự định ban đầu. Hầu hết các ứng dụng email thực sẽ trả lời tiêu đề Từ:. Tôi đã không thấy vấn đề từ người dùng blackberry và những người khác không trả lời tài khoản hệ thống.

Sau một tháng hoặc lâu hơn trong quá trình sản xuất, chúng tôi có ít vấn đề hơn so với phương pháp trước đây mà chúng tôi đang sử dụng.

Tiêu đề người gửi thêm một ghi chú nhỏ trong ứng dụng khách Microsoft Outlook về "Thay mặt cho" nhưng điều đó phù hợp cho việc sử dụng của chúng tôi. Chưa có bất kỳ vấn đề với SPF trong các khách hàng thông thường/mta với thiết lập này (Gmail, Yahoo, SpamAssassin, vv)

Cập nhật: Vào tháng Tư năm 2014, Yahoo và AOL thay đổi các thiết lập DMARC của họ để thả các loại tin nhắn mà không cần thông báo. (Họ chuyển sang p = từ chối; xem https://wordtothewise.com/2014/04/brief-dmarc-primer/ để biết thêm thông tin.) Giải pháp của chúng tôi là đặc biệt trong trường hợp các miền đó, vì chức năng cần thiết vẫn hoạt động với phần lớn các miền.

IF ISP MATCHES YAHOO OR AOL 

From: "Mary Smith" <messages+ca54bb7482ace09f@company.example> 
Reply-To: "Mary Smith" <marysmith@memberisp.example> 
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example> 

ELSE 

From: "Mary Smith" <marysmith@memberisp.example> 
Sender: <messages@company.example> 
Return Path: "Mary Smith" <messages+ca54bb7482ace09f@company.example> 

END