World: r3wp

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.

visitor. cu

?

suden visitor. Have to talk in person :)

I've got a question. open/skip does not work?

open/seek ?

That was added later. /skip works thru some networking IIRC.

I need it on files

Try seek, and then use 'skip etc. IIRC that works. (needs the newer 
rebols)

hm, works strange, but works :)

port: open/direct/skip url size ; resume position <- this can fail 
when file is complete already

I just spent a couple of nights working on a batch-downloader.

Anton, yes bcc is a blind copy. Gabriele explains it better than 
I did.  I found it very easy to code the new send function with the 
snippet above . The trick is to compose the right header and then 
send the message to both the to and bcc recipients. The MTA does 
remove the bcc field so the to: recipient or even the bcc: recipient 
do not have a bcc header field

It does seem that the bcc issue is caused by the presence of bcc 
in system/standard/email. Perhaps send could raise an error if it 
finds bcc set - and or - remove bcc from system/standard/email.