Re: utf8 messages

> Mark Martinec <[email protected]> wrote:
> >
> > It is not possible (even in the absence of SMTPUTF8 support) to be
> > able to transfer e-mail messages with no out-of-band ("metadata" /
> > envelope) information. The most obvious reason is the list of
> > recipient addresses, which is not present in a message itself.

> That is what the BCC: header is for (before message submission, if not
> at other times).

Not really. RFC 5322 is pretty clear about this:

   The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
   addresses of recipients of the message whose addresses are not to be
   revealed to other recipients of the message.

The problem is using Bcc: this way before submission conflates other cases,
e.g., the expansion of a mailing list maintained by the user agent, with the
one where you *really* don't want the other recipients to know about that
blind-carbon. So when the message actually gets sent, there's no way to
tell from the stored copy whether or not to generate separate copies containing
an indication of their Bcc: status.

Of course a lot of things don't implement proper Bcc: semantics anyway,
so this behavior ends up being "good enough". But let's not pretend it isn't
problematic in some cases, because it isn.

And as for after submission, such usage is problematic in the extreme. It
can easily lead not only to regaruly recipients becoming aware of blind
carbon recipients, it exposes their blind carbon status. It also can
conflict with legitimate uses of Bcc:

And in both cases the field fails to capture other per-recipient envelope
semantics.

> > Envelope sender may or may not be present in a mail header
> > (as a Return-Path header field).

> Right.

> > Other examples are RFC 3461 data (RET, ENVID, NOTIFY, ORCPT).

> I think it was a mistake not to specify in-header versions of those
> directives.

Actually, this was discussed at length and after the implications became
clear a decision was made not to do it.

ENVID is the best example. Support you define a field to be used on final
delivery, let's call it final-envelope-id. The problem is that lots of
agents resubmit messages with their headers more or less intact. Now
consider what happens when such an agent picks up such a message and
submits it to infrastructure that doesn't implement NOTARY. The result
can easily be to deliver a message with a completely bogus final-envelope-id
field.

Such leakage is very common with return-path fields, so there's running
code saying it will happen. But this is a tolerable situation with
return-path, where (1) We're not dealing with an identifier and (2) Enough
delivery agents generate the field. 

This is not to say there's no way to log the envelope-id in the header.
The place to do that would be as a new clause in the Received: field.
But the NOTARY work was done long before RFC 2821 came out and clarified
the syntax and extesnion model for Received: fields. And defining such a
model was far beyond the purview of the NOTARY WG.

Of course times have changed and nothing prevents us from defining
envelope-id (and orcpt) clauses for Reeived:.

As for RET and NOTIFY, I don't really think it makes the cost-benefit
cut for addition to Received:. And if you really need to carry the
envelope around at this level of detail elsewhere, that's what BSMTP
is for - in fact one of the reasons for specifying it and requiring
NOTARY support in it was for exactly this application.

				Ned

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822