GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2852

Network Working Group D. Newman Request for Comments: 2852 Sun Microsystems Updates: 1894 June 2000 Category: Standards Track

                 Deliver By SMTP Service 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.

Copyright Notice

 Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

 This memo defines a mechanism whereby a SMTP client can request, when
 transmitting a message to a SMTP server, that the server deliver the
 message within a prescribed period of time.  A client making such a
 request also specifies the message handling which is to occur if the
 message cannot be delivered within the specified time period: either
 the message is to be returned as undeliverable with no further
 processing, or a "delayed" delivery status notification (DSN) [6] is
 to be issued.
 This extension should not be viewed as a vehicle for requesting
 "priority" processing.  A receiving SMTP server may assign whatever
 processing priority it wishes to a message transmitted with a Deliver
 By request.  A Deliver By request serves to express a message's
 urgency and to provide an additional degree of determinancy in its
 processing.  An indication of an urgent message's status within a
 given time period may be requested and will be honored.  Moreover,
 the message may be withdrawn if not delivered within that time
 period.
 A typical usage of this mechanism is to prevent delivery of a message
 beyond some future time of significance to the sender or recipient
 but not known by the MTAs handling the message.  For instance, the
 sender may know that the message will be delivered as a page but does
 not consider the message to be sufficiently important as to warrant
 paging the recipient after business hours. In that case, the message
 could be marked such that delivery attempts are not made beyond

Newman Standards Track [Page 1] RFC 2852 Deliver By SMTP Service Extension June 2000

 17:00.  Another common usage arises when a sender wishes to be
 alerted to delivery delays.  In this case, the sender can mark a
 message such that if it is not delivered within, say, 30 minutes, a
 "delayed" DSN is generated but delivery attempts are nonetheless
 continued.  In this case the sender has been allowed to express a
 preference for when they would like to learn of delivery problems.

1. Definitions

 Throughout this document, the term "deliver" is taken to mean the act
 of transmitting a message to its "final" destination by a message
 transport agent (MTA).  Usually, but not always, this means storing
 or otherwise handing off the message to the recipient's mailbox.
 Thus, an MTA which accepts a message to be delivered within a
 specified time period is agreeing to store or handoff the message to
 the recipient's mailbox within the specified time period.  Outside
 the scope of the term "deliver" are any user-specified actions which
 might take place after the MTA stores or hands off the message; e.g.,
 user-programmed filters which, often unbeknownst to the MTA, resend
 the message to some other location.
 The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in this
 document are to be interpreted as described in RFC 2119 [7].

2. Framework for the Deliver By SMTP service extension

 The Deliver By SMTP service extension uses the SMTP service extension
 mechanism described in [4].  The following SMTP service extension is
 therefore defined:
 (1)  The name of the SMTP service extension is "Deliver By".
 (2)  The EHLO keyword value associated with this service extension is
      "DELIVERBY".
 (3)  One optional parameter is allowed with this EHLO keyword value.
      The optional parameter, when supplied, is a comma separated list
      of options.  Only one option, a min-by-time, is specified in
      this document.  Future documents may extend this specification
      by specifying additional options.  The min-by-time is a fixed
      integer indicating the fixed minimum by-time that the server
      will accept when a by-mode of "R" is specified as per Section 4.
      The syntax of the optional parameter is as follows, using the
      augmented BNF notation of RFC 2234 [2]:

Newman Standards Track [Page 2] RFC 2852 Deliver By SMTP Service Extension June 2000

    deliverby-param = min-by-time *( ',' extension-token )
    min-by-time     = [1*9DIGIT]
    extension-token = 1*<any CHAR excluding SP, COMMA and all control
                         characters (US ASCII 0-31 inclusive)>
    SP               = <the space character (ASCII decimal code 32)>
    COMMA            = <the comma character (ASCII decimal code 44)>
      If the parameter is omitted, no information is conveyed about
      the server's fixed minimum by-time.
 (4)  One optional parameter using the keyword "BY" is added to the
      MAIL FROM command.
 (5)  The maximum length of a MAIL FROM command line is increased by
      17 characters by the possible addition of the BY keyword and
      value.
 (6)  No additional SMTP verbs are defined by this extension.

