Why a vacation message was not generated

The list of things that can go "wrong" with vacation messages is pretty much anything that can go wrong with a message in general, plus a lot more vacation-specific factors. For instance:



 the recipient domain isn&#x27;t defined properly in LDAP, with the result that the recipient domain isn&#x27;t found and matched as desired, 

 the recipient address isn&#x27;t defined properly in LDAP, with the result that (even once the recipient domain is found) the recipient address isn&#x27;t found and matched as desired, 

 the recipient domain or user is properly defined and found in LDAP, but currently has a domain or recipient status other than  " " (or a few active-with-special-handling variants such as " ", " ",   or " "), that is, has a status such as " " or " " or " " or " "; see the various  domain and user or group status LDAP attributes including  ,  , and  , (or more precisely, the LDAP attributes named, respectively, by the  ,  , and   MTA options), 

 the sender didn&#x27;t use an expected form of the recipient&#x27;s address; recall that vacation messages very specifically, (in accordance with what&#x27;s called for by the standards), don&#x27;t get sent unless either: the recipient address is "found" in a recipient  header line, or another alternate-but-expected address form is "found" in a recipient header line (with such alternate address matching being controlled  by the    action&#x27;s    argument or the LDAP attribute named by the    MTA option), 

 the actual original message contains any of various vacation disabling (again, as called for by standards) header lines or notification envelope flags, 

 the original message matches a   mapping  table entry that sets the   flag or has a system/channel Sieve script apply a " " action, 

 the original message came in when the user was not "on vacation" (as specified via the  and    LDAP attributes, or more precisely whatever attributes are named by the   and   MTA options), 

 within the relevant response timeout period, as called for by RFC 5230 (Sieve Vacation Extension) Section 4.2, the "same" vacation message was already sent to this sender; the length of the timeout period is controlled by the  action&#x27;s    parameter, or via LDAP attributes such  as    (or whatever attribute is named by the    MTA option) as modified by the    MTA option, </li>

 the MTA encountered problems accessing the vacation-response-database file, or (new in 8.0) problems communicating with Memcache if  the vacation response data is being stored in Memcache, </li>

 a Sieve script attempts to execute "too many"  actions,  where "too many" is controlled by the   MTA option (default 2), </li>

 attempting to use  from a system level Sieve script, </li>

 attempting to use  combined with ,  , or  , </li>

 syntax errors in a Sieve   action, </li>

 for vacation messages defined via LDAP attributes, suitable vacation response text is lacking: the user lacks a value for the  LDAP attribute, or in the case of an original  message sender in the same domain as the user, lacks values for both the   LDAP attribute and the (preferentially used to respond to other "internal" users)    LDAP attribute, (or more precisely, lacks values for the attributes named by the   and    MTA options), </li>

 etc. </li>

</ul>

Overall, keep in mind that a vacation message is only supposed to be sent if everything, absolutely everything, about a particular message lines up just right as far as that particular message getting a vacation message generated back in response. The fallback in case of problems or doubt about whether  a particular message meets all the criteria for sending back a vacation message is to  not generate a vacation message. See RFC 3834 (Recommendations for Automatic Responses to Electronic Mail) for some of the principles that apply.

As of the 8.0 release, warnings that occur during Sieve evaluation such as issues accessing the vacation-prior-response database (whether that "database" is stored as an on-disk file, or stored in memcache),  (as well as similar issues with the duplicate extension),  plus any specifically specified warning text specified via the  Sieve " " action will result in a " " clause in the    field of MTA message transaction log entries. But most of the above reasons why a vacation message was not generated will not result in any such warning, as they are considered part of normal operation.

See also:
 * Overview of Direct LDAP configuration
 * Sieve vacation extension
 * ldap_autoreply_addresses MTA Option
 * Initial FROM_ACCESS mapping table
 * ldap_start_date MTA Option
 * ldap_end_date MTA Option
 * vacation_minimum_timeout MTA Option
 * max_vacations MTA Option
 * ldap_autoreply_text MTA Option
 * ldap_autoreply_text_internal MTA Option
 * Autoresponse periodicity MTA options