Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!ucselx.sdsu.edu!bionet!turbo.bio.net!lear From: lear@turbo.bio.net (Eliot) Newsgroups: comp.mail.sendmail Subject: Re: A general question of mailers Message-ID: Date: 27 May 90 05:23:47 GMT References: <9300002@ux1.cso.uiuc.edu> Organization: GenBank Computing Resource for Mol. Biology Lines: 31 To: phil@ux1.cso.uiuc.edu Actually, if you look at RFC 821 (page 36), the following replies are allowed for mail: MAIL S: 250 F: 552, 451, 452 E: 500, 501, 421 S is the success code, F is for failure, and E is for a protocol error. 250 Requested mail action okay, completed 421 Service not available, closing transmission channel 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient system storage Strictly speaking, RFC 821 doesn't call for address validation, and in fact doesn't allow for it. There was some discussion about this topic years ago (closer to when RFC 821 was written) when some TOPS-20 machines did return path validation. The argument then was that such validation should not occur, due to imperfections in the host naming system. The argument could now be made that with DNS, return paths should be validated. However, there is no point in doing so. After all, who are you going to return to if the return path is bad? In addition, it is quite possible that a message that would otherwise be delivered would get sent to the bit bucket, with the error message right behind. This also follows the implementor's golden rule. -- Eliot Lear [lear@turbo.bio.net]