World: r3wp

#3820? :-)

I don't think it's ok, that to binary! treats integer! as string!, 
but it's in the docs...

I don't mind that much about "language purity" as it may look. It 
is inconvenient above all.

Kru: thanks a lot, adding to-block to the code solves it ;-)

Pekr: solves it for one-byte integers and that's not so good :)

:-)

How do you change the content type of outgoing emails?  I want to 
change the charset to UTF-8...

Meh, just create a custom header...

Be careful of using the BCC feature with emails.  I sent mails at 
one time were the BCC recipients were viewable in the header information 
from within Outlook.  A disgruntled recepient then SPAMMED all who 
were BCC'd using my companies email address as the from Address.... 
Corporate Security didn't like me very much.

... they eventually identified the spammer by the way  :-)

Don't you mean .. beware of using "Outlook" ?

I think if you BCC someone in an email it should not appear in the 
header of an email.  I don't know the spec, but it doesn't make sense 
if you want to hide who received an email that is displayed in the 
mail header.

We've discussed this before, and the RFC does allow the BCC header 
to appear.

SEND does not take the recipients from the header, so it has no reason 
to preprocess it. if you include a BCC header, it's because you want 
it to pass... otherwise, why do you include it?

What ? I'm shocked. I always thought CC was for allowing the recipients 
to see the list, and BCC was for the mail processor to split apart 
and hide. Are you sure about that being in the RFC Graham ? I would 
believe you otherwise but I'm in denial.

I know mail sent with Outlook did not show the BCC'd recipients in 
it.

Seems there are two scenarios, both of them should not send the complete 
list of the BCC'd users in the mail message....
The 
Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains

   addresses of recipients of the message whose addresses are not to 
   be

   revealed to other recipients of the message.  There are three ways 
   in

   which the "Bcc:" field is used.  In the first case, when a message

   containing a "Bcc:" field is prepared to be sent, the "Bcc:" line 
   is

   removed even though all of the recipients (including those specified

   in the "Bcc:" field) are sent a copy of the message.  In the second

   case, recipients specified in the "To:" and "Cc:" lines each are 
   sent

   a copy of the message with the "Bcc:" line removed as above, but 
   the

   recipients on the "Bcc:" line get a separate copy of the message
   containing a "Bcc:" line.  (When there are multiple recipient

   addresses in the "Bcc:" field, some implementations actually send 
   a
   separate copy of the message to each recipient with a "Bcc:"
   containing only the address of that particular recipient.)"

(sorry about the word-wrap)

http://www.faqs.org/rfcs/rfc2822.html

Many implementations use the 

Bcc:" (blind carbon copy) field described in section 3.6.3 to facilitate 
sending messages to recipients without revealing the addresses of 
one or more of the addressees to the other recipients.  Mishandling 
this use of "Bcc:" has implications for confidential information 
that might be revealed, which could eventually lead to security problems 
through knowledge of even the existence of a particular mail address. 
 For example, if using the first method described in section 3.6.3, 
where the "Bcc:" line is removed from the message, blind recipients 
have no explicit indication that they have been sent a blind copy, 
except insofar as their address does not appear in the message header. 
 Because of this, one of the blind addressees could potentially send 
a reply to all of the shown recipients and accidentally reveal that 
the message went to the blind recipient.  When the second method 
from section 3.6.3 is used, the blind recipient's address appears 
in the "Bcc:" field of a separate copy of the message. If the "Bcc:" 
field sent contains all of the blind addressees, all of the "Bcc:" 
recipients will be seen by each "Bcc:" recipient.  Even if a separate 
message is sent to each "Bcc:" recipient with only the individual's 
address, implementations still need to be careful to process replies 
to the message as per section 3.6.3 so as not to accidentally reveal 
the blind recipient to other recipients."

First quote from section 3.6.3. "Destination address fields"
Second quote from section 5. "Security"

It states in the site that the RFC has been updated to handle security 
considterations... so our email implementation seems to be based 
on an older, out-of-date RFC.

As Gabriele says, 'send doesn't use the header for addressing.  It 
is up to you to implement how email is sent, and to whom.

Sorry, I don't understand those arguements.  From my perspective 
Rebol is sending all the BCC'd recipients when an email is sent. 
 Unless you are telling me it is up to the mail server to not pass 
the BCC along.  I somehow don't think so.

It is the responsibility of the mail client.  You control the mail 
client.  If you construct a BCC field in your header, Rebol will 
ignore that when using send.

Iikewise, for cc: header.

>> help send
USAGE:

    SEND address message /only /header header-obj /attach files /subject 
    subj /show

DESCRIPTION:
     Send a message to an address (or block of addresses)
     SEND is a function value.

It is up to you to determine what the 'address is .. whether it is 
a single email address, or a block of email addresses.

and when you do send to a bock of addresses they are send as individual 
messages (effecively a BCC)

which means the server cannot take advantage of the fact the body 
is the same on all the messages and just spam/virus filter it once.

(having this issue on a  list of 2500)

If you want, you can write your own send command that does what you 
want.

Let's make this clear: SEND is not an email client. SEND is a function 
to send email. If it was an email client, it owuld just show a window 
with the ability to send TO, CC, BCC and so on, with a send button 
in it...

what send does is: taking a message, and sending it to the list of 
recipients you provide. That's what any MTA does too.

the user interface for mailers, though, of course do more than that. 
TO, CC and BCC are part of the user interface.

Hmm.  SMTP allows the sender to make multiple RCPT TO commands before 
sending the body of the message once - which then gets sent to the 
addressees of the RCPT TO.

This is how your email client would implement a CC or BCC.

yep, just like SEND.

I don't know how 'send works ... but I assume it does only a single 
RCPT TO ?

depends on refinements. i don't recall if it does one with a list 
of emails, or several with one email address each.

I think it sends it multiple times.

SEND with multiple recipients sends a copy to each recipient; SEND/ONLY 
sends the same message to many recipients

I don't see the use of using /only, really...  With /show, I see 
all recipients whether or not /only is there - and without /show, 
with /only, it won't show any email address, and without /only, just 
it only shows the recipient.

(without /only, without show for that last one)

(/show)

Quick question .. how do you set the century to-date defaults to 
?

>> to-date "1/10/40"
== 1-Oct-2040

is not what I want.

>> to-date "1/10/1040"
== 1-Oct-1040

but what I want is last century !

Many languages have a way to set the window in which dates work.

WOuld own handlling work? Where do you get the dates from? always 
"1/10/40"?