Re: header-munging

["Randall C. Gellens" <[e-mail]>]

On 6 Aug 1996 19:20:01 -0000, D. J. Bernstein <[e-mail]>
wrote:

> > would have to try the
> > new port number, and if it timed out, use the standard SMTP port.
>
> I don't see how that could ever be useful.

If the client knows it can't produce proper Message-ID, and/or Date
headers, for example, and doesn't know if the server accepts the new
port or not.


> _If_ the server accepts broken messages on the new port, there's no
> problem.  Retrying is a bad idea here.

Yes, of course.


> _If_ the server hasn't agreed out-of-band to accept broken messages,
> and doesn't agree to accept broken messages on the new port, then the
> client is out of luck---just as it would be with your SMTP extension.
> Neither the client nor the server is willing to produce a valid RFC
> 822 message.

The situation I see quite often is one where people use off-the-shelf
clients to create mail messages.  These clients are often unable to
generate Message-ID and/or proper Date headers.  Today, they just send
the messages as best they can.  Sometimes some MTA or other (perhaps
the first one, perhaps a later one) notices the problem and fixes it.
If the MTA is the first one, the fix is usually OK.  If it is a later
MTA, the fix is misleading.

In no case is the client out of luck; the message does make it where it
is going.

The point of the SUBMIT extension is to formalize the process, so the
first MTA knows it is being given permission to fix the message, and
all other MTAs leave it alone, but to still allow the proper thing to
be done when a client doesn't use SUBMIT when it should have.

Also, the draft specifies that the MTA which fixes the message documents
what changes were made.

--
|Randall Gellens             |                    [e-mail]|
|[phone]              | fax [phone] can add ,,,,,,,,6350|
|Opinions are personal;  facts are suspect;   I speak only for myself|