PHP5+APACHE2.2配置

以下为转帖内容:

原文出处:http://hi.baidu.com/oyej/blog/item/d5b934344497d23a5bb5f5c5.html#send

 

PHP5+APACHE2.2配置成功案例:
第一、安装并配置APACHE(以我的为例,安装到E:\Program Files\Apache Software Foundation\Apache2.2)
1、安装时默认安装,Network Domain, Server Name 我填写我的计算机名,Administrator’s Email Address区域填你的邮件地址
2、安装完后在安装目录下有个conf文件夹,打开httpd.conf文件进行配置
·找到 DocumentRoot ,将其设置为你所要存放php, htm等网页文件的文件夹,如 “E:\Program Files\Apache Software Foundation\Apache2.2\htdocs”;
·找到 DirectoryIndex ,在index.html后添加index.php, index.htm等,以单个空格将其分开;
·重启Apache,用http://localhost/http://127.0.0.1/http://yourcompanyname/测试是否成功。成功的话屏幕会有个It works!
第二、安装配置PHP(解压PHP压缩包到d:\php\)
1、将php.ini-recommended文件重命名为php.ini并将其剪到系统所在目录下(如放在2000/NT的WINNT/system32, XP的Windows/system32目录下),
2、将extension_dir 改为php/ext所在目录,如 “d:\php\ext”;
3、将doc_root 改为第一步中的同样目录,如 “E:\Program Files\Apache Software Foundation\Apache2.2\htdocs”;
4、找到 ;session.save_path = “/tmp” ,将’;’去掉,设置你保存session的目录,如session.save_path = “D:/php/session_temp”;
5、然后把下面几句前面的分号去掉,以更好支持Mysql and PHPmyadmin
      extension=php_mbstring.dll
      extension=php_gd2.dll
      extension=php_mysql.dll
第三、PHP+APACHE
1、允许Apache将PHP程序作为模块来运行:
      打开httpd.conf,添加下面内容(位置任意):
      LoadModule php5_module “d:/php/php5apache2_2.dll”(特别注意这一条,很多地方是调用php5apache2.dll,这样在运行PHP代码时会提示httpd.exe应用程序错误)
      AddType application/x-httpd-php .php
      AddType application/x-httpd-php .htm
      (.htm, .php为可执行php语言的扩展名,也可加html, php3, php4,甚至txt)
