Archive

Archive for March, 2007

我的126邮箱被禁用了

March 30th, 2007 Fwolf 2 comments

我有一个126邮箱,一直都在使用,不过不是用来手法正常的邮件,当然也不是发送垃圾邮件,更不是用来存放电影什么的,而是用在自己的一些程序中,比如discuz论坛,用来给注册用户发送激活邮件。毕竟现在discuz论坛的灌水机器人太多了,加上邮件激活能够有效的控制。不过,昨天从web界面登录126邮箱的时候,却发现“用户帐号处于禁用状态”。

刚开始还以为是密码错误或者是30天、60天没使用给强制休眠了,后来发现不是,而是怀疑违反了网易的邮件服务条款,强制禁用了,于是我不服,在申诉页面申诉,今天收到了回信:

尊敬的用户: 你好! 经查询,你的帐号 fwolfcn@126.com 由于发送未经许可的邮件(垃圾邮件)或广 告信,或者曾经发生滥用行为(恶意上传或共享),违反了网易邮箱服务条款,已被系 统自动禁用,不予解禁。关于邮箱禁用的问题,我们在免费邮箱页面已有公告,如方便 ,请你访问:http://mail.126.com/new/126news20060324.htm 。 网易客户服务中心:小曹 2007-03-30

显然是一封机器自动回复信,根本就不想给你解禁而已,你输入的大段申诉理由估计也没人看,但是我还没死心,想再次进行申诉,却发现:

您已于2007-03-29 23:02:49提交过本邮箱,请勿重复提交。

得,不允许重复上访,大门已经对我关闭了。可以我就想不明白了,禁用帐号的两个原因之一——发送垃圾邮件,难道就是禁用帐号就能解决的么?真想发送的话,再注册一个新的不就得了?至于另外一个原因——恶意上传,我倒还真佩服网易的程序能力,我其他的一个放了一些零碎的邮箱还是能够正常使用的,并且邮箱空间好像已经占满了 :(

还有一点更糟糕,就是我根本就不知道邮箱什么时候被禁用的,这个邮箱偶尔进去检查一下邮件而已,更多的是用来发送注册邮件,而大家都知道,不管哪个习惯机器人注册或垃圾注册的情况都非常严重,他们大多也都不使用真实邮箱注册,所以注册邮件往往会发送到无效地址,并且产生一封退信。我这个被封的126邮箱里面倒是经常堆满了这种退信,不知道这是否网易判断邮箱是否应该禁用的原则,更不知道我这种对邮箱的使用方法是否违反了网易的政策——毕竟我的程序也是可以理解为一种邮件客户端嘛。

不管怎样,126邮箱还是国内仅存不多的、好用一些的免费邮箱之一,或许我会开个新号继续使用吧,就是它的广告恼人了一些,还是尽量使用客户端,不要使用web界面的好,多那几个钻石只是唬人的噱头而已。

不知道网易的1.9亿126邮箱用户当中,有多少被禁用了,我对这个数字非常感兴趣。

Related posts

Categories: Internet Tags:

加速mutt打开文件夹的速度

March 24th, 2007 Fwolf No comments

选择mutt之前,总听别人说mutt如何如何强大,能够管理上千上万封邮件,自己使用之后,的确是强大,也能管理超量的邮件(maildir存储格式),可是每次打开有几千封邮件的文件夹的时候,都要花费时间建立索引、排序,硬盘呼哧呼哧响一阵才打开。mutt难道不会缓存文件夹的信息么?今天查询过才知道,不是不知道,而是我没有发现 :)

在muttrc中添加如下两句:

set header_cache=”~/mail/.header_cache/” set maildir_header_cache_verify=no

第一句是设置邮件头缓存文件保存的位置,我指定的是一个目录,这样每个邮件目录都会在这个目录下建立一个缓存文件,也可以直接指定一个独立的文件;第二句是禁止对已缓存内容的校验,因为除了mutt我想我应该不会再用另外一个程序去修改mail目录下的内容。

现在,再次启动mutt,所有的邮件目录浏览一遍,第二次再打开的时候,就能够很快打开了,读取每一封邮件、解析邮件header信息的过程已经被缓存了,mutt只需要对邮件进行排序就可以了。除了缓存邮件header以外,针对imap、pop这些访问可能会比较慢的邮箱,还可以对邮件本身进行缓存,不过我没有测试过。

