Ticket #1695 (closed defeito: fixed)

Opened 10 years ago

Last modified 10 years ago

E-mail com corpo em multpart tem visualização repetida.

Reported by: diogenesduarte Owned by: kolling
Priority: normal Milestone: Expresso 2.2.0-beta
Component: ExpressoMail Version: branch 2.2
Severity: média Keywords:
Cc: WorkGroup:

Description

Caso um e-mail possua um corpo de mensagem do tipo multpart, e essas partes sejam repetidas, o expresso concatena todas as partes do corpo e mostra uma mensagem repetitiva.

Attachments

fonte_da_mensagem_3_.eml Download (12.9 KB) - added by diogenesduarte 10 years ago.

Change History

Changed 10 years ago by diogenesduarte

comment:1 Changed 10 years ago by kolling

Segundo a rfc2046 multipart/alternative deve ser processado da última parte até a primeira e o mailer deve mostrar o primeiro tipo que ele reconhece. Fonte:  http://www.ietf.org/rfc/rfc2046.txt, seção 5.1.4.

comment:2 Changed 10 years ago by rodsouza

A RFC não diz que DEVE-SE processar da última para a primeira, tão pouco que DEVE-SE exibir a primeira parte a ser reconhecida.

O que ela descreve é como recomenda-se que seja a ordem e ainda possui um adendo afirmando que a ordem é estipulada pelo agente de envio.

Finalmente, o leitor DEVE escolher a melhor parte baseado em seu ambiente, em alguns casos com uma interação com o usuário. Em geral, a melhor opção é a última suportada pelo leitor (OBSERVEM que não é a última presente no e-mail). Ainda, os agentes de envio DEVEM compor o e-mail na ordem de sua preferência sendo a última a mais importante, ou seja, agentes diferentes possuem prferências diferentes (LEMBRANDO que a ordem pode ser invertida). E mesmo quando uma parte não é reconhecida o leitor pode exibir última parte reconhecida, a parte desconhecida, ou ambas.

Não tem segredo, na verdade o que o Expresso está fazendo não infringe a RFC entretanto leva o usuário a acreditar que todo o conteúdo é único quando na verdade deveria existir divisões ou mesmo ser exibido apenas (PREFERENCIALMENTE o da escolha do usuário).

comment:3 Changed 10 years ago by niltonneto

OK, tudo bem. Todo mundo com a RFC2046 na ponta da língua, ótimo. Mas e aí, como será implementado para o Expresso? Temos que definir qual a melhor maneira. Alguma sugestão?

comment:4 Changed 10 years ago by kolling

Ok... mesmo assim há a recomendação desta ordem. Ademais a própria RFC cita que "em geral" esta é a ordem utilizada pelos clientes.

De qualquer modo, para ser um pouco mais prático, a minha sugestão de implementação é uma forma simples de implementar.

Outra possibilidade seria varrer todas as subpartes e escolher a melhor (provavelmente text/html). Neste caso poderíamos até ter uma preferência de usuário que definiria qual o formato de visualização preferido pelo usuário.

Agora, dizer que a forma como o Expresso implementa não infringe a RFC, é demais, visto que a RFC cita:

What is most critical, however, is that the user not automatically be shown multiple versions of the same data. Either the user should be shown the last recognized version or should be given the choice.

comment:5 Changed 10 years ago by brunocosta

Pesando aqui nesse caso é simples de resolver, quando for uma multipart/alternative colocar uam variável de controle que faça somente uma das partes (HTML ou text/plain) seja mostrada. O problema disso é que é possível que exista um email que tenha dentro de uma das partes do alternative um outro multi-part (tipo um HTML com imagens dentro de um multi-part related). Do jeito que é feito hoje tratar todos os casos é complicado.

comment:6 Changed 10 years ago by kolling

  • Owner changed from ninguem to kolling
  • Status changed from new to assigned

comment:7 Changed 10 years ago by kolling

  • Status changed from assigned to closed
  • Resolution set to fixed

Implementado seguindo a sugestão do Bruno.

Testei esta implementação com este e-mail em questão e vários outros e-mails que anteriormente apresentavam problemas, todos foram exibidos corretamente. Peço que devido à criticidade do parser de e-mail, mais testes sejam realizados.

Commit na revisão [3922].

Note: See TracTickets for help on using tickets.