Routing email into Slack, which is not the same as forwarding it

Description and use

Emails are routed into Slack with proper threading, noise suppression, and unread state preservation, improving communication flow.

Problem

Email notifications and replies arrive in a separate inbox, causing fragmented information and cluttered Slack channels when simply forwarded.

Outcome

Emails are cleanly routed into Slack with proper threading, no noise, and preserved mailbox state, improving information flow and reducing channel clutter.

Workflow

• 1. Receive email in mailbox
• 2. Router checks Message‑ID against 7‑day cache to deduplicate
• 3. Detect reply via In‑Reply‑To/References and post to corresponding Slack thread
• 4. Extract main body from multipart MIME, removing signatures and tracking pixels
• 5. Suppress auto‑replies and no‑reply senders before posting
• 6. Post formatted message to Slack channel
• 7. Preserve unread state in mailbox

Evidence

Deduplication on the RFC Message-ID. Every email carries a globally unique Message-ID header... The router keeps a seven-day lookback of what it has already posted

Source

Thread and reply detection. Because the headers say what answers what, a reply can be posted into the Slack thread of the message it answers instead of starting a new one.

Source

Body extraction rather than preview. Multipart MIME, quoted history, signature blocks and tracking pixels are all separable from the sentence somebody actually wrote.

Source