This is not related to what you are asking, but check to make sure that IDENT packets coming in are either allowed or rejected, NOT dropped. That can cause a consistent 5 sec delay or so. If the mail is being handed off to your own server, make sure ident is not blocked between the two.
an alternative to this would be running a mailqueue daemon (a second copy of postfix or another relay) on the mailhubs, keeping all the mailhandling off the webservers (and getting an instant accept).
so the webservers would send the message to the non-blocking queueing postfix which would then send it onto the workhorse postfix which may block the first postfix.
i'm sure this is far too complicated and there is probably an easier way to configure the postfix.
as above i'd also be tempted to say the delay is a dns reverse lookup issue or something similar. most mail daemons do accept the message to a local queue and return straight away, as mail sending to the next hop is allowed to take days in theory.
Our 40-some webservers don't have disks. I don't think running mailservers on them is the best idea.
We do, however, have a number of postfix instances with disks behind a virtual load-balanced IP, so the webserver code need only connect to one IP, and it'll get a postfix instance with disks.
if all the deliveries are to a single domain: define transport_maps. set the domain to hold:
[16:29] if the deliveries are all over the map, make smtp a defer transport.
More info here.
defer_transports (default: empty) The names of message delivery transports that should not be delivered to unless someone issues "sendmail -q" or equivalent. Specify zero or more names of mail delivery transports names that appear in the first field of master.cf).
Example:
defer_transports = smtp
I think this might mean the messages will never get delivered unless another instance of postfix reads the queue, but I'm not sure about that.
Make sure default_process_limit is high enough, the default is pretty low (50 or so, usually, though I'm not that conversant with debian defaults). Also check that you don't have in_flow_delay set to something high.
Comments 34
Reply
Reply
(The comment has been removed)
so the webservers would send the message to the non-blocking queueing postfix which would then send it onto the workhorse postfix which may block the first postfix.
i'm sure this is far too complicated and there is probably an easier way to configure the postfix.
as above i'd also be tempted to say the delay is a dns reverse lookup issue or something similar. most mail daemons do accept the message to a local queue and return straight away, as mail sending to the next hop is allowed to take days in theory.
i should be asleep.
Reply
We do, however, have a number of postfix instances with disks behind a virtual load-balanced IP, so the webserver code need only connect to one IP, and it'll get a postfix instance with disks.
Reply
define defer_transports.
if all the deliveries are to a single domain:
define transport_maps. set the domain to hold:
[16:29] if the deliveries are all over the map, make smtp a defer transport.
More info here.
defer_transports (default: empty)
The names of message delivery transports that should not be delivered to unless someone issues "sendmail -q" or equivalent. Specify zero or more names of mail delivery transports names that appear in the first field of master.cf).
Example:
defer_transports = smtp
I think this might mean the messages will never get delivered unless another instance of postfix reads the queue, but I'm not sure about that.
Reply
Reply
Reply
Leave a comment