@totoro625 在子域名里面已经有 v 友试了

@Damn

mailplus 是一个群晖提供的套件，准确的说是服务端和客户端都有，客户端除了网页版也提供手机 app ，支持 pop 收信，最初是想着家里翻墙，出门手机节约电不翻墙也能及时的收 gmail 。
参考介绍 https://www.synology.cn/zh-cn/dsm/feature/mailplus

日志截图就是被扫描了，随手看了两个 ip 一个美国，一个俄罗斯

我在注册网站的时候，习惯性填写邮箱为网站的二级域名，作为邮箱号来收验证和通知邮件

比如 https://tudou.com/ ，我就用 [email protected] 去注册

同时，我的域名 mx 记录里面有一段为了快速跑路指向我 mailplus stmp 服务的记录

有人买到了的社工库里有 [email protected] 的地址，以及我在 tudou 的密码，就肯定想能不能爆我邮箱嘛，都是程序扫，没特别智能，因为有做了 catch-all ，tudou 并不是我邮箱的登录账号，所以日常就能在 mailplus 里看到这样的日志

还有给网易这种操作洗地的？简直丧心病狂~

手机号不说了，成本内只有用三大运营商的

但邮箱这种东西，还是用域名邮箱靠谱，国内外厂商没个是干净的

我现在的方案是

一个 com 的域名一年也就六七十块钱，随便挂靠一个服务商，现在挂的 google apps ，前段时间说要收回，现在有没消息了。要跑的时候，直接改解析，再换一个地方挂靠，不涉及资料迁移。

邮件客户端也不用服务商的，用黑群晖的 mailplus ，送了 5 个授权，自己也就只用一个够了。

服务商只是帮我收发信，数据都在群晖上，由 mailplus 管理

mailplus 也设置好收信，防止措手不及的时候，先临时挂在群晖上，免得丢信

设置好 catch ，域名邮箱下，所有的邮件归你，每注册一个网站，就换用户名，数据泄露，也大概能猜到谁被脱裤了

比如今天的日志，tuodou 、178 ，嗯嗯，又是开心的一天

https://i.imgur.com/nCMz7Rm.png

@pendulum 又测试了一遍，确实失效了，也许你配置了多个镜像，或者直接直连了

Error response from daemon: Get "https://f1361db2.m.daocloud.io/v2/": x509: certificate has expired or is not yet valid: current time 2022-03-03T14:13:35+08:00 is after 2017-06-11T02:21:00Z

CNAME: daohub-booster-2133630403.cn-north-1.elb.amazonaws.com.cn. (ttl=4)
A: 54.222.248.173 (ttl=4)
A: 54.223.39.82 (ttl=4)

============================

Error response from daemon: Get "https://mirror.baidubce.com/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

CNAME: mirror.baidubce.n.shifen.com. (ttl=1)
A: 106.39.162.224 (ttl=1)

@InDom 好像也只有这个出路

@coolair 谢谢


@pendulum 都失效了


@privil 外网访问也是直接被转到阿里云


@jim9606 就是有需求拉最新，不想天天手动去换版本


@boringcc 不是，大学专业相关，转行了纪念一下

https://i.imgur.com/2umlPuY.png

截图给错地址了 https://i.imgur.com/wgnukxM.png

https://i.imgur.com/WyJtjIO.png

这里不是还开了个后门吗？
如果您有兴趣在未来几个月内收到有关您的非企业旧帐户更多选项的更新，请填写以下表格： https ://forms.gle/RcYKnJuSC6h7YXgcA

您将能够在 2022 年 7 月 1 日之前和帐户暂停之前评估此选项。

https://imgur.com/a/2c2VT35

深信服 AF 8.0.35 当前版本:8.0.35

@SteveWoo 感谢提供宝贵从业经验

@Joker123456789 ？？？弟弟你在说啥？ restful 和 RPC 是两个东西呀
RPC 规范并不是对 http 的，RPC 本身就是跨越了传输层和应用层的存在。
restful 是对 HTTP 中 web api 开发中的规范，http 可以理解为是最常用的承载 RPC 的通信协议之一
不管是 TCP 还是 UDP 甚至 ICMP 都可以设计 RPC ，我这样表达不知道说清楚没有

你要再用 HTTP 再去实现一次 RPC 的想法，有没有问题？
我前面已经表达了，使用了 HTTP 除非是不依赖常规浏览器，又由于环境限制必须使用 HTTP ，否则基于 HTTP 设计 web api 还是要应该遵循 restful
这不是教条 restful 本身就是实践出来的东西。你非不遵循 restful 没问题，你知道这样做是不规范的就 OK 。
明明业内有推荐规范，为什么非要自己去摸着石头过河呢？简单的举例 GET 和 PUT 在失败后是可以允许自动重试的，POST 作为大多数时候作为新增数据或者过程变更的操作可以随便发起重试？重试、限流、容错这些基本功能，你们的系统里面都没有的吗？都用 RPC 自己从头设计一遍？

------
嗯，为什么今天还来扯这个，今天甲方来电话，说是防火墙厂商表示不支持目的地 IP 放行，要么全放要么全关，请我们准备好和深信服的实施供应商现场对线~

@shyangs @Joker123456789 有点反智了哈，我认为在实际过程中，怎么做是一回事，但心里还是要知道什么规范的，什么是不太规范的，我前面说了，如果真的 http 不适合你的项目，又非得 B/S 化建议直接使用 Websocket

@patrickyoung 感谢哈，就是直接给怼回去了哈，我在前面的帖子中已经说了后续的处理了

@lesismal http 是无状态，不管什么原因，选择了这个协议，就该按这个思路来。除非是特殊原因的变相使用，把 http 当承载协议。否则设计系统通信的时候，就该按无状态设计

@0o0o0o0 我们的整个部署环境就没有 dva 这个东西

@lesismal 我们后端就是 go ，echo+gorm,后端迭代特别顺滑，现在有点趋势上的包袱反而在前端，当年历史原因这套系统选择了 angular 作为底层框架，进新人特别慢，上手 angular 确实需要两周的时间，现在国内几乎是 vue 的天下

@wqtacc 那承诺就是个笑话，在告诉懂的人，这甲方在质疑 restful 的安全性 ？？？

@iseki Websocket 这东西，一直没怎么用起来，看过有有人用 Websocket 写的 bbs 项目，各种原因也没推广开，没测过，但是有状态协议，对服务器的压力还是比无状态大的，说白了，普通的 web 应用的需求都是无状态的，任何绕开的方式，都是在对 http 造轮子

@fuxkcsdn 不觉得这是矫情，现场不就是不停的和甲方+友商小伙伴扯皮吗？都不加钱的甲方爸爸，只能算孙子~

@lesismal

认真看了#88 突然有种恍然大悟的感觉

web 其实提供了这么一套方案，叫 websocket 。只有一个方法 get ，初始化 token 通过 header 传输
然后，，，嗯，，，，[狂笑]
对比 http 那 9 种方法有诸多优势，及时性，有状态，可以发送 binaryType

@lesismal

> 抛开 RESTFul 不谈，我前面提到的三元 /三个维度的问题，其实 post delete 的方法在路由上就搞定了比如 /aaa/bbb/delete ，但是路由上做可以省去 Method 的不统一和比如这次聊到的 PUT 的问题

我们的理解可能不太相同

为什么要抛开 restful?至少我还没找到一种在 web api 设计中更优的最佳实践

你看了半天，也没找到你前面提的三元问题

至于说“省去 Method 的不统一”,其实你自己的举例中也在路由中，补入了一个 delete
难道我的
/user?ids=aaa,bbb
method delete
就没统一描述 /user 这个资源？

我在脑子里做了，想象中你的方案的落地，没找到比 restful 的优点

反而感觉像放弃了，http 协议做为应用层协议的优势，感觉上你在把 http 当 tcp 来玩

@lesismal 额，，，不会的，新项目我依然会坚持做这样的设计

考虑的点是基于这样几个考虑

1. 产品设计应该尽量统一，采用流行的模式，方便交付，以及和其他厂商同行对接，流行的规范，大多数人更容易接受，读到你是 delete 请求，自然知道这里是要删除一个什么东西，读到 post 的时候，知道这里是新增了一个什么东西，不是 and,create,built 一堆动词的滥用

2. 哪怕我改成全 POST 封装，实际还是会在 POST 的不管是 body 或者 url 中描述这个操作是 query ，还是 edit 或者 delete ，和写 header 里面的 method 头没区别，只是小聪明的重复造轮子了

3.不是每个客户都这么恼火，也有甲方，默认给关了，但是你提出需求，就直接放行了，不是每个客户都这么固执

4.这次坚持了，下一次同一个甲方再遇到这个问题，哪怕是其他同行就不存在沟通成本了

嗯，暂时想到这么多，突然想起两句话，其他地方不一定对，在这里我觉得可以参考“用户是需要被教育的”，“用户不会提前告知你什么是更好的”

我去，，，下班回来直接麻了，这破事儿居然吵热了

给各位汇报一下这个事儿的进展
最后的方案，是甲方也不想再花钱，我们写一个承诺书，我写了一句话，其他甩给商务去扩展了
------------------------------------
因为我司产品遵循 restful 设计原则导致的网络安全问题，由我方承担全部相关责任
------------------------------------
下午还有个小故事

最开始电话和网络中心主任沟通的，表示我们能说明是安全的就行，问题不大，
十分钟后又打电话来，说他问了他们专门管安全的专员，说这个就是风险！！！最后怎么变成修承诺说的就不知道商务怎么周旋的了


我前面已经说过了，这事儿其实也不是个什么事儿，

但是，我明明没有错，为什么要为别人的无知买单？要去“委曲求全”的“绕过”？

GET/POST+结构化 body ，省去了 method 设计这块的心智成本
-----------
这个看不先去了哈，那 http1.1 设计就太冗余了，按这个说法最安全的最好的浏览器发展方向，应该把包括 GET 在内的所有方法，都自动封装为一个 WANT 发送

各大厂商的开发 API 还搞什么 restful 呀，完全是莫名其妙的增加心智成本

有些想法很中肯，客户傻逼就不陪他玩，我绕过就行

但这次就是不太想绕过了，要么重新开发，要么你把 put 给放了

确实给了私钥的哈

不太认同那种因为甲方就要应承他的想法，什么都照甲方的想法改，最后出问题了还是会甩锅到自己头上。

就像十年前的项目，你不兼容 IE 就说你系统有问题，技术都顶着，技术栈全线更新全切 Chrome 了，现在客户也知道旧版 IE 不能正常显示不完全是系统的

就给了两个方案，要么双倍预算我们重做系统，要么防火墙放行