World: r3wp

wow, I'm impressed, I might have to stay awake for this ;)!!

Graham is the mail master, along with Phil. :-)

Hey, it's untested .... !!

this is a great example. at this time I'm going to be moving bounces 
into another mailbox instead of deleting them as I need them for 
forensic evidence. We have just received word that the ISP is forcing 
the subscriber offline as the spam constitues a breach of contract

thanks I'll  kick this around a bit but it's a great start for someone 
who's having trouble wrapping his head around the rebol paradigm, 
too many decades of procedural programming, I'm afraid.

this is rather brute force as each email is downloaded ...
better to use one of the top hacks to just get the headers

good idea, some of the emails are huge'

I reversed the series so that you remove them from the end backwards

as otherwise I guess the numbering changes if you remove from the 
head instead

any idea if there is a way to read emails and forward them to another 
inbox without altering the header? it would be nice if I could move 
them from one account to another without affecting the to/from.

why not just write them to a text file?

well, i'll do that to, but if I have to forward one to someone its 
easier if its in an inbox. at this point i've been up too many hours 
in a row to think straight, so I'm just trying to preserve everything 
in statis in case we have to revisit the "evidence".

that should be 

 email/return-path = "<>"

got it

thanks

I guess you could save them individually, and then send to the other 
mailbox as an attachment

were talking thousands. I just have 800 in one account.. i would 
just as soon tie up some of my 1GB on the providers mail server ;)

I know your pain.  I was the victim of such an identity theft, and 
I was getting 10,000 bounces a day.

Hello.  I was wondering how to replace a quotation mark in a string.. 
like this.
x: 'this " one'
replace x '"' ""

??

replace/all {A"B"C} {"} "'"

Ok, thanks.

the carret is rebol's escape chat so

>> s: "^""
== {"}

is another way

Just reading the rbbs.r script, and there are a number of comments 
about Rebol/View embedded in it .. which is a little odd as R/View 
is not recommended to be used to run cgi scripts.

Ahhh, they were added by Dirk Weyland to make it compatible with 
his serve-it web server.

did the latest version of OSX Rebol/Core come with the new FTP stuff? 
I have lots of trouble with a flakey FTP server here both with old 
and new versions of Rebol/Core for OSX...

User Error: Server error: tcp 500 RT not understood
 seems a bit broken to me

this is very strange... I get a whole range of different random errors: 
time outs, connection refused, commands not understood

For those that have smtp problems, I have posted a way to the mailing 
list on how to make rebol smtp send directly to the recipient's mail 
server by passing those messages about no mail forwarding allowed. 
 I would be interested to hear if anyone tries it out, and how well 
it works.

This means that a cgi script should be able to send out email even 
though the host does not provide a mail server for this purpose.

Of course, anyone using this method to spam will be $#@#!^@

Working with INDEX? often, it annoys me that it can't handle none! 
values. If I for example want the index for a value and in some cases 
the value can't be found:

index? find [a b c] 'd


FIND returns none!, which INDEX? can't handle. I would have liked 
to see INDEX? also return none! or false! (like FOUND?) rather than 
an error. It gives a better flow and the same opportunity for checking 
on your FIND result, but you don't need to handle the error.


The reason I'm pointing this out is that some functions tend to go 
hand in hand, such as INDEX? FIND, and I think it would be nice that 
no errors ever occurred here in all naturally occuring states.


LENGTH? can sometimes be a bit of a pain with that too. What do you 
think?

I have that problem all the time with having to write

	first find series val

as:

	if f: find series val [f: first f]

absolutely. FIRST, SECOND, etc. have the same problem

first find series val?

i could maybe understand third... not first or second :)

You're right. First is nonsensical and second could use 'select. 
I just checked my code and it is in fact 'index? not first I've had 
to code like this. ;)

ah well.... :-) but I think there is a point in it, don't you? or 
maybe there ought to be some conventions, like: "Never change a block 
to a none!" or things like that

henrik: i added your wish to rambo. will probably be implemented.

thanks

Henrik: your wish looks unnatural, I prefer the following:

    default [index? find [a b c] 'd] [none]


the Default function is available and it has been in Rambo for quite 
some time

Otoh, your example can be written using Attempt too as follows:

    attempt [index? find [a b c] 'd]

Re default: (a user poll) I wonder whether it is useful to have it 
like: 


    default [trial code here] 'error-variable [print disarm error-variable]

or in a shorter form like:

    default [trial code here] [print disarm error]


, in the last case the error variable will always be 'error, which 
will be local to the error handling block, i.e. if you want any other 
variable you have to explicitly assign the value of the 'error variable 
to it

my suggestion: if the arg is a block, use 'error. if it's a function, 
assume it has one argument and pass it the error. so i can write 
default [trial code] func [myerr] [print disarm myerr] if i really 
need to.

anyway, index? none returning none doesn't seem bad to me. will probably 
be faster than using attempt or default.

Carl did similar with 'remove, for failing "remove find". but may 
be better for error-checking to be explicit (rest of code expects 
dealing only with numbers, better bail out immediate.

about default, i prefer implicit error-var too. if not, at least 
put the error-var first. maybe together with an assignment?
 default 'var [index? find [a b c] 'd] [none] 
instead of
 var: default [index? find [a b c] 'd] [none]
but i prefer the second (old) version.

The problem I see is that it complicates debugging.

>> 1 + index? find "abc" "e"

** Script Error: index? expected series argument of type: series 
port
** Near: 1 + index? find "abc"

>> 1 + attempt[index? find "abc" "e"]
** Script Error: Cannot use add on none! value
** Near: 1 + attempt [index? find "abc" "e"]

So if INDEX? returns none the error of not finding the element propagates 
to the add function. In a longer expression the programmer will start 
debuging int the wrong place.

(thats what i wanted to say too. just wrong wording. should be "but 
<no-none> may be better for error-checking .."