linear_email:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		 Previous revision
linear_email:start [2026/09/17 14:23 UTC] – created - external edit 127.0.0.1linear_email:start [2026/09/21 12:30 UTC] (current) – external edit 127.0.0.1
Line 12: Line 12:
  
 A Linear workspace using this service is given its own dedicated email subdomain --- something like A Linear workspace using this service is given its own dedicated email subdomain --- something like
-''ln.example.com''. Every address at that subdomain belongs to the service, and mail sent to one of+''acme.ccissue.com''. Every address at that subdomain belongs to the service, and mail sent to one of
 them ends up in Linear: them ends up in Linear:
  
Line 18: Line 18:
   * Mail to an **issue address** is added to that issue as a comment.   * Mail to an **issue address** is added to that issue as a comment.
   * **Replies thread.** A reply to a message the service already knows about is added to the original issue as a comment rather than opening a second issue --- even if someone has changed the subject line mid-conversation.   * **Replies thread.** A reply to a message the service already knows about is added to the original issue as a comment rather than opening a second issue --- even if someone has changed the subject line mid-conversation.
 +  * **Closed issues are left closed.** Where a message is matched to an earlier issue by its subject alone, and that issue has since been completed or cancelled, a new issue is created instead of a comment being added to something nobody is watching.
  
 The body of the message is converted to Linear's formatting, and attachments and inline images come The body of the message is converted to Linear's formatting, and attachments and inline images come
Line 24: Line 25:
 ===== The two address forms ===== ===== The two address forms =====
  
-Using ''ln.example.com'' as the subdomain and a team whose Linear key is ''LIMS'':+Using ''acme.ccissue.com'' as the subdomain, and teams whose Linear keys are ''ABC'' and ''DEF'':
  
 ^ Address ^ What happens ^ ^ Address ^ What happens ^
-| ''LIMS@ln.example.com'' | Creates a new issue in the LIMS team, or adds a comment to an existing issue if the message is part of a conversation already tracked. | +| ''ABC@acme.ccissue.com'' | Creates a new issue in the ABC team, or adds a comment to an existing issue if the message is part of a conversation already tracked and that issue is still open. | 
-| ''LIMS-42@ln.example.com'' | Adds a comment to issue LIMS-42. |+| ''DEF@acme.ccissue.com'' | The same, for the DEF team. Each team has its own address. | 
 +| ''ABC-42@acme.ccissue.com'' | Adds a comment to issue ABC-42. |
  
 Both forms are case-insensitive, and both the //To// and //Cc// fields are checked --- so a single Both forms are case-insensitive, and both the //To// and //Cc// fields are checked --- so a single
Line 68: Line 70:
  
   * A **baseline list of domains** configured for the whole service --- normally the operating organisation's own domains.   * A **baseline list of domains** configured for the whole service --- normally the operating organisation's own domains.
-  * A per-team **"Allowed Senders" document**, kept in that team's ''_Resources'' project inside Linear.+  * A per-team **"Allowed Senders" document**, attached to that team in Linear.
  
 The second of those is the one worth knowing about: it lets a team add an outside client or vendor The second of those is the one worth knowing about: it lets a team add an outside client or vendor
Line 77: Line 79:
  
 ^ Address ^ Authentication ^ Authorisation ^ ^ Address ^ Authentication ^ Authorisation ^
-| Team address (''LIMS@...'') | Required | Required | +| Team address (''ABC@...'') | Required | Required | 
-| Issue address (''LIMS-42@...'') | Recorded, not enforced | Not applied |+| Issue address (''ABC-42@...'') | Recorded, not enforced | Not applied |
  
 Issue addresses are deliberately open. Knowing one is treated as the authorisation, because such an Issue addresses are deliberately open. Knowing one is treated as the authorisation, because such an
Line 96: Line 98:
   * Reads the workspace's teams and members, to route mail to the right team and to recognise senders.   * Reads the workspace's teams and members, to route mail to the right team and to recognise senders.
   * Reads each team's "Allowed Senders" document, where one exists.   * Reads each team's "Allowed Senders" document, where one exists.
 +  * Reads the status of an issue matched to a message by its subject, so that a completed or cancelled issue does not quietly collect new mail.
   * **May assign a new issue** to the Linear member whose email address matches the sender, so mail from a colleague arrives already assigned to them. Anything assigned this way can be reassigned normally in Linear afterwards.   * **May assign a new issue** to the Linear member whose email address matches the sender, so mail from a colleague arrives already assigned to them. Anything assigned this way can be reassigned normally in Linear afterwards.
  
-The application's name is what appears as the **author** on every issue and comment it creates, so +Everything the service produces is identifiable in the workspace, but the two kinds are labelled 
-anything it has produced is identifiable in the workspace.+differently: 
 + 
 +  * An **issue** it creates is authored by the application, so its name is what appears. 
 +  * A **comment** it posts is attributed to the person whose message it came from, shown as //their name and address// followed by //via// the application's name. Linear does not treat that person as the comment's account holder --- it is a label, and they need no Linear account for it. 
 + 
 +A comment is only attributed this way when the sender was authenticated. On an issue address, where 
 +authentication is recorded but not required, a message the service could not verify is attributed 
 +to the application instead --- so a name on a comment is one the service proved, never one the 
 +message merely claimed.
  
 You can see and revoke it under **Settings → API → OAuth applications** in Linear. Revoking it stops You can see and revoke it under **Settings → API → OAuth applications** in Linear. Revoking it stops
  • linear_email/start.1789654999.txt.gz
  • Last modified: 2026/09/17 14:23 UTC
  • by 127.0.0.1