分享
 
 
 

RFC2442 - The Batch SMTP Media Type

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group N. Freed

Request for Comments: 2442 D. Newman

Category: Informational Innosoft

J. Belissent

Sun Microsystems

M. Hoy

Mainbrace

November 1998

The

Batch SMTP

Media Type

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

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

Abstract

This document defines a MIME content type suitable for tunneling an

ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable

transport. This type can be used for a variety of purposes,

including: Extending end-to-end MIME-based security services (e.g.,

[RFC-1847]) to cover message envelope information as well as message

content. Making it possible to use specific SMTP extensions sUCh as

NOTARY [RFC-1891] over unextended SMTP transport infrastructure.

Enabling the transfer of multiple separate messages in a single

transactional unit.

Requirements Notation

This document occasionally uses terms that appear in capital letters.

When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"

appear capitalized, they are being used to indicate particular

requirements of this specification. A discussion of the meanings of

the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the

terms "MUST NOT" and "SHOULD NOT" are logical extensions of this

usage.

The Application/batch-SMTP Content Type

The "application/batch-SMTP" MIME content type is a container for the

client side of an SMTP or ESMTP transaction. In keeping with

traditional SMTP, the contents are line oriented and CRLF line

terminators MUST be used.

The "application/batch-SMTP" type is defined as follows:

Media type name: application

Media suBType name: batch-SMTP

Required parameters: none

Optional parameters: required-extensions

Encoding considerations:

8bit material may appear, so quoted-printable or base64

encoding may be necessary on transports that do not

support 8bit. While the content of this type is

line-oriented and uses conventional CR/LF terminators,

lines longer than 7bit and 8bit encodings allow (998

octets) may appear, hence quoted-printable or

base64 encoding may be necessary even in conjunction

with 8bit transports.

Security considerations:

Discussed in the Security Considerations Section.

How application/batch-SMTP is used

The following diagram illustrates how the application/batch-SMTP type

is intended to be used:

application/batch-SMTP object

+----------------+

+-----------+ v +----------+ v +-----------+

batch MIME- batch

=> SMTP => capable => SMTP =>

generator transport processor

^ +-----------+ +----------+ +-----------+ ^

+-- conventional SMTP/RFC822 message transaction --+

A conventional SMTP message transaction is converted into an

application/batch-SMTP object by the batch SMTP generator. This

object is then carried over some type of MIME-capable transport. Once

the destination is reached the object is presented to a batch SMTP

processor, which converts the application/batch-SMTP object back into

a conventional SMTP message transaction.

Generation of application/batch-SMTP material

Application/batch-SMTP material is generated by a specially modified

SMTP client operating without a corresponding SMTP server. The client

simply assumes a successful response to all commands it issues. The

resulting content then consists of the collected output from the SMTP

client.

Honoring SMTP restrictions

Most batch SMTP processors will be constructed by modifying and

extending existing SMTP servers. As such, all of the restrictions on

SMTP constructs imposed by RFC821, RFC1123, and RFC1869 MUST be

observed. In particular, restrictions on command and data line

lengths, number of recipients, and so on still exist and apply to

batch SMTP.

Use of SMTP Extensions

Since no SMTP server is present the client must be prepared to make

certain assumptions about which SMTP extensions can be used. The

generator MAY assume that ESMTP [RFC-1869] facilities are available,

that is, it is acceptable to use the EHLO command and additional

parameters on MAIL FROM and RCPT TO. If EHLO is used MAY assume that

the 8bitMIME [RFC-1652], SIZE [RFC-1870], and NOTARY [RFC-1891]

extensions are available. In particular, NOTARY SHOULD be used. MAY

create private bilateral agreements which specify the availability of

additional SMTP extensions. Additional SMTP extensions MUST NOT be

used in the absence of such an agreement, and, perhaps more

importantly, a conformant generation of application/batch-SMTP

objects MUST be able to produce objects restricted to use of the

