[From nobody Tue May 26 11:17:16 2026
Received: (at submit) by bugs.debian.org; 10 Jul 2019 09:25:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
 (2018-09-13) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-14.2 required=4.0 tests=BAYES_00,HAS_PACKAGE,
 RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham
 autolearn_force=no version=3.4.2-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 18; hammy, 137; neutral, 57; spammy,
 3. spammytokens:0.912-+--e-mail, 0.908-+--email, 0.855-+--delivery
 hammytokens:0.000-+--H*UA:NeoMutt, 0.000-+--H*u:NeoMutt,
 0.000-+--H*UA:1.7.2, 0.000-+--H*u:1.7.2, 0.000-+--H*UA:20170113
Return-path: <Sergio.Gelato@astro.su.se>
Received: from mail-prod-route03.it.su.se ([77.238.36.174])
 by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.89) (envelope-from <Sergio.Gelato@astro.su.se>)
 id 1hl8pd-0007IK-Mq
 for submit@bugs.debian.org; Wed, 10 Jul 2019 09:25:07 +0000
Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se
 [IPv6:2001:6b0:8:2::202])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail-prod-route03.it.su.se (Postfix) with ESMTPS id 45kDK30NpWzxxP
 for <submit@bugs.debian.org>; Wed, 10 Jul 2019 11:24:07 +0200 (CEST)
Received: from smtp.su.se (mail-prod-smtp04.it.su.se [130.237.181.99])
 by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id
 x6A9O6Tr056903
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
 for <submit@bugs.debian.org>; Wed, 10 Jul 2019 11:24:06 +0200
Received: from astro.su.se (dhcp-169.astro.su.se [130.237.166.169])
 by smtp.su.se (Postfix) with ESMTPS id 45kDK231s4z2tqh
 for <submit@bugs.debian.org>; Wed, 10 Jul 2019 11:24:06 +0200 (CEST)
Date: Wed, 10 Jul 2019 11:24:05 +0200
From: Sergio Gelato <Sergio.Gelato@astro.su.se>
To: submit@bugs.debian.org
Subject: RT: On Create scrip ran but ticket not created
Message-ID: <20190710092405.dd3m3ycnbiq63auz@astro.su.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-su-se:default,
 su-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=130.237.181.99; country=SE; region=Stockholm; city=Stockholm;
 latitude=59.3333; longitude=18.0500;
 http://maps.google.com/maps?q=59.3333,18.0500&z=6
X-CanItPRO-Stream: outbound-su-se:outbound (inherits from
 outbound-su-se:default, su-se:default, base:default)
X-Canit-Stats-ID: 0a0yVo65T - 4a7b1201cba6 - 20190710
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
X-Greylist: delayed 3268 seconds by postgrey-1.36 at buxtehude;
 Wed, 10 Jul 2019 09:24:09 UTC
Delivered-To: submit@bugs.debian.org

Package: request-tracker4
Version: 4.4.1-3+deb9u3

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.
]