Guía del administrador de Goooy

Todo lo que un administrador necesita para ejecutar, proteger y operar Goooy: tu alternativa autoalojada a Microsoft Exchange / Office 365.

Goooy es una suite de groupware completa que alojas tú mismo: correo, calendario, contactos, tareas, notas, chat, archivos, videorreuniones, ofimática colaborativa y una consola de administración, todo desde una única aplicación, un único modelo de datos y un único chart de Helm. Tú eres el dueño de los servidores, los datos y las claves.

Esta guía es para quienes ejecutan Goooy. Para los fundamentos técnicos de la plataforma -la arquitectura, el despliegue con Helm o Docker Compose y la configuración esencial-, consulta la Guía del desarrollador. Para conocer la visión de las aplicaciones desde el punto de vista del usuario final, consulta la Guía del usuario. Para obtener detalles técnicos profundos, la carpeta docs/ contiene referencias específicas (arquitectura, seguridad, servidor de correo, multitenencia, despliegue, migración y los protocolos de cliente nativo).

Contenido

• La consola de administración
• Organizaciones, dominios y usuarios
• Autenticación y política de acceso
• El servidor de correo
• Clientes nativos y gestión de dispositivos
• Migrar desde otro sistema
• Multitenencia y aislamiento
• Seguridad y cumplimiento
• Copias de seguridad y operaciones
• Registro de autoservicio y tu portada de marketing

La consola de administración

Inicia sesión como administrador y obtendrás un área de Administración protegida por RBAC (la superficie REST es /api/v1/admin, restringida a SYSADMIN / ORGADMIN y delimitada por organización). Desde ella puedes:

• Gestionar organizaciones, dominios, usuarios y grupos (crear, editar, eliminar).
• Ver un panel de estadísticas del uso de la plataforma/organización.
• Ejecutar la gestión de dispositivos móviles: listar los dispositivos registrados y solicitar borrados remotos.
• Integrar un directorio: importar usuarios de forma masiva y sincronizar desde LDAP.
• Configurar el SSO por organización y la política de seguridad (obligatoriedad de 2FA, aplicación de SSO).
• Verificar la propiedad de dominios mediante registros DNS TXT.
• Ejecutar migraciones desde otros sistemas de correo (Administración ▸ Migraciones).

Organizaciones, dominios y usuarios

La columna vertebral de multitenencia de Goooy es Organization → Domain → User. Cada usuario posee un buzón con un árbol de carpetas tipado (correo, calendario, contactos, tareas, notas, archivos), de modo que un único modelo de almacenamiento y permisos respalda todas las aplicaciones. Eliminar una organización, un usuario o un buzón se propaga en cascada de forma limpia a todo lo que está por debajo.

Roles (RBAC)

Las acciones de ORGADMIN se delimitan automáticamente a su orgId; un ORGADMIN no puede crear organizaciones ni otorgar SYSADMIN. Cada consulta multitenencia filtra por la organización de quien la realiza, de modo que los inquilinos nunca ven los datos de los demás.

Añadir usuarios

Crea usuarios de forma individual en la consola, impórtalos de forma masiva o sincronízalos desde LDAP con ldapts. Cada usuario nuevo se aprovisiona automáticamente con un buzón y el árbol de carpetas predeterminado. Las contraseñas siguen tu política (véase más abajo).

Verificación de la propiedad del dominio

Antes de que un dominio gestione correo real, un administrador puede demostrar su control sobre él de la misma manera que lo hacen Google Workspace y Microsoft 365:

1. La consola muestra un registro TXT que publicar (_goooy-verify.<domain> con un valor de token estable).
2. Publícalo en tu DNS.
3. Haz clic en Verificar ahora. Goooy realiza una consulta DNS en vivo y marca el dominio como verificado.

Esto está delimitado por organización y auditado; un ORGADMIN solo puede verificar los dominios de su propia organización.

Autenticación y política de acceso

Goooy admite toda la gama de controles de acceso modernos. Los valores predeterminados son seguros; refuérzalos por organización según sea necesario.

Contraseñas

• Cifradas con bcrypt (coste 12), los mismos hashes que verifica Dovecot, de modo que hay un único almacén de credenciales para el webmail y el IMAP/POP3 nativo.
• Se aplica una política de contraseñas en cada establecimiento/cambio/restablecimiento/registro: una longitud mínima (PASSWORD_MIN_LENGTH, predeterminado 10) y una comprobación opcional de filtraciones con Have I Been Pwned (k-anonimato: del servidor solo sale un prefijo SHA-1, y falla en abierto, de modo que una caída de HIBP nunca bloquea un cambio de contraseña).
• El restablecimiento de contraseña de autoservicio es seguro frente a la enumeración y revoca todas las demás sesiones al usarse.

Autenticación multifactor

• Códigos de autenticación TOTP con códigos de recuperación de un solo uso, además de claves de acceso FIDO2/WebAuthn (con detección de clonación).
• Establece Organization.requireMfa para exigir la 2FA en una organización. A los usuarios se les guía por el registro y se les bloquea el acceso a la aplicación hasta que lo completen.

Defensa contra fuerza bruta y secuestro de cuentas

• Dos capas de limitación: un límite de velocidad por IP en los endpoints de inicio de sesión/MFA y un bloqueo por cuenta (tras un umbral de intentos fallidos, la cuenta se bloquea durante una ventana que crece exponencialmente) que frustra el relleno de credenciales distribuido.
• Auditoría de inicio de sesión: se registra cada intento (IP, user-agent, resultado) y los usuarios pueden ver sus inicios de sesión recientes en Ajustes → Seguridad.
• Alertas de dispositivo nuevo: la primera vez que un dispositivo inicia sesión, la cuenta recibe un correo de «nuevo inicio de sesión»; los cambios de contraseña y de MFA también notifican al usuario (condicionado por SECURITY_EMAILS_ENABLED).

Inicio de sesión único (OIDC por organización)

Configura una conexión OIDC genérica por organización (flujo de código de autorización). La organización se resuelve a partir del dominio de correo del usuario (descubrimiento de dominio de origen), los usuarios se aprovisionan justo a tiempo si su dominio está alojado, y el secreto de cliente es de solo escritura (sellado en reposo, nunca se devuelve).

Puedes aplicar el SSO en una organización (ssoEnforced) para desactivar por completo el inicio de sesión con contraseña, con dos salvaguardas para que no te quedes fuera: solo surte efecto mientras exista una conexión SSO utilizable, y las cuentas SYSADMIN siempre conservan el inicio de sesión con contraseña como recurso de emergencia.

Consulta Onboarding de autoservicio y autenticación externa para la API de autenticación completa, y Seguridad para la referencia detallada.

El servidor de correo

Por defecto, Goooy es autónomo: acepta el correo entrante en sus propios escuchadores SMTP (2525) y LMTP (2526), retransmite el saliente mediante nodemailer, puntúa el spam con una heurística integrada basada en reglas y entrega localmente entre los usuarios alojados, de modo que el correo interno funciona sin ninguna infraestructura externa.

Para el correo de internet real, habilita la pila de Postfix + Dovecot + Rspamd y la API se convierte en el centro de entrega de un servidor de correo completo:

helm upgrade goooy ./deploy/helm/goooy --set mail.enabled=true

Internet ─SMTP:25─▶ Postfix ──milter──▶ Rspamd ──LMTP──▶ api ─┬─▶ Postgres (web UI; spam→Junk)
 clients ─587/465─▶  (MTA, SASL)        (scan+DKIM)           └─▶ Dovecot ─▶ Maildir (IMAP/POP3)

• Postfix acepta el correo de tus dominios alojados (consultados en vivo en Postgres), lo analiza a través del milter de Rspamd (SPF/DKIM/DMARC + puntuación de spam) y lo entrega a la API mediante LMTP.
• La API escribe el mensaje en Postgres (el almacén del webmail, archivando en Correo no deseado el spam marcado por Rspamd) y lo replica en Dovecot para que los clientes IMAP/POP3 nativos lo vean.
• El correo saliente se retransmite de vuelta a través de Postfix, firmado con DKIM por Rspamd.

El anti-phishing está integrado: los resultados de autenticación del remitente entrante se almacenan por mensaje; un banner de remitente externo señala el correo procedente de fuera de tus dominios; las suplantaciones del propio dominio que no están autenticadas se archivan en Correo no deseado con una advertencia contundente; las acciones «Denunciar» / «No es spam» de los usuarios entrenan el filtro bayesiano de Rspamd; y el lector advierte sobre enlaces engañosos, hosts con homógrafos/punycode y suplantación del nombre visible, con el contenido remoto bloqueado por defecto y servido a través de proxy.

Enlaces seguros y sandboxing de adjuntos. Dos defensas adicionales para el correo entrante pueden activarse por organización en Admin ▸ Seguridad del correo (ambas desactivadas por defecto):

• Enlaces seguros reescribe cada enlace del correo externo entrante y vuelve a comprobar el destino en el momento del clic: las URL de la lista de bloqueo reciben una página de bloqueo, las sospechosas (hosts con IP literal, credenciales incrustadas, imitaciones punycode) una página de advertencia, y las limpias redirigen directamente: cada clic queda auditado. Las copias enviadas, el correo interno y los cuerpos firmados o cifrados permanecen intactos.
• El sandboxing de adjuntos detona estáticamente los adjuntos entrantes, además del análisis antivirus siempre activo: ejecutables detectados por su contenido, proyectos de macros de Office, archivos comprimidos protegidos con contraseña o anidados, y HTML/SVG con scripts. El correo malicioso se archiva en Correo no deseado, y cualquier adjunto marcado queda en cuarentena (descarga bloqueada) hasta que un administrador de la organización lo libere.

Precaución operativa: nunca pongas permit_mynetworks en un escuchador SMTP expuesto a internet. Eso crea un open relay. Las configuraciones que se distribuyen separan el puerto público :25 de un puerto de envío solo interno precisamente por esta razón. El detalle completo y los límites están en Servidor de correo y deploy/mail/README.md.

Clientes nativos y gestión de dispositivos

Goooy habla los protocolos estándar, de modo que tus usuarios conservan las aplicaciones que ya tienen. Todos se montan en sus raíces bien conocidas y usan HTTP Basic (correo + contraseña) donde el protocolo lo espera:

Aplicación móvil de Outlook: la aplicación de Outlook para iOS/Android necesita un EAS de tipo OAuth que Goooy no ofrece; aconseja a los usuarios de iPhone/iPad que usen en su lugar la aplicación Apple Mail integrada.

Gestión de dispositivos móviles. Los dispositivos que se registran mediante ActiveSync quedan monitorizados. Desde la consola de MDM puedes listar los dispositivos registrados y solicitar un borrado remoto. El dispositivo se marca y se borra en su siguiente sincronización.

El servicio de soporte

Un servicio de soporte es una capa de flujo de trabajo sobre un buzón compartido, no un sistema aparte. Crea primero el buzón compartido, compártelo con los agentes y luego actívalo en Administración ▸ Soporte.

• Los agentes son exactamente las personas con las que está compartido el buzón. Quien solo tiene lectura puede abrir tickets, pero no asignarlos, responder ni cambiar el estado.
• Los ajustes de la cola guardan el prefijo de la clave (TCK), el horario laboral, los objetivos de primera respuesta y resolución en minutos laborables, el periodo de cierre automático y el acuse que se envía a un remitente nuevo.
• Las respuestas predefinidas se limitan a una cola o se comparten en toda la organización.
• La clasificación con IA es opcional por cola: sugiere prioridad y etiquetas, y nunca envía nada por su cuenta.

La entrega de correo no cambia: cada mensaje sigue llegando a la bandeja de entrada del buzón y sigue visible por IMAP, ActiveSync, MAPI y JMAP. Si desactivas el soporte, el buzón y todo su correo quedan tal cual estaban.

Autenticación del correo e informes

Publicar SPF, DKIM y DMARC es el primer paso; saber si funcionan es el segundo. Apunta la dirección rua= de tu registro DMARC a un buzón del dominio y Goooy analizará cada informe agregado según llega.

Administración ▸ Autenticación del correo muestra entonces, por dominio: la tasa de aprobación, la alineación de SPF y DKIM y las fuentes de envío que fallan, que es como distinguir un remitente legítimo olvidado de alguien que te suplanta. Los informes TLS de SMTP (TLS-RPT) llegan igual y sacan a la luz las conexiones fallidas o degradadas.

Goooy también puede alojar una política MTA-STS por dominio en /.well-known/mta-sts.txt, para que otros proveedores se nieguen a entregar tu correo por una conexión sin cifrar.

Aprovisionamiento con SCIM y LDAP

Tres formas de mantener las cuentas al día con tu directorio:

• SCIM 2.0 en /scim/v2, con un token bearer por organización. Tu proveedor de identidad crea, actualiza y desactiva usuarios y grupos según la gente entra, cambia de puesto y se va.
• Sincronización con LDAP / Active Directory, que trae usuarios y grupos de forma programada.
• Importación masiva por CSV para una carga puntual.

Combínalas con SSO por organización para que desactivar a alguien de forma centralizada le quite el acceso en todas partes, clientes nativos incluidos.

Migrar desde otro sistema

El Goooy Mover traslada los datos de una empresa existente a Goooy desde un servidor IMAP en vivo o desde archivos de exportación subidos: un administrador asigna cada buzón de origen a un usuario de Goooy (los usuarios que faltan se aprovisionan automáticamente), hace clic en iniciar y se transfiere en segundo plano con un seguimiento de estado en vivo por usuario. La interfaz de administración es Administración ▸ Migraciones.

Lo que conserva y garantiza:

• Jerarquía de carpetas: las carpetas conocidas (Bandeja de entrada, Enviados, Papelera, Correo no deseado, Archivo) se asignan a sus roles en Goooy; las carpetas más profundas se recrean como carpetas hijas.
• Fechas y estado: las fechas de recepción originales y el estado de leído/marcado, de modo que un buzón migrado se vea como el original.
• Reanudable e idempotente: registra puntos de control del progreso, de modo que si se detiene la API a mitad de un lote se reanuda desde donde se quedó, y volver a ejecutarla nunca crea duplicados (deduplicado por Message-ID, o por un UID para calendario/contactos).

La vía del servidor en vivo funciona con Gmail, Microsoft 365, Dovecot, Zimbra y la mayoría de los servidores IMAP (usa una contraseña de aplicación donde el proveedor la requiera: el asistente incluye perfiles de conexión de un clic para los proveedores más comunes). La vía de subida de archivos acepta Outlook .pst (correo + calendario + contactos), .mbox (correo, incluida una exportación de Google Takeout: la forma más sencilla de salir de una cuenta personal de Gmail), .ics (calendario) y .vcf (contactos), con el formato detectado automáticamente a partir del contenido del archivo. El flujo es Origen → Cuentas→ usuarios (con una prueba de credenciales por fila, o una subida por archivo) → Ejecutar → Panel en vivo con reintento por fila y pausa/cancelación por lotes. Todas las modificaciones se auditan. El detalle completo y la hoja de ruta (CalDAV/CardDAV, Microsoft 365 Graph, Gmail API, de inquilino a inquilino) están en Migración.

Multitenencia y aislamiento

Por defecto, Goooy es lógicamente multitenencia: cada consulta se delimita por orgId y se protege con RBAC, con todos los inquilinos compartiendo una única base de datos. Para requisitos más estrictos, un modo de aislamiento fuerte opcional otorga a cada inquilino su propio esquema de PostgreSQL o su propia base de datos:

TENANT_ISOLATION = shared (default) | schema | database

Un catálogo de plano de control resuelve la conexión correcta por solicitud (req.db), de modo que el valor predeterminado de base de datos compartida queda completamente sin cambios cuando no te acoges a la opción. Esto te permite ofrecer residencia de datos por inquilino o aislamiento contractual sin ejecutar despliegues separados. Consulta Multitenencia.

Seguridad y cumplimiento

Una lista de verificación condensada. La referencia autorizada es Seguridad.

• Transporte. TLS termina en el Ingress (opcionalmente automatizado con cert-manager). El TLS hacia los almacenes de respaldo se controla mediante la URL y no requiere cambios de código: ?sslmode=require en DATABASE_URL, rediss:// para Redis, endpoint de S3 con https://.

• Cabeceras. Helmet en la API; nginx establece una CSP estricta, X-Frame-Options: SAMEORIGIN, Referrer-Policy y una Permissions-Policy que limita la cámara/micrófono/captura de pantalla al propio origen. El CORS está delimitado a PUBLIC_WEB_URL (las rutas de protocolo nativo están exentas de forma intencionada; no lo «arregles»).

