Là SRS viết lại hoàn toàn cần thiết cho một máy chủ chuyển tiếp?

Tôi đang vận hành một máy chủ email Postfix cho tên miền của mình, giả sử mydomain.com. Nó chủ yếu hoạt động như một máy chủ email chuyển tiếp: người dùng nhận được địa chỉ email @ mydomain.com, nhưng thường chọn để chuyển địa chỉ của họ sang hộp thư đến bên ngoài (Gmail, Yahoo, v.v.). Có một vài ngàn địa chỉ được chuyển tiếp, vì vậy máy chủ xử lý một khối lượng lưu lượng thư khá đáng kể.

Trước đây, máy chủ không sử dụng viết lại SRS. Điều này tất nhiên có nghĩa là thư chuyển tiếp sẽ không kiểm tra SPF, vì địa chỉ IP của tôi không được ủy quyền về mặt kỹ thuật để gửi email thay mặt cho tên miền của người gửi ban đầu. Tuy nhiên, từ những gì tôi có thể thấy nó dường như không gây ra bất kỳ vấn đề quan trọng nào. Nói chung, không có khiếu nại nào từ người dùng như Gmail, Yahoo, v.v. dường như đủ thông minh để bỏ qua các lỗi SPF và gửi thông điệp bằng mọi cách.

Với suy nghĩ này, có thực sự cần thiết để cho phép viết lại SRS không? Tôi đang xem xét kích hoạt nó nhưng mối quan tâm chính của tôi là tên miền của tôi sẽ bị đưa vào danh sách đen vì đã gửi thư rác khi thư rác chắc chắn bị xóa. Sẽ không viết lại làm cho nó xuất hiện như thể tôi là người khởi tạo thư rác? (Ít nhất, đây là sự hiểu biết của tôi từ việc đọc Thực tiễn tốt nhất để chuyển tiếp thư điện tử của Gmail ).

Được cho phép, tôi đã thực hiện một số biện pháp phòng ngừa được đề xuất như sử dụng SpamAssassin để thêm "SPAM" vào dòng tiêu đề của thư rác bị nghi ngờ trước khi chuyển tiếp, không chuyển tiếp thư rác có độ tin cậy cao (15+) và sử dụng danh sách chặn spamhaus Hoàn hảo và thư rác vẫn có thể bị đánh dấu.

Việc cho phép viết lại SRS có đáng không, nếu nó làm tăng nguy cơ bị đánh dấu sai là người gửi thư rác? Hoặc sẽ an toàn hơn nếu cứ để nguyên như vậy và bỏ qua những thất bại SPF?

Dường như với tôi rằng câu hỏi của bạn sôi nổi là "có bao nhiêu máy chủ mail ngoài đó kiểm tra các bản ghi SPF trên email đến? ". Nếu đó là hầu hết trong số họ, SRS là một yêu cầu tuyệt đối cho một máy chủ chuyển tiếp; nếu không có ai trong số họ, bạn không cần SRS.

Thật không may, tôi không thể ngay lập tức đặt tay vào bất kỳ công việc học tập nào về việc này. Nhưng vì tôi kiểm tra SPF trên email đến, tôi có thể chắc chắn rằng một số máy chủ thư sẽ kiểm tra nó. Bất kỳ khách hàng nào của bạn có máy chủ của bạn chuyển tiếp đến tài khoản trên máy chủ của tôi sẽ bị mất email được gửi từ những người gửi quảng cáo SPF kết thúc (như tất cả họ nên) -all, trừ khi bạn sử dụng SRS. Vì vậy, tôi có thể nói chắc chắn rằng nếu không có SRS, một số email của khách hàng của bạn sẽ không được gửi .

Tôi xin lỗi Marc rằng tôi không thể đọc tiếng Đức, vì vậy tôi không thể nói liệu PDF mà anh ấy trích dẫn có thúc đẩy các lập luận thuyết phục hay không, nhưng tôi có thể nhắc lại rằng nếu không có SRS, một số phần email của khách hàng của bạn sẽ không được gửi. Tôi không thể nói phân số đó là bao nhiêu, nhưng nó không bằng 0 - và được đưa ra, tôi không nghĩ bạn có bất kỳ sự thay thế nào ngoài việc chạy SRS.

