Resumo

  • O RFC 9671 pode reconhecer endereços associados ao usuário, o destinatário final do envelope e aliases fornecidos por :addresses ao decidir se um convite o tem como alvo.
  • Essa correspondência prova uma condição de roteamento e política; não prova autoridade do organizador, intenção do usuário nem destino correto da mutação.
  • O resultado updated reúne alteração, cancelamento e remoção, exigindo leitura posterior do UID, do calendário, do estado, dos alarmes e dos anexos.

Uma empresa encaminhava o alias coletivo do departamento de viagens para várias pessoas. O script de uma delas incluiu esse alias em :addresses. Um itinerário destinado ao grupo passou no teste de endereço e entrou no calendário pessoal padrão. A mensagem chegou ao lugar previsto; o evento, não.

O caso mostra por que entrega e destino funcional não são a mesma coisa. O RFC 9671 permite que processcalendar use endereços conhecidos pela implementação, o destinatário final do envelope ou endereços declarados pelo autor do script. A regra acomoda aliases, redirecionamentos e identidades múltiplas. Ela não define, por si só, a governança desses vínculos.

Três fontes de endereço, três fatos diferentes

Sem :allowpublic, os dados precisam formar uma mensagem iTIP válida e um endereço do usuário deve corresponder ao alvo indicado pelo método. Em REPLY, o alvo é ORGANIZER. Em REQUEST, CANCEL e ADD, é um ATTENDEE.

Um endereço associado à conta representa conhecimento do serviço. O destinatário final do envelope registra a rota efetivamente usada na entrega. :addresses acrescenta uma decisão local do autor do script. Todos podem ser legítimos, mas não são intercambiáveis.

Quando um alias de equipe entra em um script pessoal, a superfície de mutação cresce. O recebimento pelo alias não informa qual pessoa deveria incorporar o evento, se ele pertence a um calendário compartilhado ou se deveria apenas permanecer como mensagem. Por isso, o comprovante precisa registrar a origem do endereço, a versão da regra e o calendário resolvido.

:calendarid permite escolher o destino de novos objetos. Quando é omitido, a implementação usa um calendário padrão. added confirma que algo foi incluído, mas não que foi incluído no lugar que a organização pretendia. :updatesonly, por outro lado, impede a criação de um UID ausente; nesse cenário, no_action pode demonstrar que o limite protegeu o usuário.

A mensagem precisa representar uma única realidade

processcalendar amplia o Sieve para dados de calendário em MIME. Informação malformada deve ser ignorada. Se várias partes MIME contêm dados de calendário, elas precisam ser semanticamente equivalentes. Se divergem, nada deve ser processado; se coincidem, apenas uma representação é aplicada.

Essa verificação evita que um texto legível anuncie um local enquanto o conteúdo processável grava outro. Também impede que duas representações aparentemente redundantes produzam duplicidade. Interoperabilidade de formato não pode virar liberdade para escolher uma verdade.

O RFC proíbe que a ação altere a participação do destinatário. Receber um convite e colocar um objeto no calendário não significa aceitar presença. A interface que mostra participação confirmada após uma simples inserção cria uma afirmação que processcalendar não fez.

Confiar no remetente exige manter o alcance de cada sinal

Alterar um calendário sem interação pode ser explorado para abuso. Por isso, mensagens marcadas como spam ou maliciosas não podem ser processadas. O RFC recomenda remetentes conhecidos e desaconselha remetentes potencialmente maliciosos ou não confiáveis. S/MIME, SPF, DKIM e DMARC podem informar essa avaliação.

Cada mecanismo tem objeto próprio. SPF trata autorização de domínio para um cliente SMTP. DKIM valida uma assinatura vinculada a um domínio sobre partes da mensagem. DMARC trata alinhamento e política do receptor. S/MIME exige uma leitura da assinatura, do certificado e da identidade reconhecida.

Nenhum passe demonstra sozinho que a pessoa indicada quis aquela alteração naquele instante. Uma conta válida pode estar comprometida; uma aplicação autorizada pode produzir o UID errado; uma automação de viagem pode reenviar informação antiga. O sinal técnico deve continuar valendo, mas dentro da pergunta que responde.

:organizers acrescenta uma lista externa de endereços aceitos. Quando usada, exige iTIP válido e ORGANIZER correspondente. Quando omitida, o RFC não faz essa validação. Mesmo com lista, a correspondência comprova uma política configurada, não um ato mental do organizador.

updated é o início da reconciliação

Com Variables, :outcome recebe no_action, added, updated ou error. :reason pode detalhar, mas deve ser vazio quando não houver motivo disponível. Uma operação honesta preserva esse vazio em vez de preenchê-lo com uma narrativa conveniente.

updated cobre três caminhos: conteúdo alterado, objeto cancelado ou objeto removido. :deletecancelled pede que um cancelamento remova o objeto; sem a opção, ele permanece marcado como cancelado. Os dois resultados cabem na mesma palavra, e a remoção é formulada como SHOULD. Só a leitura do calendário mostra o que ficou.

O primeiro trecho do registro deve unir ID da mensagem, destinatário final, endereço que casou, geração do script, decisões de spam e malware, autenticação, partes MIME, equivalência, método iTIP, UID, ORGANIZER, ATTENDEE, lista, opções e calendário escolhido.

O segundo trecho consulta o estado real: o UID existe? Em qual calendário? Qual revisão e STATUS? A participação do destinatário continuou intacta? Os alarmes foram removidos, como recomendado? Os anexos incorporados foram decodificados e analisados? Se um deles for malicioso, os dados de calendário não podem ser processados.

O correio permanece outra superfície. processcalendar não cancela o implicit keep do Sieve. Um evento pode mudar enquanto a mensagem fica na caixa. Apagar a mensagem não apaga necessariamente o evento; remover o evento não elimina a evidência de correio.

A orientação da CalConnect mostra o custo de confundir essas camadas: eventos abusivos podem aparecer no passado ou futuro, repetir-se e disparar alarmes em vários dispositivos. O resultado humano continua muito depois do filtro. O estado visível precisa ser observado.

O RFC 9671 oferece uma base comum sem fingir que conhece a política local de aliases e calendários. Esse limite é força, não ausência. A responsabilidade começa quando a organização escolhe quem pode transformar uma entrega em mudança duradoura.

Sources