平时都是用gmail，域名邮箱的话只是拿来玩一下，用的cloudflare的邮件转发。今天因为有特殊的需求，需要用这域名邮箱发一封email，只能自己弄一下了。
因为用的虚拟主机(webhosting)自带了邮箱功能，所以，只需要设置一下dns等就可以了。自建以及别的邮箱提供商应该也差不多。
设置MX记录什么不表了，这是基本的。
坑一：
邮件发出去后，马上收到退信。PTR记录错误。

Action: failed
Final-Recipient: rfc822;[email protected]
Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [2406:17c0:0:2::10] Gmail has detected that this message does not meet
 550-5.7.1 IPv6 sending guidelines regarding PTR records and authentication. For

这个是需要在DNS中增加一个@的txt记录，内容例子如下:
"v=spf1 a mx ip4:69.12.xx.xxx ip6:2406:xxxx:0:2:0:0:0:10 ~all" 就是指定发件的主机IP。
坑是，前后的引号(")是必须的，这用法还真够怪。
坑二：
邮件发出去了，接收了,但直接扔垃圾箱。
解决：开启 DKIM。

第一版在: https://blog.yessure.org/index.php/archives/85/
做了一点小更新，支持命令行方式查看到收到的信息以及回复信息。只是很简单的做做，而且只支持纯文本，聊胜于无。具体的用处自己想象和发挥了。

收到的信息会显示在控制台上，格式是:
(12345)张三: 你好 发消息的人uid是12345，名字是张三，内容是：你好
然后输入命令:
12345 你也好 就是向12345，也就是张三回复消息，内容是：你也好。
如果输入
0 你也好 就是向最新发来消息的那个人回复信息，内容是：你也好。
程序需要在前台一直运行，建议在screen中运行。要查看和回复信息嘛，肯定不能直接扔后台服务了。
更新后的源代码:
bot.go
telegram.go
这个机器人就到此为止了，我自己用了几个月了，需要的功能都可以了，不再更新了。

linux(x86)执行文件这次我也放出来吧，有些朋友不会编译。
下载回来把它放到一个目录，先改名成 bot.tar.gz，然后解压 tar zxf bot.tar.gz ，然后chmod+x bot，然后修改bot.yaml文件中的二处设置（在文首链接中有说明），然后 ./bot 即可。如果需要在ARM上运行，或者运行时报告GLIBC错，就麻烦自己编译吧，我环境有限。
bot.tar.gz

手里一大把vps，不过为了省力省心也是省钱，还是€1一年的虚拟主机走起。因为这样心里不会有浪费的负罪感，拿着大杀器跑一天几个几十个IP的站过份了。
做站不做刑法上的东西现在感觉真的是已经没前途了。
这个博客我全部手搓原创，半年了，访问量和收录量都是一塌糊涂。我已经绝望了，就自己写着看着玩玩，防止老年痴呆吧。

不知道从哪天开始，但1-2个月肯定有了，我访问cloudflare就很卡很卡，上套了cf的网页也是时不时的抽一下。我一直觉得是我本地的cf节点有了问题，因为我从其它地方访问都没问题，我忍！
今天晚上，我例行上blog检查一下，结果直接chrome跳出来了ERR_QUIC_PROTOCOL_ERROR的错，完全上不去。换了多台服务器去curl，都没问题，就是我本机的chrome上不去，就是这个QUIC错！突然灵光一闪，关了chrome的QUIC，瞬间就可以上了，速度飞起，再试试上cloudflare,速度也起飞了！ 好吧，我明白了，QUIC/UDP出问题了。。。 我居然忍了这么久才意识到。至于具体是宽带QOS还是我用的Clash出问题还得继续检查一下，大概率是后者。（我常年clash通过香港反向入墙）
顺便记录下二个解决这问题的操作。
一、关闭chrome的quic支持。就是自己不再用quic。

二、关闭cloudflare的QUIC支持。就是别人访问自己网站时不会用quic。

404攻击，就是不存在的文件攻击了。攻击者大量的向服务器请求不存在的每次都不相同的链接，cdn/waf将会将所有的请求回源，因为cdn并没有此请求的cache，也无法验证此请求的合法性。404攻击基本可以穿透所有的cdn，当然，也包括cf。
一个404请求无所谓，但是，如果同一时间几千几万个ip并发过来然后每秒10次8次，源服务器也就被回源崩了。(不要对cf等的rate limit有幻想，它只是限制单ip的频率。) 现在的后端系统，比如各php框架和应用，喜欢将所有请求接管，包括404，而不是使用nginx等直接处理，更上雪上加霜。
基于上面的分析，404是无法在cdn层面用普通方式拦截的，所以，必须在源服务器上进行处理，在源服务器还没有被打死前，发现404攻击，然后做出相应对策。在套用cf的前提下，就是直接启用5秒盾，识别不了，就全拦掉，总比挂了好。
下面的代码可以参考:

main.go

这个一个后台进程，它建立一个本地web服务器， http://127.0.0.1:8080/handle_404，如果应用系统接收到404时，就调用此链接。这个进程，它会判断404的频率，在例子中，10秒内超过了100次404，就会激活5秒盾5分钟。
之所以将其单独出来而不是写入应用逻辑，是为了结构和通用性方面的原因。
比如，如果nginx没有特殊设定， 那么可以在nginx的location中，将404错误重写到此链接，而在本博客的typecho中，当捕获到错误时，只需要修改/usr/themes/default/404.php即可:

$url = "http://172.17.0.1:8080/handle_404";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_exec($ch);
curl_close($ch);
?>

好了，这下基本随便404了，超了100/10就5秒盾挡一会，完事。。 当然，我设置的10秒100次其实限制很紧，稍微大些都不是问题，因为404攻击会远远超过这频率，大一点防止误报更好。