Contrib: UpdateMessageId (RT2.0.x)

The attached ScripAction will update the Attachments.MessageId field of
the parent attachment of a given mail (ie, the first one). It is designed
to operate as part of a Global Scrip:

OnIncomingEmail UpdateMessageId with template Blank

( The OnIncomingEmail condition is available from the RT2 2.0 contrib
directory )

Caution: This functionality will be replaced by code in rt-mailgate in a
later release of RT2. This is merely how I have chosen to implement
MessageId tracking on my own installation due to other factors. Your
milage may vary. May contain traces of nuts.

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.

Regards,

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

UpdateMessageId.pm (1.57 KB)

insert_action_UpdateMessageId.pl (1.48 KB)

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 :slight_smile:
FWIW, you can use a trick like

$attachment->{’_AccessibleCache’}{‘MessageId’} = { ‘read’=>1, ‘write’=>1 };

to temporarily openup the attachment’s message id for writing.

-j

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

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 :slight_smile:

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’ :wink:

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

The attached perl script will update the Attachments.MessageId field of
all attachments in an RT database which:

*) Are a parent attachment (the first one)
*) Have a Message-Id header in the 'Headers' field
*) Do not have the MessageId field set (IS NULL)

This is intended to be run on an existing RT database to flesh out
MessageId fields that previously were not set. Suggested one-off running
method is:

# While we're still getting output (ie, updating the db)
while [ "`perl CreateMessageId.pl | wc -l`" -gt "1" ] ; then
	# Sleep for 10 seconds to avoid overloading the database.
	sleep 10
done

You will need to edit CreateMessageId.pl to refer to your local RT
libraries (see the ‘!! CHANGEME’ lines)

Note that you will need to ensure that your lib/RT/Attachment.pm has been
updated in the following fashion:

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.

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

The attached perl script will update the Attachments.MessageId field of
all attachments in an RT database which:

Of course, I meant this attached perl script. My apologies for using a
non-existent coding method in the previous mail :wink:

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

CreateMessageIds.pl (7.1 KB)