Re: header-munging

> On 23 Sep 1996 16:03:38 -0700, Ned Freed <Ned.Freed <at> innosoft.com> 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: <ietf-smtp%LIST.CREN.NET <at> MV.Unisys.COM>, <moore%CS.UTK.EDU <at> MV.Unisys.COM>,
]         <Ned.Freed%Innosoft.com <at> MV.Unisys.COM>

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
From RANDY <at> MPA15AB.MV.UNISYS.COM Tue Sep 24 18:10:33 1996
Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by list.cren.net
(8.7.6/8.6.12) with ESMTP id SAA02176 for <ietf-smtp <at> LIST.CREN.NET>; Tue, 24 Sep 1996 18:10:31 -0400 (EDT)
From: RANDY <at> MPA15AB.MV.UNISYS.COM
Received: from mvdns1.mv.unisys.com (mvdns1.mv.unisys.com [192.59.253.100]) by
bbmail1.unisys.com (8.7.3/8.6.12) with SMTP id WAA23425; Tue, 24 Sep 1996 22:09:29 GMT
Received: from MPA15AB.MV.UNISYS.COM by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8)
	id AA05541; Tue, 24 Sep 96 22:10:36 GMT
Date: 24 SEP 96 15:10   
To: <Ned.Freed%Innosoft.com <at> MV.Unisys.COM>,
        <ietf-smtp%LIST.CREN.NET <at> MV.Unisys.COM>,
        <moore%CS.UTK.EDU <at> MV.Unisys.COM>
Subject: Re: header-munging
In-Reply-To: Your message of "24 Sep 1996 17:28:52 -0400"
References: <199609242128.RAA01948 <at> ig.cs.utk.edu>
Message-Id: <EL1R0845D8123F <at> MPA15AB>

On 24 Sep 1996 17:28:52 -0400, Keith Moore <moore <at> cs.utk.edu> wrote:

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

But many ISPs can determine user identity from the dynamic IP address,
since they authenticated that user and assigned that IP address.

> In fact, your messages provide a convenient example as to why having
> submission agents do message fixup should be strongly discouraged.
>
> ] To: <ietf-smtp%LIST.CREN.NET <at> MV.Unisys.COM>,
> ] <moore%CS.UTK.EDU <at> MV.Unisys.COM>,
> ]         <Ned.Freed%Innosoft.com <at> MV.Unisys.COM>
>
> 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.

Actually, I manually percent-hacked the addresses, because the firewall
prevents the SMTP server I am using (the one my user agent talks to)
from opening an outbound SMTP port.  I have to percent-hack to force it
to route the messages such that they arrive at a server which is
authorized to open an outbound SMTP connection.  (The server does have
an option that forces such routing, but there is a bug in it, so I
resort to manual percent-hacking until the bug is fixed *sigh*).

This is actually a case where the server would correct my return address
(from "randy <at> mpa15ab" to "randy <at> mpa15ab.mv.unisys.com") and everything
would be fine, but for the firewall and a different bug in the server
routing override options.

--
|Randall Gellens             |                    randy <at> mv.unisys.com|
|(714) 380-6350              | fax (714)597-8053 can add ,,,,,,,,6350|
|Opinions are personal;  facts are suspect;   I speak only for myself|