3. The Deliver By SMTP service extension

 A SMTP client wishing to use the Deliver By SMTP service extension
 may issue the EHLO command to start a SMTP session and to determine
 if the SMTP server supports the service extension.  If the server
 responds with code 250 to the EHLO command, and the response includes
 the EHLO keyword DELIVERBY, then the Deliver By SMTP service
 extension is supported by the server.
 If a numeric parameter follows the DELIVERBY keyword value of the
 EHLO response then that parameter indicates the minimum value allowed
 for the by-time when a by-mode of "R" is specified with the extended
 MAIL FROM command as described in Section 4.  Any attempt by a client
 to specify a by-mode of "R" and a by-time strictly less than this
 limit, min-by-time, will be rejected with a permanent failure (55z)
 reply code.
 A SMTP server that supports the Deliver By SMTP service extension
 will accept the extended version of the MAIL FROM command described
 in Section 4.  When supported by the server, a SMTP client may use
 the extended MAIL FROM command (instead of the MAIL FROM command
 described in [1]) to request that the message be delivered within the
 specified time period.  The server may then return an appropriate
 error code if it determines that the request cannot be honored.  Note
 that this may not be apparent to the server until either presentation
 of the recipient addresses with RCPT TO commands or completion of the
 transfer of the message data with the dot (.) command.  As such, the

Newman Standards Track [Page 3] RFC 2852 Deliver By SMTP Service Extension June 2000

 server may send to the client a success response to the MAIL FROM
 command only to later return an error response to the RCPT TO, DATA,
 or dot command.

4. The extended MAIL FROM command

 The extended MAIL FROM command is issued by a SMTP client when it
 wishes to inform a SMTP server that a message is to be delivered
 within a specified period of time and further what action to take
 should the message prove undeliverable within that time period.  The
 extended MAIL FROM command is identical to the MAIL FROM command as
 defined in RFC 821 [1], except that a BY parameter appears after the
 address.
 The complete syntax of this extended command is defined in [4].  The
 esmtp-keyword is "BY" and the syntax for the esmtp-value is given by
 the syntax for by-value shown below.  In the augmented BNF of RFC
 2234 [2], the syntax for the BY esmtp-parameter is
 by-parameter = "BY="by-value
 by-value     = by-time";"by-mode[by-trace]
 by-time      = ["-" / "+"]1*9digit ; a negative or zero value is not
                                    ; allowed with a by-mode of "R"
 by-mode      = "N" / "R"           ; "Notify" or "Return"
 by-trace     = "T"                 ; "Trace"
 Note that the BY esmtp-keyword MUST have an associated esmtp-value.
 The by-time is a decimal representation of the number of seconds
 within which the message should be delivered and has the range
  1. 999,999,999 seconds ⇐ by-time ⇐ +999,999,999 seconds
 and is thus sufficient to represent a time anywhere from
 approximately 31.6 years in the past to 31.6 years in the future.
 As described in Section 4.1, the by-mode indicates the action the
 SMTP server must take should it not be possible to transmit the
 message within by-time seconds.
 Note that by-time is a delta time: the number of seconds within which
 to deliver the message.  This delta time does not extend an MTA's
 normal retention period for undeliverable messages nor is it a
 "deliver after" time.
 A delta time is used so as to prevent problems associated with
 differences in system clocks between clients and servers.  Servers in
 receipt of a valid by-parameter are expected to convert the by-time
 into a locale-specific absolute time called the deliver-by-time.

Newman Standards Track [Page 4] RFC 2852 Deliver By SMTP Service Extension June 2000

 This is done by adding the by-time upon receipt to the current
 locale-specific time and thereby arriving at a locale-specific
 absolute time which is by-time seconds in the future or past,
 depending upon the arithmetic sign of by-time.  The message is then
 to be delivered by the deliver-by-time.  The sending client and
 receiving server should assume the transmission time of the MAIL FROM
 command to be instantaneous.  Clearly, it will not be and network
 latency will introduce an error, the nature of which will be to
 extend slightly the effective by-time. The more hops the message
 takes, the more pronounced the effect will be owing to the cumulative
 nature of this latency-induced error.
 In the case of a by-mode of "N", it is possible that by-time may be
 zero or negative.  This is not an error and should not be rejected as
 such.  It indicates a message for which the deliver-by-time occurred
 -(by-time) seconds in the past.  [Here, "-(by-time)" represents the
 arithmetic negation of the by-time value.]  Zero and negative values
 are allowed so as to preserve information about any requested
 delivery time information -- information which the delivering MTA may
 wish to include with the delivered message for the benefit of the
 recipient or to show in a DSN or NDN (non delivery notification).
 In the case of a by-mode of "R", a zero or negative by-time is a
 syntax error. In such a case, the SMTP server SHOULD return a
 permanent failure (501) SMTP reply code in response to the extended
 MAIL FROM command.  If the SMTP server also supports enhanced error
 codes [8], then an enhanced error code of 5.5.4 SHOULD also be
 returned.
 If the by-time is a valid by-time specification but the SMTP server
 cannot honor or accept it for a server-specific reason, then SMTP
 server SHOULD respond with either a 455 SMTP response if the
 condition is transient or a 555 SMTP response if the condition is
 permanent. In addition, if the SMTP server also supports [8], a
 suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned.

