World: r3wp

Nice, missed that one.

what is the difference anyway between 'dehex and 'to-string  and 
'as-string ?

>> A: [%23%67%68%69]
== [%23ghi]
>> dehex A

** Script Error: dehex expected value argument of type: any-string
** Near: dehex A               ;dehex doesn't work with blocks
>> to-string A

== "23ghi"                ;to-string converted it to a string and 
de-hex only some of the characters.
>> A: {%23%67%68%69}
== "%23%67%68%69"
>> dehex A
== "#ghi"              ;dehex works on all parts of the string

No idea about as-string, dun have that beta.

er whoops nevermind the first part of it - didn't realize it dehexed 
part right away lol

Hey that looks like a bug - it won't auto-dehex the first part of 
a block, but works on the rest no problem:
>> A: [%70%70]
== [%70p]

I think it's because rebol think its a file! due to the first percent 
sign

> A: [%70%70]
== [%70p]
>> type? a/1
== file!

>> A: [%%70%70]
== [%pp]

That's interesting... I wouldn't have thought that.. Thanks!

anyone got a parse rule that tells me whether the text constitutes 
a fully qualified domain?

Does REBOL/Core (or any other version) support the IMAP protocol?

yes .. limited

http://www.rebol.com/core-info25.htmlmentions IMAP and APOP

There is a difference between the IMAP protocol itself (RFC 2060) 
and the imap:// URL scheme (RFC 2192). At this time REBOL only supports 
the imap:// URL scheme, which has a subset of the full IMAP protocol 
functionality. It handles mailbox lists, message lists, retrieving 
and deleting of messages, and message searches, i.e. it is API-compatible 
to pop://, with added support for multiple mailboxes and searches. 
Move/copy/rename and other administrative IMAP functions are not 
specified in RFC 2192 and not supported by REBOL's imap:// scheme 
at this time.

which is what I posted to the list in Feb 2003

Thanks, folks. I know that IMAP itself is a bit of a muddle (based 
on profanities that I overheard from somebody who was trying to write 
a complete IMAP client for another language), but a subset of functionality 
is more than I knew about.

trace/net on
mbox: open imap://userid:[password-:-imapaddress-:-com]

there's a bug in imap as released in the current stable and beta 
versions which Scott and I fixed.

http://www.compkarori.com/vanilla/display/IMAP

is there reverse to dehex "Documents and settings", simply some 
function to provide it "Documents and settings" and having replaced 
spaces etc.?

ah, to-url, sorry ...

rebol []
  
     secure [   net allow  file allow  ]

no security check .

I ask about help  ?

Anyone got a function to reduce a ip-address to a tuple ?

I mean, make something like 192.168.1.254 -> 192.168.1    .. dropping 
the last number

no matter.

Well I know how I'd do it in Perl or Ruby, but I'm not that far with 
my Rebol yet.

192.168.1.254/1 -> 192
192.168.1.254/2 -> 1

Hey, that's cool.

I'm writing a greylisting implementation for my smtp server .. and 
I needed to drop the last digits of an ip address to form the triplet

What about 
>> to-tuple reduce [first ip second ip third ip]
== 192.168.1

Graham do you want to compare the spammer ip address against a range?

Yes, because you could test   (ip * 1.1.1.0) = (ip2 * 1.1.1.0)

;If you do why not use comparison under mask? 

>> same-subnet?: func [src dst mask][(src and mask) = (dst and mask)]
>> same-subnet? 10.10.10.0 10.10.10.5 255.255.255.0
== true
>> same-subnet? 10.10.10.0 10.10.9.5 255.255.255.0
== false

This version handles also cidr prefixes.

>> cidr-as-mask: func[prefix /local mask][
[        mask: make string! 34

[        repeat i 32 [insert tail mask either prefix >= i [1][0]] 
[        to-tuple load rejoin ["2#{" mask "}"]
[    ]  
>> 
>> same-subnet?: func [src dst mask [tuple! integer!]][
[        if integer! = type? mask [mask: cidr-as-mask mask]
[        (src and mask) = (dst and mask)
[    ]
>> same-subnet? 10.10.10.0 10.10.10.5 255.255.255.0
== true
>> same-subnet? 10.10.10.0 10.10.10.5 24           
== true
>> same-subnet? 10.10.10.0 10.10.9.5 255.255.255.0
== false
>> same-subnet? 10.10.10.0 10.10.9.5 24           
== false

I need to construct what is called a "triplet".  The triplet in greylisting 
parlance is a unique set of three facts about an email.
These are IP-address+smtp envelope from+smtp envelope to

The idea is that you construct a database of triplets from smtp clients. 
 If you have never seen such a triplet before, you send a smtp delay 
back to the client.  Most well constructed MTA's honor the delay 
and try again.  You set a block period .. from 10 seconds to 1 hour 
during which you do not accept any mail from that triplet.  Spamming 
engines generally ignore this delay, and just give up.  It's too 
expensive for them to log such delays and retry again.

If you have seen mail from such a triplet before, you then allow 
that mail to go thru without any delays.

In my testing, I found that my ISP sent me three consecutive emails 
to my smtp server using three different ip addresses all within the 
same subnet.  So, this meant that all three emails were subjected 
to a delay.

So, I constructed the triplet without the last set of digits so that 
it will treat all email from the same subnet as orginating from the 
same address.

Shouldn't parse and checksum be able to work directly on files? The 
only current option is to bring the files to memory either in chunks 
or completely, which can be very expensive in memory resources.

checksum more than parse, because with parse there are (not easy) 
workarounds, not with checksum

Romano. Why not parse, because of skip not working?

Isn't skip working now in the new alphas ?

I believe so.  But I havent tested this.

useful for both, but checksum has not workaround while some workaround 
can be found for parse

like inserting data at tail of parsed string?

I guess you have to access to the whole file in memory to calculate 
md5s ...

need some other checksum that can be calculated by loading parts 
of a file at a time.

Vincent: almost, it is not easy: you must 1) read a chunk of data, 
parse it 2) when parse stop remember the position where it stops 
3) delete parsed data 4) read a ne chunk of the file 5) append it 
to the old data 6) restart parse from the right rule (this is the 
hardest part)