自动回复 实现

注：都是些网上查找到的资料，都记录下面，免得自己忘了。。

如果是dovecot较高的话，可以参考http://blog.chinaunix.net/u2/73230/showart_1088531.html，如果比较低的话，由于DOVECOT配置文档中会缺少几个QUOTO参数，所以无法实现；

如果dovecot是低版本（由于使用高版本的dovecot中，出现了些未知原因，造成系统非常缓慢，所以我现在使用的仍然是低版本的），可以参考实现，目前我用的就是这个方法来实现自动回复。

以下方法是在查找过程中，网上找到的一些资料，都是些实现自动回复功能的，经过测试，有些可以实现，但针对每个用户设置自动回复信息功能没有实现。

-------------------------------------------------------------------

1. 首先要在postfixadmin的config.inc.php中把vacation功能打开，并且添加一个转发的vacation域.（自定）。
2. 在数据库中建一张表，如果用mysql表查询的话。表名:transport
加两个字段: vdomain varchar primary key
Dummy varchar
3. 在配置文件中加上域传输的映射选项（main.cf）
Transport_maps = mysql:/usr/local/etc/postfix/vacation.cf
4. 在所指定的目录下，建一个传递映射表，我的是vacation.cf，查询把域指到一个用脚本上。
5. 在master.cf中加上：
vacation unix - n n - - pipe
flags=DRhu user=vacation argv=/var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}.
6. 在系统下建一用户vacation,然后再建一目录 /var/spool/vacation/,同时改变目录的所用者和组为vacation，接下来拷贝 postfixadmin/VIRTUAL_VACATION/vacation.pl到/var/spool/vacation/目录下，并改变它的所用者和所有组为vacation，权限为750.
7. 修改部分vacation.pl和vacation.php的代码
8. 在postfixadmin/users/下登陆用你的邮件账号，然后设置自动回复，这时会在表vacation中加入一条记录，同时在别名表alias中相应的字段（goto）中加入要自动回复的地址。
9. 重新启动postfix或者postfix reload 然后你就可以试着往你设置的邮箱中发送邮件啦

 

 ----------------------------------------------------------------------

postfix使用vaction做自动回复功能
1.必备条件
  - Perl5
  - Perl DBI.
  - Perl DBD::mysql
  要在postfixadmin的config.inc.php中把vacation功能打开，并且添加一个转发的vacation域(自定义)

2.创建本地用户及组vacation.vacation
  #/etc/passwd
  vacation:*:65501:65501::0:0:Virtual Vacation:/var/spool/vacation:/sbin/nologin
  #/etc/group
  vacation:*:65501:

3.创建一个目录，用于存放vacation tmp file，使其只有宿主有权限，700
  mkdir /var/spool/vacation

4.拷贝vacation.pl档案到创建的目录里
  cp vacation.pl /vacation.pl
  chown -R vacation:vacation
  权限应为：
  -rwx------ 1 vacation vacation 3356 Dec 21 00:00 vacation.pl*

5.设置转发类型，vi /etc/postfix/master.cf
  添加如下内容：
  vacation unix - n n - - pipe
  flags=Rq user=vacation argv=/var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}
  (前有2个空格，表示上一行的延续)

6.修改postfi配置文件
  vi /etc/postfix/main.cf
  transport_maps = hash:/etc/postfix/transport
  transport_maps = btree:/etc/postfix/transport
  (default_database_type = btree,建议使用第二条)

7.生成transport文件
  vi /etc/postfix/transport
  添加内容如下：
  #/etc/postfix/transport
  autoreply.yourdomain.com vacation

8.生成transport的db文件
  postmap /etc/postfix/transport

9.创建vacation用表,如果postfix安装ok，此表已经建立
  USE postfix;
