Potencjalne problemy z użyciem adresu "od" członka i nagłówka "nadawcy"

Główny komponent naszej aplikacji wysyła wiadomości e-mail do członków w imieniu innych członków. Obecnie ustawiamy adres "From" na nasz adres systemowy i używamy nagłówka "Reply-to"z adresem członka. Problem polega na tym, że odpowiedzi od niektórych klientów e-mail (i auto-odpowiedzi/odbicia) nie respektują nagłówka "Reply-to", więc wysyłaj je na nasz adres systemowy, skutecznie wysyłając je do czarnej dziury. Rozważamy ustawienie adresu " Od " na adres naszego członka, a Adres "nadawcy" na adres naszego systemu. Wygląda na to, że ten sposób przejdzie kontrolę SPF i Sender-ID.

Czy są jakieś powody, aby nie przełączyć się na tę metodę? Czy są jakieś inne potencjalne problemy?

Oto o wiele więcej szczegółów, niż prawdopodobnie potrzebujesz:

Kiedy aplikacja była rozwijana po raz pierwszy, po prostu zmieniliśmy adres "from" na adres wysyłającego członka, ponieważ była to powszechna praktyka w tym czasie (to było wiele lat temu). Później zmieniliśmy to na " z" adres to imię i nazwisko członka oraz nasz adres, tj.

From: "Mary Smith" <[email protected]>

Z nagłówkiem" reply-to " ustawionym na adres członka:

Reply-To: "Mary Smith" <[email protected]>

Pomogło to w błędnym klasyfikowaniu wiadomości jako spam. Gdy SPF stał się bardziej popularny, dodaliśmy dodatkowy nagłówek, który będzie działał w połączeniu z naszymi rekordami SPF:

Sender: <[email protected]>

Wszystko działa OK, ale okazuje się, że w praktyka, niektórzy klienci e-mail i większość MTA nie szanują nagłówka "Reply-To". Z tego powodu wielu członków wysyła wiadomości do wiadomości @ company.przykład zamiast żądanego członka.

Więc zacząłem przewidywać różne schematy, aby dodać dane o nadawcy do nagłówków wiadomości e-mail lub zakodować je w adresie e-mail "od", abyśmy mogli odpowiednio przetworzyć odpowiedź i przekierować. Na przykład,

From: "Mary Smith" <[email protected]>

Gdzie ciąg po "wiadomości" to hash reprezentujący członka Mary Smith w naszym systemie. Oczywiście, ta ścieżka może prowadzić do dużego bólu, ponieważ musimy opracować funkcjonalność MTA dla naszego adresu systemowego. Przeglądałem ponownie dokumentację SPF i znalazłem tę stronę ciekawą:

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

Pokazują dwa przykłady, że z evite.com i że z egreetings.com. zasadniczo, evite.com robi to tak, jak my to robimy. Na egreetings.com przykład używa adresu członka z dodanym nagłówkiem "Sender".

Więc pytanie brzmi, czy są jakieś potencjalne problemy z użyciem metody egreetings adresu członka z nagłówkiem nadawcy? To wyeliminowałoby odpowiedzi, które źli klienci wysyłają na adres systemu. Nie wierzę, że to rozwiązuje problem bounce / vacation/whitelist, ponieważ te często wysyłają do poczty z, nawet jeśli ścieżka powrotu jest określona.