(以下两步可以不需要)
2、如果你出于某种原因而需要在CGI模式中运行PHP程序(使用Php.exe),
      请将上面这一行变成注释(各行头加#即可),添加下面这些行:
      #     ScriptAlias /php/ “d:/php/”
      # AddType application/x-httpd-php .php
      #Action application/x-httpd-php “/php/php-cgi.exe”
3、现在apache 2 支持HTML而不支持PHP,先把下面几句加到d:\apache2\conf\httpd.conf去:
      # ScriptAlias /php/ “d:/php/”
      # AddType application/x-httpd-php .php
      #Action application/x-httpd-php “/php/php-cgi.exe”
   
第四、重起服务
1、在d:\PHP里找到php5ts.dll,libmysql.dll将其复制到c:\winnt\system32下(winNT/2000的机器),而winXP/2003是复制到c:\windows\system32下
2、测试Apache与php是否连接成功:
     启动start apache服务或者正在运行的就重新启动restart apache
3、在Web根目录下新建test.php(即E:\Program Files\Apache Software Foundation\Apache2.2\htdocs目下)
<html>
<head><title>test</title></head>
<body>
<?php
phpinfo();
?>
</body>
</html>

4、运行http://localhost/test.php
如果成功,则应该看到一个含有PHP徽标的网页,其中包含大量设置和其他信息
那么恭喜你

前百度员工追忆百度乱象

这是一篇百度前员工发表的博客,在这篇长文里回忆了他离开百度的原因、他眼中的百度乱象以及对百度文化的反思。全文转载,无删减。

  1、离开

  离开百度已经一年多了。

  间或有人问我为什么要离开百度。找工作的时候问,工作了几个月后还是会有人问。我怎么回答这个问题呢?说A)试用期没通过不得不卷铺盖走人?还是说B)自己工作不爽主动离职?事实上我多数情况下会选择说B。被炒鱿鱼这种事当然是不光彩的,只是有的时候懒得解释,也就随便撒个小慌,一笑而过。我会跟人家说,他娘的我也想炒掉那个操蛋老板,只是我没有那个权利,被暗算了吗?

  间或也有百度的同事打来电话,跟我抱怨说工作上如何束手束脚无法施展。两个月前,Robin一封狼性邮件,将百度推向了舆论的风口浪尖。可是通篇读下来,我只看到了两个字——“吃人”。

  2、狼性

  中国的领导似乎都有一个毛病,那就是总以为自己高高在上,神圣不可侵犯。事情做好了,功劳都是自己的,心情好了赏仨瓜俩枣给手底下辛苦干活的员工;事情搞砸了,就开始埋怨员工不好好干活,没有“奉献自己100%的热血和青春”。

  10年初Google退出中国后,百度已然躺在印钞机上数了两年的钱,其员工规模也从不到五千人膨胀到了接近两万人。不过,在电子商务、云计算和移动互联网的大潮下,这艘航母似乎还没有找到自己的航向,在通往未来的路上越走越偏……

  无可否认,在中国互联网的发展历史中,百度占有举足轻重的地位(废话一),创造了多个中国第一(废话二),即便在百度略显疲惫衰落的今天,它依然是中国互联网界当之无愧的三大巨头之一(废话三)。这里有(一些)中国顶尖的工程师,(比较)海量的数据,(比较)庞大的机器规模以及许许多多在很多公司、高校和实验室都无法找到的学习工作环境(废话四,你能指望学校的实验室搭建千台规模的集群供你把玩吗?)可是我们也异常遗憾的看到,凤巢以后:

  百度已经很久没有推出令人耳目一新的产品了(典型的如03-06年的知道、百科和贴吧)。

  百度迄今为止所有的国际化努力都是失败的。

  在电子商务、移动互联网和云计算方面,相比较其余互联网公司,百度毫无建树。

  一个手握百亿现金流,掌握中国互联网生杀大权的公司,竟然几年之内拿不出响当当的产品,Robin首先想到的是员工不够拼命,因此任何“有良好背景,流利英语,稳定的收入,信奉工作只是人生的一部分,不思进取,追求个人生活的舒适才是全部”的人,都是小资,都是要被淘汰的。可是我不明白的是,“信奉工作只是人生的一部分”,“追求个人生活的舒适”,这个有错吗?绝大多数的人死之前,想到的不是工作,而是家庭、朋友、亲情。人之所以成为人而不是一部工作机器,正是因为人生中有比工作更为重要的东西。我热爱我的家庭朋友,也享受下班归来灯下漫笔读书的时光,这个有错吗?

  没错,作为老板,你当然可以挥舞着狼牙大棒叫你的员工一边加班一边喊爽,但这种所谓狼性是由上而下的,不会长久。我认为,百度当今最大的问题在于上下异心。上层想要业绩要改变要漂亮的报表,中层欺上瞒下只看KPI,每天想着怎样弄份漂亮的报表好生存下去越爬越高,而底层技术人员确实想做一些技术上的事情,但被中层经理压制,有心无力。技术上不去,一切都是空谈,所谓的业绩报表,除了欺上瞒下,就是自欺自娱。房地产企业的土地房子可以升值,但互联网企业的代码机器却会腐朽。

  3、岁月

  即便算上实习,我在百度待的时间也只有九个月,不到一年。从最初的新鲜兴奋,到最后悲剧性的离开,这期间各种人事变动、技术思考,我几乎从未在博客上写过。今日趁着记忆尚存,偏又莫名辗转难眠,权且将自己在百度的经历,以及自己对工作的一些思考记录下来,希望对后来人有些帮助。其中陈述可能有失公允,欢迎讨论和指正。

  以下逐条列出百度之“怪现状”:

  3.1 百度论语的洗脑文化

  当代企业最爱做的事情就是给新员工洗脑,洗脑的内容也无非就那么几项,一是你现在的公司多么多么好,二是你现在的老板多么多么圣明,三是你现在的工作对公司多么多么重要(对,后勤工作对公司也很重要,搞卫生扫厕所的就更不用提了),四是即使你当前的工作不怎么重要不怎么有趣不怎么符合你的预期只要你好好工作那么多年媳妇熬成婆你总会有出头之日的。洗脑本来无可厚非,特别是在天朝这种神奇的国度里。只是百度也搞这一套,倒真是让刚刚实习入职的我大跌眼镜。我记得那个时候刚刚入职实习的时候发了一本《百度论语》,然后每周开例会的时候,一组人做一圈,每周学习一条,轮流说心得报告,总共29条,可以学习半年了。事实上这本书也不是什么不好的书,但这种学习的方式总让我想起七十年代人手一本《毛泽东语录》的场景。书中Robin被写的近乎完美神化,可是我却从来没有看到过百度内部哪里有关于失败产品(典型的比如百度Hi、有啊)的总结。

  3.2 封闭的技术开发

  中国的互联网企业都有一个毛病,那就是没有开源共享的精神,对开源社区索取大于回馈,百度也是如此。这些企业总是以为自己的技术高人一等,又不想做那些”琐碎“的基础工作,将开源的项目拿过来修修补补贴点牛皮藓后就开始到处吹牛逼说什么世界领先国内一流。比如我在的时候,百度宣称自己的Hadoop集群在规模、负载和利用率上是世界前三的。可是这又有什么用呢?第一,Hadoop不是百度开发的,百度只是打了点补丁做了些定制而已;第二,百度的Hadoop集群数量只有10+个,远远比不上Google 100+个GFS集群这样的规模,其整体的自动化运维水平也差了一个世代;第三,百度所做的所有“改进”很少回馈过开源社区。

  其实在Hadoop之前,百度也曾想过开发自己的GFS+MapReduce+BigTable,没错,百度想要开发的系统就是基于Google那三篇著名的论文的。这个系统叫做Pyramid,其领衔人是王选的高徒阳振坤博士。Pyramid大约开发了2-3年,最终以失败告终,据说最后与Hadoop PK的时候完败下来,阳振坤也在其后离职加盟淘宝。我不知道Google开发GFS+MapReduce+BigTable用了多久,但是GFS的论文是03年,MapReduce论文是04年,BigTable应该是07年,想来Google应该也是开发了4-6年左右的时间。Pyramid的失败直接导致了Hadoop在百度的崛起,不到两年,Hadoop的机器数量从无到有,很快就突破了万台的规模,并且机房也从北京开始像长三角扩展,百度也终于迈出了跨数据中心的步子,尽管这个步伐似乎比Google慢了5-8年?

  不过百度虽然自己用Hadoop用得很High,负载什么的,报表都弄得不错,集群规模也上了国内少有的3000+台,但是却很少对Hadoop社区进行开源回馈。其内部Hadoop是基于Hadoop 0.19-0.20改进的。这样做的好处就是快,一方面依赖社区拿到已有的代码基,整合测试就可上线,同时也不用管什么伦理道德奉献回馈的鸟事,但其缺点就是内部的Hadoop和官方的Hadoop会逐渐越走越远,上游的Patch和改进越到后来会越难引进合并。这样做的结果就是和社区分离,用自己一人之力对抗全球智慧,最终只能自讨苦吃。

  我记得有一次内部年会上,有位工程师跳起来问,“公司可不可以做一些开源的产品呢?很多东西本来就是从外边拿过来的。”我只记得当时台上的两位高管,其中一位女高管脸色稍变,过了一会又开始讲什么“做开源需要时间精力;好的东西才好意思开源出去,否则会丢脸”什么什么的。我想,*一个IT公司有没有勇气拥抱开源,是一个公司是否对自己的技术有足够自信的一个表现*。在这方面,百度乏陈可善,不但没有代码,连论文也很少。而淘宝在章文嵩的带领下,其开源已经做的如火如荼,算是国内IT企业中开源做的最好的一个。

  3.3 世界上最优秀的工程师?

  百度的内部邮件中不止一次的提到“世界上最优秀的工程师”这个字眼,可惜作为这封邮件的收件人,连我们自己都不相信自己是世界上最优秀的工程师。09-11年高速扩张的两年,百度的招人标准降低了很多。这也是无可奈何的事情,毕竟中国的人才储备有限,有时候即便你想花钱,也不一定能招到足够的人。

  你当然无法否认,百度内部有很多牛人,可是大凡拿得上台面的公司,那个手里没有一些牛人呢?重要的是保证整体人才的平均质量,而不是树立几个典型,然后就自吹自擂说自己的工程师是世界上最优秀的。

  3.4 KPI为王

  我在Hadoop运维组做到第4个月的时候,一手创立Hadoop运维的经理走了,空降了一位新来的经理。当然,这位经理是不懂Hadoop的,加上他又实在繁忙,所能做的就是从报表入手。比如说每周几千台机器几百条小报警有没有都处理掉,预算做的怎么样,总之都是报表性的东西。至于技术上的,监控怎么做,如何才能更好的自动化,怎样统一归约化的整合集群的各个系统,从来就不是他关心的重点。我辛苦两周做出来一个小的监控系统,可以自动的检测各个集群的一些指标参数,并且支持自定义插件,自动化的生成监测报告发送到邮箱中,他给的评价是“这算啥,T2的工程师都能做”。我当时特别火也特别委屈,心里想“T2的工程师都能做,可是为什么一直没有人做呢?站着说话不腰疼”。

  再比如我们每周都要写Hadoop集群运维周报,内容无非是去几个监控系统上鼠标copy/paste一些数据到一个模板里。其实这样的东西完全可以稍微花些人力写点程序抓点网页完成,可是一直没有人做这个事情,大家就这样一周一周的写下来。反正经理要的就是这个,谁管你怎么得来的呢。

  当一家技术公司由技术驱动变成KPI驱动的时候,也就意味着这家公司发展到了一个瓶颈期。不断有前同事跟我聊,说自己想做一些事情,但是经理不让。为什么呢?比如说一个4、5年的产品代码,由于人员的交替加上技术的封闭,必然是有很多丑陋的代码的,这个时候后来接手的人如果是个有责任心又有代码洁癖的人的话,自然就想对代码做些重构和改进。这就带来了一个问题:万一由于这种额外的改动造成产品出现事故,怪谁?经理是不想承担这样的责任的,因为百度的经理不写代码,多一事不如少一事。这样一个技术人员的积极进取心就这样被压制了。还有的经理说,”做,可以做,如果一个星期之内可以完成,就去做”。可是有多少伟大的产品是一个星期内完成的呢?GFS不是,MapReduce也不是。可是经理才不会管这些,他关心的是他的KPI,是报表。一个东西,如果短期内无法出成果,就不要做。

  所以像Puppet这样的工具是不可能出自百度之手的。即便是工程师在平时的工作之中有一些思考,但也很少能有时间形成系统化的,并且能够走出百度被业界认可的东西的。

  3.5 会议,还是会议;总结,还是总结;沟通,还是沟通

  百度的会议之多,总结之烦,沟通之杂简直是令人闻风丧胆。我在百度的时候,每周至少开3个会,每个会不少于1个小时;每天发送查看邮件不少于40封;每天花在Hi上交流的时间不少于3个小时。有人会问,这么多的沟通会议时间,还有时间干正事嘛?怎么会需要这么多时间沟通交流呢?首先是百度非常看中邮件文化,所有事无论大小都要有个邮件性的总结,学会设定邮件规则是每个百度人的第一课;其次就是百度的部门极其多,据统计整个公司大概有500多个部门和组,工种单一,想要完成一个Project需要跨越很多部门。这就导致了百度内部的沟通成本一直居高不下,会议室都要提前一周甚至两周才能订上。很多rd都是上午过来处理邮件,下午开会,然后晚饭后写代码。

  3.6 自由上班?Shit

  百度号称自由上班,但这个所谓的自由上班,每天8小时只多不少。

  3.7 部门隔离

  没错,百度虽然号称“简单可依赖”,“不唯上”,平等,无“公司政治”的企业文化,但是由于部门繁多,流程繁杂,真的想做一件事情,如果没有自上而下的推动,光预算、排期、开会就要耗掉几周甚至几个月的时间。

  另一方面,如果你去仔细观察百度的产品,你会发现百度的产品风格差异极大。无论是网页产品还是客户端产品,其UI方面从来都没有给人一种非常明朗统一的感觉,能够让人一看就知道这是百度的东西。这方面,苹果做的最好,Google次之,百度毫无章法。

  3.8 Geek在哪里?

  百度并不是一个Geek公司。Facebook是,Google是,但百度不是。大多数工程师还在用着10年前的XP系统,用着盗版的Office和SecureCRT软件登录SSH写着各种文档和代码。百度的工程师没有追求美感的习惯,这种美感包括但不限于代码风格、文档排版、产品设计等。据我所知,Google的所有代码在提交之间都会经过一系列的检查,但百度至今没有如此完善的流程。至少在我们组,代码写了一年多,才想到要重新整理,规整风格。百度内部的wiki、代码审查,项目管理系统从来也是破破烂烂,没有类似于Facebook phabricator这样的系统。

  3.9 有啊

  百度历史上有很多失败的产品,但是从来没有一个产品,如有啊这般惨烈悲壮。这样的人,这样的团队,这样的条件下这样的时间内做出了这样的牺牲和这样的业绩,但最终依然无法摆脱失败的命运。有的时候,我真的怀疑,当你怀着“我坚信让我一往无前的唯一力量就是我热爱我所做的一切”这样的信念去努力去拼搏的时候,你的老板能够看到并且认可你的付出吗?有啊的惨败,百度的高管可曾做过认真的反省?这究竟是公司战略上的问题还是员工的问题?员工犯错可以扣钱扣绩效,但如果是公司犯错呢?公司做过这样的检讨吗?

  4、无他 

  最终导致我离职(或者被炒掉)的事件是因为一次不快的沟通。那次沟通中经理对我做出了“好高骛远”的评价,并且不认可我平时业余时间KPI之外的工作成果,说我的东西“连T2的工程师都可以做”。而我当然不认可这种评价,当面顶撞了他,说“不认可这种评价”。这可能直接导致经理认为我是个刺头,无法约束,干脆开掉为好。于是在我转正前一周我接到通知让我滚蛋走人。我将此事告知了我前面三个月的导师,他表示非常震惊。HR也特别奇怪,说一个人怎么前面三个月好好的,到了快要转正的时候突然就被开掉了。

  回家之后,我跟妞说,“不以物喜,不以己悲”,《偷得浮生半年闲》。

  5、箴言

  一个人工作的价值(狭义上讲是薪水)正比于这个人的不可替代性。

  “谢谢你们曾经看轻我”。

  “即使缤纷落尽,繁华消亡,也不要被生活磨平了棱角”。

  原标题:李彦宏的“罪己诏”,原文链接