#
# Table structure for table vacation
#
CREATE TABLE vacation (
  email varchar(255) NOT NULL default '',
  subject varchar(255) NOT NULL default '',
  body text NOT NULL,
  cache text NOT NULL,
  domain varchar(255) NOT NULL default '',
  created datetime NOT NULL default '0000-00-00 00:00:00',
  active tinyint(4) NOT NULL default '1',
  PRIMARY KEY (email),
  KEY email (email)
) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Vacation';

10.重新加载postfix设置
  postfix reload

 

- -------------------------------------------------------------------

 

自动回复整个流程:
-----------------
other MTA <====>; postfix MTA ====>; maildrop (判断当前邮件接收者的状态是否设定自动回复，后面是用户设定了自动回复状态) ====>; 邮件被发送到邮件接收者 ====>; 邮件同时被转发到自动回复代理帐户 ====>; MTA系统调用vacation.pl ====>; vacation.pl 分析邮件中的头信息得出邮件回复地址 ====>; vacation.pl 利用 "sendmail" 程序发送邮件到 otherMTA

一个实例:
---------
说明:本实例设置域 autoreply.com 为自动回复代理域，为测试帐户 ， 为自动回复代理用户。
用户在建立自动回复时Postfix Admin 有2个动作，首先会在数据库中建立一封邮件，并在alise表的goto字段中添加一个别名即 。邮件到达时，系统会将邮件发到两个地址和，在 transport中设置从autoreply.com -->; vacation 的转发，所以系统会将发送到autoreply.com域的邮件，利用master.cf中配置vacation.pl脚本做出自动回复动作。

自动回复部分安装:
以下操作是在安装完postfix admin之后进行

-----
系统要求
---------
你需要在你的系统中安装如下组件
- Perl5
- Perl DBI
- Perl DBD::mysql

关于自动回复
------------

这个自动回复是使用一个系统帐户利用一个Perl 脚本来对发送者进行自动回复

安装自动回复
------------

1. 创建一个本地帐户
-------------------

创建一个"vacation"的本地帐户，并且"vacation"不容许登陆。不要使用"nobody",也不能使用"root"和"postfix"等。

#/etc/passwd
vacation:*:65501:65501::0:0:Virtual Vacation:/nonexistent:/sbin/nologin

#/etc/group
vacation:*:65501:

2. 为自动回复创建数据表
-----------------------

USE postfix;
#
# Table structure for table vacation
#
CREATE TABLE vacation (
  email varchar(255) NOT NULL default '',
  subject varchar(255) NOT NULL default '',
  body text NOT NULL,
  cache text NOT NULL,
  domain varchar(255) NOT NULL default '',
  created datetime NOT NULL default '0000-00-00 00:00:00',
  active tinyint(4) NOT NULL default '1',
  PRIMARY KEY  (email),
  KEY email (email)
) TYPE=MyISAM COMMENT='Postfix Admin - Virtual Vacation';

3. 创建一个目录
---------------
创建一个目录，例如/var/spool/vacation,它只容许"vacation"用户访问
vacation.pl脚本及其日志文件等将放在这里。

4. 复制文件
-----------
将$postfixadmin-2.1.0/VIRTUAL_VACATION/vacation.pl文件拷贝到刚才创建的文
件夹中

  $ cp vacation.pl ;/vacation.pl
  $ chown -R vacation:vacation ;

然后你将会看到:
ls -al ;/
-rwx------   1 vacation  vacation  3356 Dec 21 00:00 vacation.pl*

5. 修改文件
-----------

为了让 vacation.pl 能够执行所有邮件都回复这一特性，下面修改其内容:
将if (do_cache ($email, $orig_from)) { return; } 这句注销掉即可。

6. 开始对系统进行设置
---------------------
在master.cf中定义transport 的类型:

#/etc/postfix/master.cf:
vacation  unix  -       n       n       -       -       pipe
  flags=Rq user=vacation argv=/var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}#

在mail.cf 中设定一个 transport maps file
下面举A/B两种方法
A.哈希数据库
--
#/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

然后添加在/etc/postfix/transport 文件中添加一条新的解析记录

