CN100514941C - 一种阻止垃圾推消息的方法 - Google Patents
一种阻止垃圾推消息的方法 Download PDFInfo
- Publication number
- CN100514941C CN100514941C CNB2004100695011A CN200410069501A CN100514941C CN 100514941 C CN100514941 C CN 100514941C CN B2004100695011 A CNB2004100695011 A CN B2004100695011A CN 200410069501 A CN200410069501 A CN 200410069501A CN 100514941 C CN100514941 C CN 100514941C
- Authority
- CN
- China
- Prior art keywords
- ppg
- terminal
- authentication
- authentication table
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种阻止垃圾推(PUSH)消息的方法，所述PUSH消息由PUSH发起者(PI)发送到PUSH代理网关(PPG)，由PPG控制并转发到目的终端，所述PPG上设置有用于对PI鉴权的PPG可信任PI列表；该方法为：在PPG上维护终端是否信任PI的第二鉴权表；当PPG接收到推消息时，利用所述第一鉴权表和第二鉴权表对该推消息的PI进行鉴权，如果PI通过第一和第二鉴权表的鉴权，则将接收到的推消息发送到目的终端，否则丢弃该推消息。
Description
技术领域
本发明涉及通信领域的推消息技术，尤其涉及一种阻止垃圾推(PUSH)消息的方法。
背景技术
Internet上绝大多数应用都基于客户机/服务器模型，从表现形式上看大致可以分为两种：PULL(拉)业务和PUSH(推)业务。PULL业务是目前在Internet上使用最多的业务形式，首先由客户机发起请求，然后服务器将客户机所请求的内容发给客户机。
PUSH技术也基于客户机/服务器模型，不同于PULL业务的是，在服务器发送内容给客户机之前，没有客户机请求。也就是说，PUSH事务是由服务器发起的，如图1所示。
在无线应用协议(WAP)应用体系结构中，PUSH业务的结构分为三大部分：PUSH代理网关(PPG)、PUSH发起者(PI)和WAP终端。典型的PI是运行于普通WEB服务器上的一个应用程序，它通过PAP(PUSH Access Protocol)与PPG通讯。
PPG通过PUSH-OTA(Over-the-air)协议在一个可设置的超时(timeout)时间内将信息转发给WAP客户，PUSH结构如图2所示，PUSH业务的核心是PPG，PPG负责对PUSH业务的整个流程进行控制。
从业务体现来看，PUSH业务发起时候是不需要用户请求的，PI知道了用户的地址，就能向用户推送消息，在这一点上PUSH业务很像Email业务。当前PUSH应用还很少，如果以后应用增多后，可以预见它会面临与Email一样的问题，即网路上大量的垃圾Email极大地浪费了人力和物力。
中国互联网协会反垃圾邮件协调小组2003年公布的数据显示，去年12月份中国网民每周收到的正常电子邮件数为7.7封，垃圾邮件8.3封，而半年后的2003年7月份，网民收到的正常电子邮件为7.2封，而垃圾邮件数量为8.9封。总量超过6亿封的垃圾电子邮件每周通过网络源源不断传送到6800万网民的电子信箱中。这种危害是双重的：这些垃圾邮件占用了用户的电子邮箱空间，网民需要花费大量时间去删除这些邮件，而在网上频频出现的垃圾邮件还导致网速下降。
虽然现在很难说有多少垃圾PUSH消息会产生，但是PUSH的业务特点决定了必然有不少的垃圾PUSH消息产生，由于无线网络传输带宽相对有线网络极为有限，移动终端相对固定终端存储能力小得多，所以防范垃圾PUSH消息是非常重要的事情，其重要性超过了防范垃圾邮件。开放移动终端联盟(OMA)论坛在制定PUSH规范时候在这方面已经考虑到了这一需求，下面分析一下WAP协议中已有的技术。
在当前的PUSH技术中，PPG将作为终端的鉴权代理，这种鉴权机制是基于信任可转移原则，即如果一个客户机与一个PPG之间能建立信任关系，则PPG能够代替客户机对PI进行鉴权。PPG必须能明确地对PI进行鉴权，PPG如果已经对某个PI进行了鉴权，则在发给终端的PUSH消息中会携带已经鉴权的标识Authenticated flag和PI的URL地址Initiator URL。终端在接收到Authenticatedflag后，终端可以通过比较保存在本地的可信任PI的URL列表来判断PUSH消息中指示的Initiator URL是否是可信任的，如果可信任则接收该PUSH消息，如果该PI不可信任则拒绝PUSH消息。
这种技术提供两层鉴权机制，一是由PPG对PI鉴权，只有通过鉴权的PI才能发送PUSH消息；二是终端根据本地配置的可信任PI的列表对PPG鉴权后的PUSH消息再次鉴权，如果能通过鉴权则终端最终接收该PUSH消息。虽然这种方法已经可以大大减少垃圾PUSH消息，但还是存在以下不足：
1、PPG并不针对特定终端进行PI鉴权，所以不能深入了解到各个终端的信任PI列表情况，某个PI对PPG来说是可信任的，但是终端认为此PI是不可信任的。按照上面提到的方法，终端必须接收该PUSH消息与本地PI信任列表比较后才能最终确定是否是可以接收，如果该PI不可信任，则丢弃，但是由于此时PUSH消息已经接收到了本地，因此实际上已浪费了无线资源。如果能通过PPG鉴权却不能通过终端鉴权的PUSH消息量增多，则浪费的无线资源就会相当可观。由于终端丢弃了PUSH消息，用户不会接收到该消息，则对此PUSH消息的计费也会很困难。
2、对能够通过鉴权的PI无有效的监控机制，不能保证这些可信任的PI不发送垃圾PUSH消息。即该PI通过了PPG的鉴权，也通过了终端的鉴权，但是当最终用户接收后发现它仍然是一条垃圾PUSH消息，这种情况不仅浪费了无线资源，而且相对前一种情况还浪费了用户的时间。
发明内容
本发明的目的在于提供一种阻止垃圾推(PUSH)消息的方法，以解决现有技术中因PPG不了解终端对PI的信任情况而将终端不信任的PI发送的大量PUSH消息转发给终端，从而存在浪费大量无线资源和给用户造成不便的问题。
为解决上述问题，本发明提供以下技术方案：
一种阻止垃圾推消息的方法，所述推(PUSH)消息由发起者(PI)发送到推代理网关(PPG)，由PPG控制并转发到目的终端，所述PPG上设置有PPG是否信任PI的第一鉴权表；该方法为：在PPG上维护终端是否信任PI的第二鉴权表；当PPG接收到推消息时，利用所述第一鉴权表和第二鉴权表对该推消息的PI进行鉴权，如果PI通过第一和第二鉴权表的鉴权，则将接收到的推消息发送到目的终端，否则丢弃该推消息。
根据上述方法：
对PI鉴权时，先利用第一鉴权表对PI进行鉴权，并在鉴权通过后再利用第二鉴权表对PI进行鉴权。
PPG通过向终端发送请求消息来获取或更新所述第二鉴权表。
PPG获取或更新第二鉴权表包括步骤：
A、PPG向终端发送包含本端是否具有第二鉴权表信息的请求消息；
B、终端根据所述请求消息中的信息判断PPG是否保存有第二鉴权表；如果是则进行步骤C，否则将本地的第二鉴权表和时戳发送给PPG，进行步骤D；
C、根据第二鉴权表的时戳判断PPG上保存的第二鉴权表与本地的第二鉴权表是否一致；如果不一致，则将本地的第二鉴权表和时戳发送给PPG，进行步骤D，否则向PPG返回第二鉴权表一致的响应消息并结束；
D、PPG保存或更新第二鉴权表。
当终端确认收的消息为垃圾推消息时，向PPG发送投诉消息，由PPG进行统计并动态监控对应的PI。
所述第一鉴权表为PPG可信任PI列表(即白名单)或PPG不可信任PI列表(即黑名单)；所述第二鉴权表为终端可信任PI列表或终端不可信任PI列表。
本发明通过在PPG上保存终端可信任PI列表，采用PPG可信任PI列表和终端可信任PI列表对PI鉴权，并在通过该两个列表的鉴权后PPG才将接收到的PUSH消息发送到目的终端，因而能更加有效地阻击垃圾push消息，节约网络资源。在本发明中，最终用户能够投诉发送垃圾PUSH消息的PI，能够为PPG更有效地管理PI提供依据，从而动态监控PI的行为。
附图说明
图1为拉(PULL)业务和推(PUSH)业务的工作模型示意图；
图2为PUSH业务的原理图；
图3为PPG从终端获取终端可信任PI列表的示意图；
图4为PPG更新终端可信任PI列表的示意图；
图5为终端主动上报其可信任PI列表的示意图(PPG中无终端可信任PI列表)；
图6为终端主动上报其可信任PI列表的示意图(PPG中有旧的终端可信任PI列表)；
图7为动态监控PI的流程图。
具体实施方式
本发明为了进一步减少垃圾推(PUSH)消息，推代理网关(PPG)除了保留和维护自身是否信任推消息发起者(PI)的第一鉴权表外，还保存和维护各个终端提供的是否信任PI的第二鉴权列表。第一鉴权表可以是PPG可信任PI列表，即白名单；也可以是PPG不可信任PI列表，即黑名单。第二鉴权表可以是终端可信任PI列表，即白名单；也可以是终端不可信任PI列表，即黑名单。本实施例以第一、第二鉴权表为白名单为例对本发明进行说明。
PPG接收PI的PUSH消息后，首先检查该PI是否在PPG的信任列表中，即利用PPG的信任列表对PI鉴权，如果在列表中，则再代理终端检查该PI是否在目地终端的可信任PI列表中，即利用终端可信任列表对PI鉴权，如果不在列表中则丢弃PUSH消息，如果属于终端信任的PI才将PUSH消息发送给终端。这样可以进一步减少发给终端的垃圾PUSH消息，节约无线带宽和减少对终端资源的占用。
终端依然保留自己的可信任PI列表，并建立本地可信任PI列表与PPG上的终端可信任PI列表的同步机制(或称白名单同步机制)。即利用终端本地的可信任PI列表更新PPG上的旧的终端可信任PI列表，以此来更多地减少垃圾PUSH消息的流量。
PPG可以用两种方式获取终端的PI列表，一种是PPG通过发送请求消息主动申请，另外一种是终端在每次用户更改了可信任PI列表后，终端主动发给PPG。
PPG通过向终端发送请求消息获取或更新终端可信任PI列表，在该请求消息中携带两个新的消息头：
x-wap-whitelist(白名单列表)：此消息头用于指明被终端列入可信任PI列表的PI的URL表。
x-wap-whitelist-stamp(白名单列表时戳)：此消息头用于指明当前应该采用的终端可信任PI列表的时戳。
在终端向PPG返回的响应消息中，引入两个新的状态码：
x-wap-PUSH-status(白名单PUSH消息状态码)＝502：此状态码表示PPG上的终端可信任PI列表与终端本地的可信任PI列表不匹配。
x-wap-PUSH-status＝503：此状态码表示PPG上的终端可信任PI列表与终端本地的可信任PI列表相匹配。
PPG没有终端所拥有的可信任PI列表(即白名单)时，PPG向终端发送的HTTP(HyperText Transfer Protocol，超文本传送协议)OPTIONS(选项)消息中不携带x-wap-whitelist-stamp头，或者携带了x-wap-whitelist-stamp头，但取值为空或非法值，则终端认为PPG没有终端拥有的终端可信任PI列表，它会用x-wap-whitelist头将最新的可信任PI列表发给终端，并且用x-wap-whitelist-stamp将最新的时戳发给PPG，PPG接收后更新其本地保留的相应信息。参阅图3所示，其流程如下：
1、PPG发送HTTP OPTIONS Request(HTTP OPTIONS请求)消息启动同步流程，也就是说，通过发送HTTP OPTIONS Request消息给终端，以请求与终端设备中的可信任PI列表信息(即白名单列表)同步。
由于PPG没有该终端提供的可信任PI列表信息，所以该消息中不包括x-wap-whitelist-stamp头。
2、终端接收该消息后，知道PPG上没有本地的可信任PI列表，终端从本地获取最新的可信任PI列表和该列表的时戳，然后通过在HTTP OPTIONSResponse(HTTP OPTIONS响应)消息中添加x-wap-whitelist头和x-wap-whitelist-stamp头传递给PPG，并且以x-wap-PUSH-status＝502告诉PPG，PPG上保存的终端可信任PI列表与终端本地不一致。
3、PPG接收后则保存终端可信任PI列表和该列表的时戳，然后再发一条HTTP OPTIONS Request消息，将最新获得的终端可信息PI列表的时戳通过头信息x-wap-whitelist-stamp通知终端。
4、终端获取该消息以后，如果检查后认为PPG发来的x-wap-whitelist-stamp与自己本地保存的一样，则以x-wap-PUSH-status＝503确认，即利用该503状态码表示PPG上的终端可信任PI列表与终端本地的可信任PI列表相匹配，以确认。
当PPG保存有旧的终端可信任PI列表时，PPG向终端发送的HTTPOPTIONS消息中携带x-wap-whitelist-stamp头与终端本地保存的x-wap-whitelist-stamp头的取值不一样，则终端认为PPG拥有的终端可信任列表不是最新的，终端会用x-wap-whitelist头将最新的可信任列表发给终端，并且用x-wap-whitelist-stamp将该列表最新的时戳发给PPG，PPG接收后更新其本地保留的相应信息。参阅图4所示，其流程如下：
1、PPG发送HTTP OPTIONS Request消息启动更新流程，由于PPG将其保存的最新终端可信任列表的时戳用x-wap-whitelist-stamp头发给终端，即此时PPG中保存的该终端的wap-whitelist-stamp＝X。
2、终端接收该消息后，取出本地保存的可信任列表时戳与接收的进行比较，发现本地x-wap-whitelist-stamp＝Y，与PPG的不一样，则终端从本地获取最新的可信任PI列表和该列表的时戳，然后通过在HTTP OPTIONS Response消息中添加x-wap-whitelist头和x-wap-whitelist-stamp头传递给PPG，并且以x-wap-PUSH-status＝502告诉PPG，PPG上保存的终端可信任PI列表与终端本地不一致。
3、PPG接收后更新可信任PI列表和该列表的时戳，然后再发一条HTTPOPTIONS Request消息，将最新获得的头信息x-wap-whitelist-stamp＝Y通知终端进行确认。
4、终端获取该消息，检查PPG发来的x-wap-whitelist-stamp与自己本地保存的一样，则以消息头x-wap-PUSH-status＝503给予确认，即利用该503状态码表示PPG上的终端可信任PI列表与终端本地的可信任PI列表相匹配，以确认，告诉PPG它所获得的可信任PI列表是最新的。
当用户更改了可信任PI列表后，终端可通过HTTP的方法向PPG发送新的可信任列表，在该请求消息中携带两个新的消息头：
x-wap-whitelist：用于指明被终端列入可信任PI列表的PI的URL表。
x-wap-whitelist-stamp：用于指明当前应该采用的终端可信任PI列表的时戳。
如果PPG本地没有保存终端的可信任PI列表，PPG接收该消息后，则保存。参阅图5所示，其流程如下：
1、终端发送HTTP Options Request给PPG，该消息中通过两个头来携带可信任PI的信息，x-wap-whitelist、x-wap-whitelist-stamp。
2、由于PPG本地没有保存该终端提供的可信任PI列表信息，所以PPG取出这两个头中所包含的信息，即取出x-wap-whitelist、x-wap-whitelist-stamp并保存在本地。
如果PPG本地已经保存终端的可信任PI列表，PPG接收该消息后，则根据请求决定是否更新。参阅图6所示，其流程如下：
1、终端发送HTTP Options Request给PPG，该消息中通过两个头来携带可信任PI的信息，x-wap-whitelist、x-wap-whitelist-stamp。
2、PPG将比较消息中携带的x-wap-whitelist-stamp和本地保存的该终端上次给出的x-wap-whitelist-stamp是否一致，如果一致，PPG不更新可信任PI列表；如果不一致PPG将用终端发来消息中的x-wap-whitelist信息更新本地保存的终端可信任PI列表的信息。
对于经PPG鉴权后的PUSH消息是否为垃圾PUSH消息，最终用户最有发言权，所以本发明还允许最终用户参与到阻击垃圾PUSH消息的过程中。当PI通过了PPG的鉴权，也通过了终端的鉴权，但是当最终用户接收后发现它仍然是一条垃圾PUSH消息，则允许用户提交一条投诉消息给PPG，PPG统计这样的投诉消息以监控PI的行为。PPG可以基于一定的时长对投诉PI进行管理，例如该PI发出的垃圾PUSH消息超过一定的比例，就对该PI给予警告或不允许接入的惩罚，这样就提供了动态监控PI的机制。
为了实现动态监控PI，利用X-Wap-PUSH-Status头，为它定义一个新的状态码，OMA论坛中已经定义的状态码如下：
| 状态码 | HTTP方法 | 是否允许重试 | 描述 |
| 234 | POST | 是 | Push消息拒绝 |
| 235 | POST | 否 | Push消息拒绝 |
| 236 | POST | 否 | Push消息拒绝 |
| 237 | POST | 是 | Push消息拒绝 |
| 238 | POST | 否 | Push消息拒绝 |
| 256 | POST | 否 | Push消息拒绝，CPITag不存在或不匹配 |
| 257 | POST | 否 | Push消息拒绝，配置信息不匹配 |
| 300 | OPTIONS | 是 | 注册请求拒绝，允许重试 |
| 301 | OPTIONS | 否 | 注册请求拒绝，不允许重试 |
| 302 | OPTIONS | 否 | 注册请求拒绝，配置信息没有找到 |
| 400 | POST | N/A | Push请求接受，CPITag不存在或匹配 |
| 401 | POST | N/A | Push请求接受，CPITag不匹配 |
| 500 | OPTIONS | N/A | 注册请求接受，CPITag匹配 |
| 501 | OPTIONS | N/A | 注册请求接受，CPITag不存在或不匹配 |
| 600 | N/A | 请求拒绝，终端不支持PPG要求的OTA-HTTP协议版本 |
本实施例扩展X-Wap-PUSH-Status，定义如下状态码：
X-Wap-PUSH-Status＝239
| 状态码 | HTTP方法 | 是否允许重试 | 描述 |
| 239 | POST | 否 | Push消息被用户丢弃，因为这是个垃圾消息 |
可见，若X-Wap-PUSH-Status＝239，即拒绝重试，表明Push消息将被用户丢弃，因为这是个垃圾消息。
参阅图7所示，具体流程如下：
1、PPG向终端发送一条PUSH消息，PPG用X-Wap-PUSH-Info＝Authenticated指出，X-Wap-Initiator-URI头中的URI(PI)是已经被鉴权的，可信任的。
2、终端检测确认该PI是可信任的，接收此PUSH消息然后通知用户查看。用户查看该消息后发现此PUSH消息是一条垃圾消息，则通过终端GUI操作设置X-Wap-PUSH-Status＝239，终端将该状态码通过该PUSH消息的确认消息发送给PPG，告知PPG，这条消息被用户认为是垃圾消息。
3、PPG接收终端发来的确认消息后，查看X-Wap-PUSH-Status的值为239则做相应统计。然后根据一定的方法对PI进行管理，PPG具体如何管理PI可根据实际情况灵活确定。
在本实施例中，终端可信任PI列表和PPG可信任PI列表(也称白名单)中的PI可以是可信任的PI，鉴权时只要PI在列表中就确定该PI为可信任PI，即鉴权成功；当然列表中也可是不可信的PI(即黑名单)，鉴权时只要PI在列表中就确定该PI为不可信任，即鉴权失败。
Claims (7)
1、一种阻止垃圾推消息的方法，所述推PUSH消息由发起者PI发送到推代理网关PPG，由PPG控制并转发到目的终端，所述PPG上设置有PPG是否信任PI的第一鉴权表；其特征在于，该方法为：在PPG上维护终端是否信任PI的第二鉴权表；当PPG接收到推消息时，利用所述第一鉴权表和第二鉴权表对该推消息的PI进行鉴权，如果PI通过第一和第二鉴权表的鉴权，则将接收到的推消息发送到目的终端，否则丢弃该推消息。
2、如权利要求1所述的方法，其特征在于，对PI鉴权时，先利用第一鉴权表对PI进行鉴权，并在鉴权通过后再利用第二鉴权表对PI进行鉴权。
3、如权利要求1所述的方法，其特征在于，PPG通过向终端发送请求消息来获取或更新所述第二鉴权表。
4、如权利要求3所述的方法，其特征在于，PPG获取或更新第二鉴权表包括步骤：
A、PPG向终端发送包含本端是否具有第二鉴权表信息的请求消息；
B、终端根据所述请求消息中的信息判断PPG是否保存有第二鉴权表；如果是则进行步骤C，否则将本地的第二鉴权表和时戳发送给PPG，进行步骤D；
C、根据第二鉴权表的时戳判断PPG上保存的第二鉴权表与本地的第二鉴权表是否一致；如果不一致，则将本地的第二鉴权表和时戳发送给PPG，进行步骤D，否则向PPG返回第二鉴权表一致的响应消息并结束；
D、PPG保存或更新第二鉴权表。
5、如权利要求1所述的方法，其特征在于，当终端确认收的消息为垃圾推消息时，向PPG发送投诉消息，由PPG进行统计并动态监控对应的PI。
6、如权利要求1所述的方法，其特征在于，当终端上的第二鉴权表修改后，终端主动将修改后的第二鉴权表发送给PPG，由PPG保存或更新。
7、如权利要求1至6任一所述的方法，其特征在于，所述第一鉴权表为PPG可信任PI列表或PPG不可信任PI列表；所述第二鉴权表为终端可信任PI列表或终端不可信任PI列表。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100695011A CN100514941C (zh) | 2004-06-28 | 2004-06-28 | 一种阻止垃圾推消息的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100695011A CN100514941C (zh) | 2004-06-28 | 2004-06-28 | 一种阻止垃圾推消息的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1716918A CN1716918A (zh) | 2006-01-04 |
| CN100514941C true CN100514941C (zh) | 2009-07-15 |
Family
ID=35822353
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2004100695011A Active CN100514941C (zh) | 2004-06-28 | 2004-06-28 | 一种阻止垃圾推消息的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100514941C (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1853044B1 (en) * | 2006-05-02 | 2009-01-14 | Research In Motion Limited | Push framework for delivery of dynamic mobile content |
| CN101355729B (zh) * | 2008-09-02 | 2011-11-30 | 中国联合网络通信集团有限公司 | 短消息中心监控wap push消息的方法及系统 |
-
2004
- 2004-06-28 CN CNB2004100695011A patent/CN100514941C/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN1716918A (zh) | 2006-01-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101193070B (zh) | 即时通信系统、即时通信客户端及即时通信方法 | |
| EP1618727B1 (en) | A data access, replication or communication system comprising a distributed software application | |
| US6965920B2 (en) | Profile responsive electronic message management system | |
| US7730136B2 (en) | System and method for integrating electronic mail accounts | |
| DE69935339T2 (de) | Protokoll für sofortige Nachrichtenübermittlung | |
| US20050198545A1 (en) | Automatic user device presence registration system | |
| US20030231207A1 (en) | Personal e-mail system and method | |
| CN101179520A (zh) | 一种感知邮件状态的方法及系统 | |
| US8819102B2 (en) | Method and system for managing message communications | |
| EP1469643B1 (en) | Apparatus and method for forwarding e-mail | |
| CN101252499A (zh) | 一种检查邮件服务器是否有新邮件到达的邮件服务器动态轮询方法 | |
| CA2534537A1 (en) | Efficient new e-mail discovery | |
| US7912905B2 (en) | System and method for filtering network messages | |
| US7054907B1 (en) | Systems and methods for blocking delivery of an electronic communication | |
| WO2008071124A1 (fr) | Opération de commande à distance | |
| CN100514941C (zh) | 一种阻止垃圾推消息的方法 | |
| GB2401011A (en) | A client terminal and a server are each provided with a message queue to facilitate session independent transfer of messages | |
| CN106453119A (zh) | 一种认证控制方法及装置 | |
| CN101137094A (zh) | 电子邮件通知方法及其装置和系统 | |
| US20020161613A1 (en) | Message-address management program, recording medium carrying message-address management program, message-address management method, and message-address management apparatus | |
| KR100614866B1 (ko) | 메일 송신 전 수신 가능 상태를 판단하는 시스템 및 방법 | |
| JP2008099162A (ja) | 未到達メール通知システム、未到達メール通知方法および未到達メール通知プログラム | |
| Fang | The Safety precautions and Design of Mail System | |
| KR100442094B1 (ko) | 이메일을 이용한 실시간 쌍방향 통신 시스템 및 방법 | |
| WO2005119994A1 (en) | System and method for filtering network messages |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |