Lucas RayanandClaude Sonnet 5.5
60c6f5731c
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>
68 lines
2.8 KiB
TypeScript
68 lines
2.8 KiB
TypeScript
import type { NextConfig } from "next";
|
|
|
|
const PROTOCOLS_SERVICE_URL = process.env.PROTOCOLS_SERVICE_URL ?? "http://protocols:8080";
|
|
|
|
const nextConfig: NextConfig = {
|
|
output: "standalone",
|
|
|
|
// The event stream is a WebSocket upgrade, which a route handler cannot
|
|
// proxy: a handler sees a finished request, not the raw connection. A
|
|
// rewrite hands the socket to Next's own proxy, which does upgrade.
|
|
// Everything else under /api/v1 keeps going through the route handler,
|
|
// which needs to read and rewrite Set-Cookie.
|
|
async rewrites() {
|
|
return [
|
|
{
|
|
source: "/api/v1/events",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/api/v1/events`,
|
|
},
|
|
// The well-known documents belong to the protocols service, but the
|
|
// hostnames senders ask for - mta-sts.<domain> above all - resolve to
|
|
// this app. Without these rewrites the Next 404 page was served in
|
|
// place of the MTA-STS policy: the _mta-sts TXT record advertised a
|
|
// policy that could not be fetched, so every sender fell back to
|
|
// "no-policy-found" and no TLS policy was enforced on inbound mail.
|
|
// Google's daily TLS-RPT report reports precisely that.
|
|
//
|
|
// A rewrite rather than a redirect, because RFC 8461 section 3.3 has
|
|
// the sender fetch that exact HTTPS path and it need not follow one.
|
|
{
|
|
source: "/.well-known/mta-sts.txt",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/.well-known/mta-sts.txt`,
|
|
},
|
|
{
|
|
// Fetched by receiving mail providers evaluating a message, which
|
|
// hold no session and never will.
|
|
source: "/.well-known/bimi/default.svg",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/.well-known/bimi/default.svg`,
|
|
},
|
|
{
|
|
// A record names its own domain in the path, so every domain the server
|
|
// hosts can publish its own logo and certificate from this one host.
|
|
source: "/.well-known/bimi/:domain/default.svg",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/.well-known/bimi/:domain/default.svg`,
|
|
},
|
|
{
|
|
source: "/.well-known/bimi/:domain/vmc.pem",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/.well-known/bimi/:domain/vmc.pem`,
|
|
},
|
|
{
|
|
// The BIMI certificate (VMC/CMC) the DNS record's a= tag points at,
|
|
// fetched the same way as the logo above.
|
|
source: "/.well-known/bimi/vmc.pem",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/.well-known/bimi/vmc.pem`,
|
|
},
|
|
{
|
|
source: "/.well-known/security.txt",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/.well-known/security.txt`,
|
|
},
|
|
{
|
|
source: "/.well-known/autoconfig/mail/config-v1.1.xml",
|
|
destination: `${PROTOCOLS_SERVICE_URL}/.well-known/autoconfig/mail/config-v1.1.xml`,
|
|
},
|
|
];
|
|
},
|
|
};
|
|
|
|
export default nextConfig;
|