INTERNET DRAFT                                           M. S. Kucherawy
Title: draft-kucherawy-sender-auth-header-02              Sendmail, Inc.
Expires: November 2005                                          May 2005



       Message Header for Indicating Sender Authentication Status


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This memo defines a new message header for use with [MAIL] messages
   to indicate the results of sender authentication efforts to mail user
   agents (MUAs) in order to equip them to relay that information in a
   convenient way to users.

Table of Contents




Kucherawy                Expires September 2005         [Page 1]

 
Internet-Draft    Message Sender Authentication Header        March 2005


.  Introduction


   This memo defines a new message header for [MAIL] messages which
   presents the results of a sender authentication effort in a machine-
   readable format.  The intent is to create a place to collect such
   data when sender authentication mechanisms are in use so that an MUA
   can provide a recommendation to the user as to the trustworthiness of
   the message's origin and content.

   This memo defines both the format of this new header, and discusses
   the implications of its presence or absence.

   At the time of publication of this draft, only [AUTH] is a published
   sender authentication standard.  However, several more are in the
   Internet Draft stage.  As various methods emerge, it is necessary to
   prepare their appearance and encourage convergence in the area of
   interfacing these filters to MUAs.


1.1.  Purposes


   The header defined in this memo is expected to serve several pur-
   poses:

(1)  Convey to MUAs from filters and MTAs the results of various sender
     authentication checks being applied;

(2)  Provide a common location for the presentation of this data;

(3)  Create an extensible framework for specifying new authentication
     methods as such emerge.

(4)  Convey the results of sender authentication tests to later filter-
     ing agents within the same "trust domain", as such agents might
     apply more or less stringent checks based on sender authentication
     results.


1.2.  Requirements


   This memo establishes no new requirements on existing protocols or
   servers, as there is currently not a standard place for the described
   data to be collected or presented.





Kucherawy                Expires September 2005         [Page 2]

 
Internet-Draft    Message Sender Authentication Header        March 2005


1.3.  Terminology


   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
   NOT", and "MAY" appear capitalized, they are being used to indicate
   particular requirements of this specification.  A discussion of the
   meanings of these terms appears in RFC2119.

   Generally it is assumed that the work of applying sender authentica-
   tion schemes takes place at a border MTA, that is, an MTA which acts
   as a gateway between the general Internet and the users within an
   organizational boundary.  This specification is written with that
   assumption in mind.  However, there are some sites at which the
   entire mail infrastructure consists of a single host.  In such cases,
   such terms as "border MTA" and "delivery MTA" may well apply to the
   same machine or even the very same agent.



.  Definition and Format of the Header


   The new header being defined here is called "Authentication-Results".
   It qualifies in [MAIL] terms as a Structured Header Field, and thus
   all of the related definitions in that document apply.

   The decommented value of the header consists of a hostname, some
   whitespace, a "property=value" statement indicating which property
   was selected to determine who sent the message and what value was
   extracted from that property, followed by zero or more authentication
   method names and a result associated with each, returned by the code
   that implements the method.

   As it is currently a matter of some debate, the header MAY appear
   more than once in a single message, or more than one result MAY be
   represented in a single header, or a combination of these MAY be
   applied.


   Formally, the header is specified as follows:


   header = "Authentication-Results" CFWS ":" CFWS hostname CFWS
             headerspec *(CFWS ";" CFWS method CFWS "=" CFWS result)
             CFWS

   hostname = domain



Kucherawy                Expires September 2005         [Page 3]

 
Internet-Draft    Message Sender Authentication Header        March 2005


              ; as defined in section 3.4.1 of [MAIL]

   method = token
            ; a method indicates which method's result is
            ; is represented by "value", and is one of the methods
            ; explicitly defined as valid in this document
            ; or is an extension method as defined below

   result = "pass" / "fail" / "softfail" / "neutral" /
             "temperror" / "permerror"
             ; an indication of the results of the attempt to
             ; authenticate the sender

   token = ; as defined in Appendix A of [MIME]

   CFWS = ; as defined in section 3.2.3 of [MAIL]

   headerspec = ptype CWFS "." CWFS property CWFS "=" CFWS value
                ; an indication of which property of the message
                ; was evaluated by the authentication scheme being
                ; applied to yield the reported result

   ptype = "smtp" / "header"
           ; indicates whether the property being evaluated was
           ; a parameter to an SMTP command or was a value taken
           ; from a message header

   property = token
              ; if "ptype" is "smtp", this indicates which SMTP command
              ; provided the value which was evaluated by the
              ; authentication scheme being applied, or if "ptype" is
              ; "header", this indicates from which header the value
              ; being evaluated was extracted

   value = token / mailbox
           ; the value extracted from the message property defined
           ; by the "ptype.property" construction; if the value is
           ; intended ; to identify a mailbox, then it is a "mailbox"
           ; as defined in section 3.4 of [MAIL]


   The "ptype" and "property" are case-insensitive.

   If the parsed "ptype.property" construction clearly identifies a
   mailbox (in particular, smtp.mail, smtp.rcpt, header.from,
   header.sender), then the "value" must be a "mailbox".  Other proper-
   ties (e.g. smtp.helo) may be evaluated, but the property MUST still
   be expressed as a "token" for simplified parsing.



Kucherawy                Expires September 2005         [Page 4]

 
Internet-Draft    Message Sender Authentication Header        March 2005


   The six possible values of the "result" are:

pass
        sending domain publishes an authentication policy of some kind,
        and the message passed the authentication tests

fail
        sending domain publishes an authentication policy of some kind,
        and the message failed the authentication tests

softfail
        sending domain publishes an authentication policy which doesn't
        require authentication of all messages from that domain, and the
        message failed the authentication tests

neutral
        sending domain does not publish any sender authentication policy

temperror
        a temporary (recoverable) error occurred attempting to authenti-
        cate the sender; either the process couldn't be completed
        locally because of some transient condition, or there was a tem-
        porary failure retrieving the sending domain's policy; a later
        attempt to re-authenticate this message might produce a more
        final result

permerror
        a permanent (unrecoverable) error occurred attempting to authen-
        ticate the sender; either the process couldn't be completed
        locally, or there was a permanent failure retrieving the sending
        domain's policy


.  Definition Of The "auth" Method


   As it is currently an existing standard for sender authentication, it
   is appropriate to define an authentication method identifier for
   [AUTH].  The authentication method identifier "auth" is thus defined
   for MTAs applying that standard for sender authentication.




.  Adding The Header To A Message


   This specification makes no attempt to evaluate the relative



Kucherawy                Expires September 2005         [Page 5]

 
Internet-Draft    Message Sender Authentication Header        March 2005


   strengths of various sender authentication methods that may become
   available.  As such, the order of the presented authentication meth-
   ods and results are not relevant since ultimately the importance on
   any given method over another is the decision of the MUA that is
   interpreting the value of the header.

   The "method" MUST refer to an authentication method declared in this
   memo, or in a subsequent one, or to an authentication method name
   assigned by IANA.

   If an MTA applies any authentication test, it MUST add this header to
   indicate at which host the test was done, which test got applied, and
   what the result was.  If an MTA applies more than one such test, it
   MUST either add this header once per test, or one header indicating
   all of the results.  An MTA MUST NOT add a result to an existing
   header.

   An MTA adding this header in either form MUST use its own hostname
   only.  It MUST be a fully-qualified domain name.

   For security reasons, an MTA SHOULD remove any discovered instance of
   this header for which the "hostname" is its own, i.e. headers which
   claim to be from the MTA but were added before the mail arrived at
   the MTA for processing.  A border MTA MAY also delete any discovered
   instance of this header which claims to have been added within its
   trust boundary.  For example, a border MTA at mx.example.com SHOULD
   delete any instance of this header claiming to come from mx.exam-
   ple.com and MAY delete any instance of this header claiming to come
   from any host in example.com prior to adding its own headers.  This
   applies in both directions so that hosts outside the domain cannot
   claim results MUAs inside the domain might trust.

   An MTA compliant with this specification MUST add this header after
   performing one or more sender authentication tests.  An MTA MAY add
   this header containing only the "hostname" portion to explicitly
   indicate that no sender authentication schemes were applied prior to
   delivery of this message.


4.1.  Header Position and Interpretation


   In order to ensure non-ambiguous results and avoid the impact of
   false headers, an MUA SHOULD NOT interpret this header unless specif-
   ically instructed to do so by the user.  That is, this should not be
   "on by default".  Naturally then, users would not activate such a
   feature unless they are certain the header will be added by the
   receiving MTA that accepts the mail which is ultimately read by the



Kucherawy                Expires September 2005         [Page 6]

 
Internet-Draft    Message Sender Authentication Header        March 2005


   MUA, and instances of the header added by foreign MTAs will be
   removed before delivery.

   Furthermore, an MUA SHOULD NOT interpret this header unless the host-
   name it bears appears to be one within its own trust domain as con-
   figured by the user.

   An MTA adding a header MUST add the header at the top of the message
   so that there is generally some indication upon delivery of where in
   the chain of handling MTAs the sender authentcation was done.

   Further discussion of this can be found in the Security Considera-
   tions section below.


4.2.  Extension Fields


   Additional authentication method identifiers may be defined in the
   future by later revisions or extensions to this specification.
   Extension identifiers beginning with "x-" will never be defined as
   standard fields; such names are reserved for experimental use.
   Method identifiers NOT beginning with "x-" MUST be registered with
   the Internet Assigned Numbers Authority (IANA) and published in an
   RFC.

   Extension identifiers may be defined for the following reasons:


(a)  To allow additional information from emergent authentication sys-
     tems to be communicated to MUAs.  The names of such identifiers
     should reflect the name of the method being defined, but should not
     be needlessly long.

(b)  To allow the creation of "sub-identifiers" which indicate different
     levels of authentication and differentiate between their relative
     strengths, e.g. "auth1-weak" and "auth1-strong".

   Authentication method implementors are encouraged to provide adequate
   information, via [MAIL] comments if necessary, to allow an MUA devel-
   oper to understand or relay ancilliary details of authentication
   results.  For example, if it might be of interest to relay what data
   was used to perform an evaluation, such information could be relayed
   as a comment in the header, such as:

   Authentication-Results: mx.example.com; foo=yes (2 out of 3 tests
   passed)




Kucherawy                Expires September 2005         [Page 7]

 
Internet-Draft    Message Sender Authentication Header        March 2005


.  Discussion



   This section discusses various implementation issues not specifically
   related to security.  Security issues are discussed in a later sec-
   tion.



5.1.  Legacy MUAs


   Implementors of this proposal should be aware that many MUAs are
   unlikely to be retrofit to support the new header and its semantics.
   In the interests of convenience and quicker adaptation, a delivery
   MTA might want to consider adding things that are processed by exist-
   ing MUAs as well as the header defined by this specification.  One
   suggestion is to provide a Priority: header with a value that
   reflects the strength of the authentication that was accomplished,
   e.g. "low" for weak or no authentication, "normal" or "high" for good
   authentication.

   Certainly some modern MUAs can filter based on the content of this
   header, but as there is keen interest in having MUAs make some kind
   of graphical representation of this header's meaning, other interim
   means of doing so may be necessary while this proposal is adopted.



5.2.  Trusting The Header


   Rather than the coding rigor of doing a digital signature on the con-
   tent of this header, it may be sufficient to establish a maximum SMTP
   path length between the addition of the header and final delivery.
   The path length is defined as the count of Received headers above the
   Authentication-Results header.  If more than that maximum path length
   is traversed between insertion of the header and delivery, the value
   of the header should no longer be trusted to be valid.

   This requires a configurable MUA setting to define this maximum path
   length.  The setting would need to take into account possible addi-
   tional hops should the final delivery server be unavailable.
   Although this approach likely bears a much shorter time to implement,
   it is a less general solution than the proposed one and would proba-
   bly require additional user education above the norm and thus lead to
   more confusion on deployment.  The MUA SHOULD trust this header if it



Kucherawy                Expires September 2005         [Page 8]

 
Internet-Draft    Message Sender Authentication Header        March 2005


   is trusting such headers and the path length after the addition of
   the header is less than three.




.  Conformance and Usage Requirements


   An MTA or gateway conforms to this specification if it applies one or
   more sender authentication mechanisms and inserts a header corre-
   sponding to this standard after doing so and prior to delivery.

   MTAs that are relaying mail rather than delivering it MAY perform
   sender authentication or even take actions based on the results
   found, but MUST NOT add a "Authentication-Results" header if relaying
   rather than rejecting or discarding at the gateway.  Conversely, an
   MTA doing local delivery MUST add this header prior to delivery the
   message in order to be compliant.

   A minimal implementation which does at least one sender authentica-
   tion check will add the header defined by this memo prior to invoking
   local delivery procedures.

   This specification places no restrictions on the processing of the
   header's contents by user agents or distribution lists.  It is pre-
   sented to those packages solely for their own information.


.  IANA Considerations


   Following the policies outlined in [IANA-CONSIDERATIONS], names of
   sender authentication methods supported by this specification must be
   registered with IANA under the IETF Consensus method, with the excep-
   tion of experimental names as defined above.


.  Security Considerations


   The following security considerations apply when applying or process-
   ing the "Authentication-Results" header:








Kucherawy                Expires September 2005         [Page 9]

 
Internet-Draft    Message Sender Authentication Header        March 2005


8.1.  Non-conformant MTAs


   An MUA that is aware of this specification which accesses a mailbox
   whose mail is handled by a non-conformant MTA is in a position to
   make false conclusions based on forged headers.  A malicious user or
   agent could forge a header using the destination MX for a receiving
   domain as the hostname token in the value of the header, and with the
   rest of the value claim that the sender was properly authenticated.
   The non-conformant MTA would fail to strip the forged header, and the
   MUA could trust it.

   It is for this reason an MUA SHOULD NOT have processing of the
   "Authentication-Results" header enabled by default; instead it must
   be ignored, at least for the purposes of enacting filtering deci-
   sions, unless specifically enabled by the user after verifying that
   the MTA is compliant.  It is acceptable to have an MUA aware of this
   standard, but have an explicit list of hostnames whose "Authentica-
   tion-Results" headers are trustworthy, but this list SHOULD initially
   be empty.

   Proposed alternate solutions to this problem are nascent.  Possibly
   the simplest is a digital signature on the header which can be veri-
   fied by a posted public key.  Another would be a means to interrogate
   the MTA that added the header to see if it is actually providing any
   sender authentication services and saw the message in question.  In
   either case, a method needs to exist to verify that the host which
   appears to have added the header (a) actually did so, and (b) is
   legitimately adding that header for this delivery.



8.2.  Header Position



   Headers can sometimes be reordered enroute by intermediate MTAs.  The
   goal of requiring header addition only at the top of a message is an
   acknowledgement that some MTAs do reorder headers, but most do not.
   Thus, in the general case, there will be some indication of which
   MTAs (if any) handled the message after the addition of the header
   defined here.

   However, this is not universally true.  In an environment involving
   an MTA that does reorder headers, the above-mentioned hop count test
   for header validity may not be possible.





Kucherawy                Expires September 2005        [Page 10]

 
Internet-Draft    Message Sender Authentication Header        March 2005


.  Appendix - Authentication-Results Examples

   This section presents some examples of the use of this header to
   indicate authentication results.  It makes use of some authentication
   methods which are still in the draft phase, namely "domainkeys",
   "sender-id" and "spf".  These are not IANA-registered or otherwise
   formally defined, but they are presented here under the assumption
   that they eventually will be.


9.1.  Trivial case; header not present


   The trivial case:

     From: sender@example.com
     Received: from mail-router.example.com
                   (mail-router.example.com [1.2.3.4])
               by server.sendmail.com (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@sendmail.com
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

   The "Authentication-Results" header is completely absent.  The MUA
   may make no conclusion about the validity of the message.  This could
   be the case because the sender authentication services were not
   available at the time of delivery, or no service is provided, or the
   MTA is not in compliance with this specification.


9.2.  Nearly-trivial case; service provided, but no authentication done


   A message that was delivered by an MTA which conforms to this stan-
   dard but provides no actual sender authentication service:

     Authentication-Results: mail-router.example.com
               header.from=sender@example.com
     From: sender@example.com
     Received: from mail-router.example.com
                   (mail-router.example.com [1.2.3.4])
               by server.sendmail.com (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;



Kucherawy                Expires September 2005        [Page 11]

 
Internet-Draft    Message Sender Authentication Header        March 2005


               Fri, Feb 15 2002 17:19:07 -0800
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@sendmail.com
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

   The "Authentication-Results" header is present, indicating the deliv-
   ering MTA (which is named in the value of the header) conforms to
   this specification.  The absence of any method and result tokens
   indicates no sender authentication was done.


9.3.  Service provided, authentication done


   A message that was delivered by an MTA which conforms to this stan-
   dard and applied some sender authentication:

     Authentication-Results: mail-router.example.com
               smtp.mail=sender@example.com; auth=pass (cram-md5)
     From: sender@example.com
     Received: from dialup-1-2-3-4.example-isp.com
                   (dialup-1-2-3-4.example-isp.com [1.2.3.4])
               by mail-router.example.com (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@sendmail.com
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

   The "Authentication-Results" header is present, indicating the deliv-
   ering MTA (which is named in the value of the header) conforms to
   this specification.  Furthermore, the sender authenticated her-
   self/himself to the MTA via a method specified in [AUTH].  The actual
   method is identified in a header comment after the method's result is
   indicated.  The MUA could extract and relay this extra information if
   desired.


9.4.  Service provided, several authentications done, single MTA


   A message that was relayed inbound via a single MTA which conforms to



Kucherawy                Expires September 2005        [Page 12]

 
Internet-Draft    Message Sender Authentication Header        March 2005


   this standard and applied two different sender authentication checks:

     Authentication-Results: mail-router.example.com
               smtp.mail=sender@example.com;
               auth=pass (cram-md5); spf=pass
     Authentication-Results: mail-router.example.com
               header.from=sender@example.com; sender-id=pass
     From: sender@example.com
     Received: from mail-router.example.com
                   (mail-router.example.com [1.2.3.4])
               by dialup-1-2-3-4.example-isp.com (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@sendmail.com
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

   The "Authentication-Results" header is present, indicating the deliv-
   ering MTA (which is named in the value of the header) conforms to
   this specification.  Furthermore, the sender authenticated her-
   self/himself to the MTA via a method specified in [AUTH], and both
   SPF and Sender-ID checks were done and passed.  The MUA could extract
   and relay this extra information if desired.

   Two "Authentication-Results" headers are required because the methods
   applied did not all base their results on the same property of the
   message.


9.5.  Service provided, several authentications done, different MTAs


   A message that was relayed inbound by two different MTAs which con-
   form to this standard and applied multiple sender authentication
   checks:

     Authentication-Results: auth-checker.example.com
               header.from=sender@example.com; sender-id=pass;
               domainkeys=pass (good signature)
     Received: from mail-router.example.com
                   (mail-router.example.com [10.11.12.13])
               by auth-checker.example.com (8.11.6/8.11.6)
                   with ESMTP id i7PK0sH7021929;
               Fri, Feb 15 2002 17:19:22 -0800
     Authentication-Results: mail-router.example.com



Kucherawy                Expires September 2005        [Page 13]

 
Internet-Draft    Message Sender Authentication Header        March 2005


               smtp.mail=sender@example.com; auth=pass (cram-md5);
               spf=fail
     Received: from dialup-1-2-3-4.example-isp.com
                   (dialup-1-2-3-4.example-isp.com [1.2.3.4])
               by mail-router.example.com (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     DomainKey-Signature: a=rsa-sha1; s=gatsby; d=sendmail.com;
               c=simple; q=dns;
               b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
     From: sender@example.com
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@sendmail.com
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

   The "Authentication-Results" header is present, indicating confor-
   mance to this specification.  It is present twice because two differ-
   ent MTAs in the chain of delivery did authentication tests.  The
   first, "mail-router.example.com" reports that [AUTH] and SPF were
   both used and [AUTH] passed but SPF failed.  In the [AUTH] case,
   additional data is provided in the comment field, which the MUA can
   choose to render if desired.  The second MTA, "auth-checker.exam-
   ple.com", reports that it did a Sender-ID test and a DomainKeys test,
   both of which which passed.  Again, additional data about one of the
   tests is provided as a comment, which the MUA may choose to render.


.  Acknowledgements


   The author wishes to acknowledge the following for their review and
   constructive criticism of this proposal: Mark Delany and Miles Libbey
   of Yahoo! Inc., Jim Fenton of Cisco, and Rand Wacker and Eric Allman
   of Sendmail, Inc.

.  References


   Normative:


[AUTH]
     Myers, J., "SMTP Service Extention for Authentication", RFC 2554,
     Netscape Communications, March 1999.




Kucherawy                Expires September 2005        [Page 14]

 
Internet-Draft    Message Sender Authentication Header        March 2005


[IANA-CONSIDERATIONS]
     Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Con-
     siderations Section in RFCs", RFC 2434, October 1998.

[MAIL]
     Resnick, P. (editor), "Internet Message Format", RFC 2822, Qual-
     comm, Inc., April 2001.

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

[SMTP]
     J. Klensin, (editor), "Simple Mail Transfer Protocol", RFC 2821,
     April 2001

.  Author's Address:


   Murray S. Kucherawy
   Sendmail, Inc.
   6425 Christie Ave., 4th Floor
   Emeryville, CA
   94608
   USA

   Comments may be sent to msk+ietf@sendmail.com.


.  Copyright Notice



   Copyright (C) The Internet Society (year).  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 on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.






Kucherawy                Expires September 2005        [Page 15]