ietf-asrg
[Top] [All Lists]

[Asrg] Internet Draft -- SMTP Postage Extension

2008-12-14 06:59:53
   There is an Internet Draft at

https://datatracker.ietf.org/drafts/draft-irtf-asrg-postage/

   (I don't think there's any automated posting to an IRTF WG.)

   I attach a HTML version.

--
John Leslie <john(_at_)jlc(_dot_)net>
 TOC 
Network Working GroupB. April
Internet-DraftTrendMicro
Intended status: ExperimentalJ. Leslie
Expires: June 16, 2009JLC.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.



Table of Contents

1.  Introduction
    1.1.  Purpose and applicability
    1.2.  Terminology
2.  Description of Extension
3.  Use of the POSTAGE extension
4.  Operational Considerations
    4.1.  Backwards compatibility considerations
    4.2.  Issuing tokens
    4.3.  Inter-Bank Agreements
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative references
    8.2.  Informative references
Appendix A.  Change log
    A.1.  Changes from draft-irtf-00 to -00
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction



 TOC 

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.



 TOC 

1.2.  Terminology

The uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" follow RFC2119.



 TOC 

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.



 TOC 

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 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 "<currency name>
0*(<comma><currency name>)
<colon>
"BANK="<bank name>
0*(<comma><bank name>)

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 "<currency name>
<colon>
<bank name>

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 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.



 TOC 

4.  Operational Considerations



 TOC 

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 transaction. Alternatively, it MAY accept without postage a limited number of transactions from a sending SMTP client it chooses to tentatively trust.



 TOC 

4.2.  Issuing tokens

Each POSTAGE domain-name bank MUST maintain a human-readable web page accessible by "http://<domain-name>" 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.)



 TOC 

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.

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://<source-bank domain-name>/exchange/<destination-bank domain-name>".

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.



 TOC 

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



 TOC 

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.



 TOC 

7.  Acknowledgements



 TOC 

8.  References



 TOC 

8.1. Normative references

[RFC5321] Klensin, J., “Simple Mail Transfer Protocol,” RFC 5321, October 2008 (TXT).


 TOC 

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 (TXT, HTML, XML).


 TOC 

Appendix A.  Change log

This appendix is intended to be removed by the RFC Editor when this document is published as an RFC.



 TOC 

A.1.  Changes from draft-irtf-00 to -00



 TOC 

Authors' Addresses

  Ben April
  TrendMicro
  22 North Meadow Road
  Amherst, NH 03031
  US
Email:  ben_april(_at_)trendmicro(_dot_)com
  
  John Leslie
  JLC.net
  10 Souhegan Street
  Milford, NH 03055
  US
Email:  john(_at_)jlc(_dot_)net
  
  Bart Schaefer
  iPost
  60 Galli Drive, Ste T
  Novato, CA 94949
  US
Email:  schaefer(_at_)ipost(_dot_)com


 TOC 

Full Copyright Statement

Intellectual Property

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg