Joachim Schrod wrote:
Sandy Drobic wrote:
Henne Vogelsang wrote:
The reason was too few postfix processes delivering mail, therefor the
delivering queue ran full (due to some bug in postfix it seems). This is
fixed now.
Usual advice is to use "relay" as transport for outgoing mail, so that
incoming smtp connections do not use up all allowed smtp connections
or vice versa.
Please allow us the opportunity to learn more about that.
This is caused by the maxproc column in master.cf, isn't it? But I have
to confess that I didn't understand it, after reading the documentation.
Sigh, I am just typing this the second time due to power outage. Well, at
least I know that my ups is cleanly shutting down all my systems.
Just keep in mind that postfix will use the default values if not
configured otherwise. The default setting for how many processes are
allowed to run simultaneously is set with $default_process_limit.
The default is: `postconf -d default_process_limit` = 100.
I looked at my master.cf, and I think the relevant lines seem to be: (I
hope that there won't be too much line breaks inserted.)
# service type private unpriv chroot wakeup maxproc command + args
smtp inet n - n - - smtpd
That's for incoming TCP connections, AFAIU.
Yes, the command row shows smtpd, the daemon that accepts connections. If
a "-" is set instead of a number, then the default is applied, in this
case 100.
smtp unix - - n - - smtp
relay unix - - n - - smtp
According to my syslog entries, smtp seems to get used for outgoing
emails. It is the default value for default_transport which is used for
all mails except to $mydestination. The default transport for incoming
email is local. The default transport for relayed email is relay.
Yes, smtp is the client program of Postfix that is used to send mails via
SMTP. local is a local delivery agent, it does not speak smtp.
I don't understand which service definition in master.cf causes the "use
up of allowed smtp connections" for incoming and outgoing emails. Would
you please do me the favor and explain that?
I was assuming a mail relay, for example a Postfix relay in front of an
exchange server. In that case incoming mail for internal domains will be
relayed to the internal exchange server via SMTP, outgoing mails will also
be sent via SMTP to their destination servers.
Another transport that normally uses the SMTP protocol is the
content_filter amavisd-new.
If not told otherwise, Postfix won't care, where the smtp clients are
sending the mails to, be it to the internal mailserver or the external
foreign destination server.
A mailinglist server is a special case. If a mailing list has a lot of
subscribers, then a few incoming mails are sufficient to generate many
thousands of outgoing emails.
So Postfix will per default use a max of 100 smtp processes. 5 emails are
submitted to the mailing list manager, 10000 emails are generated, and
Postfix is using all 100 smtp processes to send mails out. If you are
using amavisd-new to first filter the mail, that mail might have to wait
for a smtp process to be free to be delivered to amavisd-new.
Now, if you are using relay as the default transport for outgoing mails,
all 100 smtp processes are available for tranport to amavis or other purposes.
The usual reason is, that the mailgateway is using relay as transport to
send mails to the internal server and smtp for outgoing mails, so that
incoming and outgoing mails do not have to fight for a common pool of
available smtp processes to be delivered. They each have their own maxproc
setting.
As I said, a mailinglist server is a very special beast, and if you have
several busy mailing lists with lots of subscribers each, you can have a
huge incoming or active queue in a very short time. I haven't yet handled
a server that has to send a few hundred thousand mails each day (at
least). If I remember correctly Henne said that opensuse has about 1800
subscribers with probably 100-150 mails each day. So, just the opensuse
list causes about 200.000 mails to be sent each day. Pack on a few more
high-volume mailing lists, and you've got one really busy server.
Good hardware and a fast internet connection can cope with that, but it
still takes a good deal of careful configuration to deal with the spikes
of mails.
Sandy
--
List replies only please!
Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
