Re: more 3028bis comments

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


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

For example, procmail _usually_ (but not always!) inserts or updates
a "From " line before processing any rcfiles.  It also tries to
strip that line before forwarding the message.  However, it fails
to remove it when saving the message in mailboxes whose format does
not call for (or permit!) a "From " line, such as MH or maildir.
It also fails to enforce the presence of a "From " line when saving
to V7-format mailboxes, meaning that a poorly written rcfile can
remove or munge it, resulting in a broken mailbox.

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.


>I've seen occasions
>where script writers either want to suppress the line if supplied, or
>add one if not, e.g.:
>
>    if exists "From_" { deleteheader "From_" };
>
>as a very simple case.

All the cases I've seen of people deleting "From " lines fall into
three groups:

1) the @($* software isn't removing the "From " line when saving
   the message in other formats or when feeding the message to
   another program
2) the *#@( software is letting through a bad "From " line from
   'upstream' and has to be forced to generate a new, correct one
   manually by deleting the bogus one
3) the user is confused as ends up breaking their V7 mailboxes

All three of those cases are best handled by fixing the softwware
to strip "From " lines on input, perhaps after taking a stab at
extracting an address and date from them for later use, and then
only generating a new "From " line in output when writing directly
to a V7 mailbox or when otherwise directed to.


Philip Guenther