Re: header-munging

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

> As such, while I have no problem with implementing facilities along
> these lines, I believe the real solution is to provide a means by
> which user agents can obtain a definitive form of this information,
> e.g.  as part of the ACAP protocol.  I am also afraid that attempting
> to solve this problem in a submission protocol may take energy away
> from engineering a real solution to the problem.

I'm not sure that allowing "Sender:" fixups as part of a submission
protocol takes much incremental energy.  The hard part seems to be
getting agreement on the need for a submission protocol at all.

I do agree that ACAP can help provide the information needed by the
user composition agent to avoid the need for fixups for many headers.

>      (4)   Add a 'Date' field to the submitted message, if it lacks it
>
> Adding a 'Date' field when it is missing is better than not having one
> at all.  But as Keith has already pointed out, the RFC822 'Date' field
> is the creation date for the message, not the posting date, and as
> such this really doesn't fix the problem properly.

But it is better than no date at all, and the draft does say that the
submission agent SHOULD add a note to document where the date header
was added.


>      (5)   Correct the 'Date' field if it does not conform to
>            [RFC-822] syntax (as modified by [RFC-1123]).
>
> Again, fixing a broken 'Date' field (e.g.  one that lacks a time zone)
> is better than leaving it broken, but there is no guarantee that the
> submission server will know how to fix a given sort of bust in a
> 'Date' field.  I believe that at a minimum there needs to be a note
> added to the effect that this field wasn't generated by the
> originating agent, and thus doesn't necessarily reflect the creation
> time of the message.

I agree, and the draft does say that such a note SHOULD be added.

>     (10)   Add a 'Content-MD5' field to the submitted message, if it
>            lacks it.
>
> I'm not entirely comfortable with this, as it implies that the message
> hasn't been corrupted in the process of getting it to the submission
> server.  I guess this would be OK if the submission server noted where
> the checksum field had been added.

Good point about the potential for prior corruption.  (The draft does
say the agent SHOULD add a note such as you suggest).

> So where does all this leave us?  It leaves us with a non-null class
> of problems that a submission server can be called upoin to solve.  It
> also leaves us with a non-null class of problems a submission server
> isn't likely to be able to solve with sufficient degree of generality
> to be called a real solution to the underlying problem.

And perhaps ACAP can help with the second set.

> Whether or not the set of problems solvable with a submission server
> is large enough and the set of problems not solvable with a submission
> server small enough to go to the effort of specifying such a thing is
> the key decision we have to make here.

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.


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