Alteration of Rebol's SEND favouring To/CC/BCC fields for defining recipients

I was looking for a way to better define email recipients along the lines of the To/CC/BCC convention. Although SYSTEM/STANDARD/EMAIL contains CC and BCC fields, they are not currently functional, see:

"How to Add Addresses to the BCC Field Using Rebol's Send Function"

Therefore in this solution, I've reorganised the SEND command to do my bidding based in part on this handy little answer:

"Sending BCC emails using an SMTP Server" (by @eml)

The SEND Function

The key is collecting ALL recipient addresses from To/CC/BCC (and the ADDRESS function argument) for use with the SMTP RCPT command, then reformatting the To/CC fields and setting BCC to none before composing the header object. Preliminary tests seem to indicate this approach works.

(Also included here is the function uses SYSTEM/STANDARD/EMAIL as a base for the header object, so you only need pass a block/minimal object as an argument—this should preserve the 'copy part of the message for the subject line' feature)

```
send: func [
{Send a message to an address (or block of addresses)}
address [email! block!] "An address or block of addresses"
message "Text of message. First line is subject."
/only "Send only one message to multiple addresses"
/header "Supply your own custom header"
header-obj [block! object!] "The header to use"
/attach "Attach file, files, or [.. [filename data]]"
files [file! block!] "The files to attach to the message"
/subject "Set the subject of the message"
subj "The subject line"
/show "Show all recipients in the TO field"
/local smtp-port boundary make-boundary tmp from
][
make-boundary: does []

if file? files [files: reduce [files]]

message: either string? message [copy message] [mold message]

; bases any custom object on SYSTEM/STANDARD/EMAIL
header-obj: make system/standard/email any [
header-obj
[subject: any [subj copy/part message any [find message newline 50]]]
]

As a sort of coarse suggestion I would say that you're over-refining and not dialecting enough. Imagine if you said it was always arity-2...header and body. But if the header is just an email assume it's the To address.

So these would be equivalent:

send bar@foo.com "Message content"

send [To: bar@foo.com] "Message content"

/attach makes sense as a refinement that might add a third section, because when I think of parameterization that does seem appropriate and it's also "in the right position".

send/attach bar@foo.com "See attached files" [%world-takeover.pdf %kittens.gif]

I would suggest though that the other refinements are too much, and should be perhaps slipstreamed into the header or body as `` instructions...something out-of-band.

This feels a bit like a "port scheme" for email when you frame it this way.

StackExchange Code Review Q#111395, answer score: 4