[MASOCH-L] SPF LOCAWEB

[Leandro Carlos Rodrigues]

Em 27/07/2012 14:03, Henrique de Moraes Holschuh escreveu:
> On 27-07-2012 11:32, Leandro Carlos Rodrigues wrote:
>> Em 27/07/2012 11:10, Henrique de Moraes Holschuh escreveu:
>>> On 27-07-2012 10:17, Leandro Carlos Rodrigues wrote:
>>>> Certo. Mesmo assim quem te impede que forjar uma mensagem de erro
>>>> no envelope e no cabeçalho e no lugar do corpo da mensagem
>>>> colocar propaganda ou golpes?
>>>
>>> Se o HMAC que seria correspondente ao MTA durante o caminho de
>>> retorno não valida, você descarta a DSN. O HMAC é composto
>>> utilizando detalhes de conhecimento privado do MTA, e é difícil de
>>> ser forjado. Seria incluído no cabeçalho received, e as regras para
>>> DSN ajustadas se necessário para garantir que estes cabeçalhos
>>> devem obrigatoriamente estar presentes na DSN. Projetar o HMAC não
>>> é trabalho para amador.
>>>
>>
>> Tudo bem. Mas, além do HMAC ser difícil de implementar assim como
>> você disse, ainda sim você precisa receber o cabeçalho, que está
>> concatenado com corpo, para checar isso. E pela forma como exergo, o
>> desempenho para
>
> Sim, você vai precisar checar o cabeçalho.  Seria possível estender só o
> ESMTP e passar isso como informação de sessão (como é o envelope). É
> preciso fazer uma boa comparação de trade-offs, inclusive já de posse
> das informações que serão necessárias para criar e validar o HMAC.
>
>> checar isso é ruim. Não seria mais fácil descartar a mensagem assim
>> que o MAIL FROM fosse passado, caso quele dominio estivesse em lista
>> negra interna ou externa? Ou se tratasse de email forjado, você
>> rejeitar no
>
> Isso é ortogonal.
>
>> momento que é passado a assinatura DKIM (isso no protocolo modificado
>>  que eu propus)?
>
> Implementar um protocolo modificado não é realista.  A única coisa com
> chance não zero de decolar é estender de forma compatível o protocolo
> existente.  Repense sua proposta como uma extensão.
>

Acho que dá para pensar numa forma que seja uma extensão. Não é tão 
difícil. Porém agente nunca vai escapar da obrigação do servidor de 
origem seguir a regra porque o protocolo atual permite anonimato porque 
foi projetado numa época em que mensagens eletronicas em mais comuns 
entre universidades. Apesar disso tudo, acho que você tem toda razão. 
Começar do zero é um puta trabalho.

>> mensagem. Os DNSBL passariam a se orientar pelo dominio e não mais
>> pelo IP. Se bem que isso não significa que você não iria fazer
>> checagem de IP
>
> Já existem rhsbls.  Usamos para verificar o envelope e os headers,
> inclusive.
>