How to inspect incoming email issues

[isscbta]

Here you will find step-by-step solutions on how to inspect a variety of problems with incoming emails:

1. For example, let's say that emails sent from domain.com are not reaching your Inbox or they are going into the Spam folder:

- First, you should check logs, to do this - in your SSH, as root, run:

Code: Select all

exigrep 'domain.com' /var/log/exim4/mainlog

Now depending on the date when the problem occurred, you should inspect mainlog.1 / rejectlog / rejectlog.1 to find what is the problem

Possible problems:
A: Let's say that you got this output from exigrep:

Code: Select all

root@server:~# exigrep 'domain.com' /var/log/exim4/mainlog
2022-08-04 11:52:46 1oJXX4-0004XK-SL DKIM: d=domain-com.20210112.gappssmtp.com s=20210112 c=relaxed/relaxed a=rsa-sha256 b=2048 [verification succeeded]
2022-08-04 11:52:47 1oJXX4-0004XK-SL <= [email protected] H=mail-ej1-f41.google.com [209.85.218.41] P=esmtps X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 CV=no S=5042 [email protected]
2022-08-04 11:52:48 1oJXX4-0004XK-SL => receiving.email <[email protected]> R=localuser_spam T=local_spam_delivery
2022-08-04 11:52:48 1oJXX4-0004XK-SL Completed

Take a close look at this line: 2022-08-04 11:52:48 1oJXX4-0004XK-SL => receiving.email <[email protected]> R=localuser_spam T=local_spam_delivery

This means that emails sent from [email protected] to [email protected] are going to spam, so you should whitelist this email/domain in order to prevent this. Here you can find how to whitelist domain in spamassassin: viewtopic.php?f=16&t=594&p=1993#p1993

B: If the log shows 'authentication error' related to domain.com, you should check where is their email server hosted: https://mxtoolbox.com.
If domain.com (this is the domain from which we should receive email) have external MX records in place, the server may be attempting to deliver email locally on the server instead of delivering the email to the servers listed as domain.com MX records. In that case, you need to contact the administrator of the remote server to do an investigation on his server.

On our side, we can check if emails for domain.com were hosted on our server, by running this command:

Code: Select all

 ls -l /etc/exim4/domains/ | grep 'domain.com' 

If there is no output, that means it's not hosted on our server. Furthermore, if there is an output that indicates that we are hosting emails for this domain, but MX is showing some other mail servers different from ours, then that's the reason for those authentication errors and not receiving emails.

To get a deeper understanding of this, let's go through one simple example:
- Domain AAA.com is hosted on Google Workspace
- Domain BBB.com is hosted on our server
- Domain AAA.com is sending an email to BBB.com
- At some point in time, our server hosted AAA.com, and after that AAA.com was migrated to Google Workspace, but meanwhile we didn't delete AAA.com from our email tab at myVesta hosting panel. So an email is coming from AAA.com hosted on Google Workspace, our server is going to receive that email - but before he does that, the server checks if AAA.com is already hosted on our server and realizes that there is AAA.com hosted on our (email) server. Because of this, our server stops receiving emails from AAA.com as a measure to prevent potential email fraud

2. Another problem that possibly could prevent emails from reaching the inbox:

If you in your SSH, as root, have run:

Code: Select all

exigrep '[email protected]' /var/log/exim4/mainlog

And then found this line:

Code: Select all

...
2022-09-08 09:18:35 1oWBo2-0004vr-Pg == [email protected] R=localuser T=local_delivery defer (-22): mailbox is full (MTA-imposed quota exceeded while writing to tmp/1662621515.H369942P18974.mail.domain.com)

This means that the email quota is reached, and should be increased.