Subject: [ietf-smtp] CC'ing ticket systems

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jul 2020 06:55:40 -0400

Hi, have you had the experience of starting an email thread where one of the
participants is a ticket system?  As the initiator you get a ticket open,
and then each person who was in the To/CC, as they reply, get their own
ticket open.
(IANA, IETF-action, etc.)

Damn, that was not what you wanted.
What one wanted was to open a ticket and then collect the whole conversation
into it.

We have sometimes elegant and sometimes horrible hacks which try to leverage
how MUA work to collect the ticket information state into Subject lines, and
into bodies...

There are a bunch of things that I can imagine that might solve this,
ranging from the mundane to the revolutionary.
But, I wondered if others think it important to think about ticket systems
and other automated email processes.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Jul 2020 06:27:50 -0700

Hi Michael,
>(IANA, IETF-action, etc.)

Please see 
https://mailarchive.ietf.org/arch/msg/media-types/bweMuSAMwqa9LaeVz5SGBil6a5Y

>and other automated email processes.

Please see RFC 3834.  I used it to avoid email loops, e.g. a service 
responder responding to another one.

Regards,
S. Moonesamy

---

From: Tony Finch <[email-masked]>
Date: Tue, 7 Jul 2020 17:55:52 +0100

S Moonesamy <[email-masked]> wrote:
> > [...]
> Please see RFC 3834.  I used it to avoid email loops, e.g. a service responder
> responding to another one.

There's a bit more to this ticketing system problem than just the
auto-responses. (And auto-response suppression doesn't kick in if the
thread involves people CC:ing each other directly as well as a mailing
list and a ticketing system etc...)

As far as I can tell the problem is that most ticketing systems are
oblivious to threading, so they don't try to use In-Reply-To: or
References: headers to tie incoming messages to existing tickets.

There is the related problem that certain common mail software also
willfully fails to implement standard threading. So even if ticketing
systems were aware of threads they would still have to cope with other
mail software that breaks threads.

This should all have been solved in the 1990s, bah.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Northerly or
northwesterly 4 to 6. Moderate. Showers. Good, occasionally moderate.

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2020 20:49:00 -0400

>What one wanted was to open a ticket and then collect the whole conversation

While that's a reasonable idea, the fact that we've had ticketing
systems for 30 years and haven't solved it suggests that maybe it's
not worth solving.

If I were trying to solve it, I would start with a variation on the
way mailing list subject tags work, adding the tag if it's not there
but leaving the subject line alone if it is.  My impression these days is
that mail systems thread at least as much by subject as by References an
In-Reply-To

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jul 2020 15:52:33 -0400

> list and a ticketing system etc...)

Right.

So one manual approach that I've taken for over a decade is to email the
ticket system with a mostly empty message, and then reply to that with the
CC.  This works for systems that expect that, but for many systems, the
humans behind the system are confused by the "emptyish" message.
{And some ticket systems only like to expose a web interface to start a ticket}

I have sometimes initiated tickets on behalf of another party.
(for instance, my mom).  And I wish to be on the CC, but not be the
primary party.

I now have the Subject line (or other thing) initialized, and the other
participants now fill interact with the same ticket.
This is annoying, because I have to wait for an email round trip,
and I have to suspend my (brain) state for awhile.

    > mail software that breaks threads.

I am a bit surprised to hear this, because I thought that they all had
figured out threading-by-top-quoting, but I guess I am wrong.

I notice that many ticket systems now try to assume top-quoting, put their
ticket number into the body, and they ask me write above some line.
I am perplexed that there are systems that omit the Subject line with
replying, but I have experienced it. I assume some phones.

I think that many non-IT organizations should make more use of ticketing
systems. Many do, but do not expose them to the public/customers for reasons
which I think are simply a question of short-sighteness, but also because the
interaction is non-standard.

There are also multi-lingual aspects which the lack of standards makes hard,
because the locatization of the actions has to be done centrally.
(French or English first?  Both offend someone in Ottawa/Gatineau)

Some solutions that I can imagine:
1) a way to get the ticket initialized with the info in a standard place.
   I can imagine new headers for this.
   I can also imagine new SMTP verbs for this, but I expect that won't fly.

2) As you and John have suggested, a BCP that explains how to use In-Reply-To
   headers tie replies back to the same initial ticket.

3) Some kind of notification from the ticket system with a mime type that
   tells me about my ticket and how to interact with it.
   Ideally this content could be forwarded as part of the next CC.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Thu, 09 Jul 2020 17:57:15 -0400

> and then each person who was in the To/CC, as they reply, get their own

The vast majority of the time, it's the result of somebody subscribing to a
fairly active list like NANOG, and then leaving their organization, at which
point some low-lumen bulb forwards the departed's mail to the trouble ticket
system.

Hilarity and hijinks ensue.

Surprisingly enough, if the mails carry some chaining indication, such as a
'TICKET AG7342'  in the Subject: header, usually the ticketing system *does*
aggregate all the replies into one ticket - and still sends out another
notification for each addition to the ticket.  I don't know of any that use
the References: or In-Reply-To: headers to determine if a mail is related, but
that would also be a sane behavior, except the chances of a MUA breaking
the threading by nuking those headers is pretty high.  In fact, one of the
replies in this thread is lacking a References: header.

And if the ticket system is being fed multiple mails that *don't* look like
they're part of a thread (by whatever method the system uses), it's hard to
argue that starting a new ticket is always a bad idea (and sometimes it
may even be required for regulatory compliance purposes)...

So I suspect there's two orthogonal issues here, and you're looking at the
less problematic one.

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Thu, 09 Jul 2020 18:52:15 -0400

On 07 Jul 2020 20:49:00 -0400, "John Levine" said:

> but leaving the subject line alone if it is.

The problem is that many MTA's *already* screw around with the Subject: line to
jam in the listname (because apparently some people *still* can't filter based
on headers other than Subject:) or "this was from outside the organization and
might be a phish" or other nonsense...

<insert .wav of 'Dueling Banjos" here>

Two headers seen on the Educause Security list:

Subject: Re: [SECURITY] [Ext] Re: [SECURITY] [EXTERNAL] Re: [SECURITY]  [EXTERNAL] Re: [SECURITY] [External] [SECURITY] Duo/2FA exemption policies

Subject: Re: [SECURITY] [BULK]  Re: [SECURITY] [BULK]  Re: [SECURITY]  [EXTERNAL] Re: [SECURITY] [BULK]  Re: [SECURITY] Microsoft Defender ATP

At which point, if your MUA doesn't thread based on References: or
In-Reply-To:, you're totally screwed because the meaningful part of the
header is now 2 feet to the right of your screen....

I despair of being able to write an RFC on the topic that won't result
in at least a half dozen organizations Getting It Totally Wrong.