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
Context
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:
NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN
THE
TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS 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?
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net