Re: header-munging

[Keith Moore <[e-mail]>]

> On 23 Sep 1996 16:03:38 -0700, Ned Freed <[e-mail]> wrote:
> 
> >      (3)   Add a 'Sender' field to the submitted message, if it knows
> >            the identity of the sender and this is not given in the
> >            'From' field.
> >
> > In some configurations you can infer the proper 'Sender' field from
> > the IP address of the client and possibly from the use of some sort of
> > authentication mechanism used under the SMTP connection.  However, in
> > many configurations this simply isn't possible, and as such a
> > submission protocol does not provide a general solution to this (very
> > real and very vexing) problem.
> 
> Since there are many situations (such as large companies where people
> submit messages from their PCs) where the submission agent can determine
> the sender, it makes sense to let the agent handle this when it can.

A site can presumably do whatever it wants to, at its own peril, with
its outgoing mail.  The question is, what practices should we encourage 
or discourage for wide use?

It's not possible in general (or even widely feasible) to determine the 
sender's user name or domain given the IP address from which a message was 
submitted.  Many environments do not do static IP address assignment; 
others share PCs or workstations between several people.  And given the
scarcity of IPv4 address space, it's not a solution we want to encourage.

In fact, your messages provide a convenient example as to why having 
submission agents do message fixup should be strongly discouraged. 

] To: <[e-mail]>, <[e-mail]>,
]         <[e-mail]>

By attempting to compensate for your UA or gateway's incorrect 
configuration (i.e. lack of knowledge of your return address), your 
SMTP server has damaged several perfectly valid addresses.  

In general, the chance that a message will be trashed due to configuration
error or implementation error INCREASES with every additional processing step.

Introducing new processing steps can indeed help in some cases.   But if 
this were recommended as a general solution for Internet, it would make 
things worse.  Indeed, widespread encouragement of this practice by certain 
workstation vendors is one of the biggest sources of broken mail today.


> I think the first set is large enough to make a submission protocol
> worthwhile.  The second set can be attacked through ACAP or other
> means.

The only things I can find that belong in the first set are: (a) repairing
implementation errors in certain MUAs and gateways, and (b) supporting
legacy systems that generate uuencode or some such instead of MIME.  
And the use of fixups in the latter category has its own problems which
make it questionable. 

Keith