ned+ietf-smtp(_at_)mrochek(_dot_)com <ned+ietf-smtp(_at_)mrochek(_dot_)com>
wrote:
It's certainly possible to have the MSA make the message copy, but we'd
need to define an extension for that. No such extension exists AFAIK.
http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html
As you might expect, I have a *lot* of problems with this approach. For one
thing, it mandates what I regard to be the suboptimal way to handle BCC by
completely deleting the field; as I have previously stated, not having a clear
indication that you got the message as a Bcc: risks exposure when someone
mistakenly does a reply-all.
It also requires parsing headers and extracting addresses from them, something
I'd prefer to avoid and which other approaches do not require.
The draft doesn't specify how to handle errors resulting from invalid
recipient addresses nearly well enough, but this is a correctable problem,
not a fundamental issue with the approach. (The batch SMTP specification
already covers most of this so I know it's possible to do.)
But the biggest problem is the approach to consuming Resent-* fields, in
particular its dependency on header ordering as well as requiring the presence
of Received: field separators. This is an incredibly fragile way to do it.
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.
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).
We will have a slot at the next IETF meeting (APP area WG) to bring attention
on the CEM systems scenario where there could be quite strange (or
interesting?) requirements (such as to forbid the BCC) that I think should be
addressed and discussed by the IETF community.
References:
http://datatracker.ietf.org/doc/draft-gennai-appsawg-cem/
http://datatracker.ietf.org/doc/rfc6109/
Francesco
Ned