Two bugs found by the setup check right after the last deploy:
- every domain's BIMI record named the deployment's own mail host, and the
server picked the domain from the host name, so only the primary domain's
logo could be fetched: ciberlab.seg.br's record pointed at a 404. The logo
and the certificate are now served at /.well-known/bimi/<domain>/..., the
record names that, and the webmail routes it. The old path still answers
- SetBimiPublisher ran before SetBimiAPI, found no BIMI API to attach to and
was dropped, so saving a logo never published the DNS record by itself. It is
kept on the router now, so the order does not matter
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The reconciler never wrote the BIMI record: only the console's verification
knew about it, so a stored logo was never published to the zone.
- SyncDnsRecordsInput carries the BIMI logo and certificate URLs; the record is
created, updated (a= added or dropped) and, when the logo is removed,
deleted. Only a record carrying this reconciler's comment is retired: one
made by hand is left alone
- bimi.Publish decides the record in one place for the timer sweep, the
console's button and the panel's verification. A held certificate is
advertised only while it is valid for the logo being served: replacing the
logo ends the certificate, and a record that kept naming it makes every
receiver reject BIMI, including those that need no certificate
- saving or removing the logo or the certificate triggers the reconciliation in
the background; the panel shows the record as the server writes it, says when
a certificate is held back and why, and has a publish-now button
- a read error is not 'no logo': the sync leaves the record alone instead of
deleting it over a database hiccup
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A Verified Mark Certificate cannot be made here: an authority issues it after
checking the organisation. What the service can do is hold the file the
authority returns, serve it where the DNS record points, and refuse one that
would make receivers ignore BIMI without a word.
- migration 0015: domain_bimi keeps the PEM chain next to the logo
- bimi.InspectCertificate reads a chain and reports every reason it would not
work: private key blocks refused outright, the brand-indicator usage, the
validity period, the domain (exact, wildcard or organisational), and that
the logo embedded in the certificate (gzipped data URI in the logotype
extension) is byte for byte the logo being published. Tested against two
real public VMCs (eBay via DigiCert, CNN via Valimail) plus mutations
- GET /.well-known/bimi/vmc.pem (public, conditional, cacheable for an hour),
and PUT/DELETE /api/v1/admin/bimi/certificate; the GET of the logo now
reports the certificate as it stands against the logo being served, and
replacing a logo under a held certificate says it no longer matches
- GET /api/v1/admin/bimi/check looks at what a receiver would: the logo, DMARC
enforcement, the BIMI record, the public logo URL, the certificate and its
public URL. Its HTTP client is HTTPS only and refuses non-public addresses
after DNS, since the URLs come from DNS and an operator field
- the DNS record points a= at the held certificate when there is one
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Repoe as duas funcionalidades. A reversao foi uma precaucao enquanto o site
estava em baixo, e acabou por ser ela a provar que a culpa nao era delas: o
502 continuou depois de reverter.
A avaria era o servico web nao declarar porta nenhuma, o que levava o Coolify
a gerar um servico Traefik apontado ao porto 80. Fica corrigida no commit
anterior, com expose 3000.
As migracoes 0012 e 0013 nunca sairam do repositorio nem da base de dados, por
isso o codigo reposto encontra as tabelas que espera.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
O site ficou a responder 502 em todos os hostnames depois do deploy destas
duas funcionalidades. A reversao vem primeiro; o diagnostico vem a seguir, com
o servico de pe.
As migracoes 0012 e 0013 ficam. Sao aditivas, nada no codigo revertido as usa,
e apaga-las deixaria a base de dados numa versao sem ficheiro correspondente,
o que parte o proprio migrate no arranque seguinte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A foto de perfil nao viaja: nem o Gmail nem o Outlook leem uma imagem por
utilizador do servidor de quem envia, e nao existe protocolo que o permita. O
avatar que esses mostram vem dos contactos de quem recebe ou da conta Google
ou Microsoft do remetente.
O que eles leem e BIMI, que e por dominio. Fica implementado: validacao,
alojamento e o registo.
O validador reporta todas as violacoes de uma vez, e nao a primeira. Um
receptor que recusa a marca nao explica nada -- simplesmente nao desenha -- por
isso descobrir as regras uma viagem de cada vez seria a pior maneira possivel
de aprender este formato. Sao verificados o baseProfile e a versao que os
receptores procuram, o viewBox quadrado (uma marca nao quadrada e cortada de
forma diferente por cada cliente), exactamente um title, e a ausencia de tudo
o que seja activo ou externo: script, handlers de evento, links, imagens
rasterizadas, animacoes e referencias para fora do documento.
O registo so e publicado quando ha mesmo uma marca guardada. Um registo que
aponta para um logotipo inexistente e pior do que nenhum, porque o receptor
para de procurar assim que encontra um.
O logotipo e servido aberto, porque quem o vai buscar sao os fornecedores de
correio a avaliar uma mensagem e esses nunca terao sessao aqui.
Fica escrito no README que o Gmail e o Outlook so desenham a marca com um VMC,
e o painel avisa quando nao ha nenhum configurado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