#/etc/postfix/transport
autoreply.yourdomain.com        vacation
注意:"autoreply.yourdomain.com"此处与$postfixadmin-2.1.0/config.inc.php文件中的$CONF['vacation_domain']的参数相同
     "vacation"要与master.cf 中的 "vacation" 相同

执行 "postmap /etc/postfix/transport" 去创建一个哈希数据库

执行 "postfix reload" 完成配置

B.mysql数据库
--
#/etc/postfix/main.cf:
transport_maps = mysql:/etc/postfix/mysql/mysql_virtual_transport_maps.cf

其中mysql_virtual_transport_maps.cf的内容如下

        user = postfix
        password = postfix
        hosts = 127.0.0.1
        dbname = postfix
        table = domain
        select_field = transport
        where_field = domain
        additional_conditions = and backupmx = '0' and active = '1'

然后添加使用postfix admin 创建新域"autoreply.com"，在Transport段中添加"vacation"

执行 "postmap /etc/postfix/transport" 去创建一个哈希数据库

执行 "postfix reload" 完成配置

注意:英文安装文档在$postfixadmin-2.1.0/VIRTUAL_VACATION/install.txt 中找到

----------------------------------------------------------------------

Network Working Group                                       T. Showalter
Request for Comments: 5230
Category: Standards Track                                  N. Freed, Ed.
                                                        Sun Microsystems
                                                            January 2008

               Sieve Email Filtering: Vacation Extension

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

 

 

Showalter & Freed           Standards Track                     [Page 1]

RFC 5230               Sieve: Vacation Extension            January 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  Capability Identifier  . . . . . . . . . . . . . . . . . . . .  3
   4.  Vacation Action  . . . . . . . . . . . . . . . . . . . . . . .  3
     4.1.  Days Parameter . . . . . . . . . . . . . . . . . . . . . .  3
     4.2.  Previous Response Tracking . . . . . . . . . . . . . . . .  4
     4.3.  Subject and From Parameters  . . . . . . . . . . . . . . .  6
     4.4.  MIME Parameter . . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  Address Parameter and Limiting Replies to Personal
           Messages . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.6.  Restricting Replies to Automated Processes and Mailing
           Lists  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.7.  Interaction with Other Sieve Actions . . . . . . . . . . .  8
     4.8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Response Message Generation  . . . . . . . . . . . . . . . . .  9
     5.1.  SMTP MAIL FROM Address . . . . . . . . . . . . . . . . . .  9
     5.2.  Date . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Subject  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.5.  To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.6.  Auto-Submitted . . . . . . . . . . . . . . . . . . . . . . 10
     5.7.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
     5.8.  In-Reply-To and References . . . . . . . . . . . . . . . . 10
   6.  Relationship to Recommendations for Automatic Responses to
       Electronic Mail  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Internationalization Considerations  . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 15

 

 

Showalter & Freed           Standards Track                     [Page 2]

RFC 5230               Sieve: Vacation Extension            January 2008

1.  Introduction

   This document defines an extension to the Sieve language defined in
   [RFC5228] for notification that messages to a particular recipient
   will not be answered immediately.

2.  Conventions Used in This Document

   Conventions for notations are as in [RFC5228] section 1.1.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED",
   and "MAY" in this document are to be interpreted as defined in
   [RFC2119].

3.  Capability Identifier

   Sieve implementations that implement vacation have an identifier of
   "vacation" for use with the capability mechanism.

4.  Vacation Action

   Usage:   vacation [":days" number] [":subject" string]
                     [":from" string] [":addresses" string-list]
                     [":mime"] [":handle" string]

   The "vacation" action implements a vacation autoresponder similar to
   the vacation command available under many versions of Unix.  Its
   purpose is to provide correspondents with notification that the user
   is away for an extended period of time and that they should not
   expect quick responses.

   "Vacation" is used to respond to a message with another message.
   Vacation's messages are always addressed to the Return-Path address
   (that is, the envelope from address) of the message being responded
   to.

