Phương pháp tốt nhất để gửi email thay mặt cho tên miền của khách hàng của tôi là gì?


15

Tôi muốn biết cách tốt nhất để làm cho máy chủ thư của tôi gửi email thay mặt cho tên miền của khách hàng của tôi, mà không bị xóa sổ và cũng tránh được các vấn đề bị trả lại.

Tôi đã đọc một số câu hỏi khác ở đây , ở đâyở đây nhưng không có câu hỏi nào khám phá tất cả các giải pháp có thể. Dưới đây là một số khả năng mà tôi muốn so sánh:

A.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Câu hỏi : Đây là những gì gmail làm. Đó là tiêu đề thư "Từ:" có tên miền khác, không phải người gửi phong bì.
emailclents sẽ hiển thị "Từ: res@client.com qua do-not-reply@myapp.com" hoặc "Từ: do-not-reply@myapp.com trên Behalf Of res@client.com" , đây không phải là vấn đề cho tôi.
Bây giờ, điều này có ảnh hưởng xấu đến danh tiếng của tên miền của tôi không, thực tế là tiêu đề "Từ:" có tên miền khác không? (và nếu không phải Google thì họ đang làm điều đó ..)

B.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Có vẻ như Google đã từng làm điều này và gọi đó là một lỗi http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=g + của% 22 & pli = 1
Một lỗi đã xóa "Người gửi:" khỏi tin nhắn của họ và "thông qua" không hiển thị trong emailclient. (RFC nói rằng nó PHẢI có mặt nếu nó không giống với "Từ:")

C.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

Như thể client.com đang gửi tin nhắn (MAIL TỪ cũng bị "giả mạo"). Nhưng nếu tên miền client.com nổi tiếng hoặc có mục SPF trong DNS của nó, tôi sẽ phải thay đổi DNS của nó, cho phép mymailserver.com gửi tin nhắn thay cho họ .. (Điều này là không thể đối với tôi vì nb . của khách hàng và một số khách hàng của tôi không có quyền kiểm soát tên miền của họ, tức là, đang sử dụng chính @ gmail.com)

D

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Câu hỏi : Đây là cách đơn giản nhất, tôi chỉ thêm tiêu đề "Trả lời:". Đây có thực sự được tính đến TẤT CẢ THỜI GIAN bởi các khách hàng email? Điều này có thể được coi là giả mạo không, thêm các tên miền khác nhau vào tiêu đề "Trả lời" và có ảnh hưởng xấu đến danh tiếng của tên miền của tôi không?
- RFC chỉ nói rằng "nếu trường Trả lời tồn tại, thì câu trả lời NÊN đi đến các địa chỉ được chỉ định trong trường đó chứ không phải đến địa chỉ được chỉ định trong trường Từ.".
- Chỉ nhãn tiêu đề "Từ:" mới bị "giả mạo":
"Từ: myclient.com (qua myapp.com) <do-not-reply@myapp.com>".


Khi đọc RFC, 'NÊN' có nghĩa là đó là một khuyến nghị rất mạnh mẽ. Lý do duy nhất mà khách hàng không muốn trong hầu hết các trường hợp là vì nó đã cũ và chưa được cập nhật kể từ khi RFC được viết. Xem RFC 2119 để biết các định nghĩa chuẩn: ietf.org/rfc/rfc2119.txt
Matthew Scharley


Thật không may, kể từ năm 2018, nhiều ứng dụng khách email vẫn bỏ qua tiêu đề Trả lời. meta.discference.org/t/ từ
Martin Meixger

Câu trả lời:


2

Câu hỏi tuyệt vời. Tôi vừa mới dành vài giờ để nghiên cứu điều tương tự.