现在,结合目录层次的搭配,我想mutt管理几万封邮件还是非常轻松的。如果邮件再多些,应该就需要在目录划分等其他措施上进行优化了。

参考: * The Mutt E-Mail Client – version 1.5.14 (2007-02-12) * Speed up folder loading in mutt * Using mutt’s header_cache feature * maildir / imap header caching for mutt * 15.1. Header caching(还介绍了缓存文件的默认命名规则)

Related posts

Categories: Tools Tags:

保护眼睛的颜色

March 22nd, 2007 Fwolf 1 comment

最近网上风传一种能夠保护眼睛的颜色,“色调设为85,饱和度设为90,亮度设为205”,把浏览器和窗口背景调成这个颜色,据说对眼睛有好处,尤其是用计算机时间比较长的人。

由于我用的是ubuntu linux和fierfox,在themes里没有找到如何修改窗口背景色和菜单颜色什么的,不过firefox倒是可以强制指定网页背景色,在选项preference的content选项卡,Fonts&Colors部分有一个colors按钮,打开就可以指定Text & Background的颜色了,不过要不勾选“Use system colors”和“Allow pages to choose their own colors, instead of my selection above”这两个选项才能生效。Background的颜色不能随意指定,只能从既有的那些颜色中选择,这个就要通过设置about:config中的browser.display.background_color这一项来完成了,默认值是#FFFFFF,修改成#CCE8CF就和上面那个颜色一样了,CCE8CF就是这个颜色的rgb数值,换算成十进制是rgb(204, 232, 207)。

通过这种方式强制指定了网页背景色之后,眼睛似乎是舒服了一些,但绝大多数网页都表现非常难看,我不知道这算不算是另外一种折磨。其实,如果能夠把窗口面板和菜单颜色调整为草绿,应该就能舒服多了,网页需要各种颜色搭配来体现出层次和各种效果,都用一个颜色替代让人很不习惯。如果把“Allow pages to choose their own colors, instead of my selection above”这个选项再选中,让设了背景色的网页显示它设置的,没设背景色的网页就用草绿,情况能好一些。

PS: 手机如果长期在外地用,想用呼叫转移的办法转到本地新手机号的方法不划算的,直接接电话是掏漫游费,呼叫转移是要掏转移费+长途费,相差应该不会很大的,颇有一种“伸头也是一刀,缩头还是一刀”的感觉,该死的漫游费啊。

Related posts

Categories: Living Tags:

注意Mutt的reply-hook会被send-hook覆盖

March 22nd, 2007 Fwolf No comments

一般经常上网的不会只有一个邮箱的,大多数人都会私人邮箱和工作邮箱一起用,我也是,不过我不愿意把他们混淆,我希望发到工作邮箱的邮件就用工作邮箱回复,其他的用私人邮箱回复。在mutt中,只要我们设置了邮件的From,procmail在发信的时候就会根据这个From来选择相应的identity,所以,只要根据邮件是发送到哪个邮箱,设置相应的From即可。

要想实现上面所说的筛选,需要用到mutt的hook,mutt有很多种类型的hook,通过他们可以实现根据当前邮件的情况和用户所要作的操作,自动进行一些设置。hook的不同主要在于他们的触发时间,比如切换目录的时候会触发folder-hook,回复邮件的时候会触发reply-hook(触发时间大约是用户按下回复命令“r“的时候),发送邮件的时候会触发send-hook等等。

首先来介绍一下我的环境,我的私人邮箱为P@gmail.com,工作邮箱为W@gmail.com,那么为了设置在大多数情况下都使用私人邮箱发信,首先在muttrc中设置:

reply-hook . “my_hdr From: Fwolf <P@gmail.com>” send-hook . “my_hdr From: Fwolf <P@gmail.com>”

这就定义了默认使用我的私人邮箱来回复和发送邮件,然后再在下面定义特殊情况下的处理。因为hook是按照定义的顺序来触发和执行的,所以如果没有特殊情况,就会使用刚才定义的设置,如果出现了特殊情况,就会执行特殊情况对应的设置,不过这并不意味这上面我们定义的默认情况下的设置就不会执行,而是默认情况下的设置的执行效果被“覆盖”了。

reply-hook “~t W@gmail” “unmy_hdr From:; my_hdr From: Fwolf <W@gmail.com>”

这样就定义了一个特殊情况——当回复邮件时,如果要回复的邮件是发送到我的工作邮箱W@gmail.com的,就把我要写的回复邮件的From设置为我的工作邮箱。在实际执行的时候就是这样一种顺序:

  1. 首先,用户按“r“回复邮件
  2. reply-hook . 被触发,From被设置为P@gmail.com
  3. reply-hook “~t W@gmail” 被触发,From被设置为W@gmail.com,覆盖了上面一条reply-hook的效果

看起来并没有问题,思路也对,设置也对,可是一执行就不对了,回复发送到工作邮箱的邮件,发信人仍然是P@gmail,难道是reply-hook的条件没有设置对么?不是,仔细分析之后,我发现刚才的执行过程中漏掉了一条:

  • send-hook . 被触发,From被设置为P@gmail.com

From被覆盖了两次,最终的结果还是P@gmail,所以看起来好像reply-hook没有正确触发似的。究其原因,mutt中是这样定义的:

  • 不管是reply-hook,还是send-hook,都是按照定义的顺序来触发的。
  • 但所有的reply-hook都将在send-hook之前被执行。

所以,我只顾着设置reply-hook的匹配和设置,却忘记了后面还有一条肯定会被执行的send-hook。要解决这个问题,可以使用unhook把已经定义了的hook关闭掉,刚才的设置调整为:

reply-hook “~t W@gmail” “unmy_hdr From:; my_hdr From: Fwolf <W@gmail.com>; unhook send-hook”

如果回复发送到工作邮箱W@gmail的邮件,不仅把From设置为W@gmail,而且还把所有的send-hook都关掉,这样就不会受前面定义的send-hook .的影响了,经测试执行正常,并且捎带脚把signature和pgp sign也给“unhook“掉了,正好。

如果在unhook之后确实还需要使用send-hook定义进一步的设置,可以直接在后面再加上send-hook ....的设置,记得命令之间用;间隔就可以了。

update @ 2007-03-24 其实上面介绍的方法并不科学(不过reply-hook和send-hook的顺序关系没有错),今天找到了更适合的方式,首先在正常的muttrc设置中要尽量不用my_hdr,而是用下面几行来代替:

alternates “P@gmail.com|W@gmail.com” #所有我可能会用到的邮箱 set from=”P@gmail.com” #默认的发信人 set use_from=yes #mutt自动生成from地址 set reply_to=yes #尽量使用原信中的reply-to,对邮件列表尤其适用 set reverse_name=yes #用哪个邮箱收的信,就用哪个邮箱回信

这样就基本实现了根据信件发送到的邮箱来自动选择回信了,如果要在发信时根据收信人来选择邮箱,可以用下面的设置:

send-hook . “unmy_hdr From:” send-hook “~t my_workmate@gmail.com” “my_hdr From: Fwolf ; set pgp_autosign=no”

这样在发信时的特殊情况下,就会选择非默认发信邮箱了,而在一般情况下,my_hdr是不存在的,mutt会选择set from设置的发信人邮箱,比较完美得解决了发信人邮箱选择问题。

在使用send-hook的时候,千万不要用发信人来作为判断条件,肯定不会匹配,reply-hook执行更在前面,更不会匹配了,所以下面的写法是错误的:

send-hook “~f W@gmail.com” “do something”

~f一样在send-hook中不工作的还有~h~B,直接报错。

最后还有一点遗留问题,私人邮箱使用数字签名,工作邮箱不用,但由于同样采用了先“默认设置”再设置“特殊情况”的方式,加上上面的send-hook和~f无法搭配,导致即使使用工作邮箱发信,默认也会进行数字签名,甚至会导致默认的发信人别名(<>之前的部分)不是我设置的名称,而是数字证书中的名称,郁闷,暂时我只好用宏macro来强制去除了:

macro compose <F9> "pc<ESC>f<HOME><DELETE><DELETE><DELETE><DELETE><DELETE><DELETE>\n"

参考:

Related posts

Categories: Internet, Tools Tags:

超级纯文本转换为HTML的工具Markdown Extra

March 21st, 2007 Fwolf 2 comments

JunChen一样,我也不喜欢所见即所得的编辑器(WYSIWYG,What you see is what you got),虽然他们能够实现大部分“文字处理”工作,但是对于像我这样以技术性blog为主的人来说,经常要贴代码或者是一些特殊的文本,离开对HTML代码的直接控制是不可能的。并且大部分WYSIWYG所生成的HTML代码可读性都比较差,所以就养成了直接写HTML代码的习惯,虽然麻烦些,但是我写的每一个字符都是按原样存储的,每个回车,每个<都不会被编辑器改变。

如果你曾经参与过WikiPedia的编写,肯定会被它简明的编辑方式所打动,[]就是链接,==就是标题等等,如果平时写文档也这么方便就好了,呵呵。开源世界的美妙就在于你的大部分需求都有人去解决,Markdown就是这样的一个工具,你按照特定的语法书写纯文本文件,它就可以将其转换为标准的html代码。虽然不一定能写出让领导满意的格式公文,用来写blog或者文档说明书还是足够而且方便的。最关键的是,即使不转换为html代码,这种标记形式的txt纯文本文件可读性也是非常好的。

Markdown官方网站上有它的基本语法,我还找到了一份jjgod翻译的中文版Wikipedia上也列出了各种语言的Markdown实现——由于Markdown只是一种对格式的定义,所以不管用哪种语言都可以写出解析这种语法的工具。

但是相对于wikipedia的语法来说,markdown的功能相对少一些,所以Markdown Extra就出现了,它不仅用php语言实现了Markdown语法的解析,而且还添加了一些额外的扩展,同样也可以方便的嵌入各种cms,比如wordpress。Markdown Extra的主要改进有:

  • 可以在行中任意地方嵌入任何HTML代码,只要行开头的缩进不超过3个空格。
  • 可以在table或者div等“块”元素中使用标记语言。
  • 可以为标题创建id,这些id可以像链接的id一样使用,方便在标题之间跳转。
  • 支持表格。
  • 支持定义列表。
  • 支持脚注,并且可以在脚注和正文之间来回跳转。
  • 支持缩写。
  • _在词中使用不再代表加重。
  • 可转义字符中增加了冒号:和管道符号|。

可以看出Markdown Extra相对于原版除了完全的兼容,还更加灵活和强大了一些。另外虽然WordPress官方不支持Markdown或者Textile标记语言Markdown Extra本身就是按照wp的插件方式设计的,安装非常简单,基本上就是三步:

  1. 下载,并把markdown拷贝到wp的wp-content/plugins/目录。
  2. 在管理页面激活Markdown插件。
  3. 在发帖时要关闭可视化编辑功能,有了Markdown,还要他们作甚。

现在,Markdown Extra就可以作用于wp的文章和留言啦。

通过简单的使用,我发现Markdown Extra发掘了txt文本的真正威力,简单、实用,无论是源文件还是生成的HTML文档,格式和可读性都非常好,尤其是在*nix这些经常要用到字符界面的操作系统中,更能体现出纯文本的优越性来。

另注几点:

使用了*[HTML]: Hyper Text Markup Language之后,调用会出现Segmentation fault错误,已经向作者反映了,不过贴到blog里好像又可以了。

作为wp的plugin使用时,对于我原来使用纯HTML编写的文章,由于包含很多代码或者输出片段,格式会乱掉,要是能定义哪篇文章用Markdown语法,哪篇文章不用就好了。我目前的办法是手工修改markdown.php文件,把第88行的:

remove_filter(‘the_content’, ‘wpautop’);

注释掉,恢复wp自己的段落划分功能,和markdown一起使用就没事了。当然在使用<div>贴代码的时候,<div></div>都要占用单独的一行才行。如果你发现还有其他文章格式乱了,请告诉我。

还发现了另外一个更强大的txt转HTML工具:texy,居然把css什么的功能也作进来了,不过好像刚刚起步,还不是很成熟,支持的应用和各种语言的实现也不多,对unicode的处理也不尽人意,暂时观望。

Related posts

Categories: Tools Tags: