[rt-devel] Contrib: UpdateMessageId (RT2.0.x)

[Bruce Campbell]

On Wed, 27 Feb 2002, Jesse Vincent wrote:

> On Wed, Feb 27, 2002 at 09:55:41PM +0100, Bruce Campbell wrote:
> > Caution: You will need to allow write access to the MessageId field in the
> > _ClassAccessible method of RT::Attachment .  You must know what you are
> > doing to take this step, or have certif{ied/able} RT technicians standing
> > by.
>
> Nice. I'm pleased that Scrips seem to be working well as an extension mechanism :)

Yup.

Next snag is avoiding too much guesswork in attempting to match RT's
(RT::Action::SendEmail) default Message-Id generation.  Now, the regex for
it is simple enough, being:

	/^rt-(\d+)-(\d+)-(\d+)\@(\S+)$/

	$1 is ticket id.
	$2 is transaction id that generated the message
	$3 random number junk to hopefully keep it unique.
	$4 should be $RT::rtname ($RT::hostname would break a seriously
	   large RT installation)

However, I think this generated message id should only be used as the
outgoing Message-Id under the following circumstance:

	The transaction that triggers an outgoing mail does not have its
	own Message-Id (ie, WebUI transactions).

In all other cases, we should preserve the original Message-Id in the
outgoing Message-Id.  This then correctly handles the instance of a reply
being sent to multiple ticketing systems or people (the person sending it
to RT sent it to multiple addresses), and gives us a better change of
picking up Message-Ids coming back.

The above can be stated more simply as 'eat your own dogfood' ;)

However, if we have a supplied Message-Id, we should still generate and
supply our own in the 'Resent-Message-Id' field due to the nature of RT -
with the exception of autoreplies, we're always resending messages, not
generating new ones. (rfc2822 3.6.6.)

Autoreplies, must also touch on them as this is the prime thing we want to
catch.  As its a new message, we do generate a new Message-Id, but we
don't store it.  Thus, we need to special-case this and see if we can
match a *valid* Ticket and Transaction id.  Its useless to us if the
implied reference is not within our database.

Finally, we also need to get around the problem of the continuance of
Scrips after we've done our magic of merging the newly created ticket into
the referenced ticket.  As we're doing this magic (with Scrips) as part of
the ticket Create, we will of course also fire any AutoReply Scrips which
are also on the Queue (or global) and thus confuse the poor requestor.
More pondering required.

Regards,

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B                      Operations