What about the existing Precedance header, which is sometimes used? Is it
defined in any RFC?
AFAIK, no.
I observe that it does seem to have levels below
normal, such as "bulk" and "junk".
And several other values. Unfortunately, the semantics of this field are quite
inconsistent across various implementations. It is sometimes seen as a sort of
priority field, sometimes as an indication that delay notifications should not
be returned, and sometimes as an indicatin that no notifications should be
returned. And the values that cause each of these results are inconsistent as
well.
The history of the precedence field is a pretty strong argument for
standardization, actually.
Also, is there any use of such a header
for saying "this is so unimportant that I do not want you to bother to
tell me if it fails to get delivered"?
This is one of the functions of NOTARY, which does it using an SMTP
extension rather than a header field.
And as pointed out above, this is one of the various interpretations of
nonstandard precedence field as well.
I am frequently annoyed by systems
that are on some mailing list and tell everyone who posts to the list that
their message was not received :-( .
This is really a different problem. Lists should redirect error returns to a
handling address by changing the MAIL FROM (envelope from), and MTAs and
delivery agents should respect this redirection. Unfortunately, there are a few
lists that don't do this when they should. And worse, there are a fair number
of agents that send error reports to the wrong address.
Most lists should suppress delay notifications using NOTARY, but suppression
of all nondelivery notifications isn't a good idea.
There is also a school of thought that says since problems with errors being
returned to the wrong address are fairly common, errors should be suppressed
for all but a small subset of list postings.
Ned