Trước đây tôi đã triển khai nhiều trang web sử dụng Tùy chọn C cho các biểu mẫu email (chủ yếu là do sự ngây thơ), nhưng chúng tôi đang gặp phải một số vấn đề về giao hàng ngày càng tăng. Các nhà cung cấp email đang dần thắt chặt về mọi thứ. Ví dụ, Yahoo gần đây đã thay đổi chính sách DMARC của họ để yêu cầu người nhận từ chối tất cả các email From: ____@yahoo.commà không có chữ ký DKIM hợp lệ . Việc nhận các máy chủ SMTP tuân theo DMARC (bao gồm Gmail và có lẽ cả Hotmail / Outlook.com và Yahoo) sẽ trả lại những thông báo này. eBay và Paypal có những chính sách nghiêm ngặt tương tự mà tôi tin, trong nỗ lực giảm lừa đảo. Thật không may, việc chỉ định tiêu đề "Người gửi" không giúp ích.

(Tôi tự hỏi làm thế nào Gmail hoạt động xung quanh vấn đề này khi gửi "Từ" bí danh Yahoo?!)

Tùy chọn A sẽ là một lựa chọn tốt hơn nếu bạn biết email "Từ" không có chính sách DMARC nghiêm ngặt (bạn có thể xác nhận điều này thông qua truy vấn DNS đơn giản).

Mặc dù ít hấp dẫn nhất về mặt trực quan, Lựa chọn D thực sự an toàn nhất và là điều tôi sẽ giới thiệu cho hầu hết các dự án trong tương lai của chúng tôi. Nó đáng chú ý là PayPal đã qua sử dụng lựa chọn A, nhưng hiện nay đã chuyển sang lựa chọn D .

Để có được sự tín nhiệm bổ sung và tăng cơ hội giao hàng, tôi sẽ xem xét triển khai SPF và / hoặc DKIM. Những điều này và những điều khác được đề cập trong Nguyên tắc người gửi hàng loạt của Google mà tôi thấy hữu ích.


1

Tôi không chắc chắn những gì bạn muốn. Không có cách "an toàn" hay "không an toàn" để làm những gì bạn muốn.

Tôi sẽ luôn luôn thích D). Ngoài ra, tôi sẽ thêm các bản ghi SPF. Nhưng như tôi đã nói, điều này không an toàn hơn hoặc không an toàn hơn những người khác (bất kể bạn có ý gì với nó).

Tiêu đề Trả lời không ảnh hưởng đến danh tiếng dưới bất kỳ hình thức nào. Nó chỉ khuyến cáo khách hàng sử dụng địa chỉ đó để trả lời (Duh, có lẽ đây là tên đến từ đâu?!). Nếu khách hàng làm theo khuyến nghị này không được đảm bảo.


Bởi "an toàn" Tôi có nghĩa là giảm thiểu khả năng tên miền của tôi bị xóa, bị coi nhầm là kẻ lừa đảo / người gửi thư rác vì giải pháp tôi đã chọn. Có, nếu tôi đi với D, tôi có thể xem xét thêm mục nhập SPF vào tên miền của mình và ký các tin nhắn bằng DKIM.
dgaspar

Tôi đã chỉnh sửa câu hỏi của mình và cố gắng làm rõ nó ..
dgaspar

@dgaspar Greylning là dựa trên phong bì. Vì vậy, nội dung của bạn (Từ:, Người gửi:, ...) hoàn toàn bị bỏ qua. Vì mọi người đều có thể viết bất kỳ địa chỉ thư nào dưới dạng người gửi, mọi địa chỉ người gửi đều bị coi là giả mạo. Ngoại trừ bạn ký thư của bạn với SPF hoặc DKIM.
mailq

0

Hai giải pháp đáng tin cậy:

  1. yêu cầu khách hàng thêm máy chủ thư của bạn vào bản ghi miền SPF của họ
  2. yêu cầu khách hàng cung cấp cho bạn thông tin đăng nhập tài khoản email (IP mailserver, tên người dùng, mật khẩu) và sử dụng chúng trong ứng dụng của bạn để kết nối với máy chủ mail của họ và gửi email (bạn thực sự tạo một ứng dụng email bên trong ứng dụng của bạn).
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.