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.
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.
The extension will not solve the problem because I will need to
check for messages coming from clients that doesn't support it.
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?
I suspect the most of the MUAs just sent only a copy with no BCC header.
But in the case that a MUA should generate more than a copy
there could a problem in managing such requirement by just comparing
TO/CC with RCPT-TO (the copy without any BCC address could be accepted.... )