4.1.  Days Parameter

   The ":days" argument is used to specify the period in which addresses
   are kept and are not responded to, and is always specified in days.
   The minimum value used for this parameter is normally 1.  Sites MAY
   define a different minimum value as long as the minimum is greater
   than 0.  Sites MAY also define a maximum days value, which MUST be
   greater than 7, and SHOULD be greater than 30.

   If ":days" is omitted, the default value is either 7 or the minimum
   value (as defined above), whichever is greater.

 

Showalter & Freed           Standards Track                     [Page 3]

RFC 5230               Sieve: Vacation Extension            January 2008

   If the parameter given to ":days" is less than the minimum value,
   then the minimum value is used instead.

   If ":days" exceeds the site-defined maximum, the site-defined maximum
   is used instead.

4.2.  Previous Response Tracking

   "Vacation" keeps track of all the responses it has sent to each
   address in some period (as specified by the :days optional argument).
   If vacation has not previously sent the response to this address
   within the given time period, it sends the "reason" argument to the
   SMTP MAIL FROM address [RFC2821] of the message that is being
   responded to.  (The SMTP MAIL FROM address should be available in the
   Return-path: header field if Sieve processing occurs after final
   delivery.)

   Tracking is not just per address, but must also take the vacation
   response itself into account.  A script writer might, for example,
   have a vacation action that will send a general notice text-decoration: underline;">   A particular vacation response can be identified in text-decoration: underline;">   The second way is via a synthesis of the :subject, :from, :mime, and
   reason vacation command arguments.  All vacation actions that do not
   contain an explicit handle and that use an identical combination of
   these arguments are considered the same for tracking purposes.

   For instance, if sends mail to
   twice, mailto:[e-mail]">[e-mail] has the script shown below,
   would receive two responses, text-decoration: underline;">   require "vacation";
   if header :contains "subject" "cyrus" {
       vacation "I'm out -- send mail to cyrus-bugs";
   } else {
       vacation "I'm out -- call me at [phone]";
   }

 

Showalter & Freed           Standards Track                     [Page 4]

RFC 5230               Sieve: Vacation Extension            January 2008

   In the above example, gets the second
   message despite having gotten the first text-decoration: underline;">   There is text-decoration: underline;">   require ["vacation", "variables"];
   if header :matches "subject" "*" {
       vacation :subject "Automatic response to: ${1}"
                "I'm away -- send mail to foo in my absence";
   }

   As noted above, the optional ":handle" parameter can be used to tell
   the Sieve interpreter to treat two vacation actions with different
   arguments as the same command for purposes of response tracking.  The
   argument to ":handle" is a string that identifies the type of
   response being sent.  For instance, if sends
   mail to twice, mailto:[e-mail]">[e-mail] has the script shown below,
   will text-decoration: underline;">   require "vacation";
   if header :contains "subject" "lunch" {
       vacation :handle "ran-away" "I'm out and can't meet for lunch";
   } else {
       vacation :handle "ran-away" "I'm out";
   }

   NOTE: One way to implement the necessary mechanism here is to store a
   hash of either the current handle and the recipient address or, if no
   handle is provided, a hash of the vacation action parameters
   specifying the message content and the recipient address.  If a
   script is changed, implementations MAY reset the records of who has
   been responded to and when they have been responded to.

   IMPLEMENTATION NOTE: Care must be taken in constructing a hash of
   vacation action parameters.  In particular, since most parameters are
   optional, it is important not to let the same string used as the
   value for different parameters produce the same hash value.  One

 

Showalter & Freed           Standards Track                     [Page 5]

