分享
 
 
 

RFC2142 - Mailbox Names for Common Services, Roles and Functions

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

Network Working Group D. Crocker

Request for Comments: 2142 Internet Mail Consortium

Category: Standards Track May 1997

MAILBOX NAMES FOR

COMMON SERVICES, ROLES AND FUNCTIONS

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

ABSTRACT

This specification enumerates and describes Internet mail addresses

(mailbox name @ host reference) to be used when contacting personnel

at an organization. Mailbox names are provided for both operations

and business functions. Additional mailbox names and aliases are not

prohibited, but organizations which support email exchanges with the

Internet are encouraged to support AT LEAST each mailbox name for

which the associated function exists within the organization.

1. RATIONALE AND SCOPE

Various Internet documents have specified mailbox names to be used

when reaching the operators of the new service; for example, [RFC822

6.3, C.6] requires the presence of a <POSTMASTER@domain> mailbox name

on all hosts that have an SMTP server. Other protocols have defacto

standards for well known mailbox names, sUCh as <USENET@domain> for

NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]).

Defacto standards also exist for well known mailbox names which have

nothing to do with a particular protocol, e.g., <ABUSE@domain> and

<TROUBLE@domain>.

The purpose of this memo is to aggregate and specify the basic set of

mailbox names which organizations need to support. Most

organizations do not need to support the full set of mailbox names

defined here, since not every organization will implement the all of

the associated services. However, if a given service is offerred,

then the associated mailbox name(es) must be supported, resulting in

delivery to a recipient appropriate for the referenced service or

role.

If a host is not configured to accept mail directly, but it

implements a service for which this specification defines a mailbox

name, that host must have an MX RR set (see [RFC974]) and the mail

exchangers specified by this RR set must recognize the referenced

host's domain name as "local" for the purpose of accepting mail bound

for the defined mailbox name. Note that this is true even if the

advertised domain name is not the same as the host's domain name; for

example, if an NNTP server's host name is DATA.RAMONA.VIX.COM yet it

advertises the domain name VIX.COM in its "Path:" headers, then mail

must be deliverable to both <USENET@VIX.COM> and

<USENET@DATA.RAMONA.VIX.COM>, even though these addresses might be

delivered to different final destinations.

The scope of a well known mailbox name is its domain name. Servers

accepting mail on behalf of a domain must accept and correctly

process mailbox names for that domain, even if the server, itself,

does not support the associated service. So, for example, if an NNTP

server advertises the organization's top level domain in "Path:"

headers (see [RFC977]) the mail exchangers for that top level domain

must accept mail to <USENET@domain> even if the mail exchanger hosts

do not, themselves, serve the NNTP protocol.

2. INVARIANTS

For well known names that are not related to specific protocols, only

the organization's top level domain name are required to be valid.

For example, if an Internet service provider's domain name is

COMPANY.COM, then the <ABUSE@COMPANY.COM> address must be valid and

supported, even though the customers whose activity generates

complaints use hosts with more specific domain names like

SHELL1.COMPANY.COM. Note, however, that it is valid and encouraged

to support mailbox names for sub-domains, as appropriate.

Mailbox names must be recognized independent of character case. For

example, POSTMASTER, postmaster, Postmaster, PostMaster, and even

PoStMaStEr are to be treated the same, with delivery to the same

mailbox.

Implementations of these well known names need to take account of the

eXPectations of the senders who will use them. Sending back an

automatic mail acknowledgement is usually helpful (though we suggest

caution against the possibility of "duelling mail robots" and the

resulting mail loops).

3. BUSINESS-RELATED MAILBOX NAMES

These names are related to an organization's line-of-business

activities. The INFO name is often tied to an autoresponder, with a

range of standard files available.

MAILBOX AREA USAGE

----------- ---------------- ---------------------------

INFO Marketing Packaged information about the

organization, products, and/or

services, as appropriate

MARKETING Marketing Product marketing and

marketing communications

SALES Sales Product purchase information

SUPPORT Customer Service Problems with product or

service

4. NETWORK OPERATIONS MAILBOX NAMES

Operations addresses are intended to provide recourse for customers,

providers and others who are experiencing difficulties with the

organization's Internet service.

MAILBOX AREA USAGE

----------- ---------------- ---------------------------

ABUSE Customer Relations Inappropriate public behaviour

NOC Network Operations Network infrastructure

SECURITY Network Security Security bulletins or queries

5. SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES

For major Internet protocol services, there is a mailbox defined for

receiving queries and reports. (Synonyms are included, here, due to

their extensive installed base.)

MAILBOX SERVICE SPECIFICATIONS

----------- ---------------- ---------------------------

POSTMASTER SMTP [RFC821], [RFC822]

HOSTMASTER DNS [RFC1033-RFC1035]

USENET NNTP [RFC977]

NEWS NNTP Synonym for USENET

WEBMASTER HTTP [RFC2068]

WWW HTTP Synonym for WEBMASTER

UUCP UUCP [RFC976]

FTP FTP [RFC959]

6. MAILING LIST ADMINISTRATION MAILBOX

Mailing lists have an administrative mailbox name to which add/drop

requests and other meta-queries can be sent.

For a mailing list whose submission mailbox name is:

<LIST@DOMAIN>

there MUST be the administrative mailbox name:

<LIST-REQUEST@DOMAIN>

Distribution List management software, such as MajorDomo and

Listserv, also have a single mailbox name associated with the

software on that system -- usually the name of the software -- rather

than a particular list on that system. Use of such mailbox names

requires participants to know the type of list software employed at

the site. This is problematic. Consequently:

LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED,

INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE

MAILBOX NAMES.

7. DOMAIN NAME SERVICE ADMINISTRATION MAILBOX

In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of

Authority record (SOA RR) has a field for specifying the mailbox name

of the zone's administrator.

This field must be a simple Word without metacharacters (such as "%"

or "!" or "::"), and a mail alias should be used on the relevant mail

exchanger hosts to direct zone administration mail to the appropriate

mailbox.

For simplicity and regularity, it is strongly recommended that the

well known mailbox name HOSTMASTER always be used

<HOSTMASTER@domain>.

8. AUTONOMOUS SYSTEM MAILBOX

Several Internet registries implement mailing lists for Autonomous

System contacts. So, for example, mail sent to <AS3557@RA.NET> will

at the time of this writing reach the technical contact for

Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and

[RFC1656]).

Not all Autonomous Systems are registered with all registries,

however, and so undeliverable mailbox names under this scheme should

be treated as an inconvenience rather than as an error or a standards

violation.

9. SECURITY CONSIDERATIONS

Denial of service attacks (flooding a mailbox with junk) will be

easier after this document becomes a standard, since more systems

will support the same set of mailbox names.

10. REFERENCES

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

821, Information Sciences Institute, August 1982.

[RFC822] Crocker, D., "Standard for the format of ARPA Internet text

messages", STD 11, RFC822, University of Delaware, August 1982.

[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",

STD 9, RFC959, Information Sciences Institute, October 1985.

[RFC974] Partridge, C., "Mail routing and the domain system", STD 14,

RFC974, CSNET CIC BBN Laboratories Inc, January 1986.

[RFC976] Horton, M., "UUCP mail interchange format standard", RFC

976, Bell Laboratories, February 1986.

[RFC977] Kantor, B., et al, "Network News Transfer Protocol: A

Proposed Standard for the Stream-Based Transmission of News", RFC

977, University of California, February 1986.

[RFC1033] Lottor, M., "Domain administrators operations guide", RFC

1033, SRI International, November 1987.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",

STD 13, RFC1035, USC/Information Sciences Institute, November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation and

Specification" STD 13, RFC1035, USC/Information Sciences Institute,

November 1987.

[RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)",

RFC1654, T.J. Watson Research Center, IBM Corp., July 1994.

[RFC1655] Rekhter, Y., et al, "Application of the Border Gateway

Protocol in the Internet", RFC1655, T.J. Watson Research Center, IBM

Corp., July 1994.

[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and

Implementation Experience", RFC1656, cisco Systems, July 1994.

[HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol --

HTTP/1.0", RFC1945, May 1996.

11. ACKNOWLEDGEMENTS

This specification derived from an earlier draft written by Paul

Vixie. Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D.

Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and

Ed Morin for their comments on that draft.

12. AUTHOR'S ADDRESS

Dave Crocker

Internet Mail Consortium

127 Segre Ave.

Santa Cruz, CA

Phone: +1 408 246 8253

EMail: dcrocker@imc.org

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
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- 王朝網路 版權所有