Acceptalladdresses, acceptvalidaddresses Channel Options

Envelope recipient validity checks
When specified on a source channel, the  option causes all envelope recipient addresses to be accepted unconditionally. Rather than returning errors during the SMTP session, a delivery status notification, or DSN, will be returned later if the message cannot be delivered to the specified recipient. With, various sorts of normally "invalid: recipient addresses will be accepted: syntactically invalid addresses,  addresses of local users with problematic status (such as being "over quota" or "disabled" -- see the  ,  ,  and    MTA options), and recipients of messages that fail message acceptability checks.  Relevant message acceptability checks include checking on whether a message: exceeds a configured  sensitivity limit, or contains unnegotiated eight bit data (on a source channel marked   or  ), or contains too-long-for-SMTP lines (on a source channel marked  ),  or exceeds a configured message size limit (such as   ,  ,  ,   ,  ,  ,  ,  ,  , or &#x5b;BLOCKLIMIT&#x5d;) or message line limit  (such as  ,  ,  , or &#x5b;LINELIMIT&#x5d;) when the excessive size is  detected after the DATA stage, or is entirely lacking in recipient header lines (on a source channel marked   , or if the MTA option    is  set), or is rejected via the     mapping table. Setting  will also disable the SMTP protocol level rejection feature of the Sieve " " action; with  , addresses to be rejected due to application of a " " action will be accepted during the SMTP dialogue, and instead a subsequent non-delivery DSN generated.

In contrast, setting the  option on a source channel causes all envelope recipient addresses to be validated prior to being accepted by the MTA. If an address fails to validate, an appropriate error will be returned to the client during the SMTP dialogue. is the default.

Note that the MTA&#x27;s default,, behavior is normally far preferable to  : rejecting invalid addresses and messages "up front" rather than accepting them initially only to have to generate and send back a non-delivery notification later has advantages that should hardly need to be pointed out, including:



 Less work for the MTA. The reductions in work are in several areas,   including: less processing required on incoming messages (in cases    where a recipient address can be detected as invalid), less work    generating non-delivery notification messages, less work attempting to    deliver non-delivery notification messages, etc. 

 Less network bandwidth required. 

 Due to the above two points, less potential impact on throughput of   other, valid, messages. 

 Immediate (via an SMTP error) notification to e-mail clients of the   error in their message, rather than a delayed notification via DSN. 

 Avoiding "blow-back" spam, in cases of so-called   "joe-job" (forged envelope From) spam. 



However,  can sometimes be useful in  certain limited cases, such as when attempting to support poorly  designed e-mail clients that fail to report SMTP errors correctly to  the user. In such cases a DSN, while providing only a delayed indication rather than an immediate indication of an address or message  problem, may be the only way to convey the MTA&#x27;s accurate error  information to the user. So appropriate use of   tends to be restricted to cases of  special incoming TCP/IP channels dedicated for submission of messages  by applications or user e-mail clients with known limitations;    effects,  or else channels associated with  special Dispatcher services listening on  special ports or  interface addresses,  are features typically used for setting up such special  channels.

Unconditional address acceptance should be used with extreme care; in particular, it should never be used on a source channel that accepts unauthenticated transactions from the Internet. The problem with such usage is that spammers will attempt to send mail to invalid addresses, which will be accepted and later result in a DSN being returned. Since envelope From addresses on spam are commonly forged, this will turn the system into a major source of blowback spam and is likely to result in blacklisting and other operational issues.

These options were first added in MS 6.1.

Compare with the (new in 8.0.1.1.0)  and   channel options.

See also:
 * Notification messages
 * ldap_user_mail_status MTA Option
 * ldap_group_mail_status MTA Option
 * ldap_domain_attr_mail_status Option
 * sensitivitycompanyconfidential Option
 * eightstrict Option
 * utf8strict Option
 * rejectsmtplonglines Option
 * blocklimit Option
 * sourceblocklimit Option
 * block_limit MTA Option
 * ldap_blocklimit MTA Option
 * ldap_sourceblocklimit MTA Option
 * ldap_maximum_message_size MTA Option
 * ldap_domain_attr_blocklimit MTA Option
 * ldap_domain_attr_sourceblocklimit MTA Option
 * linelimit Option
 * line_limit MTA Option
 * alias_blocklimit Option
 * alias_linelimit Option
 * Alias file named parameters
 * missingrecipientpolicy Option
 * missing_recipient_policy MTA Option
 * AUTH_REWRITE mapping table
 * Sieve ereject and reject and refuse extensions
 * Service group
 * tcp_ports Option
 * listenaddr Option
 * accepttemporaryfailures Option
 * defertemporaryfailures Option
 * Addresses channel options
 * Channel options