[Top] [All Lists]

Re: "proper" handling of BCC

2012-03-01 09:20:41

Francesco Gennai wrote:

I'd actually rather have an extension that worked the opposite way: Construct
the headers from an appropriately decorated envelope and add them to the
message, and if handling error results from RCPT TO is an issue for clients
have a means to require that only outright syntax errors be reported as a
command result and report all other errors later with a DSN.

I would add to this discussion a possible (new?) need about the BCC handling (that come out in some scenario, see below) that is to forbid at MSA level the use of a BCC.

My Opinion:

After rethinking this, at first I would agree but I don't quite see how this would fall under SMTP (as an extension) due to the wide agree of how the integrated systems are done, i.e. the presumption as I read SMTP would be processing the headers once it is accepted. Maybe a internal (local vs remote) router will, perhaps even a gateway or a mail importer who may be already doing final clean up (i.e. stripping Return-Path or old uucp/slip "From " headers are no longer necessary).

In this case I agree with the Ned approach (based on a SMTP extension) versus the one that currently we are using in the Italian Certified email system, where we are parsing the TO and CC headers and comparing the result with the list of RCPT-TOs (many platforms have been adapted to be compliant with such MSA requirement).

Interesting and curious for the genesis of that logic. The two don't need to match. The offline MUA used did not do the separation?

It always helped me to view this in three parts (perhaps four, trace lines) regarding the format or network:

   Network Control Headers
   Display Headers

The network control lines basically that deals with ensuring routing and replies are possible and correct. Display headers are basically those no longer important for networking.

In our system, the operator decides how he mail is stored in preserved mode (RFC5322) or converted to the backend default format, which includes extraction and storage of attachments prepare it for online viewing, keeping only the network control lines as hidden meta fields. (Some user are allowed only online access, some have POP access, and for them he MAY preserves the RFC5322 storage to make sure there is no degrading of end to end originality. For some users, he operator may have a policy to protect the less savy user so he may get just plain text).

Perhaps what I can see here is agree that am existing BCC header should be forbidden from the standpoint that who ever massages the mail either for final delivery or for further routing that it simply strips the BCC from the headers on the presumption there is already a separate independent message/transport to the target BCC address done.

There is also the consideration regarding displaying. The MUA may want to inform the BCC recipient to the privacy nature of the message:


As you probably see, this will help avoid a possible mistake the BCC recipient is unaware of the BCC nature the the message and he jump into the conversion to the surprise of others the "boss" was listening.

IMV, only the offline MUA can do this when it separates BCC distribution from the rest for its SMTP client. The RFC-based offlne MUST always be aware of this responsibility because there is no current expectation the SMTP/MSA will. If that isn't already written somewhere, perhaps it needs to be done.

But I do agree the backend should do a "Double Check" to remove the BCC from public set of messages. Not sure if that is a SMTP issue. Maybe RFC 4409?


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net

<Prev in Thread] Current Thread [Next in Thread>