extensions listed above.

The "required-extensions" content type parameter MAY be used to

communicate a list of the extensions actually used, specified as a

comma-separated list of EHLO responses. If absent it defaults to the

list "8bitMIME,SIZE,NOTARY". Any use by private bilateral agreement

of additional or different extensions MUST be noted in the

"required-extensions" parameter.

Note that many SMTP extensions simply do not make sense in the

context of batch SMTP. For example, the pipelining extension [RFC-

2197] makes no sense in the absence of a network connection.

Handling Multiple Messages

Generators SHOULD attempt to minimize the number of messages placed

in a single application/batch-SMTP object. Ideally a single

application/batch-SMTP object will be created for each message. Note,

however, that some uses of application/batch-SMTP (e.g., mail

bagging) may exist solely to take advantage of the multiple messages

in a single container capability of batch SMTP, so requiring one

message per container is not possible.

DISCUSSION: The SMTP protocol provides for the transfer of a series

of messages over a single connection. This extends in a natural way

to batch SMTP. However, the issues in batch SMTP are somewhat

different. Suppose, for example, that a batch SMTP processor receives

an application/batch-SMTP object containing two messages but is

unable to process the second message because of a storage allocation

failure. But suppose that not only does this failure preclude

processing of the second message, it also precludes recording that

the first message has already been processed. Subsequent reprocessing

of the application/batch-SMTP could then lead to duplication of the

first message.

This issue is not materially different from the well-known problems

with SMTP synchronization that in practice often lead to duplicated

messages. Since this behavior is inherent in SMTP to begin with it is

not incumbent on application/batch-SMTP to completely address the

issue. Nevertheless, it seems prudent for application/batch-SMTP to

try and not make matters even worse.

Transport of application/batch-SMTP objects

Application/batch-SMTP objects may be transported by any transport

capable of preserving their MIME labelling, e.g., HTTP or SMTP.

Transports MUST remain cognizant of the special nature of

application/batch-SMTP. An application/batch-SMTP object contains one

or more "frozen" SMTP message transactions. SMTP message transactions

typically carry with them various assumptions about quality of

service, e.g., that messages will either be delivered successfully or

a nondelivery notification will be returned, that a nondelivery

notification will be returned if delivery cannot be accomplished in a

timely fashion, and so on. It is vital that the encapsulation of

these objects for carriage over other forms of transport not

interfere with these capabilities.

Processing of application/batch-SMTP material

Processing of application/batch-SMTP material is considerably more

complex than generating it. As might be eXPected, a modified

SMTP/ESMTP processor is used. However, since it cannot return

information to the client, it must handle all error conditions that

arise itself. In other Words, a batch SMTP processor assumes both the

responsibilities of a traditional SMTP server as well as part of the

responsibilities of a traditional SMTP client.

As such, a conforming processor: MUST check MIME content type

information to insure that the material it has been presented with is

labelled as application/batch-SMTP and doesn't specify any extensions

the processor doesn't support in the "required-extensions" parameter.

Application/batch-SMTP objects that employ an unsupported extension

SHOULD be forwarded to the local postmaster for manual inspection and

handling. MUST accept any syntactically valid EHLO or HELO command.

MUST accept any syntactically valid MAIL FROM command. A conforming

processor, MAY, if it so desires, note the unacceptability of some

part of a given MAIL FROM command and use this information to

subsequently generate non-delivery notifications for any or all

recipients. MUST accept any syntactically valid RCPT TO command. A

conforming processor SHOULD note the unacceptability of some part of

a given RCPT TO command and subsequently use this information to

generate a non-delivery notification for this recipient in lieu of

actually delivering the message. MUST accept any of the additional

parameters defined by the 8bitMIME, SIZE, and NOTARY SMTP extensions

on the MAIL FROM and RCPT TO commands. MUST accept the DATA command

even when no valid recipients are present. 8bit MIME messages MUST be

