binding

binding — configure binding specific options

Use the binding stanza to define per-binding configuration options. You can nest domain and host stanzas inside binding stanzas to create per-binding per-domain, or per-binding per-host configurations.

Apart from the domain and host options, the following options are commonly specified in a binding stanza:

• bind_address

• connect_timeout

• ehlo_hostname

• generate_bounces

• message_expiration

See Table 9.26, “binding options” to determine whether an option is valid in the binding scope. An example of a binding stanza follows.

Binding names are case-sensitive. Spaces and colons are not allowed in binding names.

The default binding is a special case of a binding scope. This binding exists without being explicitly defined. You can confirm its existence by issuing the ec_console command binding summary. Along with any other bindings that you have defined, you should also see Summary Statistics For Binding default.

However, if you wish, you can explicitly create the default binding scope and set options in that scope. Do this in the following way:

Defining and using the "default" binding is required any time you want to change the behavior for any message that isn't assigned to some other binding. Do this in your configuration file as indicated above or set it at runtime using Lua (or Sieve). Setting the default binding from a script is done in exactly the same way as setting any other binding. For an example of setting a binding see msg:binding.

Even if you never assign messages to bindings the "default" binding can still be used to alter default behavior. This is done by setting the values of options in the default binding scope.

More importantly, if you do assign messages to bindings, ensure that all messages are assigned to bindings, or make sure that the fallback binding (otherwise known as "default") does what you want. Good scripting practice ensures that there is always an else clause or some other way of ensuring that all messages are always dealt with in some way. For example, you could create a variable at the top of your script with the most general binding, then if blocks to assign a message to a more specific binding if it matches. At the end of the script, assuming no if condition applies, the else clause would assign the message to the most general binding.

In a cluster configuration, if you wish to set an option to different values within the default binding scope you can do this by explicitly defining the default binding in the node-specific configuration file and then defining options within that scope. You can create a node-specific configuration file using the web UI or by manually creating it as described in “Best Practices for Adding Configuration Files”.

When you are removing a binding that is in use take the following steps:

1. Examine the binding assignment to determine if there are any policy settings associated with the binding.

2. If there are none, then suspend the binding and apply the configuration changes. For information about suspending a binding see suspend_delivery.

3. Examine the mail queue. If there is mail for the suspended binding, reassign it to another binding. If the queued messages are not reassigned to another binding, they will go to the default binding. For more information see showqueue and reroute queue.

4. Once all of reassigned messages are out of the queue, restart ecelerity to fully remove the binding from the configuration.

binding is valid in the global scope and in the binding_group scope.

The options valid in the binding scope are as follows:

binding_group domain, host, “Configuration Scopes and Fallback”, ec_set_binding, “Set binding example”