|
osdir.com mailing list archive |
|
Subject: Re: EXPN and :fail: - msg#00007List: mail.exim.devel> For comparison, I observe that exim3 (3.35) shows the :fail: message for > all three commands, but shows a filter fail message only for EXPN, not > for VRFY or RCPT. Just had time to take a quick look at the code. The change does seem to be deliberate, though I cannot find any documentation of when or why it happened. However, the change is there in Exim 4.00, so I think it must date from the great 3->4 upheaval, where a lot of individual changes didn't get noted. For release 4.11, the additional restriction of requiring the caller to be an admin user was added. The ChangeLog for this mentions only defer rather than hard errors, but the change was made for both. The reason for the restriction was to prevent "private" information escaping. At the level this is output, all Exim knows is that verification failed, and here is the error message. It no longer know that is was specifically :fail: that generated the message. The problem is that the message might be something internal such as a failed expansion, and that might contain, for example, LDAP password information. [I'm now offline for the best part of a week.] -- Philip Hazel University of Cambridge Computing Service, ph10@xxxxxxxxxxxxx Cambridge, England. Phone: +44 1223 334714. -- Thread at a glance:
Previous Message by Date: click to view message previewRe: EXPN and :fail:[Reply-to set to the exim-users list, which is the better home for this discussion, if there's any more to be had. The exim-dev list is currently for discussion of the Exim development process itself.] On Wed, 26 Jan 2005, Adam M. Costello wrote: > In exim4 (4.34) I observe that when I set a custom error message using > :fail: in /etc/aliases (or using the fail command in an exim filter), > I see the custom message in the result of a VRFY command, and in the > result of a RCPT command (if the relevant ACL doesn't override the > message, or incorporates $acl_verify_message into its override) but I > don't see it in the result of an EXPN command, and it looks like there's > currently no way of configuring EXPN to show it. Is that by design? Probably by accident. My natural instinct is to think that nobody permits the use of EXPN any more, so it is not in my consciousness. > For comparison, I observe that exim3 (3.35) shows the :fail: message for > all three commands, Thanks for pointing out this anomaly. I'll check them all out in the current source code, and fix the problem, as it seems reasonable that EXPN should show the error. Unless I find some buried comment in the code which explains why a change was made. If so, I'll document it. This may or may not happen before the 4.50 release, as I'm about to be away. -- Philip Hazel University of Cambridge Computing Service, ph10@xxxxxxxxxxxxx Cambridge, England. Phone: +44 1223 334714. -- Previous Message by Thread: click to view message previewRe: EXPN and :fail:[Reply-to set to the exim-users list, which is the better home for this discussion, if there's any more to be had. The exim-dev list is currently for discussion of the Exim development process itself.] On Wed, 26 Jan 2005, Adam M. Costello wrote: > In exim4 (4.34) I observe that when I set a custom error message using > :fail: in /etc/aliases (or using the fail command in an exim filter), > I see the custom message in the result of a VRFY command, and in the > result of a RCPT command (if the relevant ACL doesn't override the > message, or incorporates $acl_verify_message into its override) but I > don't see it in the result of an EXPN command, and it looks like there's > currently no way of configuring EXPN to show it. Is that by design? Probably by accident. My natural instinct is to think that nobody permits the use of EXPN any more, so it is not in my consciousness. > For comparison, I observe that exim3 (3.35) shows the :fail: message for > all three commands, Thanks for pointing out this anomaly. I'll check them all out in the current source code, and fix the problem, as it seems reasonable that EXPN should show the error. Unless I find some buried comment in the code which explains why a change was made. If so, I'll document it. This may or may not happen before the 4.50 release, as I'm about to be away. -- Philip Hazel University of Cambridge Computing Service, ph10@xxxxxxxxxxxxx Cambridge, England. Phone: +44 1223 334714. -- Loading Comments...
|
|
