Network Working Group B. April Internet-Draft TrendMicro Intended status: Experimental J. Leslie Expires: June 16, 2009 JLC.net B. Schaefer iPost December 13, 2008 An SMTP Extension for email postage draft-irtf-asrg-postage-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 16, 2009. Abstract The Anti-Spam Research Group is considering research into how operators of mail systems sometimes might want to pay for transmission of e-mail. This document details an extension to the SMTP email protocol for this purpose. April, et al. Expires June 16, 2009 [Page 1] Internet-Draft SMTP POSTAGE December 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose and applicability . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Description of Extension . . . . . . . . . . . . . . . . . . . 3 3. Use of the POSTAGE extension . . . . . . . . . . . . . . . . . 3 4. Operational Considerations . . . . . . . . . . . . . . . . . . 5 4.1. Backwards compatibility considerations . . . . . . . . . . 5 4.2. Issuing tokens . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Inter-Bank Agreements . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative references . . . . . . . . . . . . . . . . . . . 8 8.2. Informative references . . . . . . . . . . . . . . . . . . 8 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8 A.1. Changes from draft-irtf-00 to -00 . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 April, et al. Expires June 16, 2009 [Page 2] Internet-Draft SMTP POSTAGE December 2008 1. Introduction 1.1. Purpose and applicability This document defines an extension to the SMTP protocol to exchange postage charges for transport of email messages, through tokens issued by a "bank" acceptable to the receiving SMTP server. The receiving SMTP server lists currencies and banks it deals with in the EHLO response; the sending SMTP client chooses one currency and one bank in each MAIL command. The receiving server lists Postage Due in each response to a RCPT command; and the sending client includes a postage token in the DATA command. As with snail-mail postage, the postage charged is a transmission charge: the receiving SMTP server makes no representation about what may happen at the next step of the delivery chain. 1.2. Terminology The uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" follow RFC2119. 2. Description of Extension Name of SMTP extension: Email Postage EHLO keyword: POSTAGE keyword parameters: list of acceptable currency codes followed by a list of bank Domain-Names An optional parameter using the keyword "BANK" is added to the MAIL command. An optional parameter using the keyword "POSTAGE" is added to the DATA command. Several new SMTP response codes are added. A 254 response to RCPT and a 455 response to DATA are defined in Section 3. 3. Use of the POSTAGE extension A receiving SMTP server that supports the POSTAGE extension will respond to the EHLO command with the list of supported extensions including a line with the string POSTAGE followed by a list of April, et al. Expires June 16, 2009 [Page 3] Internet-Draft SMTP POSTAGE December 2008 acceptable currencies and a list of domain-names of postage-token- issuing banks with which it has an established relationship. Inclusion of this keyword establishes that the receiver supports the Email Postage extension. The EHLO extension-name line shall have the format: "POSTAGE " 0*() "BANK=" 0*() The currency name is the particular currency unit. Where the currency is listed in ISO-4217, that three-letter code SHOULD be used; otherwise the currency unit MUST be expressed as a domain (usually a top-level domain, but local domains are permitted), a slash, and the currency unit name. The MAIL command may include the keyword "BANK" followed by the selected currency code and the domain-name of the bank chosen by the sending SMTP client from the list of banks offered in the EHLO response. Inclusion of this keyword establishes that the sender supports the Email Postage extension. The MAIL keyword expression shall have the format: "BANK " A 254 response may be returned to any RCPT command, including the string "Postage Due:" followed by a floating-point number (not to exceed six characters, including the decimal point). The number presented after "Postage Due:" MUST represent the quantity of the currency code already negotiated (which cannot change during the SMTP transaction). For example 1.0000 would be one Dollar if USD were negotiated or one Euro if EUR were negotiated. This floating-point number is specific to the MAIL-FROM and the RCPT (as well as the IP address of the sending SMTP client), and would be zero in any case where the RCPT recipient had some other arrangement with the MAIL sender to cover any delivery charge. However, where no postage is requested, the "Postage Due:" string and parameters MUST NOT be used in response to the RCPT command. When there is more than one RCPT command in an SMTP transaction, the total postage due will be found by summing the amounts reported for April, et al. Expires June 16, 2009 [Page 4] Internet-Draft SMTP POSTAGE December 2008 each RCPT. All postage amounts for a single transaction MUST use the same currency unit. Alternatively, the response to any RCPT command may be a temporary error "455 You need to negotiate postage directly with that recipient", indicating that the recipient signals an unwillingness to impose any particular amount of postage issued by the MTA's bank, but is willing to negotiate conditions for accepting email (without MTA postage) from the sending SMTP server. The MTA issuing this error SHOULD be able to repeat the test of recipient willingness to see if those conditions have been met due to out-of-band negotiations during the SMTP session. The POSTAGE parameter to the DATA command SHOULD be followed by a token for the total postage due. If the DATA command contains no POSTAGE parameter, the receiving SMTP server MAY respond to the DATA command with "550 Cannot deliver without postage." The POSTAGE token returned by the bank will be an opaque string consisting of any ASCII letter or number [a-zA-Z0-9]. The token value is case-sensitive, so case must be preserved whenever it is copied. Postage tokens must not exceed 256 characters. The receiving SMTP server SHOULD present the token to the chosen bank before responding to the DATA command. If the token is not valid, the receiving SMTP server MUST respond with "550 Invalid postage token." If the token is valid, the receiving SMTP server MUST respond with "354 Go Ahead" or "550 Insufficient Postage". (The receiving SMTP server MUST accept the DATA for all or none of the RCPTs.) If the postage token exceeds the amount of postage due, any mechanism for credits or refunds is up to the bank, and is outside the scope of this protocol extension. 4. Operational Considerations 4.1. Backwards compatibility considerations The sending SMTP client MUST NOT send the "BANK" keyword on the MAIL command unless the receiving SMTP server has indicated support of this extension and listed at least one bank. The receiving SMTP server SHOULD NOT send the "Postage Due" response to the RCPT command unless the sending SMTP client has indicated a BANK on the preceding MAIL command. The receiving SMTP server MAY give the "Cannot deliver without postage" error if it has given a "Postage Due" response during that April, et al. Expires June 16, 2009 [Page 5] Internet-Draft SMTP POSTAGE December 2008 transaction. Alternatively, it MAY accept without postage a limited number of transactions from a sending SMTP client it chooses to tentatively trust. 4.2. Issuing tokens Each POSTAGE domain-name bank MUST maintain a human-readable web page accessible by "http://" describing to non-customers how to purchase tokens it issues. This may involve setting up a new account and/or recommending a consortium of banks which will facilitate the transfer of payment from an account at another bank. Each POSTAGE bank MUST run a service to issue postage tokens in any requested amount of an agreed currency name. The tokens will be opaque strings to all parties except the issuing bank. Payment for tokens MUST be acceptable in the named currency, and MAY be accepted in other currencies and/or non-currency units. The POSTAGE bank has no responsibility to do any particular currency- exchange process, except to respond to offers of a different currency with a floating-point number or a refusal to exchange in that other currency. Any mechanisms for actual transfer of government currency are outside the scope of this protocol extension. The intent is that any top-level country-code domain MAY be used to define the available currency choices, but the POSTAGE Domain-Name need not support all the currency units so defined. Alternatively, any domain-local "currency", whether or not convertible into some government-issued money, may be used as a currency-name. Whether the token represents actual value already paid or authorizes deduction of that amount from some existing account is outside the scope of this protocol. In either case, the first customer to present the token SHOULD receive the appropriate credit. (Note that the receiving SMTP server will not know the value of the token and will need to supply the number and currency units that it presumes the sending SMTP client has agreed to.) 4.3. Inter-Bank Agreements It is not practical to expect any one bank to meet the needs of all senders and receivers. We expect banks to create agreements whereby one bank is willing to accept and clear tokens issued by another bank. The nature and administrative process of any such agreement is not within the scope of this document. In order to publish such an agreement, the receiving bank the MUST process the tokens with no manual steps. April, et al. Expires June 16, 2009 [Page 6] Internet-Draft SMTP POSTAGE December 2008 Senders will encounter requests for postage due where the list of banks offered does not include a bank that they have an existing relationship with. To assist in such cases, any bank the sender is registered with MAY publish a list of banks with which it has an existing Inter-Bank Agreement. Access to this list MAY be limited to registered customers. Banks SHOULD make this information accessible by "http:///exchange/". A reply code of 200 or 204 to such a HTTP query indicates that the destination bank is willing to accept tokens issued by the source bank; reply code 404 indicates that the two banks do not have an established relationship. The source bank MAY provide a newline delimited list of the currency codes permitted by the inter-bank agreement. 5. IANA Considerations This document requests that IANA add "POSTAGE" to the list of registered SMTP Service Extensions: http://www.iana.org/assignments/mail-parameters 6. Security Considerations This extension intends to allow the transfer of currency value during SMTP sessions. The SMTP client and server may wish to use TLS to secure the amounts involved. The token passed from client to server has meaning only to the sending client and the receiving server's bank: neither the receiving server nor anyone intercepting the SMTP session can know what value (if any) it carries. Nonetheless, it would be possible in principle for an interceptor to present it to the receiver's bank before the receiver does. We assume that the receiver's bank will somehow ensure that its presentation can only serve to credit the appropriate account. 7. Acknowledgements 8. References April, et al. Expires June 16, 2009 [Page 7] Internet-Draft SMTP POSTAGE December 2008 8.1. Normative references [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. 8.2. Informative references [ISO.4217.1981] International Organization for Standardization, "Codes for the representation of currencies and funds", ISO Standard 4217, 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Appendix A. Change log This appendix is intended to be removed by the RFC Editor when this document is published as an RFC. A.1. Changes from draft-irtf-00 to -00 Authors' Addresses Ben April TrendMicro 22 North Meadow Road Amherst, NH 03031 US Email: ben_april@trendmicro.com John Leslie JLC.net 10 Souhegan Street Milford, NH 03055 US Email: john@jlc.net April, et al. Expires June 16, 2009 [Page 8] Internet-Draft SMTP POSTAGE December 2008 Bart Schaefer iPost 60 Galli Drive, Ste T Novato, CA 94949 US Email: schaefer@ipost.com April, et al. Expires June 16, 2009 [Page 9] Internet-Draft SMTP POSTAGE December 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 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 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 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 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 on-line IPR repository at http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. April, et al. Expires June 16, 2009 [Page 10]