1

I've set up an email server for my business, and everything is working fine as long as the email addresses are accessed through Thunderbird. I've got an employee that has a license for Outlook that they've have before, and prefers to use that. When trying to connect the account as POP3 via Outlook, I get the following log messages:

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 is an Ubuntu Server 20.04 image. I see that the milter is what's rejecting the connection, but I'm not sure what rules this would be. I have currently got a plain install of Spam Assassin with no changes to rules or scores.

My config for the spamass-milter is located in /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"


######################################

My spam assassin config located in /etc/defaut/spamassassin is:

# /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

I've really got no idea what Outlook is sending at this point, nor why it would have an issue while Thunderbird is able to get logged into the account with no trouble.

Zalerinian
  • 131
  • 1
  • 1
  • 8

1 Answers1

5

I have resolved this issue thanks to Michael Hampton's comment: It was not to do with Spam Assassin as I initially thought it was. I forgot that OpenDMARC is a milter itself, and assumed the milter rejecting the email was the one I just set up - Spam Assassin. Turns out, when adding an account or changing settings on an existing account, Outlook sends a default test email to the address being added/modified to test its ability to send and receive emails. Also turns out, this test email does not have a Date header, and my opendmarc config had RequiredHeaders set to true, causing it to reject the test email, because it violates RFC5322.

Instead of slapping the current date on the email to follow the spec, Outlook just doesn't include the date in this test email. Once the account is setup on Outlook, it does include the date setting, so if you've got a limited number of users that need to get setup with Outlook, I suppose you can disable the setting for OpenDMARC, get them all setup, and then turn it back on, as then the date should be in all new emails.

Zalerinian
  • 131
  • 1
  • 1
  • 8