If a message is destined for a content_filter, must we reallycheck the transport map?
in [Postfix]
|
Prev: If a message is destined for a content_filter, must we really checkthe transport map?
Next: Don?t copy message on file Send
From: Michael Alan Dorman on 11 Mar 2010 15:12 > The transport map can reject a recipient at SMTP RCPT TO time, > by resolving the recipient to the error(8) or retry(8) transport. > > The transport map must therefore be searched BEFORE the filter. I had not considered that. Ah, well, with 2.6, multi-instance isn't such a huge burden. Mike.
From: Victor Duchovni on 11 Mar 2010 15:19 On Thu, Mar 11, 2010 at 03:12:04PM -0500, Michael Alan Dorman wrote: > > The transport map can reject a recipient at SMTP RCPT TO time, > > by resolving the recipient to the error(8) or retry(8) transport. > > > > The transport map must therefore be searched BEFORE the filter. > > I had not considered that. Ah, well, with 2.6, multi-instance isn't > such a huge burden. Indeed. I don't use content_filters very much. I just have pre-filter instances with: mydestination = local_transport = error:5.1.2 Mailbox unavailable default_transport = scan:[127.0.0.1]:someport relay_transport = $default_transport virtual_transport = $default_transport -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
From: Victor Duchovni on 11 Mar 2010 16:40
On Thu, Mar 11, 2010 at 03:31:21PM -0500, Michael Alan Dorman wrote: > > And do use "proxy:ldap:" rather than "ldap:" for virtual_alias_maps, > > and other tables that are used by smtpd and cleanup. Maintain a > > simple (indexed file) transport table that routes domains, not users. > > Fortunately, the transport map is the only thing for which we use > LDAP. Sadly, this is the one place where introducing LDAP latency and potential unavailability has the maximum negative impact. The queue-manager calls trivial rewrite when bringing mail into the active queue, this is a critical function that is not parallelizable. > Am I right in assuming that since there's only ever one trivial-rewrite > process, using proxy:ldap is just adding an extra layer to no avail, or > are there other benefits that would still suggest using it for this > purpose? Yes, using "proxy:" for transport is counter-productive. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note. |