:fail: doesn't fail

[Ben]

Is anyone else having trouble when someone sets there default address to :fail: and it doens't actually fail.

What I mean is, I have a customer who has set there default address to :fail:

Now when someone sends an email to a nonexistent address (e.g. thisuserdoesntexist@domain.tld) a bounceback is NOT returned to sender.

Anyone know what could be causing this?

[sexy_guy]

Originally posted by Ben
Is anyone else having trouble when someone sets there default address to :fail: and it doens't actually fail.

What I mean is, I have a customer who has set there default address to :fail:

Now when someone sends an email to a nonexistent address (e.g. thisuserdoesntexist@domain.tld) a bounceback is NOT returned to sender.

Anyone know what could be causing this?

Why would they want it to be returned to sender? I dont get this option. 99.999% it will not be returned because its from some spammer whose forged everthing. All that will do is clog up your outqueue with useless junk that will need purging manually or from WHM. So if its broke who cares. Just another bug they need to fix if it becomes and important issue and as far as I'm concerned its really a useless option.

[Annette]

First off, IMO :fail: should never be used. It's a royal pain when it comes to spammers and their habit of using nonexistent return addresses. You get junk in the spool that takes days to expire, and while that's not generally a problem, it's messy. I like tidy blackholes for people who don't want mail to certain addresses at their domain.

Second: did you look at exim_mainlog to see what happens when you send a test message to anything@theirdomain.com?

[Ben]

exim_mainlog reports a forced failure, but a bounceback is still never returned to sender

[Annette]

If you look past the forced failure to the attempt exim makes to send the mail back, what appears? Can you cut and paste one complete iteration?

[Ben]

2003-05-01 22:44:33 19BQXJ-0000Y7-00 <= ben@cyberpixels.com H=snipe.mail.pas.earthlink.net [207.217.120.62] P=esmtp S=1026 id=000001c31054$a572fe60$b600a8c0@phantom6umjngb

2003-05-01 22:44:33 19BQXJ-0000Y7-00 ** 1212thisisjustatest@bbhhlaw.com: forced failure:

2003-05-01 22:44:33 19BQXJ-0000YA-00 <= <> R=19BQXJ-0000Y7-00 U=root P=local S=1851

2003-05-01 22:44:33 19BQXJ-0000Y7-00 Error message sent to ben@cyberpixels.com
2003-05-01 22:44:33 19BQXJ-0000Y7-00 Completed

[Annette]

That looks fine - exim is properly bouncing the mail and generating the log entry to tell the world it sent a message back. There should be an entry after that with exim sending the mail back to you, like the last two lines here:

2003-05-02 00:41:20 19BSMK-0002h5-00 <= admin@hostmatters.com H=[] P=smtp S=759 id=NEBBIGCCELAPHFGMPLFHCEOEAMAB.admin@hostmatters.com
2003-05-02 00:41:20 19BSMK-0002h5-00 ** aaa@hostmatters.com: forced failure:
2003-05-02 00:41:20 19BSMK-0002hO-00 <= <> R=19BSMK-0002h5-00 U=root P=local S=1560
2003-05-02 00:41:20 19BSMK-0002h5-00 Error message sent to admin@hostmatters.com
2003-05-02 00:41:20 19BSMK-0002h5-00 Completed
2003-05-02 00:41:20 19BSMK-0002hO-00 => admin <admin@hostmatters.com> D=virtual_user T=virtual_userdelivery
2003-05-02 00:41:20 19BSMK-0002hO-00 Completed

The return message will also have a completely different message id than the original.

[Ben]

I know, and I am sure that the logs are just fine, however, a bounce back is still never recieved.

[Express]

try :blackhole:

[Annette]

Originally posted by Ben
I know, and I am sure that the logs are just fine, however, a bounce back is still never recieved.

:fail: does work, and is working in your case. The problem is either a) the mail is not being delivered to your address because of some inherent issue (lockfile, lookup failure, or any of the other common issues that affect mail delivery) or b) you have a filter in place deleting the mail as it's coming back. Your issue is not with :fail:, which is working fine. You have some other issue going on, and without verifying in the logs that the mail is actually making it back to the sender instead of generating some other error, you'll never know what that might be or which one of those two options it actually is. Good luck with the resolution.

[Website Rob]

If we look at this example a little differently:

2003-05-02 00:41:20 19BSMK-0002h5-00 <= admin@hostmatters.com H=[] P=smtp S=759 id=NEBBIGCCELAPHFGMPLFHCEOEAMAB.admin@hostmatters.com
2003-05-02 00:41:20 19BSMK-0002h5-00 ** aaa@hostmatters.com: forced failure:
2003-05-02 00:41:20 19BSMK-0002h5-00 Error message sent to admin@hostmatters.com
2003-05-02 00:41:20 19BSMK-0002h5-00 Completed

2003-05-02 00:41:20 19BSMK-0002hO-00 <= <> R=19BSMK-0002h5-00 U=root P=local S=1560
2003-05-02 00:41:20 19BSMK-0002hO-00 => admin <admin@hostmatters.com> D=virtual_user T=virtual_userdelivery
2003-05-02 00:41:20 19BSMK-0002hO-00 Completed

Note, there is a difference in the (R)eference numbers; one for what happened and one for the 'kick-back' msg.


The last 3 lines refer to sending or 'kicking' back an msg. to the eMail address used. Presuming Ben used, not only a fake eMail addy but an invalid one as well -- for testing purposes it's much faster, I know -- no 'kick-back' could be done and therefore, the last two lines are not included.

Other than that, though, I would agree that it appears to be working just fine. Do like Annette did and use an address that is valid, but created just for testing purposes, and you should see the same results in the log files -plus- get the 'kick-back' msg.

[bennet]

Including:fail: it will be necessary the creation of a new one it counts e-mail.
Example:
it counts main = domain
counts to be created = domain@domain.com

it will work like this.

[Ben]

Your suggestions really helped alot in tracking at least some of this down. It appears to be some sort of mail routing trouble between servers that we own, and even sometimes when a server tries to send mail to a site hosted on it. Which brings me to my next question.

What is the best way to test mail routing and verify that its working between multiple machines?