Hopefully someone who is more familiar with Exim than I am can set me straight here.

We do backup MX for a customer whose main mailserver is a Cpanel/Exim machine. Actually, we do this for a lot of people who have Cpanel servers, but for some reason this one machine is acting strange... It's not bouncing incoming mail to bad addresses, but deferring it with:

550-"The recipient cannot be verified. Please all recipients of this message
550 to verify they are valid."

Mail to addresses that exist gets delivered fine.

I've spoken with the customer, helped them out as best I can, but for the life of me we can't get their server to bounce incoming email, just defer them. They've got the account set so the catch-all address is ":fail: no such address here" like Cpanel recommends.

Mail to no-longer-existant addresses at their domain gets deferred by their Cpanel server, accepted by our backup server, and then sits in the queue for a week before bouncing, which is getting annoying.

Any easy way to fix this, or should we just resign ourselves to this? It's not a huge problem, but it seems bad form to have a server that's not bouncing per se.

does the domains/accounts exists on the backup MX machine?

how do you re-forward the email when the main cpanel server is back ?

or the users checks both servers for mail everytime they pop3 or imap ?

The domain doesn't exist on the backup server per se; the machine just accepts the mail (for specified domains only, natch) and forwards it when the primary (Cpanel) server is up again. Two MX records, different priorities. Pretty straightforward.

hmm, never tried it though.

how does it really store emails and forward them to the primary MX ?

The server is set to accept email for the domain in question, and then does so, queueing it like any other messages for remote delivery to the primary mailserver. When that server becomes available again (or perhaps it is immediately available from the secondary server, but not the originating address because of network problems) the messages are sent to it for local delivery as normal.

None of which really helps with the silly Exim problem, though.

It may be really technical, but at least there's lots of (often third-party, admittedly) documentation for Qmail. Exim documentation seems sparse by comparison.

a 5xx SMTP error is not a defer, it's a fatal/permanent failure error. your backup MX should immediately bounce those messages when the primary MX responds with a 5xx.

(just wondering, what MTA is your backup MX running?)

I disagree. If the primary is up, let it respond and tell the sender about the non-existent account. That's not the job of anything but the primary server. Incoming relays shouldn't have anything to do with managing accounts or replying to mails. All they should do is queue and forward.

hehe... not trying to start an agruement on my first post... but i just couldn't resist hitting reply :stickout:

The backup's running the default build (from source) of Qmail.

The problem is that other (remote, 3rd-party) mailservers seem to be having the same problem interpreting/misinterpreting this response. At least, that's the impression I get.

During a typical day, the customer's primary mailserver will be up 100% of the time, and our relay server will receive perhaps a dozen messages, or a few more, for their domain - all for nonexistant accounts. At one point we gave them the complete list of recipients (culled from the mail logs) that our server handled for them for a week, and they were all nonexistant.

Considering that when their mail server does go down, we get one to three hundred emails per hour for them, for several dozen accounts, it really looks like other people's servers out there are also misinterpreting the 550 "The recipient cannot be verified" and rolling over to the backup server.

So is this a problem with Qmail, then, and not Exim at all?

When you are relaying mail for a domain (as a secondary mx), then one thing you'll see is spammers trying for all servers that will deliver mail, not just the primary. So they send mail through your server bound for your client. To your server that's completely fine, it's doing it's job which is relaying mail to the primary. This is one reason to see mail bound for your customers domain even when the primary is online.

The way mx works is that your server should never be relaying mail while their primary server is up and running -- unless you're acting as a gateway, and that's a different story.

A backup mx doesn't care about accounts, as none of the mail (usually) is delivered locally.

So I would say that the issue is your customer's (the Exim server), and not yours. If you are, when their server is down, queueing mail and then forwarding when their server is up, then you're doing all that is expected of you.

Having said that, I do see what you're saying about the deferred status.

But yeah, I'd say it's an Exim issue that's affecting you.

Just my 0.02 -- although I will admit to only having used sendmail for that, the principle should be the same I'd think.

Originally posted by Ankheg
The backup's running the default build (from source) of Qmail.

1. The problem is that other (remote, 3rd-party) mailservers seem to be having the same problem interpreting/misinterpreting this response. At least, that's the impression I get.

2. During a typical day, the customer's primary mailserver will be up 100% of the time, and our relay server will receive perhaps a dozen messages, or a few more, for their domain - all for nonexistant accounts.

3. Considering that when their mail server does go down, we get one to three hundred emails per hour for them, for several dozen accounts, it really looks like other people's servers out there are also misinterpreting the 550 "The recipient cannot be verified" and rolling over to the backup server.

So is this a problem with Qmail, then, and not Exim at all? oh. qmail :)

#2 - do you know whether these are spam? as picoyak mentioned, some spammers purposefully mail the secondary MX.

#1 and #3 - then it is those other people's servers which are non-compliant. the RFC821 from year 1982 describes error 550 as 'mailbox unavailable'. (reference: http://www.ietf.org/rfc/rfc821.txt ).

now that i've read your exact problem description, i think it's more of a spammer-sending-through-secondary-mx problem you have.

this problem is further compounded by the practice of spammers who send from non-existant addresses. so it ends up being double-bounced (bounced by primary MX if user doesn't exist, and then bounced by the "apparent sender's" sender).

Originally posted by picoyak
A backup mx doesn't care about accounts, as none of the mail (usually) is delivered locally.this is exactly why spammers pick the backup MX for spam delivery. it's an assumption that the backup MX is a dumb relay with no spam filtering or recipient verification. but this doesn't have to be the case :)

Originally posted by wKkaY
oh. qmail :)

#2 - do you know whether these are spam? as picoyak mentioned, some spammers purposefully mail the secondary MX.


I've had a look at some of them, and they're not spam per se; some are reply notifications from forums, some are monthly newsletters from various groups that claim, reasonably, to be opt-in, and aren't selling anything; some are Father's Day-type notices from, e.g. eBay to former accounts at this domain. All stuff, in other words, where I really believe they tried the primary server first. Checking with their admin confirms that these are all formerly-valid accounts, as well; it's not like they're dictionary spamming or somesuch.

Believe me, I know all too well about spammers sending to secondary MX's. That's actually how I first noticed this problem - looking through the addresses in the queue, I was surprised to see some that weren't "slqrgh24elgh@mail.ru" or whatever, and were actually at the domain I provide the MX service for.


now that i've read your exact problem description, i think it's more of a spammer-sending-through-secondary-mx problem you have.

this problem is further compounded by the practice of spammers who send from non-existant addresses. so it ends up being double-bounced (bounced by primary MX if user doesn't exist, and then bounced by the "apparent sender's" sender).

this is exactly why spammers pick the backup MX for spam delivery. it's an assumption that the backup MX is a dumb relay with no spam filtering or recipient verification. but this doesn't have to be the case :)

I completely understand about secondary MX spamming; we have to cope with that a lot. That sort of disk/bandwidth/processing overhead accounts for a good part of our charges for backup MX (regular MX, too) services. This situation is unusual because it's not bounces that can't be delivered, it's that either Qmail isn't understanding the recipient rejection, or the Exim server isn't authoritatively rejecting the recipient, for mail *from* valid addresses which will eventually bounce with the "I'm sorry, it's been ten days, I've given up trying to deliver this" message, which hurts my professional pride. :)

Normally spam comes in, and either gets delivered to the remote machine, or bounces. In the latter case, it can be delivered, or double-bounce and head to the bit-bucket. What's happening here is that messages come in, and the server keeps trying to deliver them, because for whatever reason they're not bouncing... yet it only seems to be affecting this one server and setup, which is what made me think it was Exim, and not Qmail.

Who knows. Legit addresses get deliveries just fine, so trying to sort this problem out isn't real critical, it was just one of those "hey, that doesn't seem right" kind of things.

Bah. :)

my apologies for restating the obvious (about spam) :)

ditto :\ i have a qmail doing backup for me and it works fine. so i'm pretty sure it's not a general exim problem. i guess it could be your client's setup. perhaps you can try telnetting to your client's exim server and test it by hand?

I've telnetted to their port 25 several times, and done a number of tests with all kinds of fake addresses and strange domains and whatnot, and always get the grammatically-stunted 550 error I posted.

I'm not going to worry about it anymore. I was hoping it was an easy problem, like some setting in Exim that turns off an authoritative rejection of addresses during SMTP to prevent spammers doing username harvesting in lieu of the "The recipient cannot be verified" message that says, really, nothing.

Now if my co-lo provider would ever respond to my emails, I'd be worry-free. :)

..and always get the grammatically-stunted 550 error I posted.LOL! the stock exim message is a short and sweet 'unknown user'.

I'm not going to worry about it anymore. I was hoping it was an easy problem, like some setting in Exim that turns off an authoritative rejection of addresses during SMTP to prevent spammers doing username harvesting in lieu of the "The recipient cannot be verified" message that says, really, nothing.that can be done pretty easily by editing the exim configs (in particular, turning off recipient verification). but since you don't wanna think about the problem anymore.. :)

(personally i prefer having the SMTP server reject at SMTP time when the recipient doesn't exist, rather accepting it then sending a delivery failure notification later)