Struggling to send anything from Exim4

/var/log/exim4/mainlog is just fine.

however as said above the entry you already posted seems to be from something that’s already stuck in the queue and probably won’t go out anyway anymore. it sadly tells nothing about, why it got into the mailqueue in the first place.

a full entry of a mail while trying to be sent the first time will be more than these three lines, holding informations about the sender, the recipient, the server connected and it’s response.
see f.i. @brackenhill-mob post/logentries in #9 above … [SOLVED] Upgrade to 1.2.0 borked Exim SMTP to GMail/GMX/Yahoo/others

there you can see a response from the smtp server complaining about the helo entry etc. - if you don’t have that your problem lies somewhere else.

but if we want to see why your mails get stuck, we need to get these informations, hence my suggestion of sending out an email that is expected to not work properly and immediately track the according log entries to that request.

in other words: only if you can reliably reproduce an issue you can track it down properly :wink:

1 Like

Ok, so as luck would have it, emails are now being sent, and successfully recieved by the recipients… Succesful tests with gmail, gsuite and a private server…

The smtp test on mxtoolbox.com still returns a localhost hello message though… I’ve no idea if that is a problem or not?

Connecting to 204.15.77.205

220 mail.emailfourgroups.com [613 ms]
EHLO keeper-us-east-1c.mxtoolbox.com
250-mail.emailfourgroups.com Hello localhost [127.0.0.1]

Thank you for your help guys!

glad it worked now.

and for your question: no that’s not a problem, because mxtoolbox tests the other way around. meaning the helo you see there is mxtoolbox greeting your server with, not the other way around :wink:
your server is responding with a ‘hello localhost’ but that’s not the actual HELO/EHLO command and actually doesn’t matter at all.

1 Like