RFC 5230               Sieve: Vacation Extension            January 2008

   possible way to accomplish this is to apply the hash to a series of
   counted or null terminated strings, text-decoration: underline;">   Implementations are free to limit the number of remembered responses;
   however, the limit MUST NOT be less than 1000.  When limiting the
   number of tracked responses, implementations SHOULD discard the
   oldest text-decoration: underline;">4.3.  Subject and From Parameters

   The ":subject" parameter specifies a subject line to attach to any
   vacation response that is generated.  UTF-8 characters can be used in
   the string argument; implementations MUST convert the string to
   [RFC2047] encoded words if and text-decoration: underline;">   A ":from" parameter may be used to specify an alternate address to
   use in the From field of vacation messages.  The string must specify
   a valid [RFC2822] mailbox-list.  Implementations SHOULD check the
   syntax and generate an error when a syntactically invalid ":from"
   parameter is specified.  Implementations MAY also impose restrictions
   text-decoration: underline;">4.4.  MIME Parameter

   The ":mime" parameter, if supplied, specifies that the reason string
   is, in fact, a MIME entity as defined in [RFC2045] section 2.4,
   including both MIME headers and content.

   If the optional :mime parameter is not supplied, the reason string is
   considered a UTF-8 string.
 

 

 

Showalter & Freed           Standards Track                     [Page 6]

RFC 5230               Sieve: Vacation Extension            January 2008

   require "vacation";
   vacation :mime text:
   Content-Type: multipart/alternative; boundary=foo

   --foo

   I'm at the beach relaxing.  Mmmm, surf...

   --foo
   Content-Type: text/html; charset=us-ascii

       "">
  
   beach relaxing.
   Mmmm, surf...
  

   --foo--
   .

4.5.  Address Parameter and Limiting Replies to Personal Messages

   "Vacation" MUST NOT respond to a message unless the recipient user's
   email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
   "Resent-Bcc" line of the original message.  An email address is
   considered to belong to the recipient if it is text-decoration: underline;">   1.  an email address known by the implementation to be associated
       with the recipient,

   2.  the final envelope recipient address if it's available to the
       implementation, or

   3.  an address specified by the script writer via the ":addresses"
       argument described in the next paragraph.

   Users can supply additional mail addresses that are theirs with the
   ":addresses" argument, which takes a string-list listing additional
   addresses that a user might have.  These addresses are considered to
   belong to the recipient user in addition to the addresses known to
   the implementation.

 

 

Showalter & Freed           Standards Track                     [Page 7]

RFC 5230               Sieve: Vacation Extension            January 2008

4.6.  Restricting Replies to Automated Processes and Mailing Lists

   Implementations MAY refuse to send a vacation response to a message
   that contains any header or content that makes it appear that a
   response would not be appropriate.

   Implementations MUST have a list of addresses that "vacation" MUST
   NOT send mail to.  However, the contents of this list are
   implementation defined.  The purpose of this list is to stop mail
   from going to addresses used by system daemons that would not care if
   the user is actually reading her mail.

   Implementations are encouraged, however, to include well-known
   addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
   addresses typically used text-decoration: underline;">   Implementors may take guidance from [RFC2142], but should be careful.
   Some addresses, like "POSTMASTER", are generally actually managed by
   people, and people do care if the user is going to be unavailable.

   Implementations SHOULD NOT respond to any message that contains a
   "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List-
   Unsubscribe", "List-Post", "List-Owner", or "List-Archive" [RFC2369]
   header field.

   Implementations SHOULD NOT respond to any message that has an "Auto-
   submitted" header field with a value other than "no".  This header
   field is described in [RFC3834].

4.7.  Interaction with Other Sieve Actions

   Vacation does not affect Sieve's implicit keep action.

   Vacation can text-decoration: underline;">   Implementations MUST NOT consider vacation used with discard, keep,
   fileinto, or redirect an error.  The vacation action is incompatible
   with the Sieve reject and refuse actions [REJECT].

 

Showalter & Freed           Standards Track                     [Page 8]

RFC 5230               Sieve: Vacation Extension            January 2008

