Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  implementation question
Message-ID: <8812121715.AA08009@gateway.mitre.org>
Date: 12 Dec 88 17:15:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30

I once wrote an SMTP which got fairly heavy use, though lately I am out
of the business of maintaining it.  I have the feeling you are looking
for someone to tell you it is fine to use method [b] (accept the mail
and then mail a rejection).  I sympathize with the problems of dealing
with brain-damaged mailers at other sites, but I think that method [b] is
too extreme for general use, notwithstanding your clever and, uh,
innovative application of "...be liberal in what you accept..."

This would have been more convincing if it didn't impose a constraint
on other people's mailers.  They may feel that they can do a better job
writing an error message than you can.  Suppose a message is sent to a
long list of addresses and several of the deliveries immediately fail for
whatever reasons.  A clever SMTP-sender (like mine) would avoid a lot of
mailbox clutter by handing the originator one error notification
listing the failures and the reasons, if it were given the opportunity
to do so - and method [b] takes away that opportunity.  Or, a sending
SMTP might want to generate the error text in some language other than
the one your SMTP speaks.

Insofar as the Host Requirements RFC (yes, it's still a-comin') says
anything on this topic, it pushes toward returning SMTP error codes at
the first appropriate moment, and minimizing after-the-fact failure
messages.  I think this is generally the right thing to do.  However,
no rule prohibits you from adopting unusual measures to defend yourself
when necessary.  I hope you can go with method [a] at least for the
most part, and find some practical criterion for restricting [b] to
actual evildoers - perhaps a configuration file listing the nasty
hosts, or heuristics to recognize the retry that ought not to be.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org