Điều gì là thích hợp hơn, không có câu trả lời nào [đóng cửa]


14

Có một dịch vụ gửi thông báo cho người dùng, tôi hiện đang suy nghĩ về việc thay đổi địa chỉ email của người gửi từ "thông tin @" thành một cái gì đó có ý nghĩa hơn.

Vì một câu trả lời không bao giờ có ý nghĩa, tôi nghĩ về việc sử dụng một trong những địa chỉ email "không trả lời" đó.

Sau khi thực hiện một số kiểm tra qua hộp thư đến email của tôi từ 10 năm trước và một số tìm kiếm của Google, tôi không chắc cái nào là "tốt hơn" (về mặt nhiều khả năng không bị lọc bởi Trình kiểm tra thư rác) để sử dụng:

  • " noreply @ mydomain.com" -hoặc-
  • " không trả lời @ mydomain.com"?

Ngoài ra, tôi không chắc liệu sự khác biệt có vấn đề gì không.

Vì vậy, câu hỏi của tôi là:

Loại địa chỉ email "không trả lời" nào sẽ được sử dụng và tại sao?


3
Đừng. Bạn cần thu thập và xử lý tin nhắn và tin nhắn bị trả lại từ những người không đọc hướng dẫn của bạn để "không trả lời tin nhắn này".
Michael Hampton

2
@MichaelHampton Mặc dù phần mềm của anh ấy chắc chắn cần thu thập và xử lý đúng các tin nhắn 4xx và 5xx, tôi không hiểu tại sao nó cần đến từ một địa chỉ email được theo dõi.
Chris S

3
@MichaelHampton - Dịch vụ của chúng tôi tương tự như YouSendIt để thông báo cho người dùng về việc tải lên. Cho đến bây giờ tôi nhận được hàng ngàn câu trả lời "Tôi ra khỏi văn phòng" mỗi ngày, điều mà tôi thực sự không cần. Trên thực tế tôi không thể tưởng tượng về một trường hợp sử dụng duy nhất trong đó một câu trả lời có ý nghĩa.
Uwe Keim

Câu trả lời:


9

Hoặc là hoàn toàn chấp nhận được miễn là bạn định cấu hình cơ bản (DNS, SPF, DKIM là một ý tưởng hay ... vv). Đảm bảo phần mềm của bạn phản hồi đúng với các lỗi 4xx và 5xx. Lọc thư rác hiếm khi xem xét địa chỉ e-mail, ngoại trừ các tin nhắn lặp lại (theo dõi "danh tiếng" để nói).

Lưu ý bên lề: trong các cộng đồng đam mê, tôi cũng đã thấy bit-xô được sử dụng; mặc dù công chúng không mong đợi "có được" tài liệu tham khảo đó. Tất cả tên miền của tôi "chấp nhận" e-mail tại địa chỉ này (cùng với tất cả các địa chỉ bắt buộc RFC 821).

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.