"Mark E. Mallett" <mem(_at_)mv(_dot_)mv(_dot_)com> 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