:fail: email, messages stuck in queue

[ttremain]

It's my understanding that if we use :fail: as the default address for a domain, then junk to that domain will be blocked from even comming into the server.

It's worked like this for years.

So if domain xxyz.com used :fail: no Such User Here

Why do I have a bunch of undeliverable emails in my queue that say:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

someone@xxyz.com
No Such User Here

I am using a standard Exim configuration, plus I've added "Mail Manage" and "Mail Queues" from ConfigServer

Any suggestions?

[LP-Tim]

I just noticed this morning that :fail: isn't failing for one of my domains. The mail sits in the queue. But just for one domain, the others seem ok. So far.

p.s. - also, when I went to edit the default address for this domain, I got:

The server was not able to find the document (./frontend/x3/def.html) you requested.

[ttremain]

This appears to have been something in cPanel 11.x

I changed from Current to Release, and this completely changed the exim.conf file.

Now verify = recipient is back in the exim.conf file, and when I send an email to a failed address, from my yahoo account, the yahoo daemon responds with the fail, instead of it being generated on my server.

I hope this helps someone later.

[rizalmhm]

My server same of you
don't know how to resolv
anyone ?

[ttremain]

After back-reving cPanel versions, other problems continued. These were caused by SpamAssassin 3.2

See this thread:
Spam Assassin v3.20 throwing errors

Once resolving all SpamAssassin problems, I was able to return again to cPanel 11.x (current) without any trouble.

[ttremain]

I seem to have spoke too soon...

I am now back to having all the :fail: emails being generated and put into the queue again, instead of being generated during the SMTP conversation.

[cpanelnick]

Can you post your /etc/exim.conf.local and /etc/exim.conf.localopts ?

Scratch that:

http://bugzilla.cpanel.net/show_bug.cgi?id=5410

[ttremain]

Nick-

Actually those have been changed since my last message. I've opened a ticket, and Russel is taking a look at it currently. He seems to ahve the original problem fixed, but is now working on a SpamAssassin issue that popped up.

If you are curious, it's ticket # 191425

Thanks!