Actually, I have completely rethought this idea which would work in a
bit more backward-compatible manner.
A reciever-host, upon deciding (at SMTP time) that it cannot deliver
the provided message, can return a specific (maybe 595? I'm not sure
which are defined already) code, that would indicate that there was
'extended' failure information available upon request. If the
sender-host recognized that code and supported this extension, it would
then issue some command to request the extended information that was
available, and include it in the nondelivery report (or in the case of
a MUA, display it directly to the user)
There would still be the hurdles of getting it accepted as a standard
and getting other MTA developers/vendors to support it.
On Fri, 22 Sep 2000, Dave C. wrote:
>
> I've been thinking about this a bit recently, and I think the _right_
> way to do this would have been to include a TURN-like concept, which
> would be initiated by the *receiver-SMTP* host, that could be used
> specifically for sending extended nondelivery reports such as the
> information below. This would relieve the receiver of having to route
> the return address and initiate a new connection to send the bounce, it
> would be taken care of right while the sender was connected waiting for
> the 200 code at the end of its DATA. If the sender didn't support the
> TURN reponse, then it could get a 500 code instead of the 200. This
> might be something which could be an ESMTP extension in exim (and if it
> caught on, other MTA's). It would have to laid out clearly in an RFC of
> course, and would have a long adoption time, but it just might be
> doable..
>
>
>
> On Sat, 9 Sep 2000, Philip Hazel wrote:
>
> > On Fri, 8 Sep 2000, Dave C. wrote:
> >
> > > Well, when you reject at SMTP-time, it is the sender MTA's
> > > responsibility to send the bounce. In the case of a legitimate email
> > > (with a mistyped address or something), the sender MTA will usuaully do
> > > so. In the case of a spam, we really don't care what it does ;)
> >
> > True. But for legitimate mail, I want to send all of this:
> >
> > Your message to ${LOCAL_PART}@??? has not been delivered, because
> > "${LOCAL_PART}" is not a known mailbox on this system.
> >
> > User mailbox names normally consist of a sequence of letters followed by a
> > sequence of digits. The letters are (some of) the user's initials, the last one
> > being the first letter of the user's surname. The first digit is always greater
> > than 0. There are a few 4-letter names that contain no digits.
> >
> > A common error is to confuse the digit "1" with the letter "l". For example,
> > Orlando Jacob Lassus' mailbox might be called ojl234, which sometimes gets
> > misread as oj1234. The digit "0" and the letter "o" can cause similar
> > confusion.
> >
> > The web page http://www.cam.ac.uk/CambUniv/Finding/ contains information about
> > finding people at Cambridge University. If you need further assistance, please
> > email to postmaster@???, giving as much information as possible.
> >
> > That's far too much to put in an SMTP error message, but we have found
> > that it does reduce load on out postmasters - at least for those senders
> > that actually bother to read it (which is another problem again).
> >
> > > Of course, it would be nice if all MTA's were smart enough to actually
> > > include the text after your 5xx code in the bounce message they
> > > generate ;)
> >
> > That's also true.
> >
> > > Of course, you could perhaps establish a list of 'legitimate' mail
> > > servers, and accept messages from those hosts, and send the bounce. Any
> > > others would get rejected at SMTP time..
> >
> > That is *exactly* what I do do, but the set has to be pretty crudely
> > defined (e.g. I exclude all of .com) and also has to be maintained.
> >
> >
> >
>
>
--
