这是困扰我许久的问题，但是一直没有时间解决，我已经无法忍受这种局面今天务必解决。

错误日志

通过podman logs -f 命令可以看到关键报错如下

[error][2025-11-27 20:26:34][0a5900036928433ebea500015475dab0][/work/utils/send/send.go:80]abcdef@gmail.com%!(EXTRA string=域名mx记录查询失败，检查邮箱是否存在！)
[debug][2025-11-27 20:26:34][/work/utils/smtp/smtp.go:415]SendMail, ,smtp.gmail.com:25 ,xfox@linuxuser.site ,linuxuser.site ,[abcdef@gmail.com] 
[info][2025-11-27 20:26:36][0a5900036928433ebea500015475dab0][/work/utils/send/send.go:135]SMTP STARTTLS on 25 Send Error. dial tcp: lookup smtp.gmail.com: i/o timeout
[info][2025-11-27 20:26:38][0a5900036928433ebea500015475dab0][/work/utils/send/send.go:142]SMTPS on 587 Send Error. dial tcp: lookup smtp.gmail.com: i/o timeout
[info][2025-11-27 20:26:40][0a5900036928433ebea500015475dab0][/work/utils/send/send.go:149]SMTPS on 465 Send Error. dial tcp: lookup smtp.gmail.com: i/o timeout
[error][2025-11-27 20:26:42][0a5900036928433ebea500015475dab0][/work/utils/send/send.go:159][0xc000290380] 邮件投递失败dial tcp: lookup smtp.gmail.com: i/o timeout
[debug][2025-11-27 20:26:42][0a5900036928433ebea500015475dab0][/work/controllers/email/send.go:210]插件执行--SendAfter
[debug][2025-11-27 20:26:42][0a5900036928433ebea500015475dab0][/work/hooks/base.go:74][wechat_push]Plugin SendAfter Start
[debug][2025-11-27 20:26:42][0a5900036928433ebea500015475dab0][/work/hooks/base.go:74][spam_block]Plugin SendAfter Start
[error][2025-11-27 20:26:42][/work/hooks/framework/framework.go:123]params error json: cannot unmarshal object into Go struct field HookDTO.ErrMap of type error
[debug][2025-11-27 20:26:42][0a5900036928433ebea500015475dab0][/work/hooks/base.go:88][wechat_push]Plugin SendAfter End
[error][2025-11-27 20:26:42][/work/hooks/framework/framework.go:123]params error json: cannot unmarshal object into Go struct field HookDTO.ErrMap of type error
[debug][2025-11-27 20:26:42][0a5900036928433ebea500015475dab0][/work/hooks/base.go:88][spam_block]Plugin SendAfter End
[debug][2025-11-27 20:26:42][0a5900036928433ebea500015475dab0][/work/controllers/email/send.go:222]插件执行--SendAfter

分析问题

显然DNS解析有问题，容器的网络似乎存在异常。
现在宿主机nslookup smtp.gmail.com确定主机网络无异常。
podman exec -it pmail /bin/ash 进入容器内再次执行ping等测试均失败确定容器网络确实有问题。

- 阅读剩余部分 -

👀我的gpg证书更新了，诸位别用旧的发信。
最新公钥地址保持原链接不变
https://xfox.fun/usr/uploads/2022/10/1276553138.asc
再过几天我会彻底吊销旧证书。
这次更新是对RSA 4096未来安全性下降做出的提前准备，新证书使用Curve25519算法，本次更新后未来较长时间不会再进行更新

新证书的信息：

这个想法自从我开始使用Pmail就有了但是一直因为各种原因没有实现。

初步预期

尽可能在不额外进行训练/微调的情况下使用RWKV（这我熟啊.webp)的小体积模型结合提示词与预设上下文对输入邮件进行处理返回一个带有概率值的JSON数值，该数值将作为入站邮件处理API的返回值传递给Pmail。
最终达到在较低算力及内存资源的边缘设备（如自组NAS）上完成对个人或小组织级别邮件服务的垃圾邮件处理。

