Práticas recomendadas? Enviar email do aplicativo da Web

Question

Temos um aplicativo da web que é semelhante a um aplicativo de CRM. As pessoas podem fazer login e gerenciar seus negócios com outras pessoas. Como parte desse gerenciamento, nosso aplicativo pode enviar e-mails para as pessoas que estão sendo gerenciadas. A ruga aqui é que nossos clientes gostam do endereço "de" desses e-mails para serem seus. Dessa forma, o destinatário recebe e-mails de alguém que conhece, não de um endereço "não responder" em nosso próprio domínio.

Com muitos servidores de e-mail, isso não é um problema, no entanto, há alguns que estão enviando esses e-mails. Por curiosidade tive um e-mail de teste enviado para mim e verifiquei os cabeçalhos. Veja o que o Google Apps adicionou:

Received-SPF: softfail (google.com: best guess record for domain of transitioning [email protected] does not designate 99.99.184.164 as permitted sender) client-ip=99.99.184.164;
Authentication-Results: mx.google.com; spf=softfail (google.com: best guess record for domain of transitioning [email protected] does not designate 99.99.184.164 as permitted sender) [email protected]

(substitui o endereço real "de" por [email protected])

Assim, enquanto o email foi entregue para mim, posso certamente ver por que outros servidores podem rejeitá-lo. Nosso aplicativo nunca será resolvido para clientdomain.com.

Quais são minhas opções aqui?

1) Eu poderia sugerir que todos os endereços "de" sejam configurados para o nome amigável do cliente, mas o usuário tenha nosso próprio endereço de e-mail "sem resposta". Então eu poderia ter spf e tudo isso ligado.

2) Eu poderia sugerir que o cliente configura spns / reverse dns para coincidir com o IP do meu servidor (isso parece ser uma opção horrível ...)

O que mais. Quais são as melhores práticas para esse tipo de coisa?

    

Answer 1

Uma coisa que você pode fazer é definir o "nome" do remetente como o nome do seu cliente e, em seguida, definir um cabeçalho Responder para ir para o endereço de e-mail.

Dessa forma, parece que eles estão recebendo um email de "Bob Johnson" que conhecem e, quando clicarem em Responder, ele será direcionado para [email protected]

Embora eu saiba que empresas como o Paypal podem receber e-mails do seu endereço de e-mail real, não tenho certeza se isso é um truque com os cabeçalhos ou se todos os provedores de e-mail "confiam" nos servidores de e-mail do paypal.

    

Answer 2

As chaves SPF / Domain funcionam em endereços Envelope From e não no endereço De no email visto pelo destinatário.

Portanto, você pode simplesmente usar o Envelope de como um ID de e-mail válido no seu domínio e deixar o De como seu ID de e-mail do cliente.

Dessa forma, as chaves SPF / Domain ainda passarão.

Em relação a outras práticas recomendadas, confira este teste do servidor de e-mail .

    

Answer 3

Consulte o link

egreetings.com does it this way:
Choose a general address in your domain ([email protected]).
Change the "MAIL FROM" to that address.
Add a "Sender" header to show to recipient who sent the message. "Sender" is a standard field; see RFC 5322.

evite.com does it this way:
Choose a general address in your domain ([email protected]).
Change the "MAIL FROM" to that address.
Change the "From" header to that address.
Add a "Reply-To" header that contains your user's e-mail address.

    

Answer 4

O SPF e o DomainKeys destinam-se a evitar o que você está fazendo - enviando e-mails usando um endereço que você não possui.

Eu não acredito que haja muito o que fazer para contornar isso, já que ele não deve ser contornado.

Você pode fornecer a cada usuário um endereço de e-mail local que seja encaminhado para o gmail ou outra conta apropriada, para que as respostas funcionem e use-o como o endereço "de". É mais trabalho da sua parte.

Além disso, você pode usar um cabeçalho "resent from".

    

Answer 5

Pelo que entendi, pelo menos para o SPF, eles precisam adicionar seu servidor de e-mail à lista de servidores permitidos.

Esse é o ponto em que o dono do foo.com está dizendo que você é um servidor de e-mail autorizado para foo.com

Você não precisa ter um DNS reverso em seu servidor de e-mail, mas seu servidor de e-mail deve HELO corretamente e esse DNS reverso deve estar correto. Por isso, é aceitável para HELO como bar.com, ter um reverso de bar.com e enviar e-mail para foo.com, desde que o SPF de foo.com permita bar.com como um revezamento.

    

Answer 6

Veja o link .

O conteúdo de "MAIL FROM" é Envelope From e é usado para Verificação de SPF. O que o destinatário vê é o que recebe o comando AFTER DATA.

Eles não precisam ser o mesmo.