Improving Mailman Delivery Performance

[d-woo]

My Exim Conf Settings currently are:

queue_only

#smtp_connect_backlog = 200
#smtp_accept_max = 500

auto_thaw = 1d
ignore_bounce_errors_after = 12h
timeout_frozen_after = 2d

split_spool_directory = yes
queue_run_max = 20
remote_max_parallel = 20
smtp_connect_backlog = 50
smtp_accept_max = 100
deliver_queue_load_max = 25

Is there anything that I can do to make my delivery of email to my Mailman lists blaze out faster?

Hardware:
Dual Core Intel(R) Xeon(R) CPU 3060 @ 2.40GHz
4GB RAM
250GB Hard Drive

 

[gmagana]

I second this request. The delays are getting ridiculous. A message sent to a mailing list yesterday at 9am did not go out until 2am the following day!

This is on a server with 0.5 load, so we're not talking about the machine being so busy it could not send the message out. Acceptable delay for mailing list messages being sent is no more than one minute. People expect these message to go out immediately.

What can we do?

 

[gmagana]

Any suggestions on this? This is really becoming a problem. Everyone expects these mails to go out immediately!

 

[sparek-3]

Everyone expects these mails to go out immediately!

That is part of the problem. E-mail was not designed with a speed factor. It was designed more for reliability. With the queuing system in place for e-mail, e-mail is designed to insure that a message is always delivered (these days though this can never be guaranteed because of all of the spam filters in place).

E-mail goes to a queue, it may then be immediately sent or tried to be sent, but it first goes to a queue. The mail server then tries to connect to the recipient mail server, if it can't then the message stays in queue and waits until another queue run. In this manner, e-mail is more reliable because most mail servers are set to do several queue runs before giving up on the delivery of the message. Even then, the non-delivered message is bounced back to the original envelope-sender.

You can't confuse this system with e-mail always being instant. It is true that most e-mail that is sent these days is received instantly or near instantly. But there is nothing in the specification that says an e-mail message has to be received within a certain amount of time of sending. I think in this new age of technology everyone gets a little spoiled with the speed of e-mail and the use of instant messaging protocols.

I really would not recommend using a mailing list for a discussion list. If you want to be able to discuss topics among several different people, I would highly advise that you setup a forum on your website. Most forums are database driven (such as vBulletin used by these cPanel forums) and provide better response. That is each post is made to a central database and all the visitors retrieve these posts from the same database. This way you are not governed by the time constraint that may appear between different mail servers as mailing list messages are delivered to some users and not others.

 

[gmagana]

Yes, I am aware of there being no guarantee of delivery timeliness in the spec for email. People expect immediate delivery nonetheless. This is much compounded in this situation because it used to work. Now it does not work the same, and everyone is angry about it. They do not expect 13-18 hour delays in sending out emails.

Your suggestions of a forum is a good one, but it does not apply in most of the cases ("push" vs "pull"). Forums do not replace mailing lists.

 

[cpanelinfoseeker]

Does the delivery attempt show why the email is delayed? I have several lists on my server and the ones that do not go out quickly are domains that are having problems, usually not on my end.
One of the larger lists will send a batch and it will process out over the next 40 minutes. A smaller list has several "bad" email addresses in it and they will sit for several hours (days) until their server willl accept the email. Also if a users email box is full, this will also cause their email to remain in my servers queue, waiting for them to empty their email account so the message can be sent to them. This also has nothing to do with my sever performance, but it will keep the email in my queue until their mailbox can accept the email, or the email times out and gets returned.

I do actively check the emails in the queue and inform my customers about the email addrsses that cause a performance degradation on my end. Almost every customer has either removed the problem emails, or notified the recipient that if the email is not accepted in a timely manner, then they will be removed from the mailing list. This cooperation with my clients has kept the delivery of email lists on my server quite efficient.

Ron

 

[gmagana]

Thanks for the info... These are mailing lists with typically 10-15 addresses on it, so we're definitely not talking about sending a couple thousand emails.

I posted a support ticket on this issue this morning, and they seem to have fixed the problem by reinstalling mailman (/scripts/reinstallmailman). Preliminary testing seems good... So hopefully that did it.