Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!cfe+ From: cfe+@andrew.cmu.edu (Craig F. Everhart) Newsgroups: comp.mail.sendmail Subject: Re: implementation question Message-ID: Date: 12 Dec 88 18:56:59 GMT References: Organization: Carnegie Mellon Lines: 16 In-Reply-To: I like [a] better (give an SMTP error rather than accept a piece of mail for later rejection). If you're most interested in tolerating a system that doesn't interpret your error codes, maybe you can narrow how you read the specification so that the error code you generate will be one that the remote system will interpret the way you want (as a permanent error). If the system in question won't interpret anything as a permanent error, this mechanism won't help much. One of the good reasons for preferring [a] when possible is that it gives faster error turnaround to the user, not to mention causing less overhead for your system because it doesn't have to handle composition, enqueueing, and delivery of the error message piece of mail. The significant reason for preferring [b], other than the reason you give of confused SMTP-user ends, is that if you always accept mail for later delivery, the SMTP-user end doesn't have to wait around while you check for the permanent-failure condition in question. Craig Everhart