Vamos dividi-lo por declaração
Servers that reject all bounce mails (contrary to the RFCs).
Sim, esse servidor mal configurado rejeita todos os e-mails com remetente < >.
To work around this problem, postfix, for example, uses either the local postmaster address or an address of "double-bounce" in the MAIL FROM part of the callout.
Sim, essa solução evitará o e-mail de rejeição do servidor remoto mal configurado com o remetente < >.
This work-around, however, will fail if Bounce Address Tag Validation is used to reduce backscatter.
O BATV foi uma técnica para verificar o email de rejeição para evitar o backscatter . Ele funciona por reescrever o remetente original para algum token criptográfico . Verificador de BATV apenas verifica o endereço do destinatário de um email se o remetente foi definido para < & gt ;. Se alguns MTAs usaram o postmaster @ address para realizar a verificação de retorno de chamada, o sistema não passará o email para o verificador BATV (porque não é bounce), mas os rejeitará porque o destinatário não existe (somente o verificador BATV pode verificar se o destinatário estava de acordo com seu token criptográfico).
Callback verification can still work if rejecting all bounces happens at the DATA stage instead of the earlier MAIL FROM stage, while rejecting invalid e-mail addresses remains at the RCPT TO stage instead of also being moved to the DATA stage.
Nota: Esta declaração não tem relação com a BATV. Ele abordou o primeiro problema (servidores que rejeitam todos os e-mails devolvidos (ao contrário dos RFCs)).
Portanto, temos dois processos de rejeição aqui, porque 1) o destinatário não existe ou 2) é o endereço de retorno (identificado por < >) . Depois que um cliente (o verificador) emitir RCPT TO, o servidor executará verificações para verificar se o endereço do destinatário existe. Se o destinatário existir, o servidor responderá com o código 2XX OK.
Por causa disso, o verificador assumirá que o endereço foi OK e desconectará . No entanto, o e-mail de devolução real entrará no estágio DATA (o cabeçalho / corpo do e-mail ainda não foi enviado ...), neste estágio o servidor irá rejeitá-lo por causa do e-mail devolvido.
The resolution is to verify the address in the "Data". Since the Data isn't verified (assuming DKIM isn't being used), can't this be spoofed and isn't this a weak workaround?
Não, ele não verifica o endereço no DATA (talvez você esteja falando do endereço no cabeçalho do email). Na verdade, o cabeçalho não foi enviado, mas o servidor já o rejeitou.
Aqui, a ilustração para explicar onde a rejeição ocorre. A fonte original
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA
S: MAIL FROM:<[email protected]>
R: 250 OK
S: RCPT TO:<[email protected]>
R: 250 OK <--- "non existed address" rejection occurs here
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF> <--- "bounce" rejection occurs here
S: Blah blah blah... <--- email header and body
S: ...etc. etc. etc.
S: .
R: 250 OK
S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel