Configurei um servidor de e-mail para minha empresa e tudo funciona bem, desde que os endereços de e-mail sejam acessados através do Thunderbird. Tenho um funcionário que possui uma licença do Outlook que já possui e prefere usá-la. Ao tentar conectar a conta como POP3 via Outlook, recebo as seguintes mensagens de log:
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
Server é uma imagem do Ubuntu Server 20.04. Vejo que o milter é o que está rejeitando a conexão, mas não tenho certeza de quais seriam essas regras. Atualmente, tenho uma instalação simples do Spam Assassin, sem alterações nas regras ou pontuações.
Minha configuração para o spamass-milter está localizada em /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"
######################################
Minha configuração do Spam Assassin localizada em /etc/defaut/spamassassiné:
# /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
Eu realmente não tenho ideia do que o Outlook está enviando neste momento, nem por que haveria um problema enquanto o Thunderbird consegue fazer login na conta sem problemas.
Responder1
Resolvi esse problema graças ao comentário de Michael Hampton: Não tinha a ver com o Spam Assassin como inicialmente pensei que fosse. Esqueci que o OpenDMARC é um milter em si e presumi que o milter que rejeitou o e-mail foi aquele que acabei de configurar - Spam Assassin. Acontece que, ao adicionar uma conta ou alterar as configurações de uma conta existente, o Outlook envia um e-mail de teste padrão para o endereço que está sendo adicionado/modificado para testar sua capacidade de enviar e receber e-mails. Acontece também que este e-mail de testenão tem Datecabeçalho, e minha configuração do opendmarc foi RequiredHeadersdefinida como true, fazendo com que ele rejeitasse o e-mail de teste, porque viola o RFC5322.
Em vez de inserir a data atual no e-mail para seguir as especificações, o Outlook simplesmente não inclui a data neste e-mail de teste. Depois que a conta é configurada no Outlook, ela inclui a configuração de data, portanto, se você tiver um número limitado de usuários que precisam configurar o Outlook, suponho que você possa desativar a configuração do OpenDMARC, configurar todos eles e em seguida, ligue-o novamente, pois a data deverá estar em todos os novos e-mails.