{讨论}关于“收信回执”的理解和思考
Shellex Well
在一些Email客户端(包括Outlook这样的桌面客户端和126这样的Web客户端)中，有一个功能叫"收信回执"，被称为Read
Receipt的。应当属于Delivery Status Notifications(DSNs)中的一种。
但是这个Read Receipt有其特殊性。一般的DSNs，包括每个人都收到过的Email Non Delivery
Receipts，都是邮件系统发出的，对于发送成功至目标邮件服务器的邮件，目标服务器会给一个DSNs，来通报发送服务器接受成功，这个姑且称为“服务器收信回执”。
而对于Read Receipt，从分层的思想来看，作用于人类一层，也就是Email系统的直接使用者，称为“收件人收信回执”。服务器接收成功不意味着收信人已经阅读过了邮件。而Read
Receipt就提供了一个（可选的）方案来使发送者确保邮件得到了阅读。
投递Email的最终目的应当是目标完成了对Email的阅读。那么为什么在SMTP这样的协议标准中没有明确定义要求实现它呢？尽管
Depending on the recipient's mail client and settings, they may be
forced to click a notification button before they can move on with
their work. Even though it is an opt-in process, therefore, a
recipient may consider it inconvenient, discourteous, or invasive.
(from http://en.wikipedia.org/wiki/Read_receipt, 我本人同意“不方便”的看法)
但我想这个问题，可以被一个设计良好的用户交互过程解决(比如，打开邮件时默认发送回执，当然了，这样就剥夺了用户拒绝回执的权力，但是我不知道出于什么普遍原因需要拒绝回执的)。
我不知道Email的处理过程算不算普通信件处理过程在计算机上的直接模拟，但是我想虽然软件产品的设计属于工业设计范畴，但是与传统的工业产品不一样，比如它的边际成本很少，比如使用的环境不一样（牛顿三定律在这个环境中就不重要），这大概是真实环境的普通邮件没有使用回执的原因。
而Email则不存在这些问题。那么既然Email更多地被使用来做一些可靠的传输，是不是像TCP协议有ACK一样，为Email添加自动的“收件人收信回执”处理过程是不是更自然也更方便呢？
--
-----------------------------------
welcome to:
http://www.sxnsx.com/
For Fun, Hack, Linux, and Life
windstorm
failed之类的提示，不然就是发到了，那么对方愿意回就回，不愿意回就不回，应该说是没有义务让你知道读没读的吧？
如果真的引入回执机制，如果不是自动的.......每天处理50封以上邮件的人会烦死。
另外，貌似很多邮箱都支持收到自动回复发信者，其实这也很烦的，但至少比发阅读回执更人性化一点。
----------------------------------------------------------------------------------
Yours Sincerely
Kun
www.forwind.cn
http://twitter.com/lk_517
2009/4/8 Shellex Well <5h3...@gmail.com>:
Tiny fool
--
--------------
Gmail: tiny...@gmail.com
Gtalk: tiny...@gmail.com
Phone: 13520711089
Twitter:http://twitter.com/tinyfool
银杏泰克科技有限公司-专业的站内搜索引擎提供商
http://www.ginkgotek.com/
Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm
TV的Google观察
http://www.tinydust.net/tinygoogle/
小马xioama
SpitFire
James Z.M. GAO
即使实现了，也很不可靠。协议层面的回执只能保证发到了目的邮件服务器，
但有可能被用户自己的过滤器打入垃圾箱。
在客户端这一层，回执最多能保证目的人open的动作，但不能保证他read了。
甚至他何时，是否真的read都无法保证。比如一个人用pop3客户端，
当下载邮件后标记为已读，两天后自动删除副本。那么邮件服务器何时认定需要发送回执呢？
对于客户端，切不说每次open邮件时候被询问回执的客户体验，
如果都是自动回执，一封已读邮件被标记为未读，下次再阅读的时候是否需要回执？
如果我有两处地方可以查看邮件，两个地方都下载了同一封邮件，每次阅读都要发送
回执？即使这个回执标记加在服务器端，那对于一封下载后立刻删除的邮件怎么处理回执？
我觉得邮件的回执和淘宝、qq、短信这样的IM的“阅读确认”不一样。
邮件并不具有很高的及时性，也无法保证用户登录的唯一性。
现在大部分邮件服务器都是静默确认的，no news is good news,
只有出了问题才通知，这样也更有效，不会因为大量确认回执而淹没了错误通知。
我们需要的是“人”这一层的回执，例如在信件中加上“请求回执”，或者在某些团体内，
对重要内容形成共识。虽然同样不完全可靠，但也算一个有效的办法了。
这个链接是Alpine对回执问题的faq，可以参考一下：
http://www.washington.edu/alpine/faq/sendreceive.html#4.2
小马xioama
Gliter Zhang
在自己的网站上生成一个随机页面，并访问计数，将这个链接放到邮件里（前提当
然是对方以html格式接收了），如果对方打开了，那个页面就记录下来了。
很粗糙不过觉得很有创意，呵呵
在 2009-04-08三的 14:50 +0800，Shellex Well写道：
李学凯
如果邮件中包含图片，服务器是不会自动下载的，除非用户点击确定要接收图片。这样可以防止不怀好意的人通过发送带图片的邮件来检测我们的邮箱地址是否是活跃的。
如果协议支持"收信回执"，我想这会是垃圾邮件发送者的福音。他们可以轻易的知道垃圾邮件是否被用户查看。
李学凯
Sent from 哈尔滨市, 黑龙江省, 中国
ShellEx Well
但是我是想可以从应用层提供一个方案来标识一份邮件是否得到阅读了。
尽管本质上还是由客户端发了一份回执邮件，但是在表现上只是简单的在 发送方那儿的上邮件添加一个 已被阅读的标识。
On Apr 8, 2:57 pm, windstorm <likunarmstr...@gmail.com> wrote:
> 在我印象中，一般发不到的都是会有delivery
> failed之类的提示，不然就是发到了，那么对方愿意回就回，不愿意回就不回，应该说是没有义务让你知道读没读的吧？
>
> 如果真的引入回执机制，如果不是自动的.......每天处理50封以上邮件的人会烦死。
>
> 另外，貌似很多邮箱都支持收到自动回复发信者，其实这也很烦的，但至少比发阅读回执更人性化一点。
>
> ----------------------------------------------------------------------------------
> Yours Sincerely
> Kun
>
> www.forwind.cnhttp://twitter.com/lk_517
>
> 2009/4/8 Shellex Well <5h3l...@gmail.com>:
>
> > 老师在收作业的时候使用了Email，有同学问我，Gmail支持"收信回执"不？在得到否定的答案后，他很失望地说，（不管是发送方还是接受方）使用收信回执应该是一个好习惯，这样可以使他的投递得到保障。
>
> > 在一些Email客户端(包括Outlook这样的桌面客户端和126这样的Web客户端)中，有一个功能叫"收信回执"，被称为Read
> > Receipt的。应当属于Delivery Status Notifications(DSNs)中的一种。
>
> > 但是这个Read Receipt有其特殊性。一般的DSNs，包括每个人都收到过的Email Non Delivery
> > Receipts，都是邮件系统发出的，对于发送成功至目标邮件服务器的邮件，目标服务器会给一个DSNs，来通报发送服务器接受成功，这个姑且称为"服务器收信回执"。
>
> > 而对于Read Receipt，从分层的思想来看，作用于人类一层，也就是Email系统的直接使用者，称为"收件人收信回执"。服务器接收成功不意味着收信人已经阅读过了邮件。而Read
> > Receipt就提供了一个（可选的）方案来使发送者确保邮件得到了阅读。
>
> > 投递Email的最终目的应当是目标完成了对Email的阅读。那么为什么在SMTP这样的协议标准中没有明确定义要求实现它呢？尽管
>
> > Depending on the recipient's mail client and settings, they may be
> > forced to click a notification button before they can move on with
> > their work. Even though it is an opt-in process, therefore, a
> > recipient may consider it inconvenient, discourteous, or invasive.
>
> > (fromhttp://en.wikipedia.org/wiki/Read_receipt, 我本人同意"不方便"的看法)
ShellEx Well
但是我是想可以从应用层提供一个方案来标识一份邮件是否得到阅读了。
尽管本质上还是由客户端发了一份回执邮件，但是在表现上只是简单的在 发送方那儿的上邮件添加一个 已被阅读的标识。
On Apr 8, 2:57 pm, windstorm <likunarmstr...@gmail.com> wrote:
> 在我印象中，一般发不到的都是会有delivery
> failed之类的提示，不然就是发到了，那么对方愿意回就回，不愿意回就不回，应该说是没有义务让你知道读没读的吧？
>
> 如果真的引入回执机制，如果不是自动的.......每天处理50封以上邮件的人会烦死。
>
> 另外，貌似很多邮箱都支持收到自动回复发信者，其实这也很烦的，但至少比发阅读回执更人性化一点。
>
> ----------------------------------------------------------------------------------
> Yours Sincerely
> Kun
>
> www.forwind.cnhttp://twitter.com/lk_517
>
> 2009/4/8 Shellex Well <5h3l...@gmail.com>:
>
> > 老师在收作业的时候使用了Email，有同学问我，Gmail支持"收信回执"不？在得到否定的答案后，他很失望地说，（不管是发送方还是接受方）使用收信回执应该是一个好习惯，这样可以使他的投递得到保障。
>
> > 在一些Email客户端(包括Outlook这样的桌面客户端和126这样的Web客户端)中，有一个功能叫"收信回执"，被称为Read
> > Receipt的。应当属于Delivery Status Notifications(DSNs)中的一种。
>
> > 但是这个Read Receipt有其特殊性。一般的DSNs，包括每个人都收到过的Email Non Delivery
> > Receipts，都是邮件系统发出的，对于发送成功至目标邮件服务器的邮件，目标服务器会给一个DSNs，来通报发送服务器接受成功，这个姑且称为"服务器收信回执"。
>
> > 而对于Read Receipt，从分层的思想来看，作用于人类一层，也就是Email系统的直接使用者，称为"收件人收信回执"。服务器接收成功不意味着收信人已经阅读过了邮件。而Read
> > Receipt就提供了一个（可选的）方案来使发送者确保邮件得到了阅读。
>
> > 投递Email的最终目的应当是目标完成了对Email的阅读。那么为什么在SMTP这样的协议标准中没有明确定义要求实现它呢？尽管
>
> > Depending on the recipient's mail client and settings, they may be
> > forced to click a notification button before they can move on with
> > their work. Even though it is an opt-in process, therefore, a
> > recipient may consider it inconvenient, discourteous, or invasive.
>
> > (fromhttp://en.wikipedia.org/wiki/Read_receipt, 我本人同意"不方便"的看法)
lcgong
收信回执的技术会大幅降低邮件帐户扫描、用户探查等侵犯个体隐私行为的成本，整体降低电子邮件服务的质量。也正因为电子邮件的发送成本近乎为零，致使垃
圾邮件泛滥，自然也提高了反垃圾邮件的技术及社会成本。
如果用户探查技术难度被降低，用户特征及群体的分类数据价值也会提高，利于形成更成熟的黑市。一旦这种数据利用成本降低以及利用效率获得大幅提高，垃圾
邮件内容变种、投放形式会更多，反垃圾邮件技术难度及成本自然大幅提高。
人使用技术也会遇到技术问题，而且两个人以上的群体就会存在经济问题。
是技术还是经济？难以分清。
On Apr 8, 2:50 pm, Shellex Well <5h3l...@gmail.com> wrote:
> 老师在收作业的时候使用了Email，有同学问我，Gmail支持"收信回执"不？在得到否定的答案后，他很失望地说，（不管是发送方还是接受方）使用收信回执应该是一个好习惯，这样可以使他的投递得到保障。
>
> 在一些Email客户端(包括Outlook这样的桌面客户端和126这样的Web客户端)中，有一个功能叫"收信回执"，被称为Read
> Receipt的。应当属于Delivery Status Notifications(DSNs)中的一种。
>
> 但是这个Read Receipt有其特殊性。一般的DSNs，包括每个人都收到过的Email Non Delivery
> Receipts，都是邮件系统发出的，对于发送成功至目标邮件服务器的邮件，目标服务器会给一个DSNs，来通报发送服务器接受成功，这个姑且称为"服务器收信回执"。
>
> 而对于Read Receipt，从分层的思想来看，作用于人类一层，也就是Email系统的直接使用者，称为"收件人收信回执"。服务器接收成功不意味着收信人已经阅读过了邮件。而Read
> Receipt就提供了一个（可选的）方案来使发送者确保邮件得到了阅读。
>
> 投递Email的最终目的应当是目标完成了对Email的阅读。那么为什么在SMTP这样的协议标准中没有明确定义要求实现它呢？尽管
>
> Depending on the recipient's mail client and settings, they may be
> forced to click a notification button before they can move on with
> their work. Even though it is an opt-in process, therefore, a
> recipient may consider it inconvenient, discourteous, or invasive.
>
> (fromhttp://en.wikipedia.org/wiki/Read_receipt, 我本人同意"不方便"的看法)
ShellEx Well
假如先不考虑垃圾邮件这样的消极因素，再使用设计得当的人类回执方式，我想应该是可取的吧。
> > (fromhttp://en.wikipedia.org/wiki/Read_receipt, 我本人同意"不方便"的看法)
DaiZW
回执基本上只对发送者有意义, 对于接收者来说一般情况下只会泄漏隐私.
所以让接收者主动做可能会有损隐私的事情, 这个.........恐怕不大靠谱吧
2009/4/8 ShellEx Well <5h3...@gmail.com>:
James Z.M. GAO
需要在邮件发送和接受端都有一个协议，不一定加入邮件头，
只要格式固定，容易解析，就像GPG签名一样。
然后在发送端，Bob写：<++请求回执: 这封信很重要，看到请回复++>
如果接受端也支持这种格式，比如gmail支持，那么接受人Alice在阅读邮件的时候，
gmail回吧<++请求回复: xxxx++>这些文字用明显但不刺眼的颜色标出来，
如果单击这段文字，gmail会自动调整焦点到回复对话框，并适当修改subject，
并加入事先准备好的回执套话，让Alice修改，修改完毕点击发送即可。
Jawley
如果一定要加这个功能，是不是可以这样设计：
James Z.M. GAO
而各个邮件服务器行为又不统一。
如果用http协议，那就需要发件人有可控制http服务器，
或者邮件服务商提供这种服务~
On Wed, 8 Apr 2009, Jawley wrote:
> 那我觉得根本不需要用邮件。发送者附上一个链接，接收者点一下就提交数据到
?? ??送者的邮件服务器那里就行了。
>
> 2009/4/8 James Z.M. GAO <gao...@gmail.com>
> 如果一定要加这个功能，是不是可以这样设计：
> 需要在邮件发送和接受端都有一个协议，不一定加入邮件头，
> 只要格式固定，容易解析，就像GPG签名一样。
> 然后在发送端，Bob写：<++请求回执:
> 这封信很重要，看到请回复++>
>
> 如果接受端也支持这种格式，比如gmail支持，那么接受人Alice在阅读邮件的时
?? ??，
刘其帅
除非把协议设计成对方在看信的时候才来发信方服务器获取正文，或让收信方点击链接进入某网站查看正文，才能准确知道是否看了内容。
2009/4/8 James Z.M. GAO <gao...@gmail.com>:
zhusupe_wanglei
Lai Jiangshan
2009/4/8 ShellEx Well <5h3...@gmail.com>:
湖心亭看雪
另外，可能在企业里面阅读回执这种功能会更加有意义一些，因为在企业里面最强调的是执行和效率。如果上司用邮件给下属发重要事务的通知邮件，不能准确知
道下属是否看到邮件的话，会耽误很多事情的。总不能每发一封邮件，就在MSN上说句话通知一下吧，呵呵。
On Apr 8, 2:57 pm, windstorm <likunarmstr...@gmail.com> wrote:
> 在我印象中，一般发不到的都是会有delivery
> failed之类的提示，不然就是发到了，那么对方愿意回就回，不愿意回就不回，应该说是没有义务让你知道读没读的吧？
>
> 如果真的引入回执机制，如果不是自动的.......每天处理50封以上邮件的人会烦死。
>
> 另外，貌似很多邮箱都支持收到自动回复发信者，其实这也很烦的，但至少比发阅读回执更人性化一点。
>
> --------------------------------------------------------------------------- -------
> Yours Sincerely
> Kun
>
> www.forwind.cnhttp://twitter.com/lk_517
>
> 2009/4/8 Shellex Well <5h3l...@gmail.com>:
>
> > 老师在收作业的时候使用了Email，有同学问我，Gmail支持"收信回执"不？在得到否定的答案后，他很失望地说，（不管是发送方还是接受方）使用收信回执 应该是一个好习惯，这样可以使他的投递得到保障。
>
> > 在一些Email客户端(包括Outlook这样的桌面客户端和126这样的Web客户端)中，有一个功能叫"收信回执"，被称为Read
> > Receipt的。应当属于Delivery Status Notifications(DSNs)中的一种。
>
> > 但是这个Read Receipt有其特殊性。一般的DSNs，包括每个人都收到过的Email Non Delivery
> > Receipts，都是邮件系统发出的，对于发送成功至目标邮件服务器的邮件，目标服务器会给一个DSNs，来通报发送服务器接受成功，这个姑且称为"服务器收 信回执"。
>
> > 而对于Read Receipt，从分层的思想来看，作用于人类一层，也就是Email系统的直接使用者，称为"收件人收信回执"。服务器接收成功不意味着收信人已经阅读过了邮 件。而Read
> > Receipt就提供了一个（可选的）方案来使发送者确保邮件得到了阅读。
>
> > 投递Email的最终目的应当是目标完成了对Email的阅读。那么为什么在SMTP这样的协议标准中没有明确定义要求实现它呢？尽管
>
> > Depending on the recipient's mail client and settings, they may be
> > forced to click a notification button before they can move on with
> > their work. Even though it is an opt-in process, therefore, a
> > recipient may consider it inconvenient, discourteous, or invasive.
>
> > (fromhttp://en.wikipedia.org/wiki/Read_receipt, 我本人同意"不方便"的看法)
>
> > 但我想这个问题，可以被一个设计良好的用户交互过程解决(比如，打开邮件时默认发送回执，当然了，这样就剥夺了用户拒绝回执的权力，但是我不知道出于什么普遍原 因需要拒绝回执的)。
>
> > 我不知道Email的处理过程算不算普通信件处理过程在计算机上的直接模拟，但是我想虽然软件产品的设计属于工业设计范畴，但是与传统的工业产品不一样，比如它 的边际成本很少，比如使用的环境不一样（牛顿三定律在这个环境中就不重要），这大概是真实环境的普通邮件没有使用回执的原因。
Flouse
觉得这种默认机制相当合理啊。
怀宇范
bool ContactMe(person you)
{
if(you.GoTo("14#344, Tsinghua") && you.Find("Fan Huaiyu"))return true;
if(you.MailTo(" dugu...@gmail.com ") || you.MailTo(" fan...@mails.tsinghua.edu.cn "))return true;
if(you.PhoneTo("13488810330") || you.PhoneTo("01062778689"))return true;
if(you.QQTo("120628812") || you.MSNTo("dugu...@hotmail.com"))return true;
if(you.NetTo(" www.cnblogs.com/duguguiyu "))return true;
return false;
}
i...@mofun.cc
http://www.mofun.cc
--
http://lwgboy.space.mofun.cc
Goo
那个..Gmail不是可以自动回复的嘛？设置里面，什么假日离开。。
On 4月8日, 下午2时50分, Shellex Well <5h3l...@gmail.com> wrote:
> 老师在收作业的时候使用了Email，有同学问我，Gmail支持"收信回执"不？在得到否定的答案后，他很失望地说，（不管是发送方还是接受方）使用收信回执应该是一个好习惯，这样可以使他的投递得到保障。
>
> 在一些Email客户端(包括Outlook这样的桌面客户端和126这样的Web客户端)中，有一个功能叫"收信回执"，被称为Read
> Receipt的。应当属于Delivery Status Notifications(DSNs)中的一种。
>
> 但是这个Read Receipt有其特殊性。一般的DSNs，包括每个人都收到过的Email Non Delivery
> Receipts，都是邮件系统发出的，对于发送成功至目标邮件服务器的邮件，目标服务器会给一个DSNs，来通报发送服务器接受成功，这个姑且称为"服务器收信回执"。
>
> 而对于Read Receipt，从分层的思想来看，作用于人类一层，也就是Email系统的直接使用者，称为"收件人收信回执"。服务器接收成功不意味着收信人已经阅读过了邮件。而Read
> Receipt就提供了一个（可选的）方案来使发送者确保邮件得到了阅读。
>
> 投递Email的最终目的应当是目标完成了对Email的阅读。那么为什么在SMTP这样的协议标准中没有明确定义要求实现它呢？尽管
>
> Depending on the recipient's mail client and settings, they may be
> forced to click a notification button before they can move on with
> their work. Even though it is an opt-in process, therefore, a
> recipient may consider it inconvenient, discourteous, or invasive.
>
> (fromhttp://en.wikipedia.org/wiki/Read_receipt, 我本人同意"不方便"的看法)
