Configuré un servidor de correo electrónico para mi empresa y todo funciona bien siempre que se acceda a las direcciones de correo electrónico a través de Thunderbird. Tengo un empleado que tiene una licencia para Outlook que ya tenía antes y prefiere usarla. Al intentar conectar la cuenta como POP3 a través de Outlook, recibo los siguientes mensajes de registro:
Aug 14 04:04:00 ikana dovecot: pop3({employee-email})<240303></Eu1gs6svtFsEUYj>: Disconnected: Logged out top=0/0, retr=0/0, del=0/1, size=963
Aug 14 04:04:00 ikana postfix/submission/smtpd[240304]: connect from <employee IP>
Aug 14 04:04:00 ikana postfix/submission/smtpd[240304]: Anonymous TLS connection established from <employee IP>: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 14 04:04:00 ikana postfix/submission/smtpd[240304]: ADB8717A1CB: client=<employee IP>, sasl_method=PLAIN, sasl_username={employee-email}
Aug 14 04:04:00 ikana postfix/cleanup[240307]: ADB8717A1CB: message-id=<>
Aug 14 04:04:00 ikana opendmarc[229281]: ADB8717A1CB: RFC5322 requirement error: not exactly one Date field
Aug 14 04:04:00 ikana postfix/cleanup[240307]: ADB8717A1CB: milter-reject: END-OF-MESSAGE from <employee IP>: 5.7.1 Command rejected; from=<{employee-email}> to=<{employee-email}> proto=ESMTP helo=<{hostname redacted}>
Aug 14 04:04:00 ikana postfix/submission/smtpd[240304]: disconnect from <employee IP> ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=0/1 commands=6/7
El servidor es una imagen de Ubuntu Server 20.04. Veo que el milter es lo que rechaza la conexión, pero no estoy seguro de cuáles serían las reglas. Actualmente tengo una instalación simple de Spam Assassin sin cambios en las reglas ni en las puntuaciones.
Mi configuración para spamass-milter se encuentra en /etc/default/spamass-milter:
# spamass-milt startup defaults
# OPTIONS are passed directly to spamass-milter.
# man spamass-milter for details
# Non-standard configuration notes:
# See README.Debian if you use the -x option with sendmail
# You should not pass the -d option in OPTIONS; use SOCKET for that.
# Default, use the spamass-milter user as the default user, ignore
# messages from localhost
# The domain after the -e option is the default domain to use if the user is logging
# in/sending mail without a full email address. Otherwise, the domain used by the
# client will be passed to spam assassin.
OPTIONS="-e maaonline.net -u spamass-milter -i 127.0.0.1 -R 'Blocked for spam'"
# Reject emails with spamassassin scores > 15.
OPTIONS="${OPTIONS} -r 10"
# Do not modify Subject:, Content-Type: or body.
#OPTIONS="${OPTIONS} -m"
# Scan attachments up to 5MB
OPTIONS="${OPTIONS} -- --max-size=5242880"
######################################
# If /usr/sbin/postfix is executable, the following are set by
# default. You can override them by uncommenting and changing them
# here.
######################################
# SOCKET="/var/spool/postfix/spamass/spamass.sock"
# SOCKETOWNER="postfix:postfix"
# SOCKETMODE="0660"
######################################
Mi configuración de spam killer ubicada en /etc/defaut/spamassassines:
# /etc/default/spamassassin
# Duncan Findlay
# WARNING: please read README.spamd before using.
# There may be security risks.
# Prior to version 3.4.2-1, spamd could be enabled by setting
# ENABLED=1 in this file. This is no longer supported. Instead, please
# use the update-rc.d command, invoked for example as "update-rc.d
# spamassassin enable", to enable the spamd service.
# Options
# See man spamd for possible options. The -d option is automatically added.
# SpamAssassin uses a preforking model, so be careful! You need to
# make sure --max-children is not set to anything higher than 5,
# unless you know what you're doing.
OPTIONS="--create-prefs --max-children 5 --helper-home-dir --nouser-config --virtual-config-dir=/var/vmail/%d/%l/spamassassin --username=vmail"
# Pid file
# Where should spamd write its PID to file? If you use the -u or
# --username option above, this needs to be writable by that user.
# Otherwise, the init script will not be able to shut spamd down.
PIDFILE="/var/run/spamd.pid"
# Set nice level of spamd
#NICE="--nicelevel 15"
# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1
Realmente no tengo idea de qué está enviando Outlook en este momento, ni por qué tendría un problema mientras Thunderbird puede iniciar sesión en la cuenta sin problemas.
Respuesta1
Resolví este problema gracias al comentario de Michael Hampton: No tenía nada que ver con Spam Assassin como pensé inicialmente. Olvidé que OpenDMARC es un milter en sí mismo y supuse que el milter que rechaza el correo electrónico era el que acabo de configurar: Spam Assassin. Resulta que, al agregar una cuenta o cambiar la configuración de una cuenta existente, Outlook envía un correo electrónico de prueba predeterminado a la dirección que se agrega/modifica para probar su capacidad para enviar y recibir correos electrónicos. También resulta que este correo electrónico de pruebano tiene Dateencabezado, y mi configuración de opendmarc se había RequiredHeadersestablecido en true, lo que provocó que rechazara el correo electrónico de prueba porque viola RFC5322.
En lugar de colocar la fecha actual en el correo electrónico para seguir las especificaciones, Outlook simplemente no incluye la fecha en este correo electrónico de prueba. Una vez que la cuenta está configurada en Outlook, incluye la configuración de fecha, por lo que si tiene un número limitado de usuarios que necesitan configurar Outlook, supongo que puede desactivar la configuración de OpenDMARC, configurarlos todos y luego vuelva a activarlo, ya que entonces la fecha debería aparecer en todos los correos electrónicos nuevos.