accepted. MUST accept the RSET command and handle multiple messages

in a single application/batch-SMTP object. Processors MUST process

each message in an application/batch-SMTP object once and SHOULD take

whatever steps are necessary to avoid processing a message more than

once. For example, if processing of an application/batch-SMTP object

containing multiple messages is interrupted at an intermediate point

it should subsequently be restarted at the end of the last message

that was completely processed. SHOULD forward any syntactically

invalid application/batch-SMTP message to the local postmaster for

manual inspection and handling.

Security Considerations

Application/batch-SMTP implements a tunneling mechanism. In general

tunneling mechanisms are prone to abuse because they may provide a

means of bypassing existing security restrictions. For example, an

application/batch-SMTP tunnel implemented over an existing SMTP

transport may allow someone to bypass relay restrictions imposed to

block redistribution of spam.

Application/batch-SMTP processors SHOULD implement Access

restrictions designed to limit access to the processor to authorized

generators only. (Note that this facility may be provided

automatically if application/batch-SMTP is being used to secure

message envelope information.)

Acknowledgements

The general concept of batch SMTP has been around for a long time.

One particular type of batch SMTP was defined by Alan Crosswell and

used on BITNET to overcome BITNET's native 8 character limit on user

and host names. However, this form of batch SMTP differed from the

current proposal in that it envisioned having the server return the

status code responses to the client. In this case the client bore the

burden of correlating responses with the original SMTP dialogue after

the fact.

Unfortunately this approach proved not to work well in practice.

BITNET eventually switched to the same basic form of batch SMTP that

has been defined here. Unfortunately that definition was, to the best

of the present authors' knowledge, never captured in a formal

specification. It should also be noted that the definition given here

also differs in that it takes SMTP extensions into account.

Einar Stefferud had previously considered the problem of carrying

extended SMTP messages over unextended SMTP transports. He proposed

that some form of "double enveloping" technology be developed to

address this problem. The mechanism presented here effectively

implements the type of solution he proposed.

References

[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10,

RFC821, August 1982.

[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet

Text Messages", STD 11, RFC822 August 1982.

[RFC-1123] Braden, B., "Requirements for Internet Hosts --

Application and Support", STD 3, RFC1123, October 1989.

[RFC-1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.

Crocker, "SMTP Service Extension for 8bit-MIMEtransport",

RFC1652, July 1994.

[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,

"Security Multiparts for MIME: Multipart/Signed and

Multipart/Encrypted", RFC1847, October 1995.

[RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.

Crocker, "SMTP Service Extensions", STD 10, RFC1869,

November 1995.

[RFC-1870] Klensin, J., Freed, N., Moore, K., "SMTP Service Extension

for Message Size Declaration", STD 10, RFC1870, November,

1995.

[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part One: Format of Internet Message

Bodies", RFC2045, December 1996.

[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part Two: Media Types", RFC2046,

December 1996.

[RFC-2197] Freed, N. and A. Cargille, "SMTP Service Extension for

Command Pipelining", RFC2197, September 1997.

Authors' Addresses

Ned Freed

Innosoft International, Inc.

1050 Lakes Drive

West Covina, CA 91790

USA

Phone: +1 626 919 3600

Fax: +1 626 919 3614

EMail: ned.freed@innosoft.com

Dan Newman

Innosoft International, Inc.

1050 Lakes Drive

West Covina, CA 91790

USA

Phone: +1 626 919 3600

Fax: +1 626 919 3614

EMail: dan.newman@innosoft.com

Mark Hoy

Mainbrace Corporation

1136 West Evelyn Avenue

Sunnyvale, CA 94086

tel: +1 408 774 5265

fax: +1 408 774 5290

email: mark.hoy@mainbrace.com

Jacques Bellisent

SunSoft

Phone: +1 650 786 3630

EMail: jacques.belissent@eng.sun.com

Full Copyright Statement

Copyright (C) The Internet Society (1998). 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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有