4.8.  Examples

   Here is a simple use of vacation.

   require "vacation";
   vacation :days 23 :addresses ["",
                                 ""]
   "I'm away until October 19.
   If it's an emergency, call 911, I guess." ;

   By mingling vacation with other rules, users can do something more
   selective.

   require "vacation";
   if header :contains "from" "" {
       redirect "";
   } else {
       vacation "Sorry, I'm away, I'll read your
   message when I get around to it.";
   }

5.  Response Message Generation

   This section details the requirements for the generated response
   message.

   It is worth noting that the input message and arguments may be in
   UTF-8, and that implementations MUST deal with UTF-8 input, although
   implementations MAY transcode to other character sets as regional
   taste dictates.  When :mime is used, the reason argument also
   contains MIME header information.  The headers must conform to MIME
   conventions; in particular, 8bit text is not allowed.
   Implementations SHOULD reject vacation :mime actions containing 8bit
   header material.

5.1.  SMTP MAIL FROM Address

   The SMTP MAIL FROM address of the message envelope SHOULD be set to
   <>.  NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
   SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.

5.2.  Date

   The Date field SHOULD be set to the date and time when the vacation
   response was generated.  Note that this may not be the same as the
   time the message was delivered to the user.

 

 

Showalter & Freed           Standards Track                     [Page 9]

RFC 5230               Sieve: Vacation Extension            January 2008

5.3.  Subject

   Users can specify the Subject of the reply with the ":subject"
   parameter.  If the :subject parameter is not supplied, then the
   subject is generated as follows: The subject is set to the characters
   "Auto: " followed by the original subject.  An appropriate fixed
   Subject, such as "Automated reply", SHOULD be used in the event that
   :subject isn't specified and the original message doesn't contain a
   Subject field.

5.4.  From

   Unless explicitly overridden with a :from parameter, the From field
   SHOULD be set to the address of the owner of the Sieve script.

5.5.  To

   The To field SHOULD be set to the address of the recipient of the
   response.

5.6.  Auto-Submitted

   An Auto-Submitted field with a value of "auto-replied" SHOULD be
   included in the message header of any vacation message sent.

5.7.  Message Body

   The body of the message is taken from the reason string in the
   vacation command.

5.8.  In-Reply-To and References

   Replies MUST have the In-Reply-To field set to the Message-ID of the
   original message, and the References field SHOULD be updated with the
   Message-ID of the original message.

   If the original message lacks a Message-ID, an In-Reply-To need not
   be generated, and References need not be changed.

   Section 3.6.4 of [RFC2822] provides a complete description of how
   References fields should be generated.
 

Showalter & Freed           Standards Track                    [Page 10]

RFC 5230               Sieve: Vacation Extension            January 2008

6.  Relationship to Recommendations for Automatic Responses to
    Electronic Mail

   The vacation extension implements a "Personal Responder" in the
   terminology defined in [RFC3834].  Care has been taken in this
   specification to comply with the recommendations of [RFC3834]
   regarding how personal responders should behave.

7.  Internationalization Considerations

   Internationalization capabilities provided by the base Sieve language
   are discussed in [RFC5228].  However, the vacation extension is the
   first Sieve extension to be defined that is capable of creating
   entirely new messages.  This section deals with internationalization
   issues raised by the use of the vacation extension.

   Vacation messages are normally written using the UTF-8 charset,
   allowing text to be written in most of the world's languages.
   Additionally, the :mime parameter allows specification of arbitrary
   MIME content.  In particular, this makes it possible to use
   multipart/alternative objects to specify vacation responses in
   multiple languages simultaneously.

   The Sieve language itself allows a vacation response to be selected
   based text-decoration: underline;">   require "vacation";
   if header :contains ["accept-language", "content-language"] "en"
   {
       vacation "I am away this week.";
   } else {
       vacation "Estoy ausente esta semana.";
   }

   Note that this rather simplistic test of the field values fails to
   take the structure of the fields into account and hence could be
   fooled by some more complex field values.  A more elaborate test
   could be used to deal with this problem.

   The approach of explicitly coding language selection criteria in
   scripts is preferred because in many cases language selection issues
   are conflated with other selection issues.  For example, it may be
   appropriate to use informal text in text-decoration: underline;"> 

