On 10/19/13 3:24 PM, Viktor Dukhovni wrote:
On Fri, Oct 18, 2013 at 10:56:59AM -0500, List wrote:
For example we have the address distgr...@domain.tld which
is an alias to 3000 local users.
What kind of "alias"? Are you using virtual(5) aliases via
virtual_alias_maps, and with backend database, the database schema
and query used as well as information about available indexes may
be pertinent?
Or are you using local aliases(5)?
I am using a virtual alias via virtual_alias_maps. The query is very
efficient and runs sub-second.
When our inbound spam filter
connects to the Postfix server to relay a message to this user we
are seeing a timeout after 60 seconds and the message gets deferred
on the filter, but the message has actually been delivered to the
alias and subsequently all the recipients.
Therefore (as Wietse points out) your timeout is at the "." command,
since earlier timeouts would not see the message delivered. The
RFC recommended minimum timeout for "." is 600s, not 60s. For
clients feeding MTAs that expand large recipient lists, I've
sometimes set timeouts of 1200s (or more as required).
Which timeout setting would need be set higher?
Is it true that Postfix is waiting to send 250 OK back to the filter
until all the recipients have had a copy of the message delivered to
their inbox?
No. Delivery happends asynchronously. However, virtual alias
expansion (which is recursive) happens synchronously during cleanup(8)
processing. Large lists can take time to expand, especially if your
database is poorly indexed.
The database query replies with a comma delimited list of aliases in
less than a second.
If so is there a more efficient way to go about
delivering to many thousands of aliases?
Index the alias database properly and use queries that can use the
index and don't force table scans. Query databases with short
network round-trip times that are not overloaded (network, disk,
CPU, ...).
Do not use aggressive timeouts, they are counter-productive.
Thanks for the detail reply, I appreciate the response.
