Failed mail delivery when web server is not running

Hi,

we recently needed shut our web server down for two days effectively
taking our RT 3.0.11 installation offline. But the system was still
installed and we expected it to still receive mail locally via postfix.

postfix delivers each e-mail using the rt-mailgate program.

What we didn’t know was that rt-mailgate obviously expects the web
service to be running as it contacts the RT system for permissions
and other information before delivering the message to a particular
queue. As the web server wasn’t running, the delivery failed.

This is already strange as I would have expected delivery to be
totally independent from the running web server using a local binding
to the database and do proper checking based on its contents.

But it got worse: when the connection to the mail server fails and
produces errors, this error condition is not signaled back to the MTA
(in this case: postfix). The MTA thinks the e-mail has been delivered
the message by rt-mailgate properly (which it didn’t) and erases the
message from its queues.

Result: we lost 2 days of incoming messages.

My questions:

  • did we understand how RT works here correctly?
  • if yes, is there an option for webserver-less delivery?
  • why does the rt-mailgate process not produce proper errors to postfix?

During re-installation we moved to RT 3.2 (3.4 did not install
properly due to various depency problems and other weird errors).

Does 3.2 or 3.4 address any of the above mentioned problems?

Maybe we’re wrong with our assumptions. But if we’re right, we
consider this behaviour to be really dangerous as any webserver-
downtime would potentially lose messages at any time.

Greetings
Tim

Tim Pritlove, Discordian Evangelist
mailto:tim@ccc.de http://tim.geekheim.de/ skype://timpritlove
aim:timpritlove jabber:tim@jabber.ccc.de
Project Blinkenlights http://www.blinkenlights.de/
“Sure it corrupts your files, but look how fast it is!”

PGP.sig (194 Bytes)

What we didn’t know was that rt-mailgate obviously expects the web
service to be running as it contacts the RT system for permissions
and other information before delivering the message to a particular
queue. As the web server wasn’t running, the delivery failed.

This is already strange as I would have expected delivery to be
totally independent from the running web server using a local binding
to the database and do proper checking based on its contents.

Posting to the web interface is actually an advantage since
the mail gateway doesn’t have to run on the same machine or
have the database client installed.

But it got worse: when the connection to the mail server fails and
produces errors, this error condition is not signaled back to the MTA
(in this case: postfix). The MTA thinks the e-mail has been delivered
the message by rt-mailgate properly (which it didn’t) and erases the
message from its queues.

Result: we lost 2 days of incoming messages.

My questions:

  • did we understand how RT works here correctly?
  • if yes, is there an option for webserver-less delivery?
  • why does the rt-mailgate process not produce proper errors to postfix?

A failed delivery should generate an error number 75 which
sendmail considers a temporary failure for local deliveries
and will retry. Postfix should observe the same convention.

Les Mikesell
les@futuresource.com

The mail gateway is a simple script which contacts RT’s
REST interface for communication with the back end API.
Depending on you rate of incoming tickets, you could
use the standalone web server that comes with RT and
configure it so that only the REST directory is
available.

-Todd

BTW, I don’t know why you didn’t get proper error messages
from rt-mailgate.

-Todd