ESMTP docs to draft standard

There has been relative silence since these docs were posted, and I've
noticed no comments that address their substance, as distinct from
editorial form.

Unless such comments appear very soon (this week?), we will assume 
consensus that they should go forward and proceed to the next step
in processing (issuing a Last Call) without formally reconstituting
the WG.

    john

Proposal for new SMTP error code

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

   Date: Tue, 5 Apr 1994 17:06:14 +0200 (MET DST)
   From: Alain Durand <Alain.Durand <at> inria.fr>
   Reply-To: Alain Durand <Alain.Durand <at> inria.fr>
   Subject: SMTP 521 Reply code, draft proposal
   To: rfc-editor <at> ISI.EDU
   Cc: alain.durand <at> inria.fr, francis.dupont <at> 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

Re: Proposal for new SMTP error code

This seems like a good idea to me, and I don't see know of any
technical problems that this would cause.

It would probably be a good idea to test various mailers to
see if they react properly to a 521 response to HELO/EHLO.
Perhaps the document should suggest an address to be used
for that purpose.

Keith Moore

Re: Proposal for new SMTP error code

I believe this addresses a real deficiency in SMTP--there is no 5XX
reply that can legally be sent in the initial greeting.  I agree that
this should be placed on the standards track.

In the case where an SMTP server sends a 521 code in the connection
greeting, it should close the transmission channel, as is done for the
421 code.  This eliminates the need to allow 521 to be sent for SMTP
commands.  In the case where an SMTP client violates 1123 section
5.2.10 and ignores the 521 greeting, it should then see the connection
dropping as a (temporary) failure and (eventually) return the mail.

Re: Proposal for new SMTP error code

  Durand's proposal for a SMTP 521 reply code for hosts not intended to
receive mail seems to me like one that meets a real need and should be on
the standards track.

Jim

Re: Proposal for new SMTP error code

I though the "preferred" solution for this was to have your DNS system
loaded up with MX records for your non-mail host that pointed at a host
with the "same" userbase.  Most such machines will have another host where
the people who run them actually live, and perhaps you will WANT to get
mail addressed to postmaster <at> gw.cisco.com, if for example it contains info
like "crackers were breaking into my system last night using your host as
a hopping point."

Now it's true that not all mail systems will use an MX record when an A
record exists as well.  But then they might not do the right thing with
a new reply code, either...

BillW

Re: Proposal for new SMTP error code

> 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?

I think it would be a good idea to add text stating that a client SMTP must
not cache the fact that a particular SMTP server is not accepting mail.  If
it was allowed to do so, and it was later decided to reconfigure the machine
to accept SMTP connections, then some mail may be returned-to-sender when it
is actually deliverable.  Aside from that I think it is a great idea.

Also there are some problems with the Perl example daemon which I've addressed
below.

Michael D'Errico
mike <at> software.com
==============================================================================
>
>   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.
>   
>   [code omitted]
>   
>   for(;;) {

Re: Proposal for new SMTP error code

To what Bill Westfield said, I'd like to add a hearty "yeah, what he
said!" and note that his description matches what we actually do.

	Erik E. Fair	apple!fair	fair <at> apple.com

Re: Proposal for new SMTP error code

> I though the "preferred" solution for this was to have your DNS system
> loaded up with MX records for your non-mail host that pointed at a host
> with the "same" userbase.  

I generall agree, however; it wouldn't bother me if a printer or an X terminal
or router or some other appliance handled SMTP traffic in the way suggested by
the proposal.  Smart sites would override the default by installing MX
records, but you'd get reasonable behavior even for sites that didn't bother.

Actually, I'd like a response of the form:

HELO planet-p.com
521 Sorry, I don't accept mail.  I'm a toaster!

...though some people would consider this a security hazard.

Keith

Re: Proposal for new SMTP error code

William "Chops" Westfield <billw <at> cisco.com> writes:
> I though the "preferred" solution for this was to have your DNS system
> loaded up with MX records for your non-mail host that pointed at a host
> with the "same" userbase.

That requires that you also configure your mail host to know that it
is handling the local-parts for all those non-mail hosts.  This can
turn out to be impractical to administer in the general case.

There are in general two ways to deal with errors like this.  One is
to do some sort of DWIM fixup such as suggested above.  The other is
to reject the input and let the source of the problem fix it.  The
"fixup" approach solves some problems in the short term, but as it
removes any motivation to fix things, tends to lead to larger problems
in the long term.

"Michael D'Errico" <Mike <at> software.com> writes:
> I think it would be a good idea to add text stating that a client SMTP must
> not cache the fact that a particular SMTP server is not accepting mail.

I disagree.  Hosts that are configured to reject SMTP connections are
not likely to be suddenly reconfigured to accept mail.  It is more
likely that "deliverable" mail will be rejected due to a cached
NXDOMAIN reply from the DNS.

Keith Moore <moore <at> cs.utk.edu> writes:
> Actually, I'd like a response of the form:
> 
> HELO planet-p.com
> 521 Sorry, I don't accept mail.  I'm a toaster!