Finlay.worksBareBones Ticketing manual

Mail

BareBones Ticketing can send outbound email about ticket events. This page covers configuring the sender, choosing which events send mail, controlling how much detail those messages carry, and verifying the sender path.

Configuring mail does not guarantee delivery. Saving settings validates them locally and records that they were saved. It does not contact every provider, prove the host is reachable, or promise a message will arrive, arrive on time, or stay confidential in transit. The ticket in the product is the record to read and act on; email is a copy.

Before you start

  • You need SystemAdmin access and step-up verification.
  • Agree the delivery mode, provider, transport, sender identity, footer text, disclosure level, and which ticket events may send mail.
  • Have a Simple Mail Transfer Protocol (SMTP) host, port, and credentials.
  • Be able to read the mailbox of the sender address you configure. Verification sends its test message to that address; there is no separate test-address field.
  • Keep the application Data Protection key ring. It decrypts the stored SMTP password. If the key ring is lost, the stored password cannot be recovered and must be re-entered.

Review the current settings

  1. Open Mail Delivery.
  2. Review Posture for the provider, the ticket-update settings, verification, and inbound state.
  3. Review Mail log. Filter it with Delivery status: All outcomes, Delivered, Suppressed, or Failed.

Delivered in the mail log means the product handed the message to the provider. It is not proof the message reached an inbox or that anyone read it.

Configure the sender

  1. Open Settings, then Provider and sender settings.

  2. Choose the Delivery mode:

    • Disabled — no outbound mail.
    • Customer-managed mail policy — no outbound mail either. The setting records that your organization sends its own mail; BareBones Ticketing does not send under it.
    • BareBones guarded delivery — the only mode that sends mail.
  3. Enter the Required footer / notice.

  4. Choose the Setup profile and the SMTP Provider. Only SMTP is accepted.

  5. Set Outbound mail posture enabled.

  6. Enter the SMTP host, the port, and the Transport mode.

  7. Select Use authenticated SMTP credentials. Turn authentication off only for a relay your organization has explicitly approved.

  8. Enter the SMTP username and password. Leaving the password blank keeps the stored one; entering a value replaces it.

  9. Enter the sender display name and sender email address.

  10. Select Save mail posture once.

Choose which ticket events send email

  1. Open Ticket updates.
  2. Review Approved event categories and which are available at runtime.
  3. Select Enable ticket email updates.
  4. Select only the categories your organization has agreed to.
  5. Select Save ticket email updates once.

Enabling a category does not mean every matching event sends mail. Each message is still checked against the category, the delivery mode, whether the recipient is entitled to the ticket, whether the ticket is visible to them, whether a contact address exists, the disclosure setting, and the transport.

What a message contains

An approved message carries the minimum needed: a ticket reference, the status, enough context to recognize it, and the next action. Messages do not carry internal comments, raw audit records, routing details, attachment contents, recipient lists, SMTP traces, or secrets.

How much ticket detail a message may include is also set per service, with Ticket email detail — one of Standard email detail, Minimal email detail (only that something changed, with no names, values, attachment names, comments, or sensitive detail), or No ticket update emails (blocked for that service). This is layered on top of the installation-wide controls here: a service can only ever carry less than these rules allow, never more. See Services and the Service Catalog for the full values.

Receiving an email grants no access. A recipient who cannot open the ticket in the product still cannot open it after receiving mail about it.

This is not a general notification system. There is no paging, chat, Short Message Service (SMS), manager escalation, notify-all, arbitrary recipient list, or custom template over raw ticket data.

Customer Portal requesters do not receive a BareBones Ticketing password or a sign-in link by email. Their access comes only from the signed handoff. A ticket-update email sent to them passes the same checks as any other and never extends their session. See Customer Portal.

Verify the sender path

Verification runs only when two conditions are already true. The delivery mode must be BareBones guarded delivery, and the saved mail settings must report as ready. If either is not so, the request is refused before any message is attempted. A refusal here is not a transport failure — correct the mode or the saved settings and try again.

  1. Open Verification.
  2. Confirm the saved provider and sender address are the ones you intend to test with.
  3. Select Verify provider once.
  4. Read the recorded result: success, blocked, or failure.
  5. Open the sender address's mailbox and look for the test message.

Verification sends one test message through the configured sender path, from the sender address to itself. There is nowhere to enter a different recipient. It proves that path worked once. It does not prove any other recipient, category, mailbox rule, or future send will work.

If verification fails, correct the transport, provider, or sender setting the result names, then verify once more. Do not repeat verification in a loop.

Reply-by-email

Reply-by-email is not available in this release. The Inbound tab reports this on the Inbound reply bridge card, which carries the label Not enabled for 1.0, and any saved inbound fields are held inactive. The switch that controls it is a deployment setting rather than something an administrator can change in the product, and it is off unless the deployment turns it on. It is off in a stock installation.

Turning that deployment switch on would still not give you reply-by-email. The bridge expects an approved mail gateway to receive the message, normalize it, sign the request, and post it back to BareBones Ticketing; that gateway does not exist yet. Treat the control as a placeholder for later work, not as a feature waiting behind a flag.

There is no mailbox polling, no Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) collection, no inbound attachments, and no approve-by-email. Requesters and Agents reply in the product.

If it does not work

  • Verification fails. Read the reported cause and correct the saved host, port, transport, credentials, or sender address.
  • The stored password stops working after a restore or migration. The Data Protection key ring was not preserved. Enter an approved SMTP password again.
  • A message shows as suppressed. The recipient, category, or disclosure check refused it. Read the recorded reason. Do not widen disclosure to force a send.
  • You cannot tell whether a message was delivered. Use the ticket in the product and the mail log outcome. Do not assume an inbox state.