mjhjmtu

Mail sent from a daemon on my server connecting to exim4 daemon light using SMTP seems to be being frozen. In the exim4 log:

2014-10-01 09:52:19 1XZKKJ-00049R-8p <= noreply@example.com H=localhost (server.example.com) [127.0.0.1] P=esmtp S=9492
014-10-01 09:52:22 1XZKKJ-00049R-8p ** someone@somewhere.com R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<someone@somewhere.com>: host somewhere.com [203.170.86.177]: 550-Verification failed for <noreply@example.com>
550-No Such User Here
550 Sender verify failed

I think this is saying exim4 rejected the sender's, i.e. the from email address? Exim4 is running on server.example.com and I am using noreply@example.com as the sender which does not exist - it worked in the past. I had to recently re-do domain records on example.com but they are all OK now and have percolated out (they were done days ago).

I think I have the same issue as here: http://help.directadmin.com/item.php?id=59, but cannot try the solution as cannot find exim4 configuration file is - there are many under /etc/exim4/conf.d (I just ran dpkg-reconfigure exim4-config when I installed exim) and the documentation says there is just one? Also how was it working before?

I am prepared to allow any sender - the firewall blocks external access to exim and I am only using it to send mail from my own daemon.

UPDATE Sending to other email addresses works, just to particular one (that is certainly valid) does not - which is weird because exim says it is problem with sender not recipient?!

It is the receiving MTA that is rejecting the non-existent sender; there is nothing that you can do about that on your end about that (besides simply using a real sender).

I also reject envelope senders that do not exist, as that means that NDRs also can't be delivered to the sender, and in 99.5% of the cases a non-existent envelope sender is spam or phishing or similar. There's no good reason not to use a working envelope sender.

Check for a "verify = sender" in your Exim acl's, such as the one that executes for the RCPT TO: command (look for acl_smtp_rcpt=xxxxx). That Exim option in an acl checks to make sure the sender is a "valid" (see exim docs for exactly what that means), and you may need to remove it since this is an internal server only sending from fake senders. In a production server, there are better ways to do the same.

If your acl's are checking the sender when processing the RCPT TO:, like some configurations do, then you can get this message where it looks like the problem is in the recipient when it is actually the sender verify causing the rejection.

Try running a command-line exim in address verification mode to see which acl's are executing:

exim4 -d -bvs noreply@example.com
exim4 -d -bv someone@somewhere.com