8 CFR 214.3中提到:
Failure of a school to receive SEVP notices due to inaccurate DSO e-mail addresses in SEVIS or blockages of the school's e-mail system caused by spam filters is not grounds for appeal of a denial or withdrawal.
写这个CFR的有高人啊，这么宅的角度都给堵上了。 #论为什么需要一个自己能控制的邮件系统
Failure of a school to receive SEVP notices due to inaccurate DSO e-mail addresses in SEVIS or blockages of the school's e-mail system caused by spam filters is not grounds for appeal of a denial or withdrawal.
写这个CFR的有高人啊，这么宅的角度都给堵上了。 #论为什么需要一个自己能控制的邮件系统
差点就顺手把某大唱片公司的YouTube频道给当作盗版商给举报了，还好在操作前先咨询了一下专业人士😢
花了20分钟尝试解决一个路由问题，最后发现是对RFC 3927的理解不深导致的，十五年前的设计中采用的RFC 1918编址其实才是比较正经的解法，盲目跟风采用RFC 3927地址的问题在于这些地址是链路本地（link-local）的，by definition这些地址就不应该路由所以直接在路由代码里就drop掉了，听包听了个寂寞的李先生丢开了tcpdump开始了grep，然后惊喜地发现这段代码是这么写的：
#define IN_LINKLOCAL(i) (((in_addr_t)(i) & 0xffff0000) == 0xa9fe0000)
嗯，a9fe，这个就有点巧妙了。您也别管grep找不找得到，您就说这写法是不是能把事儿给办了吧。
所以接下来的解决方案有：a）维持大致上两个站点采用星形拓扑，但将两站间共享服务放回RFC 1918内网上，b）改采网状拓扑，在几台机器之间直接拉一组N对N的网状VPN链接然后再把OSPF跑起来。
个人倾向于a，主要原因是本来这边的网络也是星形结构，最终这些端到端的VPN链接并不真的改善可靠性。转了一圈又回到了原点（只是这次搬家的副作用是内网变成/32而不是/23了，考虑到这个做法其实更方便跨机房搬家我打算以后就这么干了）Please open Telegram to view this post
VIEW IN TELEGRAM
https://www.britishmuseum.org/collection/object/W_1953-0411-71 原来「收到的铜品质不对，于是愤怒地花了几个小时刻泥板来抱怨」的文物是真的… #TIL
The British Museum
tablet | British Museum
Clay tablet; letter from Nanni to Ea-nasir complaining that the wrong grade of copper ore has been delivered after a gulf voyage and about misdirection and delay of a further delivery; slightly damaged; 23 + 25 + 3 + 2 ll.
Please open Telegram to view this post
VIEW IN TELEGRAM