Email :fail: message not giving proper message

[PWSowner]

Probably a question for our mail expert, Chirpy, but anyone can answer.

I recently tested some of my email :fail: settings and found out it's not sending the message I am telling it to.

On my kimrichards.net site I have the default set to:
:fail: No such address. Please resend to webmaster (at) kimrichards.net.
and I sent a test message to a nonexistant email there and got:
This Message was undeliverable due to the following reason:

Each of the following recipients was rejected by a remote mail server.
The reasons given by the server are included to help you determine why
each recipient was rejected.

Recipient: <fsfsdf@kimrichards.net>
Reason: "The recipient cannot be verified. Please check all recipients of this message to verify they are valid."


I know in the past the reason used to be what you specify after :fail: but it's not doing that anymore.

Why is the fail not giving the right message? Does how fail works not allow that option anymore?

[chirpy]

Just tested it out:

MAIL FROM: xxx@xxx.com
250 OK
RCPT TO: yyy@yyy.com
550-"The recipient cannot be verified. Please check all recipients of this
550 message to verify they are valid."

For yyy.com I have :fail: set with a distinctive response that isn't shown (note: domains changed to protect the guilty).

This would mean that either:

a. The :fail: message never used to work
b. The :fail: message stopped working after verify = recipient
c. The latest exim.conf has broken it

I'd go with c.

As to what's changed - I don't know because I haven't checked yet...

[chirpy]

...having checked it would actually appear to be have been b. rather than c. as exim.conf doesn't appear to have changed apart from a gramatical correction to that message and that damn split_spool_directory

Id' suggest a bugzilla request for them to lookup the bounce error after the :fail: directive in /etc/valiases/domain and use that as the message to the RCPT failure. Shoudl be emminemtly possible for them to do.

[PWSowner]

Bug report filed.
http://bugzilla.cpanel.net/show_bug.cgi?id=1549

[PWSowner]

I just did another little test. I sent an email to fsfsdf@kimrichards.net using my ISP as the mail server and still got the same bounce message saying:
Reason: "The recipient cannot be verified. Please check all recipients of this message to verify they are valid."

I changed the mail server to my own, on the same server, and the message didn't even get sent. I got a popup saying the exact same thing. Means my server checked for the existance of the email address BEFORE accepting the email, which is how it works now, and didn't even accept the email.

Almost looks to me like the new mail system, how it checks before accepting the email, doesn't allow custom fail messages.


To anyone out there who has an address set to fail with a custom message, if you send an email to that address, do you get the custom message, or do you get the default one like I got?

[chirpy]

Mike,

You definitely won't get any custom message if it fails at the RCPT SMTP stage and it hits verify = recipient, the code simply isn't there in exim.conf at the place it occurs to read the valiases file for the custom message.

[PWSowner]

So with the way the mail system works now, when setting an email to :fail:, it makes no difference what message follows that.

[chirpy]

Yes.

(line added cos of the character limit)

[chirpy]

Done some extensive testing. Currently you'll have this in the second box of the first triplet in the Exim Configurator:

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

If you get rid of the message line, so that you just have:

  verify = recipient

then the message in /etc/valiases will be used in the failure error to the sender.

However, if there is no message after the :fail: in /etc/valiases, there will be a blank 550 message in the failure error.

I did play with coding it to cope with this issue through a perl script, which worked, but didn't really complete it.

[PWSowner]

Thanks. It's a good thing you understand the mail system as well as you do. Now I have some tinkering to do.

As far as the case of no response, that's not a big deal. I use my own cpanel skins so I can add a note to that page, and I can always write a script to check the valiases entries and add the basic "no such address" for entries that don't have anything.


I need to find time to do some mail system studying some day.

[linux-image]

dunno if this helps.. chirpy and squirrel:
=============================
internal_search_find: file="/etc/valiases/xxxxxxxxx.com"
type=lsearch key="*"
file lookup required for *
in /etc/valiases/xxxxxxxxx.com
lookup yielded: :fail:
expanded: :fail:
file is not a filter file
parse_forward_list: :fail:
extract item: :fail:
virtual_aliases router forced address failure
sdgfsd@xxxxxxxx.com is undeliverable:

search_tidyup called
>>>>>>>>>>>>>>>> Exim pid=24960 terminating with rc=2 >>>>>>>>>>>>>>>>
==============================

and when it was set to blackhole it was:
==============================
internal_search_find: file="/etc/valiases/xxxxxxxxxx.com"
type=lsearch key="*"
file lookup required for *
in /etc/valiases/xxxxxxxxxxxxx.com
lookup yielded: :blackhole:
expanded: :blackhole:
file is not a filter file
parse_forward_list: :blackhole:
extract item: :blackhole:
address :blackhole:d
routed by virtual_aliases router
envelope to: sdgfsd@xxxxxxxxxx.com
transport: <none>
mail to sdgfsd@xxxxxxxxxxxx.com is discarded
search_tidyup called
>>>>>>>>>>>>>>>> Exim pid=25185 terminating with rc=0 >>>>>>>>>>>>>>>>
===============================

and also when this was set to :blackhole: .. it just worked.. but :fail: didnt. iam not sure of eventually the process or code... but just tried it out as you guys were serious on this.

the difference i see is at:
======================
virtual_aliases router forced address failure
sdgfsd@xxxxxxxx.com is undeliverable:

and

routed by virtual_aliases router
envelope to: sdgfsd@xxxxxxxxxx.com
transport: <none>
======================

hope this helps.

[PWSowner]

Originally Posted by chirpy

Done some extensive testing. Currently you'll have this in the second box of the first triplet in the Exim Configurator:

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

If you get rid of the message line, so that you just have:

  verify = recipient

then the message in /etc/valiases will be used in the failure error to the sender.

However, if there is no message after the :fail: in /etc/valiases, there will be a blank 550 message in the failure error.

I did play with coding it to cope with this issue through a perl script, which worked, but didn't really complete it.

Works perfect, just like it used to a while back. Thanks

All fails in the valiases had messages with them, but in case of users not including a message in the future, I'm going to write a simple script to check for :fail: with nothing after it, and just add "No such address" in those cases.

[PWSowner]

Originally Posted by linux-image

dunno if this helps.. chirpy and squirrel:

I imagine chirpy can decipher it, but I can't get much out of it.

[chirpy]

Yup. I know why it works that way, it's just the best way around it. It's straightforward enough to code, but the additional load might be better spent with a daily script to parse the valiases file as squirrel is doing.

[chirpy]

Done some more digging on this and will suggest this to cPanel:

http://www.exim.org/exim-html-4.40/d..._7.html#TOC254

If you change this:

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

to this:

  message = "The recipient cannot be verified. $acl_verify_message"
  verify = recipient

You get the best of both worlds