Token导航 LogoToken导航TokenDH.com
AI 工具权限需确认github未标认证来源可访问clear审计提醒

mailmanmailman 命令行

Agent Skill

mailman 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

816

周安装

34

GitHub Stars

93

下载量

272
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:mailman(mailman 命令行)
来源仓库:https://github.com/letta-ai/skills
仓库路径:skills/mailman
安装命令:
npx skills add https://github.com/letta-ai/skills --skill mailman
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/letta-ai/skills --skill mailman

简介

mailman 用于处理 GitHub 仓库和协作信息。

  • 适合围绕仓库状态、代码变更或协作事项进行整理。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。
  • 可结合来源仓库和原始 README 核验具体用法。
  • 安装前应确认权限范围、维护状态及是否触发联网或文件读写。
  • mailman 属于AI 工具类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Mailman

Overview

This skill provides guidance for configuring mailing list servers using Postfix and Mailman3. It covers the complete mail delivery pipeline including inbound mail handling, LMTP integration, subscription workflows, and outbound broadcast delivery to list subscribers.

Architecture Understanding

Before configuring, understand the bidirectional mail flow architecture:

Inbound Flow (Mail INTO Mailman)

  1. External mail arrives at Postfix
  2. Postfix routes list addresses to Mailman via LMTP
  3. Mailman processes: subscriptions, unsubscriptions, and posts

Outbound Flow (Mail OUT from Mailman)

  1. Mailman processes incoming posts
  2. Mailman generates individual messages for each subscriber
  3. Mailman sends via Postfix back to subscriber mailboxes
  4. Messages arrive in subscriber local mailboxes (e.g., /var/mail/)

Critical Insight: Both directions must work. A common failure mode is configuring only the inbound path while neglecting outbound delivery to subscribers.

Verification Strategy

Mandatory Pre-Completion Verification

Before declaring any mailing list setup complete, verify ALL three core functions:

  1. Join/Subscribe: User can join the mailing list
  2. Post/Broadcast: Messages sent to the list reach ALL subscribers
  3. Leave/Unsubscribe: User can leave the mailing list

End-to-End Testing Approach

To verify the complete mail flow:

  1. Test subscription

- Send join request to list-join@domain - Verify confirmation arrives - Complete subscription process

  1. Test broadcast delivery (most commonly missed)

- Send a message to list@domain - Check EACH subscriber's mailbox for delivery - Verify the message content is intact

  1. Test unsubscription

- Send leave request to list-leave@domain - Verify confirmation and removal

Log Analysis Checkpoints

Regularly inspect logs during configuration:

  • Postfix logs: /var/log/mail.log or journalctl -u postfix
  • Mailman logs: /var/log/mailman3/ or check mailman's configured log directory
  • LMTP connection logs for both directions

Common Configuration Points

Postfix Configuration Areas

Key files to examine and configure:

  • /etc/postfix/main.cf - Main configuration
  • /etc/postfix/master.cf - Service definitions
  • Transport maps for routing to Mailman
  • Virtual/relay domain configuration

Mailman3 Configuration Areas

Key areas to verify:

  • LMTP runner configuration (host and port)
  • MTA integration settings
  • Pipeline runners for processing posts
  • Outbound mail configuration

Integration Points to Verify

  1. LMTP Connection: Confirm Mailman's LMTP runner is listening on the configured port
  2. Transport Maps: Ensure Postfix routes list addresses correctly
  3. Domain Handling: Verify how list domains interact with mydestination and relay_domains
  4. Outbound Runner: Confirm Mailman's "out" runner sends messages back through Postfix

Common Pitfalls

Domain Configuration Conflicts

When the list domain is in Postfix's mydestination, Postfix treats ALL addresses at that domain as local. This can conflict with mailing list routing. Solutions include:

  • Using transport_maps to override for list addresses
  • Careful configuration of virtual domains
  • Verifying the routing precedence

LMTP Verification Gaps

A common mistake is assuming LMTP works for all message types because subscription requests succeed. Posts may fail separately. To verify:

  • Check that the LMTP port is actually listening
  • Test with actual post messages, not just subscription requests
  • Trace a post message through the complete pipeline

Incomplete Outbound Configuration

Mailman must send mail back to subscribers. Verify:

  • The "out" runner is active and processing
  • Mailman can connect to Postfix for sending
  • Subscriber addresses resolve correctly
  • Messages actually appear in subscriber mailboxes

Premature Success Declaration

Never declare success based on:

  • A single test passing
  • Only subscription tests working
  • Automated tests that may not cover all functionality

Always manually verify the broadcast functionality before completion.

Debugging Approach

When mail delivery fails:

  1. Trace the message path

- Where does the message enter the system? - Does it reach Mailman's LMTP? - Does Mailman process it? - Does Mailman attempt outbound delivery? - Does Postfix accept the outbound message? - Does it reach the subscriber mailbox?

  1. Check queue directories

- Postfix queue: mailq or postqueue -p - Mailman queues: Check configured queue directories

  1. Verify service status

- All Mailman runners active - Postfix accepting connections - LMTP port listening

  1. Examine logs between each step

- Do not restart services repeatedly without checking logs - Each restart should be followed by log examination

Incremental Verification Process

Configure and verify in stages:

  1. Stage 1: Basic Postfix mail delivery (local mail works)
  2. Stage 2: Mailman installation and basic configuration
  3. Stage 3: LMTP connection (Postfix to Mailman)
  4. Stage 4: Subscription flow (join/leave)
  5. Stage 5: Broadcast flow (post to all subscribers)
  6. Stage 6: Full integration test with multiple subscribers

Do not proceed to the next stage until the current stage is verified working.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

27.27%
按下载量换算74

Gemini CLI

23.62%
按下载量换算64

Antigravity

15.2%
按下载量换算41

windsurf

10.76%
按下载量换算29

OpenCode

8.1%
按下载量换算22

Codex

3.54%
按下载量换算10

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

权限需确认

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。

来源信息

继续浏览同类 Skills