ietf-smtp
[Top] [All Lists]

Re: "proper" handling of BCC

2012-03-01 00:45:16


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.

                                Ned

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