I've run into the following problem when submitting a ticket with a large
binary attachment. An On Create scrip is triggered (as configured for the
queue) and sends e-mail with a copy of the attachment, but in the process
the web server times out (40 seconds is the mod_fcgid default) and the
ticket creation fails, resulting in there being no entry in table TICKETS
in the database for the ticket number mentioned in the e-mail. (Also, the
attachment is truncated in the outgoing e-mail, but this is a lesser
concern.)

That it should take so long for the scrip to complete is not the object of
this bug report (see #931769 for that). My complaint here is about the
confusion created by sending out e-mail that refers to a nonexistent ticket.

I think I would prefer for the ticket to be created and the scrip
not to complete (e-mail delivery can fail for other reasons anyway) than
the opposite. Also, if the ticket is created by the mail gateway the
gateway should consume the incoming message once the ticket is created,
even if scrips haven't been run. In the original incident the incoming
mail remained in the queue, causing a new e-mail to be sent on each
delivery attempt (they all failed for the same reason). Scrip failure
should of course be reported to the system administrator, but it seems
less useful to mailbomb either the requestor or (as in my incident) the
AdminCcs for the queue.

Control: tags -1 + moreinfo

Hi Sergio

Sorry for the long silence - as I'm no longer using RT myself, I'm
not keeping as up to date with the bug list as I should.

The change you've proposed is quite a philosophical change to how
RT handles mail and I'd want to see this discussed and ideally
merged upstream before considering in Debian. Is this still an
issue for you? If so would you consider bringing it up on
https://forum.bestpractical.com/ or their bugtracker?

Cheers
Dominic

I agree that one should avoid forking RT unnecessarily. While I still think that the current behaviour is flawed, it hasn't been an urgent concern since I've addressed the performance issue that acted as a trigger in my environment. If it were, I (as a non-paying customer with correspondingly low support expectations) would probably either come up with a fix of my own or migrate to different software.

I'd rather not be the one who brings this up in upstream's forum, though, as they require prior registration. But anyone else who feels this is worth pursuing is welcome to do so (and hopefully improve on my analysis: I didn't expend all that much thought on it).

Dear submitter,

as the package request-tracker4 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1134418

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)