解析带分隔标记的结构化文件构建mailx命令，规避注入风险与参数解析错乱问题

核心业务场景 #

• 负责生成邮件数据的服务器不具备直接对外发信能力，需将全量邮件数据存入结构化存储文件，由独立的发信服务器解析后重构mailx命令完成发信
• 全流程解析发信任务由systemd定时器与配套服务驱动，每分钟扫描待处理文件，完成解析、校验、发信闭环

方案迭代过程 #

初期方案的安全缺陷 #

最初设计直接将完整可执行命令写入存储文件，在目标服务器直接执行。该方式存在极高安全风险：存储文件若在传输、存储环节被拦截篡改，会被植入恶意代码，并以当前发信服务的root权限运行，造成服务器权限失守。

隔离式存储格式设计 #

为规避上述风险，项目设计了带专属首尾标记的结构化存储格式，将邮件全量数据分块隔离存储，杜绝直接执行外部传入命令的风险：

• 分块存储的内容包括：邮件正文、邮件主题、附件路径、mailx -S 自定义配置项、收件人列表
• 配套解析脚本通过awk提取各标记块内的有效内容，按分支逻辑手动组装mailx发信命令

命令组装环节的故障问题 #

初版解析脚本在手动拼接-S配置参数时，因引号处理逻辑不完善，触发shell默认的单词拆分机制异常：

• 字符串拆分后，-S标识、对应的配置项值被误识别为独立参数，最终被归类到收件人列表
• 直接引发邮件头字段错乱、邮件被错误投递到非预期地址的故障
• 过程中尝试过多种引号嵌套转义方案，始终无法适配不同长度、不同特殊字符的配置值，故障复现概率极高

最终修复方案 #

通过调整参数组装逻辑，从机制上解决了引号处理的长期痛点：

• 放弃拼接单条字符串组装命令的思路，改用bash数组逐元素存储每个独立的命令参数
• 引用数组时为整个数组加双引号，保证shell可以正确识别每个参数的边界，从根源上避免单词拆分、参数错位的问题
• 落地后彻底理清了shell多参数传递的核心逻辑：只要将独立参数以数组形式逐元素存储，引用时整体加双引号，即可保证每个参数被完整、独立传递，无需针对特殊字符做复杂的引号嵌套转义

内容的提问来源于stack exchange，提问作者user4019417