Resumo
- A RFC 5233 acrescentou
:usere:detailàs comparações de endereço do Sieve, sem padronizar um separador nem um formato universal de endereços com marcação. - O sistema de e-mail que recebe a mensagem mantém o controle da codificação local; o envelope
topode preservar um detalhe ausente de um cabeçalho visível.
O sinal era local; o limite era o contrato
Um detalhe acrescentado ao endereço pode encaminhar a mensagem para uma pasta, identificar uma assinatura de lista ou distinguir uma caixa postal de voz. O sinal de mais é uma forma conhecida, mas apenas um exemplo. Publicada em janeiro de 2008, a RFC 5233 deu ao Sieve duas partes adicionais de endereço — :user e :detail — para comparação. Ela definiu partes observáveis para o filtro, não uma gramática global de endereçamento.
A parte local é interpretada pelo sistema de e-mail que a recebe. A RFC mostra o detalhe depois do usuário, com +, e também antes, com . Se a sequência separadora aparece mais de uma vez, a regra de divisão é definida pela implementação e normalmente depende do formato do sistema de e-mail. A implementação precisa corresponder à codificação que esse sistema usa ou permite; o mecanismo para definir ou consultar essa codificação está fora do escopo da RFC. Um filtro não pode presumir que + significa “detalhe” só porque outro provedor o usa assim.
Quando não há detalhe codificado, :user representa toda a parte local, como :localpart no Sieve. Nesse caso, :detail não corresponde a nenhuma chave solicitada. Se há um detalhe codificado, mas vazio, o valor é a string vazia. A regra distingue um componente inexistente de um componente presente sem texto.
A RFC também separa a origem do endereço. O teste address examina cabeçalhos estruturados; o teste opcional envelope examina dados do transporte. Para classificar uma mensagem conforme o endereço que a levou a determinado destinatário, a RFC prefere na maioria dos casos o envelope to. Listas, aliases e domínios virtuais podem fazer dele o único lugar onde sobrevive o detalhe daquele destinatário. Aplicar o formato local a um endereço externo — como o do remetente — pode produzir resultados inconsistentes ou errados.
A RFC 5233 substituiu o texto anterior da RFC 3598. As notas da revisão generalizaram a descrição da codificação e incluíram as ressalvas sobre envelope e endereços externos. A IANA registra a capacidade subaddress, mas o nome no registro não garante que todo sistema aceite determinado formato. O Sieve compara uma interpretação local que lhe foi fornecida; não cria essa interpretação nem comprova como uma caixa postal foi provisionada.
Fontes
- RFC 5233, registro do RFC Editor, histórico no Datatracker, errata verificada 3079.
- RFC 3598, RFC 5228, RFC 5322, registro de extensões Sieve da IANA; contexto relacionado: RFC 5230, RFC 5231, RFC 5232.
- Registros e metadados normativos: registro da RFC 5233 no Datatracker, registro da RFC 3598 no Datatracker e registros do RFC Editor para RFC 2119, RFC 2822, RFC 3598, RFC 5228, RFC 5230, RFC 5231, RFC 5232 e RFC 5322.
- Lentes interpretativas posteriores, não evidência de intenção, implementação ou adoção: Heng Lu, nota 65, nota 20, nota 64.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