Showalter & Freed           Standards Track                    [Page 11]

RFC 5230               Sieve: Vacation Extension            January 2008

   require "vacation";
   if address :matches "from" ""
   {
       vacation :subject "Gone fishing"
                "Having lots of fun! Back in a day or two!";
   } else {
       vacation :subject "Je suis parti cette semaine"
                "Je lirai votre message quand je retourne.";
   }

   IMPLEMENTATION NOTE: A graphical Sieve generation interface could in
   principle be used to hide the complexity of specifying response
   selection criteria from end users.  Figuring out the right set of
   options to present in a graphical interface is likely a nontrivial
   proposition, but this is more because of the need to employ a variety
   of criteria to select different sorts of responses to send to
   different classes of people than because of the issues involved in
   selecting a response in an appropriate language.

8.  Security Considerations

   It is critical that implementations correctly implement the behavior
   and restrictions described throughout this document.  Replies MUST
   NOT be sent out in response to messages not sent directly to the
   user, and replies MUST NOT be sent out more often than the :days
   argument states unless the script changes.

   If mail is forwarded from a site that uses subaddressing, it may be
   impossible to list all recipient addresses with ":addresses".

   Security issues associated with mail auto-responders are fully
   discussed in the security considerations section of [RFC3834].  This
   document is believed not to introduce any additional security
   considerations in this general area.

9.  IANA Considerations

   The following template specifies the IANA registration of the
   vacation Sieve extension specified in this document:

   To:
   Subject: Registration of new Sieve extension

   Capability name: vacation
   Description:     adds an action for generating an auto-reply saying
                    that the original message will not be read or
                    answered immediately
   RFC number:      RFC 5230

 

Showalter & Freed           Standards Track                    [Page 12]

RFC 5230               Sieve: Vacation Extension            January 2008

   Contact address: The Sieve discussion list <>

   This information has been added to the list of Sieve extensions given
   ">.

10.  References

10.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [RFC3834]  Moore, K., "Recommendations for Automatic Responses to
              Electronic Mail", RFC 3834, August 2004.

   [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, January 2008.

   [RFC5229]  Homme, K., "Sieve Email Filtering: Variables Extension",
              RFC 5229, January 2008.

10.2.  Informative References

   [REJECT]   Stone, A., Elvey, M., and A. Melnikov, "Sieve Email
              Filtering: Reject Extension", Work in Progress,
              October 2007.

   [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
              FUNCTIONS", RFC 2142, May 1997.

   [RFC2369]  Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
              for Core Mail List Commands and their Transport through
              Message Header Fields", RFC 2369, July 1998.

 

Showalter & Freed           Standards Track                    [Page 13]

RFC 5230               Sieve: Vacation Extension            January 2008

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2919]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
              and Namespace for the Identification of Mailing Lists",
              RFC 2919, March 2001.

   [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
              May 2002.

Showalter & Freed           Standards Track                    [Page 14]

RFC 5230               Sieve: Vacation Extension            January 2008

Appendix A.  Acknowledgements

   This extension is obviously inspired by Eric Allman's vacation
   program under Unix.  The authors owe a great deal to Carnegie Mellon
   University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil
   Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov,
   Jeffrey Hutzelman, Philip Guenther, and many others whose names have
   been lost during the inexcusably long gestation period of this
   document.

Authors' Addresses

   Tim Showalter

   EMail:

   Ned Freed (editor)
   Sun Microsystems
   3401 Centrelake Drive, Suite 410
   Ontario, CA  92761-1205
   USA

   Phone: [phone]
   EMail:
 

Showalter & Freed           Standards Track                    [Page 15]

RFC 5230               Sieve: Vacation Extension            January 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided text-decoration: underline;">Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   text-decoration: underline;">   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF ">.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   .