Re: more 3028bis comments

[Ned Freed <[e-mail]>]

> "Mark E. Mallett" <[e-mail]> writes:
> >On Tue, Jul 05, 2005 at 05:46:18PM -0700, Ned Freed wrote:
> >> > On Tue, 2005-07-05 at 16:52 -0400, Mark E. Mallett wrote:
> >> > > 2.10.6.  Errors
> ...
> >> > good question.  delivering an error report to INBOX in addition to the
> >> > message is one way of solving this, but does anyone do this?
> >>
> >> We do. Our implementation has the concept of a "responsible
> >> address" that's attached to each sieve script. When an error
> >> occurs this address is notified of the problem. For user sieves
> >> this is the user's own address, system sieves have the main
> >> system postmaster as the responsible address, and so on.

> Sendmail's implementation does that too.

Good to hear.

> >> > > The spec provides no way to access the "From_" line (which is the
> >> > > "From<sp>" line with no colon that is added by some mail software.
> >> > > While it's not part of RFC2822, and admittedly a minor concern at
> >> > > best, that 'header' is often there, but inaccessible.  I have no
> >> > > solution, other than perhaps making "From_" a special header name.
> >>
> >> > we have envelope "from" for the e-mail address.  we don't have anything
> >> > for the delivery date, but I suspect Ned is considering that for his
> >> > "date" extension.
> >
> >I was talking about accessing the header field in same ways that others
> >can be accessed, not other ways of getting at the specific parts of that
> >field that we might predict people might want.

> The "From " line is neither a header field nor permitted by RFC 822
> or RFC 2822.  It's simply part of a mailbox format that dates back
> to V7 UNIX.  Indeed, it is the bane of UNIX mail software to deal
> with that wart and treating it as part of the message header is,
> IMHO, a mistake as it complicates handling of other mailbox formats
> or even of resending message.

Agreed. It's what X.400 would call "delivery info", a remnant of what was in
the envelope at the time of final delivery. So, to the extent it contains
useful information, it should be treated as envelope material, not header
material.

> Confusing framing info with data is a mistake.  Providing access
> to incoming framing info is one thing, as is providing a means to
> set it on output (in those cases where it is used), but that should
> not be done by the backdoor of an invalid field name.

Exactly so.

				Ned