-/* $Cambridge: exim/src/src/acl.c,v 1.66 2006/09/25 10:14:20 ph10 Exp $ */
+/* $Cambridge: exim/src/src/acl.c,v 1.67 2006/11/14 16:40:36 ph10 Exp $ */
/*************************************************
* Exim - an Internet mail transport agent *
{ US"accept", US"defer", US"deny", US"discard", US"drop", US"require",
US"warn" };
-/* For each verb, the condition for which "message" is used */
-
-static int msgcond[] = { FAIL, OK, OK, FAIL, OK, FAIL, OK };
+/* For each verb, the conditions for which "message" or "log_message" are used
+are held as a bitmap. This is to avoid expanding the strings unnecessarily. For
+"accept", the FAIL case is used only after "endpass", but that is selected in
+the code. */
+
+static int msgcond[] = {
+ (1<<OK) | (1<<FAIL) | (1<<FAIL_DROP), /* accept */
+ (1<<OK), /* defer */
+ (1<<OK), /* deny */
+ (1<<OK) | (1<<FAIL) | (1<<FAIL_DROP), /* discard */
+ (1<<OK), /* drop */
+ (1<<FAIL) | (1<<FAIL_DROP), /* require */
+ (1<<OK) /* warn */
+ };
/* ACL condition and modifier codes - keep in step with the table that
follows, and the cond_expand_at_top and uschar cond_modifiers tables lower
/* If the result is the one for which "message" and/or "log_message" are used,
-handle the values of these options. Most verbs have but a single return for
-which the messages are relevant, but for "discard", it's useful to have the log
-message both when it succeeds and when it fails. Also, for an "accept" that
-appears in a QUIT ACL, we want to handle the user message. Since only "accept"
-and "warn" are permitted in that ACL, we don't need to test the verb.
-
-These modifiers act in different ways:
+handle the values of these modifiers. If there isn't a log message set, we make
+it the same as the user message.
"message" is a user message that will be included in an SMTP response. Unless
it is empty, it overrides any previously set user message.
"log_message" is a non-user message, and it adds to any existing non-user
message that is already set.
-If there isn't a log message set, we make it the same as the user message. */
+Most verbs have but a single return for which the messages are relevant, but
+for "discard", it's useful to have the log message both when it succeeds and
+when it fails. For "accept", the message is used in the OK case if there is no
+"endpass", but (for backwards compatibility) in the FAIL case if "endpass" is
+present. */
-if (((rc == FAIL_DROP)? FAIL : rc) == msgcond[verb] ||
- (verb == ACL_DISCARD && rc == OK) ||
- (where == ACL_WHERE_QUIT))
+if (*epp && rc == OK) user_message = NULL;
+
+if (((1<<rc) & msgcond[verb]) != 0)
{
uschar *expmessage;
+ uschar *old_user_msgptr = *user_msgptr;
+ uschar *old_log_msgptr = (*log_msgptr != NULL)? *log_msgptr : old_user_msgptr;
/* If the verb is "warn", messages generated by conditions (verification or
- nested ACLs) are discarded. Only messages specified at this level are used.
+ nested ACLs) are always discarded. This also happens for acceptance verbs
+ when they actually do accept. Only messages specified at this level are used.
However, the value of an existing message is available in $acl_verify_message
during expansions. */
- uschar *old_user_msgptr = *user_msgptr;
- uschar *old_log_msgptr = (*log_msgptr != NULL)? *log_msgptr : old_user_msgptr;
-
- if (verb == ACL_WARN) *log_msgptr = *user_msgptr = NULL;
+ if (verb == ACL_WARN ||
+ (rc == OK && (verb == ACL_ACCEPT || verb == ACL_DISCARD)))
+ *log_msgptr = *user_msgptr = NULL;
if (user_message != NULL)
{
return ERROR;
}
-/* Before giving an error response, take a look at the length of any user
-message, and split it up into multiple lines if possible. */
+/* Before giving a response, take a look at the length of any user message, and
+split it up into multiple lines if possible. */
-if (rc != OK && *user_msgptr != NULL && Ustrlen(*user_msgptr) > 75)
+if (*user_msgptr != NULL && Ustrlen(*user_msgptr) > 75)
{
uschar *s = *user_msgptr = string_copy(*user_msgptr);
uschar *ss = s;