World: r3wp

the BCC header field is a field used by mail clients to let users 
type addresses that will *not* be included in the header. it is, 
basically, a user interface. back at the time mail clients did not 
have a gui, and just processed mail from a file or by letting you 
type them on the terminal

so what a mail client does, is reading the mail, collecting the addresses 
from to, cc, and bcc, removing the bcc lines, and then sending the 
message to the collected addresses.

yes, B should stand for Blind .... it should prevent disclosing the 
person, you sent copy to ....

but send is not a mail client. it is a function to send email messages.

what send does (and should do!) is sending the specified message 
to the specified list of addresses. send does *not* collect the addresses 
from the mail header.

to make things easier, send will fill in a default mail header if 
the user has not provided one. however, if you are after something 
more complex than send [luke-:-rebol-:-com] "hi!" then you probably will 
want to pass your own header.

this header is sent as-is, except for a couple things such as setting 
To if you haven't set it (this is so you can have a header template 
and send many messages with it easily)

what send does *not* do and *should not* do is remove or change other 
header lines. in particular it will not remove any bcc: lines. the 
reason is, that you should *not* pass them at all, because it makes 
no sense.

now, since this is a very common error among users, it may be useful 
to let send remove bcc. personally, i will vote against this, because 
i prefer educating users (documentation) rather than keeping them 
stupid and happy. ;) even in the case we do it, send is still *not* 
collecting the addresses from bcc anyway - so we're just wasting 
time removing something that someone wasted time adding.

how about implementing an 'email function that does bcc etc?

so what you need to do now to send a message is - just send/header 
[list of addresses] msg header, with header being composed correctly 
- to should have what you want your recipients to see in to, from 
should have what you want your recipients to see in from, and so 
on; there should *not* be any bcc lines.

It just needs to wrap around send.

graham: that's a good idea and the desktop already has something 
like that, a gui that lets you type to subject and message. we could 
just add bcc and cc

also, i think there are a couple of mail clients written in rebol 
around :)

Something basic that can be enhanced by the user so this confusion 
is cleared up permanently

yes, but is it easier to write:

email [to: [graham-:-somewhere] from: [me-:-here] bcc: [carl-:-there] subject: 
"something"] msg

instead of using send directly?

looks good

email/attach

IMHO that are to much internals. I would add bcc to send. First, 
if you use bcc, its almost 100% a privacy issue. So at least no bcc. 
Second, users read "email", they know email and email has bcc. What 
happens inside the mail-client they have no clue. So bcc should also 
be added to the header-list IMHO. At least as option, send/bcc or 
such. Should not be much parsing and things works a lot more right. 
As this discussion proves.

But interesting thread :)

header-list -> recipient-list

'sends first argument.

volker, i'm not sure what you're suggesting.

To pass recipients in the bcc too, parse that.
  send/header [x-:-y] text [bcc: "[a-:-b]"]
-> mail goes to [x-:-y] and [a-:-b]

and bcc is cleared.

IMHO that is straightforward without guru-knowledge.

doesn't make sense - it should parse to: too in that case, and the 
address list would just be discarded?

better to allow something like the email function above

send [to: ...] msg     where send detects this checking for a set-word?

it seems to only add confusion to me. ymmv.

Not mm, Brocks. "Joe, I had problems with BCC in a corporate mass 
emailing I did.  Even though it did not display the email address 
in the mail client, if you viewed the header of the mail message 
the BCC content was there."

And yes, if i put 'to in the header in my client, i expect it works 
in send/header too.

we need refererence manuals like python has.  which explicitely state 
every limit and all intended useages of any and all words and refinements.

we keep guessing many things and not many of us use things like 'source 
to figure things out (when its even possible)

currently we have a brief dictionnary with SOME but not all of the 
information.

No, we need compatibility with common uses. Python maybe not, python 
has no "email!" AFAIK. But rebol has, creates an illusion and breaks 
it on the next possibility, leading to this bcc-thing.

No we don't. A programmer who wants to know how the mail system works 
should read existing standards documents.

come one Anton... you expect the mass to have time to read explicit 
out of language dry docs?

if a language has a feature which supports something, it has to explain 
exaclty how it does it.

I like that
  send [to: ...] msg

send [to: [x-:-y] subject: "i am back"] "had great hollidays"

send  is just the example of what the word does SOME things more 
than it should, but not all, and does not fully explain everything. 
 We are used to a lot of consistency in rebol. and if a word makes 
email shortcuts but not all of them... I understand the frustration 
which can come from a mistake, when you can't really know how -REBOL's- 
mail handling is performed... no matter what are the standards.

But, how about dropping 'send and switching to 'email completely 
in R3? 'send is a nice word for rebservices etc. IIRC Carl noted 
that somewhere.

Then in case of email 'send could be stupid without *any* headers, 
and 'email the dialected smart version.

http is supposed to be handled in rebol, yet I had to rewrite my 
own http-post function to talk to a webservice operating only in 
http1.1 of which rebol had a lot of trouble handling.  yet the service 
was compliant and rebol was not.

Good idea volker.

Volker - nice suggestion, really, isn't Linux shell using mail or 
email command too? Would make sense ... to even blockify its input 
arguments ...

make send more stupid so we assume/expect less of it.  and make a 
proper email function which handles most common useage like a mail 
client does it.