数据结构

为了便于Pmail使用，请求格式及返回值按照：PMail/server/hooks/spam_block/的数据结构：
请求：

curl -X POST http://localhost:8501/v1/models/emotion_model:predict -d '{ 
    "instances": [
        {"token":["各位同事请注意 这里是110，请大家立刻把银行卡账号密码回复发给我！"]}
    ]
}' 

输出：

{
  "predictions": [
    [
      0.394376636,
      // 正常邮件的得分
      0.0055413493,
      // 广告邮件的得分
      0.633584619
      // 诈骗邮件的得分，这里诈骗邮件得分最高，因此最可能为诈骗邮件
    ]
  ]
}

静域信驿

静域信驿（Tranquil Inbox Ward）
静域信驿（Tranquil Inbox Ward），专为 pmail 设计的关键词增强型垃圾邮件分类服务（规则 + LLM 混合）。
扒拉邮箱的垃圾邮件测试了很久，还是决定使用关键词加权结合LLM分类完成，因为测试发现较小的模型分类效果尚可，但直接要求给出三个分类各自的期望值效果就很差，即便使用较大规模的模型也难以通过提示词达到预期效果。（也可能我提示词写太烂....sad)按照项目预期，我打算让他跑在NAS的集成显卡上而不是AI性能更显羸弱的CPU上，这就要求必须尽可能使用更小体量的模型。
目前还有很多乱七八糟的问题，需要慢慢发现并解决，当然————欢迎PR

报错如下：

root@racknerd-14a7c8:~# podman stop pmail
2025-10-19T09:53:14.285697Z: send signal to pidfd: Permission denied
Error: timed out waiting for file /run/libpod/exits/b0fc27c2e04e4655bc2a810ce522b37952f27b4706727bbca2f9faa59de150b3: internal libpod error

并且使用podman-compose down也会有相同报错，并且重启容器时会遇到残留进程占用25端口的问题。
在经过一系列尝试后DeepSeek已经开始不断推荐我直接使用Docker，但是我不想用。所以尝试使用runc作为最后一搏，还不行我就真的换Docker了，毕竟好用的工具才是好工具。

什么是RunC？

RunC是Docker捐赠给OCI作为OCI容器运行时标准的参考实现，因此我猜想使用runc比podman的默认运行方式更符合OCI标准，因而能更大程度兼容Docker镜像。
安装 runc sudo apt install runc -y

配置 Podman 使用 runc 作为默认运行时

sudo nano /etc/containers/containers.conf
在 containers.conf 中添加：

[engine]
runtime = "runc"

为了确保podman-compose一定使用了runc，可以添加runtime: runc

version: '3'
services:
  pmail:
    image: ghcr.io/jinnrry/pmail:latest
    container_name: pmail
    restart: always
    #privileged: true 特权运行不能解决当前遇到的问题，所以没必要用。
    ports:
      - "25:25"
      - "2080:80"
      - "20443:443"
      - "110:110"
      - "465:465"
      - "995:995"
      - "993:993"
    volumes:
      - "/root/podman/pmail/config:/work/config"
    runtime: runc

这时候再使用podman-compose up -d和down 应该都问题了。
但是你最好确保自己的环境是完全干净的，可以通过：
podman system reset --force && reboot 确保这点。

当你感到睡眠会打断你持续摄入使大脑兴奋的刺激时，你有权选择违背健康原则拒绝休息。
顺便，还可以点一杯奶茶，恩令你加倍愉悦。🥰
一个21世纪的人应该永远留给自己放纵的权利。————本博主

首先解决了一下证书问题，证书现在由acme.sh正确管理，并且使用了一个脚本确保证书文件被同步到pmail的配置路径。
然后刚修好就看见日志里不停歇的撞库.....难绷啊

最后，祝大家阖家团圆，中秋快乐！

