[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SMTP 521 Reply code
Does anyone know what happened to this draft proposal?
Was it ever placed on a standards track? Is it an RFC?
Thanks
Fletcher
> From owner-ietf-smtp@dimacs.rutgers.edu Tue Apr 5 13:44:30 1994
> From: John C Klensin <KLENSIN@infoods.mit.edu>
> Subject: Proposal for new SMTP error code
> To: ietf-smtp@dimacs.rutgers.edu
>
>
> --Boundary (ID kB7XnYPx9KHEDiBEd7kVSw)
> Content-type: TEXT/PLAIN; CHARSET=US-ASCII
>
> The attached is a proposal for a new SMTP error code that was received by
> the RFC editor and forwarded to Erik and myself. Comments should be sure
> to copy the authors. There is a strong possibility of this being placed
> on the standards track. Isd there consensus that doing so would be a
> good idea?
>
> john
>
> --Boundary (ID kB7XnYPx9KHEDiBEd7kVSw)
> Content-type: TEXT/PLAIN; CHARSET=US-ASCII
>
> Date: Tue, 5 Apr 1994 17:06:14 +0200 (MET DST)
> From: Alain Durand <Alain.Durand@inria.fr>
> Reply-To: Alain Durand <Alain.Durand@inria.fr>
> Subject: SMTP 521 Reply code, draft proposal
> To: rfc-editor@ISI.EDU
> Cc: alain.durand@inria.fr, francis.dupont@inria.fr
>
>
> Internet Engineering Task Force A. Durand, F. Dupont
> INTERNET-DRAFT INRIA Rocquencourt
> April, 1994
>
>
> SMTP 521 reply code
>
>
> 1. Status
>
> Distribution of this memo is unlimited.
>
> This document is an Internet Draft. 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.
> Internet Drafts may be updated, replaced, or obsoleted by other
> documents at any time. It is not appropriate to use Internet Drafts as
> reference material or to cite them other than as a ``working draft'' or
> ``work in progress.''
>
> Please check the 1id-abstracts.txt listing contained in the
> internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
> nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current
> status of any Internet Draft.
>
> 2. Abstract
>
> This memo defines the reply code 521 in the SMTP protocol whereby an
> Internet host may indicate it WILL NOT accept any mail.
>
> 3. Motivations
>
> In large sites it happens quite frequently that some computers connected
> to the Internet are dedicated to special tasks, such as NTP, NNTP or
> DNS services. Those hosts are generally lobotomized, very few users,
> if any, have accounts on them, and nobody is expected to ever received
> any mail. Such hosts generally do not run any SMTP server. However, it
> happens that people mistakenly send mail to such hosts! Why?
> Reasons are numerous: users confuse host names, the host used to be a
> well known one,... Usually the mails end up staying for days in spool
> directories before being sent back to the original senders with
> confusing error messages.
>
>
>
>
>
>
>
>
>
>
>
>
> Expires Octobre 1994 [Page 1]
>
> 4. 521 reply code
>
> A new reply code is needed to indicate that a host WILL NOT accept
> any mail. This is a permanent negative reply. According to RFC 821
> reply codes theory given in [1], this should be a 52z reply code. On
> the model of 421 reply code indicating ``MTA is not available'', it is
> proposed that this reply code will be ``521 Host is configured NOT to
> accept any mail.''.
>
> 5. Connection greeting
>
> A host may return ``521 Host is configured NOT to accept any mail.''
> instead of the usual initial ``220 Service ready'' indicating that it
> WILL NOT accept any mail.
>
> 6. Replies to SMTP commands
>
> A host may reply reply ``521 Host configured NOT to accept any mail.''
> to any SMTP command except for the ``QUIT'' command for which the reply
> code should be either 221 or 500 as stated in RFC 821.
>
> 7. Security considerations
>
> Running SMTP service on a dedicated computer might proved dangerous.
> Simply not accepting SMTP connections is by no means polite and leads
> to users annoyance and frustration. It also fills up spool directories,
> which can be exploited by an intruder as a ``service denial'' attack.
> Running a pseudo SMTP daemon replying ``521 Host is configured NOT to
> accept any mail.'' helps to solve those problems.
>
> 8. Implementation
>
> As an example, and explicitly without any warranty of usage, a very
> simple daemon written in Perl is given bellow. This daemon is largely
> inspired from the server example given in [2]. It is currently running
> on our NTP stratum 1 server, canon.inria.fr.
>
> #!/usr/local/bin/perl
> eval 'sub WNOHANG {1;}';
> eval 'sub SOL_SOCKET {0xffff;}';
> eval 'sub SO_REUSEADDR {0x0004;}';
> eval 'sub EINTR {4;}';
>
> $SIG{'CHLD'} = 'reapchild';
> $hostname="canon.inria.fr";
> $port = 25;
> $AF_INET = 2;
> $SOCK_STREAM = 1;
> $sockaddr = 'S n a4 x8';
> ($name, $aliases, $proto) = getprotobyname('tcp');
> $this = pack($sockaddr, $AF_INET, $port, "\0\0\0\0");
> select(NS); $| = 1; select(stdout);
> socket(S, $AF_INET, $SOCK_STREAM, $proto) || die "socket: $!";
> setsockopt(S, &SOL_SOCKET, &SO_REUSEADDR, "1");
> bind(S,$this) || die "bind: $!";
> listen(S,5) || die "connect: $!";
> select(S); $| = 1; select(stdout);
> Expires Octobre 1994 [Page 2]
>
>
> for(;;) {
> ($addr = accept(NS,S));
> if ($addr == -1) {
> if ($! == &EINTR) { next;}
> else {die "accept: $!";}
> }
> if (($childpid = fork()) == 0) {
> print NS "521 $hostname is configured NOT to accept any mail.\r\n";
> while (<NS>) {
> $cmd = $_;
> chop $cmd;
> if ($cmd =~ /^quit/i) {
> last;
> }
> else {
> print NS
> "521 $hostname is configured NOT to accept any mail.\r\n";
> }
> }
> print NS "221 $hostname\r\n";
> close(NS);
> exit;
> }
> close(NS);
> # wait;
> }
>
> sub reapchild{
> while (1) {
> $pid = waitpid(-1,$WNOHANG);
> last if ($pid < 1);
> }
> }
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Expires Octobre 1994 [Page 3]
>
> 9. Author addresses
>
> Alain Durand
> Institut National de Recherche en Informatique et en Automatique
> B.P. 105 / 78153 Le Chesnay CEDEX France
> Fax : +33 1 39 63 53 30
> Phone : +33 1 39 63 53 93
> E-Mail: Alain.Durand@inria.fr
>
> Francis Dupont
> Institut National de Recherche en Informatique et en Automatique
> B.P. 105 / 78153 Le Chesnay CEDEX France
> Fax : +33 1 39 63 53 30
> Phone : +33 1 39 63 52 13
> E-Mail: Francis.Dupont@inria.fr
>
>
> 10. References
>
> [1] J.B. Postel. Simple Mail Transfer Protocol, Request For Comments 821,
> STD 10, (August, 1982).
>
> [2] L. Wall, R. Schwartz. Programming Perl, O'Reilly and Associates Inc,
> (March 1992)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Expires Octobre 1994 [Page 4]
>
> --1430341959-2078917053-765558681:#3898--
>
>
> --Boundary (ID kB7XnYPx9KHEDiBEd7kVSw)--
>