励志,冬天来了,坚持住!

2013年11月24日 21:18:03 星期日

不经不经一番彻骨寒,怎得梅花扑鼻香。
不逼自己一把,你根本不知道自己有多强
这条路很长,但它值得你走下去!!!
把悲伤的时间留给别人
趁自己还年轻,给自己一个牛逼的机会!
还在唯唯诺诺?
还在浑浑噩噩?
还在一蹶不振?
还在犹豫什么?
只要你想做,你一定可以
耐得住寂寞,才守得住繁华!
你认为这是伤痕?不!我认为这是荣耀的勋章!
文明其精神,野蛮其体魄!
相信自己!
因为摔跤,我们无所畏惧,因为信仰,我们从不后悔!!

痛苦总比遗憾好!
像傻逼样的去坚持,自会看到牛逼的结果!!
有什么不可能?
我不会放弃。

Windows 8连接VPN 691错误解决办法

最近微软发布了Windows 8 RTM版,很多朋友也安装了,我当然也不例外。

这几天就有不少朋友问我VPN连接无论怎么都说密码错误不能验证,于是,便连接VPN进行了下测试,如下:

配置好VPN,步凑不重复说了,进行连接的时候输入ID和密码。

 

连接,发现报了错误691……于是就开始查找问题

 

打开VPN连接属性发现身份验证使用可扩展的身份验证协议安全密码EAP-MSCHAP v2,原因可能就是这个。