• Seguridad del correo de extremo a extremo (S/MIME). Cada usuario puede tener una identidad X.509 autofirmada para firmar/verificar (RSA-SHA256) y cifrar/descifrar (RSA-OAEP híbrido + AES-256-GCM, multidestinatario); la clave privada está sellada en reposo y nunca se devuelve en claro.

• Representación del correo. El correo en HTML se depura con DOMPurify y queda restringido por la CSP de nginx. Conserva ambos.

• Secretos en reposo. Las claves S/MIME, los secretos de cliente de SSO y las credenciales de migración se sellan con AES-256-GCM usando JWT_SECRET. Proporciona tu propio Secret; rota JWT_SECRET de forma deliberada (invalida los valores sellados).

• Los contenedores se ejecutan sin root bajo un contexto de seguridad restrictivo.

• Soberanía de datos. Goooy es autoalojado de extremo a extremo. Tú eliges la región y el proveedor para cada almacén. Consulta Soberanía de datos.

• Retención. Las políticas por organización caducan correo, archivos y mensajes según el calendario que fijes. El barrido corre en segundo plano y queda auditado.

• Retención legal. Una retención sobre una persona conserva sus datos, anula la caducidad hasta que se levante y exporta todo en JSON para su revisión.

• Prevención de fuga de datos. Análisis para toda la organización en correo, chat y archivos según los patrones que configures.

Licencia: AGPL-3.0-or-later.

Copias de seguridad y operaciones

• Qué respaldar: PostgreSQL (el sistema de referencia) y tu bucket de S3 (los blobs de archivos y adjuntos). Redis es efímero y no necesita copia de seguridad. El chart puede ejecutar un CronJob nocturno de pg_dump (backup.enabled=true).
• Sondas de estado: la API expone /healthz (liveness) y /readyz (readiness respaldada por la base de datos) para Kubernetes.
• Escalado: la API no tiene estado (autenticación JWT) y difunde el tiempo real mediante el pub/sub de Redis, de modo que escala horizontalmente. Habilita el HPA (autoscaling.enabled=true, necesita metrics-server) y un PodDisruptionBudget para despliegues seguros.
• Observabilidad: registros JSON estructurados (pino).
• Cambios de esquema: el contenedor de la API ejecuta prisma migrate deploy al arrancar, de modo que las migraciones confirmadas se aplican automáticamente en el despliegue.
• No mates los puertos de ingesta (2525/2526) para «liberarlos» en un entorno en ejecución. Así es como llega el correo entrante.

Registro de autoservicio y tu portada de marketing

Goooy puede ejecutar un flujo público de registro de autoservicio para que los clientes creen su propia organización. Está desactivado por defecto. Establece SELF_SIGNUP_ENABLED=true para activarlo. El endpoint crea de forma atómica una Organization, su primer Domain y un usuario ORGADMIN (nunca SYSADMIN), y devuelve una sesión activa. Está limitado por IP como barrera contra el abuso.

La aplicación web incluida ya trae una página pública /signup que impulsa este flujo en el mismo origen, así que no tienes que construirla. Y se incluye un sitio de marketing estático de Astro (apps/marketing) como puerta de entrada pública. Habilítalo en su propio host:

helm upgrade goooy ./deploy/helm/goooy \
  --set marketing.enabled=true \
  --set marketing.host=www.example.com

Su CTA de «Empezar» enlaza con la página /signup de la aplicación. La API completa de autenticación externa (inicio de sesión, MFA, SSO, sesiones, verificación de dominio), todo lo que necesitarías para construir en su lugar tu propia portada de registro, está documentada en Onboarding de autoservicio y autenticación externa.

Empezar

• ¿Nuevo por aquí? Lee la Guía del usuario para conocer la visión de cada aplicación desde el punto de vista del usuario final.
• ¿Vas a desplegar o integrar la plataforma? La Guía del desarrollador cubre la arquitectura, el despliegue con Helm/Docker Compose y la configuración.
• Explora las páginas de resumen de funciones, seguridad y cumplimiento y autoalojamiento.
• La referencia técnica completa (arquitectura, modelo de datos, servidor de correo, multitenencia, despliegue, migración y los protocolos de cliente nativo) se distribuye con el código fuente del producto.