Co jest lepsze, „bez odpowiedzi @” lub „bez odpowiedzi @”? [Zamknięte]

14

Mając usługę wysyłającą powiadomienia do użytkowników, obecnie myślę o zmianie adresu e-mail nadawcy z „info @” na coś bardziej znaczącego.

Ponieważ odpowiedź nigdy nie ma sensu, myślę o użyciu jednego z tych adresów e-mail „brak odpowiedzi”.

Po sprawdzeniu mojej skrzynki odbiorczej e-mail z ostatnich 10 lat i wyszukiwaniu w Google nie jestem pewien, który z nich jest „lepszy” (pod względem prawdopodobieństwa, że nie zostanie odfiltrowany przez sprawdzających spam):

  • „ noreply @ moja_domena.com” -lub-
  • „ no-reply @ mydomain.com”?

Nie jestem też pewien, czy różnica w ogóle ma znaczenie.

Więc moje pytanie brzmi:

Jakiego rodzaju adresu e-mail „brak odpowiedzi” należy użyć i dlaczego?

smtp spam email Uwe Keim
źródło
3
Nie rób Musisz zbierać i przetwarzać odesłane wiadomości oraz wiadomości od osób, które nie czytają instrukcji „nie odpowiadać na tę wiadomość”.
Michael Hampton
2
@MichaelHampton Chociaż jego oprogramowanie z pewnością musi zbierać i poprawnie obsługiwać wiadomości 4xx i 5xx, nie rozumiem, dlaczego musi pochodzić z monitorowanego adresu e-mail.
Chris S
3
@MichaelHampton - Nasza usługa jest podobna do YouSendIt, aby powiadamiać użytkowników o przesłaniu. Do tej pory otrzymuję tysiące odpowiedzi „Jestem poza biurem” dziennie, których tak naprawdę nie potrzebuję. Właściwie nie wyobrażam sobie jednego przypadku użycia, w którym odpowiedź ma sens.
Uwe Keim,

Odpowiedzi:

9

Oba są całkowicie akceptowalne, o ile konfigurujesz podstawy (DNS, SPF, DKIM to dobry pomysł ... itd.). Upewnij się, że oprogramowanie poprawnie reaguje na błędy 4xx i 5xx. Filtrowanie spamu rzadko uwzględnia adres e-mail, z wyjątkiem powtarzających się wiadomości (śledzenie „reputacji”, że tak powiem).

Uwaga dodatkowa: w społecznościach geekierów widziałem również używane bit-bucket; chociaż nie oczekuje się, że opinia publiczna „dostanie” to odniesienie. Wszystkie moje domeny „akceptują” e-mail pod tym adresem (wraz ze wszystkimi wymaganymi adresami RFC 821).

Chris S.
źródło