2025年10月7日02点22分

把家里和RN的Debian服务器BBR都启用了（我启用之前完全没想到我之前竟然用的cubic)，算法选择： fq_codel

sudo nano /etc/sysctl.conf
net.core.default_qdisc=fq_codel
net.ipv4.tcp_congestion_control=bbr
#别忘了
sysctl -p 

如果是Fedora的桌面PC，应该更标准点修改： /etc/sysctl.d/99-sysctl.conf

这样应该可以一定程度上减少运营商对上行的恶意限制，尽可能跑满实际最大上行。
吃的好饱，嗝~

找到问题真正的元凶

早先我发了一篇文章【避雷!】别买QLC垃圾盘，下载进去就损坏！但是现在我发现问题并不像我想的那么简单，通过CrystalDiskInfo我发现INTEL SSDPEKNU512GZ : 512.1 GB 健康状态并无异常。

而且在迁移游戏文件到致钛后，昨天游玩时仍然出现了错误：逃离塔科夫进入战局前校验文件失败自动弹出了游戏并且启动器要求校验并修复损坏文件。游玩时电脑还时不时突然关机重启，有时候是软重启有时候是硬重启。
这意味着，肯定有什么别的东西坏掉了。 第一时间我就开始怀疑内存有问题，这是和频繁的蓝屏重启后的错误代码：MEMORY_MANAGEMENT 对应的。

今天早上使用MemTest64.exe 进行了内存测试，最终确定问题的确在DRAM上：
第一次测试很快结束并没有任何问题，

但是第二次测试进行时WIndows11直接崩溃重启了。
在随后的测试里，不断有黑屏等问题出现，校验出现错误非常多，下图是我在编写本文时随手再次测试的并很快手动中止的，因此显示的错误数量远不及早上长达20分钟的反复测试：

售后处理

这两根内存是在2024年七月份购买的，到现在只使用了一年。
在淘宝联系光威客服后，客服表示内存提供终身质保，售后需要发回广州。如果已经停产没有同型号的备件会调换其他同类型产品，但是可能花费更多时间。花费时间在三天到数星期不等。 因为超过了3个月运费是各付各的。
作为出门在外的打工人，只能说这太tm烦人了，因为我手头根本没有其他内存条可以临时替代，也就是说我在拆下内存发走后电脑就别想开机了。

目前已经在淘宝花了十五块随便买了一套螺丝刀，希望问题尽早解决，该死的浪费的全是我宝贵的休息时间啊。

2025年8月27日更新：这两根内存条似乎对温度比较敏感

我昨晚就运行了Windows内存测试工具跑了一晚上，结果是确实有问题。但是今天早上下班后的游戏过程中并没有发现异常，而且MemTest64的短时间测试也完全没有发现任何如同之前的error。
这些测试中唯一不同的就是我今天游戏时使用了机械革命的狂飙模式。
性能和风扇RPM成正比，且性能上办公模式<游戏模式<狂飙模式
螺丝刀已经到了，我决定继续观察，暂时不急着返厂更换内存条了。
在睡觉之前，我把MemTest64打开继续进行6个小时的测试，空调环境温度设置24摄氏度，笔记本设置游戏模式。
zZ``

昨天逃离塔克夫服务器停机更新，没玩成去打GO了。今天下班就开始重装WIndows+更新塔科夫，结果发现我下载进原机硬盘的游戏文件更新时校验不通过，浪费数个小时连续重复三次之后我完全确定这和硬盘有关系了。
那块有问题的硬盘：

产品 英特尔 SSDPEKNU512GZ (固态硬盘)
大小 512 GB
固件 002C
接口 PCIe 3.0 x4
数据传输率 4000 MB/秒
特性 S.M.A.R.T, TRIM, VolatileWriteCache
硬盘已使用 共 3923 次，累计 5115 小时

然后我把战地1从致钛7100丢了过去腾出空间，再把游戏重新下进致钛，下载完成终于是没问题，太逆天了该死的垃圾QLC盘，这下存游戏也不太合适了。

前段时间我去爬山，回来写了文章：朱雀国家森林公园痛苦一日游
上传图片的时候发现当前时代的浏览器并不支持浏览HEIF格式的图片，但是这一标准在苹果和许多较新安卓设备上都已经开始推广，并且压缩率不错，所以能不能想办法让浏览器显示HEIF格式的图片呢？

找到所需开源项目：

hoppergee/heic-to Convert HEIC/HEIF images to JPEG, PNG in browser
我的需求显然早就有人在做了，这个项目利用javascript提供了一个在前端将HEIF格式图片转换成jpeg/png的方案。

引用heic-to

工作原理：

1. 自动检测所有带有.heic或.HEIC扩展名的图片
2. 使用fetch API获取原始HEIC文件
3. 在浏览器中转换为JPEG格式
4. 替换图片的src属性显示转换后的图片

<script type="module">
// 导入CSP安全版本的HEIC转换模块 需要支持ES6特性
import { heicTo } from 'https://cdn.jsdelivr.net/npm/heic-to@1.2.1/dist/csp/heic-to.js';

document.addEventListener('DOMContentLoaded', async function() {
    // 检查浏览器是否支持所需API
    if (!window.fetch || !window.URL || !window.Blob) {
        console.warn('浏览器不支持HEIC转换所需API');
        return;
    }
    
    // 处理HEIC图片转换
    async function processHEICImages() {
        const images = document.querySelectorAll('img[src$=".heic"], img[src$=".HEIC"]');
        if (images.length === 0) return;
        
        console.log(`找到 ${images.length} 张HEIC图片，开始转换...`);
        
        for (const img of images) {
            const src = img.src;
            const originalAlt = img.alt || '';
            const originalClass = img.className;
            
            try {
                // 添加加载状态
                img.alt = 'HEIC图片转换中...';
                img.classList.add('heic-loading');
                
                // 获取HEIC文件
                const response = await fetch(src);
                if (!response.ok) throw new Error(`HTTP错误! 状态码: ${response.status}`);
                
                const blob = await response.blob();
                
                // 转换为JPEG
                const jpegBlob = await heicTo({
                    blob: blob,
                    type: "image/jpeg",
                    quality: 0.8
                });
                
                // 创建对象URL并替换
                const jpegUrl = URL.createObjectURL(jpegBlob);
                img.onload = function() {
                    URL.revokeObjectURL(jpegUrl); // 释放内存
                    img.classList.remove('heic-loading');
                    img.classList.add('heic-converted');
                };
                img.src = jpegUrl;
                img.alt = originalAlt;
                img.className = originalClass;

            } catch (err) {
                console.error('HEIC转换失败:', err);
                img.alt = originalAlt + ' [HEIC转换失败]';
                img.classList.remove('heic-loading');
                img.classList.add('heic-error');
            }
        }
    }
    
    await processHEICImages();
});
</script>

<style>
.heic-loading {
    position: relative;
    min-height: 100px;
    background: #f5f5f5 url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><circle cx="50" cy="50" r="40" stroke="%233498db" stroke-width="8" fill="none" stroke-dasharray="62.8 188.8"><animateTransform attributeName="transform" type="rotate" repeatCount="indefinite" dur="1s" values="0 50 50;360 50 50" keyTimes="0;1"></animateTransform></circle></svg>') no-repeat center;
    background-size: 50px;
}
.heic-converted {
    border: 2px solid #2ecc71;
}
.heic-error {
    border: 2px dashed #e74c3c;
}
</style>

使用方法：

你可以引用上面的代码到任意html页面，通常我们把他放在header或footer里。
在Typecho上我们可以把它放在主题文件的： header.php 中

本文代码已在Github以MIT协议开源，感谢自由软件与开源社区！
DisplayMyHEIC

测试图片