Troubleshooting Exim
Debugging Exim configs
If you're not sure how Exim is coming to a given conclusion, and if you're familiar with standard SMTP using telnet, you can manually test Exim locally with the following command:
exim -d -bh 127.0.0.1
Which lets you enter on the stdin, as if it were the same as telnet to some other host. From there you can use the normal commands:
HELO host.name.com
MAIL FROM: your@email.com
RCPT TO: destination@email.com
DATA
And if it accepts this DATA command, enter your sample email with a tailing dot on its own line:
Subject: some subject
Hello,
test message.
.
If that works, you can end it with:
QUIT
Manually checking the certificate used for SMTP on port 25
As more servers and mail clients are requiring valid certificates for mail servers, you might need to view inside the certificate to see what's currently set. You can do this by running the following command for your hostname (server.hostname.com as an example):
openssl s_client -connect server.hostname.com:25 -starttls smtp -servername server.hostname.com
The "CN" value, or "Common Name", will be the current host value set inside the certificate. You'll be looking for the subject after the certificate output, so in the case of our mail server, we have a wildcard, so the important bits would look like:
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.directadmin.com
Once run, you'll actually be connected to the remote server. To leave, just type:
QUIT
to exit the current SMTP session.
If it's a self-signed certificate, you'll see this in the "SSL-Session:" header:
Verify return code: 18 (self signed certificate)
Note, the "-servername" is used to specify the SSL host if your Exim is running SNI to allow for multiple certificates.
Lowest numbered MX record points to local host
If you find the following message in your Exim mainlog or a bounce message:
lowest numbered MX record points to local host
that means that the MX records resolve to your own server, but the domain/host in question is not present in the /etc/virtual/domains file.
If the domain should be external, change the MX record to be external.
If the domain should be internal, add the domain to the
/etc/virtual/domainsfile... but of course, ensure it was properly added into DA as a domain. E.g., the following should also exist locally:
/etc/virtual/domain.com/
Related: Remote E-Mail.
Local domains get: 550 relay not permitted, authentication required
If you are trying to send email to local domains on your server, but Exim returns this error:
550 relay not permitted, authentication required
it means that Exim doesn't think the domain is local. This is controlled by the file /etc/virtual/domains . So, your domain is likely just missing from that file. Add the domain to that file to make the domain local.
This is related to the Using an external Mailserver feature, where the User has the ability to un-check the "Local Mailserver" option, causing the domain to be removed from the domains file.
BC: Delivery of local emails is slow when multiple recipients are used
The 1.10 version of BlockCracking for SpamBlocker 4.x has a new variable:
BC_VERIFY_CALLOUT =callout=3s,maxwait=5s,connect=2s,defer_ok,use_sender,hold
which is used to speed up the outbound checks on recipients when trying to scan for a rate-limited failure count for a given smtp-auth account. Basically, when someone tries to send with smtp-auth, each recipient's destination server is checked first to ensure it exists. If it doesn't, this counts towards a hit. If there are enough hits within a given amount of time, the account will be blocked with BlockCracking.
The new setting speeds up the remote checking by aborting checks that take too long. For example, some remote mail servers love to sit around and make the client connection sweat before sending the SMTP headers to the client, which is entirely valid but means the smtp-auth client's connection to the DA server would be waiting around for the DA-to-remote server connection to finish. The new** BC_VERIFY_CALLOUT** settings lower the amount of time Exim should allow, so the smtp-auth send goes through much quicker. A timeout here does not count towards a BC hit.
The hidden side-effect appears to be that if a timeout does happen, when there are some remote recipients and some local, the remote recipients get their messages sent out without issue, but the local recipients have their message dropped into the mail queue without any errors. Exim does get around to sending them eventually, however it takes up to 30 minutes in some cases, and there are no "retry" or other similar errors added to the mainlog.
This may or may not be an Exim bug, we're not sure. Either way, if this annoys your clients, and you don't mind changing the settings to force the smtp-auth client to wait around longer, you can increase those BC exim-to-remote timeouts so that the timeouts hopefully don't hit.
Create the file /etc/exim.blockcracking/variables.conf.custom and inside, place the following, which will overwrite the defaults:
BC_VERIFY_CALLOUT ==callout=10s,maxwait=40s,connect=5s,defer_ok,use_sender
Note that the double == is correct.
Then restart Exim:
service exim restart
Feel free to tweak the settings to higher values to suit your needs, but if they're not having any effect, try fully shutting off BlockCracking to confirm if it's actually related to the issue.
IPv6 socket creation failed: Address family not supported by protocol
If your emails are not able to leave the box and you're getting errors like this below:
2013-01-25 01:31:27 2TyWGU-0004ex-Hp IPv6 socket creation failed: Address family not supported by protocol
2013-01-25 01:31:27 2TyWGU-0004ex-Hp gmail-smtp-in.l.google.com [2a00:1450:4010:c03::1a] Address family not supported by protocol
2013-02-06 03:35:07 1U31bI-0005f3-Km ASPMX.L.GOOGLE.com [2607:f8b0:4001:c02::1b] Network is unreachable
2013-02-14 11:22:32 1U6t2I-0004Ne-OW ASPMX.L.GOOGLE.COM [2607:f8b0:4001:c02::1a] Connection timed out
it means that your network device has IPv6 enabled, but your network itself doesn't support it.
The proper solution is to contact the datacenter and configure IPv6.
The simple solution is to tell Exim not to use IPv6 with:
disable_ipv6=true
Just customize it properly per /etc/exim.variables.conf.custom .
Rewrite exim configs after the change:
/usr/local/directadmin/custombuild/build exim_conf
The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does does not point to the sending IP
The message below implies that the 1.2.3.4 IP address doesn't have a reverse IP lookup (rDNS).
550-5.7.25 [1.2.3.4] The IP address sending this message does not
550-5.7.25 have a PTR record setup, or the corresponding forward DNS entry does
550-5.7.25 does not point to the sending IP
You can manually test the rDNS for an IPv4 or IPv6 with:
dig -x 1.2.3.4 @8.8.8.8
Where you'd replace 1.2.3.4 with the IPv4 or IPv6 address in question. The 8.8.8.8 is literal, it's google's pulic dns server. Solution: Most rDNS values are configured by your datacenter, or via the client portal where you manage your server's billing. It's rarely delgated to your DirectAdmin server for dns control unless specifically requested (often denied or unnecessary) IPv6 note: If 1.2.3.4 above is showing an IPv6 IP, you might not want exim to ever send on IPv6 and only ever send on IPv4. For this case, simply use the disable_ipv6=true option in exim.
Mailing List: Message too long (>40000 chars)
If you're using Majordomo to send messages to a mailing list and you run into this error in you Exim mainlog:
2013-09-18 06:41:30 1KM9Zz-00037V-4H <= owner-list@domain.com U=majordomo P=local S=321808 T="BOUNCE list@domain.com: Message too long (>40000 chars)" from for user@domain.com
Then you'd simply need to increase the limit.
Go to User Level -> Mailing Lists -> for the given list, click View.
Lastly, above the top table is text that says:
To change list and digest settings, click here
Click the link to edit the settings, and change 40000 to a higher value. It's the number of bytes for the entire message, including headers, body, and any attachments.
Debian: exim.service: Failed at step NAMESPACE spawning /usr/sbin/exim: Permission denied
Services are not starting, all throwing the error (example shown is pertaining to Exim):
exim.service: Failed at step NAMESPACE spawning /usr/sbin/exim: Permission denied
Report that it's a Debian/LXC container bug, info can be found here: https://forum.proxmox.com/threads/problem-lxc-mariadb-debian-10.55926/
Where enabling "Nesting" for the container reportedly should fix it.