4.1. Server behavior upon receipt of the extended MAIL FROM command

 Upon receipt of an extended MAIL FROM command containing a valid BY
 parameter, a SMTP server and associated MTA must handle the message
 in accord with the following subsections, Sections 4.1.1-4.1.5.
 Delivery status notifications generated in response to processing a
 message with a Deliver By request should include both the optional
 Arrival-Date DSN field as well as the new Deliver-By-Date DSN field
 described in Section 5 of this memo.

Newman Standards Track [Page 5] RFC 2852 Deliver By SMTP Service Extension June 2000

 A by-time Note that a message's by-time does not extend the MTA's
 normal message retention period: an MTA MAY return a message as
 undeliverable before the deliver-by-time has been reached.

4.1.1. Successful delivery

 If the message is delivered before deliver-by-time, no special action
 need be taken.  If the SMTP server or MTA also supports the Delivery
 Status Notification SMTP service extension [5] and a NOTIFY parameter
 including "SUCCESS" was specified, a "delivered" DSN with appropriate
 status must be returned as per [5].

4.1.2. Unsuccessful delivery; deliver-by-time not yet reached

 If deliver-by-time has not yet passed and the message has proved
 undeliverable for temporary reasons, then the SMTP server or MTA
 should continue delivery or relay attempts as per the site's message
 handling policy.  If the MTA's message retention period is less than
 by-time, the MTA MAY return the message as undeliverable before
 deliver-by-time has been reached.  However, the message MUST still be
 handled in accord with Sections 4.1.1-4.1.5.
 If deliver-by-time has not yet passed and the message cannot be
 delivered for permanent reasons, then the SMTP server or MTA MUST
 return a "failed" DSN with an appropriate status for each recipient
 address with either no NOTIFY parameter specified or for which the
 NOTIFY parameter includes "FAILURE".

4.1.3. Time has expired; deliver-by-time reached or passed

 If the message is not delivered or relayed before deliver-by-time and
 a by-mode of "R" was specified, no further delivery attempts may be
 made for the message.  The server or MTA MUST issue a "failed" DSN
 with status 5.4.7, "delivery time expired", for each recipient
 address with either no NOTIFY parameter specified or for which the
 NOTIFY parameter includes "FAILURE".
 If the message is not delivered or relayed before deliver-by-time and
 a by-mode of "N" was specified, the server or MTA should continue
 attempts to deliver or relay the message using the site's message
 handling policy.  In addition, the server or MTA MUST issue a
 "delayed" DSN with status 4.4.7, "delivery time expired", for each
 recipient address with either no NOTIFY parameter specified or for
 which the NOTIFY parameter includes "DELAY".

Newman Standards Track [Page 6] RFC 2852 Deliver By SMTP Service Extension June 2000

4.1.4. Relaying to another SMTP server

 Sections 4.1.4.1 and 4.1.4.2 below describe when a message with a
 Deliver By request may be relayed to another SMTP server and what
 additional actions, if any, should or must be taken.  In addition to
 that discussed in those sections, the following must also be observed
 when relaying is permitted.
 If the message is relayed to a SMTP server that supports the Deliver
 By extension, a new BY parameter MUST be relayed specifying a by-time
 value indicating the number of seconds remaining until deliver-by-
 time.  The new by-time value should be computed as close to the time
 the MAIL FROM command is transmitted by the relaying SMTP client as
 is reasonably possible. Note that if deliver-by-time has passed, the
 relayed by-time will be a negative value indicating how may seconds
 has elapsed since delivery-by-time.  Such a case -- relay of a
 message for which deliver-by-time has just arrived or passed -- may
 only happen with a message that has a by-mode of "N".
 When a message with a by-trace field with value "T" is relayed, a
 "relayed" DSN SHOULD be generated by the relaying SMTP client for
 each recipient which either did not specify a NOTIFY parameter or the
 NOTIFY parameter does not have the value "NEVER".
 Note that these "relayed" DSNs are generated regardless of whether
 success notifications were explicitly requested with a NOTIFY=SUCCESS
 parameter.  Note further that the "relayed" DSNs discussed here are
 not terminal notifications:  downstream SMTP servers and MTAs may
 still support [5] and as such additional notifications may still
 result.

4.1.4.1. Relaying a message with a by-mode of "R"

 A message for which a by-mode of "R" was specified MUST NOT be
 relayed to a SMTP server which does not support the Deliver By SMTP
 service extension.  Moreover, the server to which it is relayed MUST
 NOT have a fixed minimum by-time which is greater than the time
 remaining in which the message is to be delivered.  The fixed minimum
 by-time is expressed by the optional deliverby-param discussed in
 Section 2.
 If the message requires relaying in order to be delivered yet cannot
 be relayed, then the message is deemed to be undeliverable for
 permanent reasons and Section 4.1.2 should be applied.

Newman Standards Track [Page 7] RFC 2852 Deliver By SMTP Service Extension June 2000

4.1.4.2. Relaying a message with a by-mode of "N"

 A message with a by-mode of "N" may be relayed to another server
 regardless of whether or not the SMTP server to which it is relayed
 supports the Deliver By extension.
 If the message is relayed before deliver-by-time to a SMTP server
 that does not support the Deliver By extension, then the relaying
 SMTP client MUST issue a "relayed" DSN for each recipient which
 either did not specify a NOTIFY parameter or the NOTIFY parameter
 does not have the value "NEVER". Further, if the SMTP server being
 relayed to supports the Delivery Status Notification SMTP service
 extension [5] then for each recipient: if no NOTIFY parameter was
 supplied, "NOTIFY=FAILURE,DELAY" SHOULD be requested; if a NOTIFY
 parameter was specified and does not have the value "NEVER", "DELAY"
 SHOULD be added to the list of notify-list-element values if not
 already present.  Note that this explicitly overrides the "MUST NOT"
 wording of Section 6.2.1(c) of [5].

4.1.5. Relaying to a foreign mail system

 If the foreign mail system supports semantics similar to the Deliver
 By SMTP service extension described in this memo, then convey the
 Deliver By request to that system.  Otherwise, relay the message as
 if relaying to a SMTP server which does not support the Deliver By
 extension.

5. Delivery status notifications and extension

 The format of delivery status notifications (DSNs) is specified in
 [6].  DSNs generated in response to a Deliver By request should
 include an Arrival-Date DSN field.  This memo also extends the per-
 message-fields of [6] to include a new DSN field, Deliver-By-Date,
 indicating the deliver-by-time as computed by the MTA or SMTP server
 generating the DSN.  In the augmented BNF of RFC 822 [2], per-
 message-fields is therefore extended as follows:
   per-message-fields =
       [ original-envelope-id-field CRLF ]
       reporting-mta-field CRLF
       [ dsn-gateway-field CRLF ]
       [ received-from-mta-field CRLF ]
       [ arrival-date-field CRLF ]
       [ deliver-by-date-field CRLF ]
       *( extension-field CRLF )
   deliver-by-date-field = "Deliver-by-date" ":" date-time

Newman Standards Track [Page 8] RFC 2852 Deliver By SMTP Service Extension June 2000

 where date-time is a RFC 822 [2] date-time field as ammended by RFC
 1123 [3].

6. Examples

 In the following sample SMTP dialog, the SMTP client requests that a
 message from <eljefe@bigbiz.com> be delivered to
 <topbanana@other.com> within 2 minutes (120 seconds) and returned
 otherwise.  This request takes the form of a BY parameter on the MAIL
 FROM line of "BY=120;R" as shown below:
   S: 220 acme.net SMTP server here
   C: EHLO bigbiz.com
   S: 250-acme.net
   S: 250 DELIVERBY
   C: MAIL FROM:<eljefe@bigbiz.com> BY=120;R
   S: 250 <eljefe@bigbiz.com> sender ok
   C: RCPT TO:<topbanana@other.com>
   S: 250 <topbanana@wherever.com> recipient ok
 Suppose now that the receiving SMTP server in the above example needs
 to relay the message to another SMTP server, mail.other.com.  Owing
 to the original by-mode of "R", the message may only be relayed to
 another SMTP server which supports the Deliver By extension (Section
 4.1.4).  Further, when relaying the message, the Deliver By request
 must be relayed.  With this in mind, consider the following SMTP
 dialog:
   S: 220 mail.other.com ESMTP server at your service
   C: EHLO acme.net
   S: 250-mail.other.com
   S: 250 DELIVERBY 240
   C: QUIT
 In the above dialog, the relaying SMTP server, acme.net, connects to
 mail.other.com and issues an EHLO command.  It then learns that the
 Deliver By extension is supported but that the minimum by-time for a
 by-mode of "R" is 4 minutes (240 seconds).  This value exceeds the
 message's original by-time and therefore necessarily exceeds the
 remaining by-time.  The relaying SMTP server thus ends the SMTP
 session after which it must either attempt to follow any other MX
 records or, if there are no more MX records to follow, must return
 the message as undeliverable.  Similar behavior would result if the
 EHLO command was met with an error or did not include the DELIVERBY
 keyword.
 Consider instead, the relaying SMTP session:

Newman Standards Track [Page 9] RFC 2852 Deliver By SMTP Service Extension June 2000

   S: 220 mail.other.com ESMTP server at your service
   C: EHLO acme.net
   S: 250-mail.other.com
   S: 250 DELIVERBY 30
   C: MAIL FROM:<eljefe@bigbiz.com> BY=98;R
   S: 250 <eljefe@bigbiz.com> Sender okay
   C: RCPT TO:<topbanana@other.com>
   S: 250 <topbanana@wherever.com> Recipient okay
 In the above, the relaying SMTP client relays the BY parameter with
 the by-mode preserved and the by-time computed to be the remaining
 number of seconds at the approximate time that the MAIL FROM command
 was transmitted from the relaying SMTP client (acme.net) to the
 receiving SMTP server (mail.other.com).  In this example, 22 seconds
 have elapsed since acme.net received the MAIL FROM line from the
 original sending client and relayed the Deliver By request to
 mail.other.com.

7. MX based relaying considerations

 Sites which wish to use the Deliver By SMTP service extension and
 which direct their mail via MX records [9] need to ensure that all of
 their MX hosts -- hosts to which their mail is directed by MX records
 -- support the Deliver By extension. SMTP clients which support
 Deliver By SHOULD NOT attempt multiple MX hosts looking for one which
 supports Deliver By.
 MX hosts should pay careful attention to the min-by-time value they
 present in response to EHLO commands.  It is not practical for an MX
 host to present a value which either (1) is substantially different
 from that which can be handled by the destination host to which it
 relays, or (2) doesn't recognize normal delivery latencies introduced
 when the MX host relays mail to the destination host.

8. Security Considerations

 Implemention of Deliver By allows tracing of a mail transport system.
 The by-trace field "T" explicitly requests that a trace be generated.
 Moreover, even when the by-trace field is not used, a crude trace may
 be generated by entering a series of messages into the transport
 system, each with successively increasing by-time values; e.g.,
 "BY=0;R", "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can
 be accomplished through other means: querying the visible SMTP
 servers, investigating Received: header lines in bounced messages,
 and using utilities such as "traceroute".

Newman Standards Track [Page 10] RFC 2852 Deliver By SMTP Service Extension June 2000

9. Other Considerations

 SMTP servers which support the Deliver By SMTP service extension as
 well as their associated MTAs are not required to assign any special
 processing priority to messages with Deliver By requests.  Of course,
 some SMTP servers and MTAs may do so if they desire.  Moreover,
 delivery status notifications generated in response to messages with
 Deliver By requests are not required to receive any special
 processing.  Consequently, users of this service should not, in
 general, expect expedited processing of their messages.  Moreover,
 just because a message is sent with a "BY=60;R" parameter does not
 guarantee that the sender will learn of a delivery failure within any
 specified time period as the DSN will not necessarily be expedited
 back to sender.

10. Acknowledgments

 The author wishes to thank Keith Moore for providing much of the
 initial impetus for this document as well as the basic ideas embodied
 within it.  Further thanks are due to Ned Freed and Chris Newman for
 their reviews of this document and suggestions for improvement.

Newman Standards Track [Page 11] RFC 2852 Deliver By SMTP Service Extension June 2000

11. References

 [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
      August 1982.
 [2]  Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997.
 [3]  Braden, R., Editor, "Requirements for Internet Hosts --
      Application and Support", STD 3, RFC 1123, October 1989.
 [4]  Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed,
      "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
 [5]  Moore, K., "SMTP Service Extension for Delivery Status
      Notifications", RFC 1891, January 1996.
 [6]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
      Delivery Status Notifications", RFC 1894, January 1996.
 [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [8]  Freed, N., "SMTP Service Extension for Returning Enhanced Error
      Codes", RFC 2034, October 1996.
 [9]  Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
      974, January 1986.

12. Author's Address

 Dan Newman
 Sun Microsystems, Inc.
 1050 Lakes Drive, Suite 250
 West Covina, CA  91790
 USA
 Phone: +1 626 919 3600
 Fax:   +1 626 919 3614
 EMail:  dan.newman@sun.com

Newman Standards Track [Page 12] RFC 2852 Deliver By SMTP Service Extension June 2000

13. Full Copyright Statement

 Copyright (C) The Internet Society (2000).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Newman Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2852.txt · Last modified: 2000/06/09 19:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki