Purpose
The Mission of Triage Team is:
to transfer support issues to places where support can be given
some amplification:
- by definition, support is not given in/at/from support@ within the Triage Team
the task is one of selection by applying human judgement
the Triage team selects then moves the support issue to where it can get best attention
This page documents the various incoming acts and resultant outgoing acts. It is intended to be the triage team's primary resource, the starting point.
The general concept of triage is defined on wikipedia. Triage Team is part of the overall Support Team.
The Picture
The task is to look at each email coming into support@ and to pick one of several places to send it. These places are called channels or buckets. Together, these are shown as Triage Queues in the system. The below is a summary (not exact):
/----> SE ... support engineers ("fix" cacert-se)
/
/
| /--> help ... help team (mail list cacert-support)
| /
| /
triage team ------> disputes ... case managers --> arbitrators
|\
| \
| \---> meta ... stuff related to support, but not
\
\
\----> buckets ... visible/searchable by SEs
The Channels
Triage is about selecting the right place. There are several channels available to you.
High-level Channel
short
location
notes
SE
Support Engineers
creating...
Help Team
help
cacert-support
forward mail to Open Help Forum
Disputes
disputes
Disputes
meta-discussion
meta
cacert-se@
email list where you can ask serious questions (for now, might get redirected)
meta-discussion
meta
IRC chat room open for casual questions and help from SEs
Organisation Assurance
OA
Organisation Assurance
(is this one active?)
A channel is a place where there are CAcert people ready and waiting to receive your forwards. Channels are generally served by the issue tracking system. In these pages we talk about channels at the conceptual level; it is a separate subject how they are served in reality (you have to figure that out).
Channels are also to be defined at a high-level in the SecurityManual.
The Buckets
There are also several places for low level and bulk stuff, seen above as buckets. These should be visible to SEs for analysis, but there isn't necessarily anyone looking at them. Mails are stored in buckets until they are needed.
Low-level Buckets
short
OTRS
method
notes
delivery reports
bounce
returns
?
should in future feed back into email probing
junkbox
junk
Junk
Manual.
these are saved for searching for lost emails
password checks
passwd
Requested Passphrase
?
we need patches here
email ping abuse reports
abuse
Verification Abuse
Filter
may be an automatic dispute?
Paypal notifications
paypal
Paypal
these are sent automatically to Support for verification of password request fees
Deleted Accounts
Deleted
Deleted Accounts
??
??
"The Bat"
Bat
???
???
mails sent in error by old mail client "The Bat"
Sieve Filters
Buckets are sometimes automated and sometimes not. Server-side Sieve filters are set up, thanks to Neo.
Iang: Neo, are the server-side Sieve filters still set up and/or relevant with OTRS?
option 1 - is in the webmail -preferences - filters has a gui interface.
I think thunderbird has a manage sieve client - community.cacert.org:2000 same username/password - sieve is probably a thunderbird extension it appears after a quick look see CommunityEmail.
The classes of Incoming Mail
- automated responses:
- mail rejections (delivery failure notices) caused by
- ping checks of email and domain ownership
- cert expiry reminders
- ad hoc scripts
note that these mail rejections may be evidence that domains or emails are dead => revocation
or they may be short term problems.
currently no designated SE action
forward to Returns bucket
- automated benign responses caused by
- ticketing systems e.g., that the email has been received and turned into a ticket
- vacation warnings
forward to Returns bucket
- cacert internal operations
- redirections or cc's
- root, paypal
forward to Support Engineers channel
- system reports
password change attempt attempts are currently collecting in "RequestedPassphrase" folder.
forward to SE channel ???
no, there are too many to forward.
These need a channel of their own / or be visible via some interface to SEs. Patch?
where to send the rest?
IANA abuse pings because of bug 792
- mail rejections (delivery failure notices) caused by
- spam
read it
once declared as spam, transfer to Junk bucket
- Abuse Reports
- These are an option generated by people who receive "domain dispute" mails
- The Abuse reports include too little info, we need more info.
abuse of ping reports from people are currently collecting in Verification Abuse bucket.
They should be forwarded to the Support Engineers channel in the future, but we need some info => Patch.
- arbitrator's requests
- for action
- for assistance
should include a tracking token, which is the arbitration number like a20091225.1
forward to Support Engineers channel
- discussion
- meta-discussion (about support but not a support request)
- these shouldn't happen on the support@ entry point, but are destined to happen for a while
forward to meta channel
- cryptographic mail, includes
- signed, S/MIME, PGP
- encrypted (S/MIME, PGP)
- readable (decryptable)
- unreadable (undecryptable)
if unreadable because encrypted, forward to Support Engineers channel
- non-understandable
- wrong language
- unclear use of words
- garbled in transmission
- automatic gibberish
forward to Support Engineers channel
- request for Organisation Assurance, or information about
forward to Organisation Assurance channel
- request for feature enablement or service
- code-signing
- IDN International Domain Name?
- location database (find an assurer)
forward to Support Engineers channel
- disputes requests
- account deletion
- information changes (change to names, points)
- requests for information (privacy / protection requests)
forward to Disputes channel
refer to Guidelines
- help
- help requested in a process, from a human
- read the email carefully and decide
follow the guidelines at Open Help Forum
forward to the help channel located at cacert-support queue
- Paypal payments notifications
password request payments received
- normally for $15.00 USD, other amounts and currencies are probably donations.
marked: "Description:CAcert Password Reset Service" which you have to search for in the body of the mail and confirm by eyesight
forward to Support Engineer channel
paper CATS certificate purchase -> ignore
- Discussions with Education Forum indicate they are not being checked, therefore no forwarding.
marked as: "Description:Assurer Paper Certificate Donation" and are for EUR 5.00
the rest are probably Donations to CAcert -> ignore
Donations are marked: "Description:Donation to CAcert " which is deep in the body of the mail.
- May also be marked as Donation in the Subject line, but this is not confirmed.
anthing else: forward to Support Engineers channel
- payments come in by two sources: by paypal, by au account (but no notifications seen from AU account)
- bugs, patches, code, security breaches
- bugs seen in the code
- patches offered by outsiders
- claims of security breaches
forward to Support Engineers channel
- "The Bat!"
Triage signal: If the email is Russian and has a header indicating an email client called "The Bat!".
- The bucket is the folder of that name. The sieve filter classifies from the header and transfers it there.
- an automated response should be sent out to the user:
- in English and Russian
- suggesting they upgrade their client
- suggesting they use the online form for their support requirements.
- See more below.
- Apple keyChain tool requests.
probably comes from user_name@mac.com
- Has this text in it:
User Name has sent you a certificate request. Click the enclosure to complete the request. A certificate signing request (CSR) is information generated by the computer to identify the user requesting a certificate from a Certificate Authority. The CSR contains the public key of the user and is used to generate the certificate. The certificate will automatically be sent to User Name.
- Philipp writes:
This is an automatically generated email by Apple's keyChain tool. When the user tells it's email client that he wants a certificate from CAcert, the tool automatically generates a CSR, sends that to support@co, and hopes that CAcert will issue a certificate for the email address and send the certificate to the email address. (The idea isn't that bad, since that way, the email address would be verified automatically) But we haven't implement such an automatic certificate issuing mechanism at CAcert yet, so the only thing you can do is to reply to the user to please use our web-interface instead. Yes, in those cases it's natural that there is no account for that user yet. I would be surprised if you could find a related account. I would suggest that you start the discussion on the policy mailinglist, whether we should offer that additional service to Mac (and potentially to Linux and Outlook) users.
forward to Support Engineer channel
- so the SE can tell the user about alternatives.
Guidelines
- The first line of any forward should include any additional info that might be useful:
your name!
- any explanations you can think of.
- Strip away irrelevant stuff if it makes sense
- although headers and attachments can sometimes be important, they often clutter it up, and sometimes hide the real message.
- be careful!
- if it relates to a known dispute, put the dispute number into the forward.
- remove all the Re: RE: Fwd: cruft...
- Disputes is a big field. Refer to these documents:
Guidelines for Support and Arbitration
Further reading: CM and Security Policy (DRAFT) and SecurityManual.
- "The Bat!"
A particular mail client called "The Bat!" sends every mails meant for any "support@" to "support@cacert.org". It's a bug.
- The bug: that the address book also includes root certs in its searches, and this includes our support email address.
- This mail is not spam, but is wrongly directed (confusion in address book picks up root certificate email address, not user's intended email).
- If sending email manually, the Support email address should not be used. Instead, you should use your cacert address and CC to the appropriate place for tracking/ticketing.
Motive: using support@ causes meta-threads in the support email box which clutters it, making triage harder.
- note that direct forwards to the maillists (older channels) will work because support@ is subscribed to them.
- Using your own email address provides more information to the receiver.
To Join Triage
Contact the T/L who will start you on the track.
- You need to be an Assurer. This is because some of the things that you do will be relied upon by others; it's a responsibility.
CARS or CAcert Assurer Reliable Statement.
- To be part of Triage, you acknowledge / agree to Security Policy, as a dominating document. You don't need to know it, but you do need to respect it.
- Read and understand this page of notes.
- You should be good at handling email clients and IMAP boxes.
- Make sure your IRC access is good.
- Get your certs into your MUA / mail client and browser.
a CAcert CommunityEmail address is useful because email is protected point to point.
- or you must send all the work in Encrypted form (latter probably not working yet).
(OLD) Mailbox Setup
This is no longer part of Triage, however SEs may need to get access:
- details:
- username is support
- IMAP only.
- password you have to get from t/l.
See CommunityEmail for most of the details
- a separate sending-STMP-out service needs to configured in your MUA client. This is because the smtp server rejects your existing one as using your individual user name, not 'support'.
- in Tbird, it is Tools/Accounts/ "Outgoing Server (SMTP)" in the list of accounts at left; Add.
username is 'support'; see rest of details at CommunityEmail.
- Turn OFF downloading of mail before you connect.
- The mailbox is already big enough that it will take hours for your client to download and index it locally.
- Also, for security reasons, we don't want all this stuff cached on your machine.
Historical
The Famous Mailbox
mnemoc writes:
- stared mails are "pending"
- red means GM was handling it
- green was "being dealt with my mnemoc"
- starred but unread means "postponed"
"old team"
The "old team" had decided to move to trash when deleting, and not really deleting, and also to BCC:support@ to keep threads consistent.