World: r3wp

Graham, I tried that but you get the same email than before with 
a different recipient but no BCC. I want to use BCC for some archiving 
project so I want to preserve the original To field like in real 
Bcc messages

Graham, I am not in the corporate world, but when I was Bcc was one 
of the hottest features, so many people used it to copy managers 
without the recipients being aware. I did like that use but it was 
widely accepted method to keep people in the loop

I did like
 --> I meant I didn't like

A semi-solution to this problem has been posted in RAMBO http://www.rebol.net/cgi-bin/rambo.r?id=4103&

This is a hack because the message shows the original headers so 
it's not true bcc but it partly solves my problem thanks

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.

A disgruntled recepient spammed the entire BCC list indicating our 
company didn't care or respect their privacy... just my luck.. .this 
was the first attempt to use Rebol for a valuable task at this job!! 
:-(

<ouch!>

smtp-port: 	open [scheme: 'esmtp]
msg:		head insert insert tail net-utils/export o-h newline msg
insert		smtp-port reduce [v-from reduce [v-to] msg]   	
insert		smtp-port reduce [v-from reduce [v-bcc] msg]

Hi Brock, this is how I fixed the bcc issue. I set up the right headers 
in o-h and then send the to message and afterwards the bcc message

Joe, did you mean that the BCC field with all the addresses should 
appear in the header of every recipient's email ?

If so, then that's not how it's supposed to work. BCC really does 
mean "blind carbon copy". The recipient should have no way of knowing 
other addresses. Your only standards-conformant remedy is to use 
CC.

is system/locale ever used for anything beyond the date requester? 
it would be nice if it were possible to localize date! type

send - i think there is a lot of confusion here

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)