image

 

接着,修改身份验证协议,如下图。

image

 

再次连接,通过验证。

image

email相关的几个rfc协议汇总

2013年11月18日 11:08:15 星期一
  • RFC 821 – Simple Mail Transfer Protocol 简单邮件传输协议(SMTP)
  • RFC 822 – Standard For The Format Of ARPA Internet Text Messages ARPA 互联网文本信息格式(信头格式) Obsoleted by RFC 2822
  • RFC 974 – Mail Routing And The Domain System 邮件路由和域系统(MX路由)
  • RFC 976 – UUCP Mail Interchange Format Standard UUCP邮件交换格式  
  • RFC 1123 – Requirements for Internet Hosts — Application and Support 互联网主机需求
  • RFC 1321 – The MD5 Message-Digest Algorithm
  • RFC 1344 – MIME对互联网邮件网关的意义
  • RFC 1413 – 鉴别协议(ident)
  • RFC 1652 – SMTP Service Extension for 8bit-MIMEtransport 8比特-MIME-SMTP服务扩展
  • RFC 1842 – ASCII Printable Characters-Based Chinese Character Encoding
  • RFC 1869 – SMTP Service Extensions SMTP服务扩展(ESMTP规格)
  • RFC 1870 – 信息大小通报的SMTP服务扩展
  • RFC 1891 – 发送状态通知的SMTP服务扩展
  • RFC 1892 – The Multipart/Report Content Type for the Reporting of Mail System 用于报告邮件系统管理信息的多部分/报告内容类型
  • RFC 1893 – Enhanced Mail System Status Codes 增强型邮件系统状态码。
  • RFC 1894 – An Extensible Message Format for Delivery Status Notifications 发送状态通知的可扩展信息格式
  • RFC 1939 – Post Office Protocol – Version 3 邮件协议-版本3(POP3) Updated by RFC 2449
  • RFC 1957 – Some Observations on Implementations of the Post Office Protocol (POP3)
  • RFC 1985 – 远程信息列队启动SMTP服务扩展
  • RFC 2033 – 本地邮件传输协议(LMTP)
  • RFC 2034 – smtp的增强错误码
  • RFC 2045 – MIME Part One: Format of Internet Message Bodies 多用途互联网邮件扩展(MIME)第一部分:互联网信息正文格式 Updated by RFC 2231
  • RFC 2046 – MIME Part Two: Media Types     MIME 第二部分:媒介类型
  • RFC 2047 – MIME Part Three: Message Header Extensions for Non-ASCII Text MIME 第三部分:非ASCII文本信息头扩展 Updated by RFC 2231
  • RFC 2048 – MIME 第四部分:注册过程
  • RFC 2049 – 一致性标准和示例
  • RFC 2060 – 互联网信息访问协议-版本4修订本(IMAPrev1)
  • RFC 2066 – IMAP4 ACL 扩展
  • RFC 2067 – IMAP4 配置扩展
  • RFC 2068 – IMAP4 非同步字(LITERAL+)
  • RFC 2095 – IMAP/POP简单挑战/回应认证扩展(CRAM+MD5)
  • RFC 2183 – The Content-Disposition Header Field     Updated by RFC 2231
  • RFC 2195 – IMAP/POP AUTHorize Extension for Simple Challenge/Response
  • RFC 2197 – SMTP Service Extension for Command Pipelining
  • RFC 2202 – Test Cases for HMAC-MD5 and HMAC-SHA-1
  • RFC 2111 – Content-ID and Message-ID Uniform Resource Locators     
  • RFC 2222 – Simple Authentication and Security Layer (SASL) 简单认证和安全层(SASL)
  • RFC 2231 – MIME Parameter Value and Encoded Word Extensions: Character Sets,…
  • RFC 2246 – TLS POP
  • RFC 2251 – 轻量目录访问协议(LDAP)版本3
  • RFC 2342 – IMAP4 命名空间
  • RFC 2359 – IMAP4 UIDPLUS扩展
  • RFC 2387 – The MIME Multipart/Related Content-type 
  • RFC 2449 – POP3 Extension Mechanism  POP3扩展机制
  • RFC 2476 – 信息提交代理(MSA)
  • RFC 2487 – TLS上安全SMTP的SMTP服务扩展
  • RFC 2505 – SMTP MTAs垃圾信息建议
  • RFC 2553 – 用于IPv6的基本套接口扩展
  • RFC 2554 – SMTP Service Extension for Authentication
  • RFC 2632 – S/MIME Version 3 Certificate Handling     
  • RFC 2633 – S/MIME Version 3 Message Specification 
  • RFC 2821 – Simple Mail Transfer Protocol         
  • RFC 2822 – Internet Message Format     
  • RFC 2831 – Using Digest Authentication as a SASL Mechanism
  • RFC 3462 – The MIME Multipart/Report Content-type 
  • RFC 3463 –  Enhanced Mail System Status Codes
  • RFC 4406 – Sender ID: Authenticating E-Mail
  • RFC 4408 – Sender Policy Framework (SPF) for Authorizing Use of
  • RFC 4870 – Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
  • RFC 4871 – DomainKeys Identified Mail (DKIM) Signatures    
  • RFC 5617 – DKIM Author Domain Signing Practices (ADSP)