Tôi đồng ý rằng máy chủ của bạn sẽ không tự giúp mình bằng cách chuyển tiếp SPAM, nhưng theo kinh nghiệm của tôi, phần lớn thiệt hại về mặt uy tín được thực hiện đối với địa chỉ IP của nó, chứ không phải tên miền từ phong bì; điều này sẽ được thực hiện bất kể việc sử dụng SRS.

Câu trả lời sâu sắc hơn cho câu hỏi của bạn là, giữa SPF và DMARC tiếp theo (không cân nhắc và phá vỡ internet), đối với tôi, các dịch vụ chuyển tiếp thư đã có một ngày của họ. Tôi đã yêu cầu tất cả trừ một trong những người dùng của tôi phải giao hàng cuối cùng trên máy chủ của tôi và một người dùng đó sẽ phải thay đổi hoặc rời đi vào năm 2016. Ngày nay, nhiều hệ thống webmail sẽ cho phép tích hợp qua nhiều hộp thư bằng cách thu thập thư ngoài máy chủ bằng cách sử dụng IMAP hoặc POP và nhiều ứng dụng thư khách cho phép nhiều tài khoản IMAP hoặc POP hiển thị dưới dạng một INBOX tích hợp duy nhất, vì vậy việc chuyển tiếp không phải là lợi ích cho việc đọc tập trung mà nó đã từng sử dụng.

Nói tóm lại, tôi muốn nói rằng bạn cần SRS trong ngắn hạn và một mô hình kinh doanh mới trong dài hạn.

SRS có vẻ là một ý tưởng hay trên giấy tờ, nhưng thực tế không hoạt động tốt trong thực tế theo hỗ trợ của Heinlein (họ đang điều hành một dịch vụ thư cỡ trung bình với hơn 100000 tài khoản.)

Thông tin chi tiết có trong bài nói chuyện của họ, mặc dù bằng tiếng Đức, tại sao: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greyl hiện_FrOSCon_2012.pdf

Lý do chính là SRS là một bản vá nhỏ cho các vấn đề nghiêm trọng khi thực hiện SPF trong thực tế, bởi vì SPF không bao gồm một số trường hợp sử dụng email phổ biến rất tốt. Đối với SRS có ý nghĩa mặc dù nó cần được triển khai trên một cơ sở lớn các máy chủ, điều này khó có thể xảy ra. Vì vậy, cho đến khi nó được triển khai trên cơ sở máy chủ lớn đó, nó hoàn toàn không có ý nghĩa gì cả.

Vấn đề với các nhà cung cấp thư lớn là ngày nay họ có một cơ sở người dùng thực sự lớn và họ đang triển khai ngày càng nhiều kỹ thuật (sự kế thừa cho DMARC đã sẵn sàng), điều này làm cho ngày càng khó khăn hơn đối với một người bình thường thiết lập máy chủ thư để gửi thư cho họ theo một cách đáng tin cậy.

Nếu bạn muốn thư của mình được gửi tốt hơn tới các nhà cung cấp thư lớn như Gmail, Hotmail, v.v., bạn nên triển khai ít nhất DKIM và DMARC, nhưng cũng nên đặt nó ở mức mềm không thành công và có thể thực hiện một số cơ chế giới hạn tốc độ khi gửi thư sẽ làm việc kỳ diệu cho bạn.

Vấn đề này với các nhà cung cấp lớn là lý do tại sao ngày nay có các dịch vụ như Mailchimp, Mandrill hoặc Returnpath. Những nhà cung cấp này trả tiền cho Google & Co. cho chất lượng giao hàng tốt hơn.

Tôi đồng ý với từng từ của @MadHatter, NHƯNG sự thật quan trọng về Google!

Nếu bạn cung cấp dịch vụ chuyển tiếp cho gmail, rất có thể bạn cũng cung cấp quyền truy cập SMTP để người dùng gmail của bạn có thể gửi thư từ gmail thay mặt cho địa chỉ được bạn lưu trữ.

Trong trường hợp đó - gmail biết bạn là người chuyển tiếp cho email này và không gắn cờ chuyển tiếp của bạn là thư rác mặc dù nó không kiểm tra SPF.

Bạn có thể gửi thư khách hàng của bạn từ bill@microsoft.com. Tin nhắn sẽ đến hộp thư đến của họ mà không có bất kỳ cảnh báo nào! (Microsoft có -all trong bản ghi spf)

Đã kiểm tra và xác minh. Ví dụ đính kèm.

tin nhắn này đã đi đến hộp thư đến.