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 "<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
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://<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.)
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://<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.
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]