249121 - General outbound mail needs queueing

Status: RESOLVED DUPLICATE of bug 284184

(Bugzilla :: Email Notifications, enhancement, P1)

Description

[Erik Stambaugh]

In case the SMTP server is down, Bugzilla should be able to queue messages up
for later delivery.

For general mail, I think the solution is to have a new table with the message
contents, delivery information, original date, and last time tried.  Then have
params for how long a message may sit in an undeliverable state before it is
bounced to the administrator.

This will require a cron job to deliver tha mail.  I'm not 100% sure if it
should replace the instant mail delivery altogether.  It could be nice as an
option.  I'm open to suggestions.

There are also various ways that messages can be collected into a digest if a
user wants, but I think that should be considered beyond the scope of this bug.

Comment 1

[Dave Miller [:justdave]]

Considering the way Bugzilla stops and makes the user wait while it sends the
mail currently, I think having the queue method as the *only* method of
delivering mail would improve the UI experience a LOT (and drastically reduce
the time needed to update a bug when there's lots of users CCed on it), at least
on large installations.  We should probably make it an option to do that only.

There's quite a few things Bugzilla is beginning to do which require things to
be done periodically...  perhaps it's time we created a Bugzilla daemon process
with an initscript to handle some of these background processes.  The mail
sending from a queue is a good example of something that could use this.  And
for folks installing it in userspace, we can do like Apple's XCode does when you
tell it to set up a distcc server, and suggest a cron job for that user that
checks every few minutes to see if the daemon is running, and starts it if it isn't.

Comment 2

[Max Kanat-Alexander]

My solution to this was going to be:

1) All changes should have a "changeset_id", which includes the changes in bugs_activity and the comment in longdescs.

2) The queue is a database table that contains a list of all the people who need to be notified of that change, and the changeset_id that they need to be notified of. It also contains a comma-separated list of relationships that the user had to the bug at the time.

3) A cron job or daemon routinely pulls from that queue and sends mails.

4) A changeset table that contains the id of the changeset and the date it was sent (so that if it's null, we haven't sent that change out yet).

The problem is populating the X-Bugzilla headers correctly for that time. They could possibly be stored in the table.

----

Alternately, we could just write the raw email that we would have sent into the table. That's still several hundred template calls for a bug with lots of CCs, but that's better than waiting for sendmail.

Comment 3

[Bernhard Merkle]

for us it would be an option to specify _multiple_ email/SMTP servers.
So a simple list would to it. If MTA1 is out-of-time or down, then try MTA2 or the next in the list.

I think most companies run multiple MTAs so this would be an easy solution to implement.

Comment 4

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 5

[Teemu Mannermaa (:wicked)]

Mkanat, wasn't this implemented by bug 284184 or is there something more to be done here?

Comment 6

[Max Kanat-Alexander]

Oh yeah, it was. :-)