> In that case, it would be reasonable for an MTA to remove a Bcc header
> that did not agree with the envelope address. Whether that would be
> expressed as a MAY, SHOULD or MUST is another matter of course :-( .
No, this is not reasonable at all. Consider the case of a bcc recipient
whose email is forwarded. The envelope address won't agree with the bcc
header, but you still don't want the bcc header touched.
In the case of an MTA this is quite correct - forwarding makes it completely
impractical. X.400 made the mistake of thinking envelope-header correlation of
this sort was feasble as part of its MDN design. The result was that MDNs were
a crapshoot in X.400 - sometimes they worked, other times they didn't, and
often as not even exports had difficulty figuring out why. We really don't want
to go here.
Another issue with this is that it creates another condition under which the
MTA would have to perform splitting. (The reasons it does so should be
obvious.) Depending on overall MTA architecture additional splitting cases can
add real complexity, which is bad.
A more interesting case is that of bcc removal by a MSA. My guess is that the
number of cases where an MUA applies different rewrites to header and envelope
so they don't match is fairly small. So having an MSA perform bcc removal is a
considerably safer proposition.
However, this ignores another use-case: That of a file-copy listing all bcc's
that were sent. And the splitting issue remains. There's also the very real
possibility of creep out of the SUBMISSION space.
It's a much closer call, but I don't think this is worth it even if it were
restricted to SUBMISSION and MSAs.
It's a simple rule: the MTA and MSA should only touch the headers their
respective protocols say they should be adding or touching. And that
list is very small.
Yep. Simple and powerful and perilous to mess with.
Ned