pyzor-users — general discussion of Pyzor and Pyzor-related topics

Re: strange false positive

[Guido <lis...@gu...>]

On Tue, 2009-07-28 at 22:08 +1200, Tony Meyer wrote:
> I think this is just evidence of a flaw in the Pyzor specification.
> [...]
> I'm still relatively new to Pyzor development, so I'm reluctant to
> change fundamentals like the digest specification.  However, I'm not
> really convinced it's ideal, so it is something I'm looking at (as I
> have time).  I'd like to look at what other digesting methods do (I'm
> familiar with some already, but looking at more), and run some tests
> on different specs.  Since it's such a major change (for a start, it
> means a separate database) I doubt there will be any changes in the
> code in the next few months.
> 

Thanks. This explains the behavior. 

I think you are right. Changes regarding the digests should be well
thought-out. At least if this concerns the main branch. I have seen that
you separated the digest stuff from the client. This is a good start. If
you want to test other digest specs and you upload the code to the
repository I could also do some tests.

Guido

Re: strange false positive

[Tony M. <to...@sp...>]

> $ pyzor predigest < long.txt
> YoureceivedthismessagebecauseyouaretotheGoogleGroupsgroup.
> Toposttothisgroup,sendemailto
> Tofromthisgroup,sendemailto
> Tofromthisgroup,sendemailto
> Formoreoptions,visitthisgroupat

I think this is just evidence of a flaw in the Pyzor specification.
The spec uses 3 lines of the message 20% into the content and 3 lines
60% into the content (and then normalises those lines) as the digest
material (unless there are fewer than 4 lines, in which case they are
all used).

Here there are 11 lines, so Pyzor will choose to use lines 5, 6, 7 and
7, 8, 9 (since the message is short, the two groups of three end up
overlapping).  Line 9 is one long string of characters, so is
normalised away to nothing.

You could change anything in the rest of the message (line 1 (blank),
line 2 (actual content), lines 3 or 4 (blank and symbols), or lines 10
or 11 (blank)) and the predigest (and therefore the digest) would not
change.  Insert an extra line anywhere before line 10 or change lines
5, 6, 7, 8, or 9, and the predigest/digest will change.

There are two things I don't like here:

 * I don't like that in short messages the predigest can have some
material twice.

 * It seems like 6 lines is not a lot to base a unique identifier on,
especially in small messages like this.  I presume that the idea is
that it makes it hard to insert per-email text into a message and have
the digest change.  However, (1) all you need to do is insert a
newline at the right place and the digest *will* change, and (2)
taking only 6 lines seems like it's too conservative and will lead to
more false positives.

I'm still relatively new to Pyzor development, so I'm reluctant to
change fundamentals like the digest specification.  However, I'm not
really convinced it's ideal, so it is something I'm looking at (as I
have time).  I'd like to look at what other digesting methods do (I'm
familiar with some already, but looking at more), and run some tests
on different specs.  Since it's such a major change (for a start, it
means a separate database) I doubt there will be any changes in the
code in the next few months.

> And there is another odd thing. It works for the shortened message, but
> only when using <.
[...]

I don't know the answer to this.  My guess would be that the cat+|
combination are doing something slightly different than just piping in
with <.  For example, if there were a different number of blank lines
at the end, then the total number of lines would be different, and the
20% and 60% positions would be in different places, and so the
predigest/digest would change.

Cheers,
Tony

Re: strange false positive

[Guido <lis...@gu...>]

> What version of Pyzor are you using?  

I am using 0.5 (and tried with python 2.6.2/Ubuntu and 2.4.3/CentOS).

> I don't see this with 0.5:

You are right. It works with the shortened message I posted here.
Therefore I attached the full message now (long.txt). 

>>>>>>>>>>>>>>>>>>
$ gunzip long.txt.gz
$ pyzor predigest < long.txt
YoureceivedthismessagebecauseyouaretotheGoogleGroupsgroup.
Toposttothisgroup,sendemailto
Tofromthisgroup,sendemailto
Tofromthisgroup,sendemailto
Formoreoptions,visitthisgroupat
<<<<<<<<<<<<<<<<<<

And there is another odd thing. It works for the shortened message, but
only when using <.

>>>>>>>>>>>>>>>>>>
$ gunzip short.txt.gz
$ pyzor predigest < short.txt
Thanksall,foralltheusefulideas!
YoureceivedthismessagebecauseyouaretotheGoogle
Groups"[...]"group.
Toposttothisgroup,sendemailto[...]
Tofromthisgroup,sendemailto[...]
Formoreoptions,visitthisgroupat
$ cat short.txt | pyzor predigest
YoureceivedthismessagebecauseyouaretotheGoogle
Groups"[...]"group.
Toposttothisgroup,sendemailto[...]
Toposttothisgroup,sendemailto[...]
Tofromthisgroup,sendemailto[...]
Formoreoptions,visitthisgroupat
<<<<<<<<<<<<<<<<<<

It works with cat too, if a leading empty line is added to the file.

Thanks

Guido

Re: strange false positive

[Tony M. <to...@sp...>]

> Message 1:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> Thanks all, for all the useful ideas!
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "[...]" group.
> To post to this group, send email to [...]
> To unsubscribe from this group, send email to [...]
> For more options, visit this group at
> [...]
> -~----------~----~----~----~------~----~------~--~---
> <<<<<<<<<<<<<<<<<<<<<<<<<<

[...]

> Predigest of both:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
> YoureceivedthismessagebecauseyouaretotheGoogleGroupsgroup.
> Toposttothisgroup,sendemailto
> Tofromthisgroup,sendemailto
> Tofromthisgroup,sendemailto
> Formoreoptions,visitthisgroupat
> <<<<<<<<<<<<<<<<<<<<<<<<<<

What version of Pyzor are you using?  I don't see this with 0.5:

# cat p.msg
Subject: test

Thanks all, for all the useful ideas!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "[...]" group.
To post to this group, send email to [...]
To unsubscribe from this group, send email to [...]
For more options, visit this group at
[...]
-~----------~----~----~----~------~----~------~--~---

# pyzor predigest < p.msg
Thanksall,foralltheusefulideas!
YoureceivedthismessagebecauseyouaretotheGoogle
Groups"[...]"group.
Toposttothisgroup,sendemailto[...]
Tofromthisgroup,sendemailto[...]
Formoreoptions,visitthisgroupat

# pyzor digest < p.msg
74a132adee6615a0ae4a198be9fa01f5d1d86767

Thanks,
Tony

Re: strange false positive

[Guido <lis...@gu...>]

> are they only reported and not whitelisted? Maybe you need to check for
> whitelisting too, not just for reports...

Sorry.
 
The message is not whitelisted. But whitelisting would be a temporary
solution only. Because all spam messages sent through Google groups
containing a single line would be whitelisted. 
(If the behavior described before is always the case.)

Guido

Re: strange false positive

[Matus U. - f. <uh...@fa...>]

On 27.07.09 17:03, Guido wrote:
> I did some checks with my Mailbox. I found 2 false positives. Both are
> very similar.
> The messages are part of a Google groups mailing list thread. They
> contain only one line of users text, but additionally 4 lines added by
> Google.
> 
> Seems that pyzor removes the first sentence. Unfortunately it's the only
> feature that makes this mail unique. The digest has been reported 9
> times if I remember right.
> 
> I tried to find the rule which removes this first sentence (or line?)
> but I could not find it. 

are they only reported and not whitelisted? Maybe you need to check for
whitelisting too, not just for reports...

> Thanks all, for all the useful ideas!
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "[...]" group.
> To post to this group, send email to [...]
> To unsubscribe from this group, send email to [...]
> For more options, visit this group at 
> [...]
> -~----------~----~----~----~------~----~------~--~---

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states. 

Re: Important change regarding creating bug reports / feature requests

[David M. <mor...@gm...>]

On Sat, Jul 18, 2009 at 6:18 PM, Tony Meyer <to...@sp...> wrote:

>
> This isn't something I anticipated - it's quite surprising to me that
> a spammer would go to the effort of writing software that would spam
> Trac installations (unless it's software that spams any forms and just
> happens to work with Trac).


Most of the spam to my own trac server was for the purpose of increasing the
pagerank of whatever they were linking to.  It was all link spam.  In
addition, spammers aren't well known for being shrewd with  social norms
anyway.  :P

I think a SF account requirement is suitable for this crowd.



-- 
David Morton
mor...@gm...  - bulk address
mor...@dg... - direct to my server

strange false positive

[Guido <lis...@gu...>]

Hi!

I did some checks with my Mailbox. I found 2 false positives. Both are
very similar.
The messages are part of a Google groups mailing list thread. They
contain only one line of users text, but additionally 4 lines added by
Google.

Seems that pyzor removes the first sentence. Unfortunately it's the only
feature that makes this mail unique. The digest has been reported 9
times if I remember right.

I tried to find the rule which removes this first sentence (or line?)
but I could not find it. 

See more details blow.

Thanks

Guido


== More details ==

Message 1:
>>>>>>>>>>>>>>>>>>>>>>>>>>

Thanks all, for all the useful ideas!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "[...]" group.
To post to this group, send email to [...]
To unsubscribe from this group, send email to [...]
For more options, visit this group at 
[...]
-~----------~----~----~----~------~----~------~--~---
<<<<<<<<<<<<<<<<<<<<<<<<<<

Message 2:
>>>>>>>>>>>>>>>>>>>>>>>>>>

thanx alot sir ur solution is working perfectly...................

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "[...]" group.
To post to this group, send email to [...]
To unsubscribe from this group, send email to [...]
For more options, visit this group at [...]
-~----------~----~----~----~------~----~------~--~---
<<<<<<<<<<<<<<<<<<<<<<<<<<

Predigest of both:
>>>>>>>>>>>>>>>>>>>>>>>>>>
YoureceivedthismessagebecauseyouaretotheGoogleGroupsgroup.
Toposttothisgroup,sendemailto
Tofromthisgroup,sendemailto
Tofromthisgroup,sendemailto
Formoreoptions,visitthisgroupat
<<<<<<<<<<<<<<<<<<<<<<<<<<

Digest:
54aea8487f9410b1523cfa987f5030773c84c381

Re: daemonize and pid file

[Guido <lis...@gu...>]

Thanks for your reply.

> There's a ticket (#51) for the logFile option.  Most of the necessary
> code is in SVN already.
> 
Good. I was wondering if this up to date.

> I don't see any point in the (extremely old) daemonising code - can't
> you just use something like start-stop-daemon?  If you feel there is a
> use-case, please open a ticket requesting the change/addition that you
> want.

I just wanted to know what you are planning to do. Of course you should
not maintain useless code.

Re: daemonize and pid file

[Tony M. <to...@sp...>]

> Regarding daemonize and pid file.
>
> I am not sure if this did ever work, but it does not for me (0.4.0).
> I found https://sourceforge.net/apps/trac/pyzor/changeset/170
> So daemonizing, logging (and pid file) won't be supported in the future?

There's a ticket (#51) for the logFile option.  Most of the necessary
code is in SVN already.

I don't see any point in the (extremely old) daemonising code - can't
you just use something like start-stop-daemon?  If you feel there is a
use-case, please open a ticket requesting the change/addition that you
want.

Thanks,
Tony

daemonize and pid file

[Guido <lis...@gu...>]

Hi,

Regarding daemonize and pid file.
  
I am not sure if this did ever work, but it does not for me (0.4.0).
I found https://sourceforge.net/apps/trac/pyzor/changeset/170
So daemonizing, logging (and pid file) won't be supported in the future?

Guido

Re: Important change regarding creating bug reports / feature requests

[Guido <lis...@gu...>]

>  * Require authentication to create/modify (not view) tickets.  This
> means you'd have to have a SourceForge account to report a bug or
> request a feature.  SourceForge accounts are free and easy to create,
> but it's likely that many Pyzor users might not have one.

This is probably the best solution for you.

On trac installations outside sourceforge it is common to set up a guest
account and post the user/password to the trac wiki itself. But this
does not work for SF.

If you are afraid of missing useful bug reports because (some) users are
too lazy to create a SF account (or for some other reason), you could 
provide a special mail address. In this case the owner of this special
mail box would have to create tickets from the mails. Or you could ask
those users to write to the public mailing list.

Re: Important change regarding creating bug reports / feature requests

[Dreas v. D. <dr...@sp...>]

Tony Meyer wrote:
> Unfortunately, since the (necessary) change to SourceForge-hosted Trac
> for bug reports and feature requests ('tickets'), there has been a
> steady number of spam tickets opened each day.  As far as I can tell,
> there's no way for me to get a notification whenever a new ticket is
> created (this is possible on a normal Trac installation), so that
> means that I have to regularly go through the tickets and delete the
> spam ones.  This is less than ideal - it wastes time, and since I
> can't deal with them immediately, there will generally be at least a
> couple of spam tickets.
I checked with SF and they plan to add support for email ticket 
notifications still this week. I don't have a problem requiring users to 
register before they can post though, so perhaps we should activate that 
anyway.

Regards,

Dreas

RE: Important change regarding creating bug reports / feature requests

[Benedict W. <Ben...@cs...>]

----Original Message-----
From: Tony Meyer [mailto:to...@sp...]
Sent: 19 July 2009 00:19
To: pyz...@li...
Subject: Important change regarding creating bug reports / feature requests

>Hi everyone,
>
>Unfortunately, since the (necessary) change to SourceForge-hosted Trac
>for bug reports and feature requests ('tickets'), there has been a
>steady number of spam tickets opened each day.  As far as I can tell,
>there's no way for me to get a notification whenever a new ticket is
>created (this is possible on a normal Trac installation), so that
>means that I have to regularly go through the tickets and delete the
>spam ones.  This is less than ideal - it wastes time, and since I
>can't deal with them immediately, there will generally be at least a
>couple of spam tickets.

My 2 cents worth is this:

I think that going through lots of spam everyday is a dispiriting waste of time.

Unless you can get someone else to manage the process. (I can if that helps).

I do have a sourceforge account somewhere so that seems fine to me.

Carrying on where developer resource is being wasted does not seem like a good idea though.

So either get some help with the tickets or require accounts for now.



Kind Regards

Benedict White

Re: Important change regarding creating bug reports / feature requests

[Andreas S. <sch...@fa...>]

On Sun, 19 Jul 2009, at 11:18, Tony Meyer wrote:

> What are people's opinions about this?  Is requiring a SourceForge
> account too much of a burden for creating a ticket?

I'd say this the best option for now (if there are no alternatives). 
At least it's easy to set up and it's easily reversible.

HTH,

-- 
-- Andreas


   ReAlpine: https://sourceforge.net/projects/re-alpine/
   Reborn Alpine continues UW's Alpine/Pine email client

Re: Important change regarding creating bug reports / feature requests

[Thomas <mai...@ii...>]

Hi Tony,

[..]
> What are people's opinions about this?  Is requiring a SourceForge
> account too much of a burden for creating a ticket?  Can anyone see
> any other options?
I think that if you want to report a bug you will probably do it until 
you have reported even if you must create a SF account. And a lot of 
people already have one as well. Even if I always forget my password 
because I use it once or twice a year I still reports bugs. It takes 
more time but if you want help or your probable bug fixed you have no 
other choices :)

Otherwise, if you really like trac, keep trac. The SVN issue is not so 
important if there is still a spot to browse the source (through SF).

Anyway, you sorting the 'ham' from the spam tickets isn't a solution. 
You waste your time and then you might delete real tickets or you will 
be so bored/annoyed that you won't even fix the bugs and the project 
will die :)

My 2 cents

Cheers,
Thomas

Important change regarding creating bug reports / feature requests

[Tony M. <to...@sp...>]

Hi everyone,

Unfortunately, since the (necessary) change to SourceForge-hosted Trac
for bug reports and feature requests ('tickets'), there has been a
steady number of spam tickets opened each day.  As far as I can tell,
there's no way for me to get a notification whenever a new ticket is
created (this is possible on a normal Trac installation), so that
means that I have to regularly go through the tickets and delete the
spam ones.  This is less than ideal - it wastes time, and since I
can't deal with them immediately, there will generally be at least a
couple of spam tickets.

This isn't something I anticipated - it's quite surprising to me that
a spammer would go to the effort of writing software that would spam
Trac installations (unless it's software that spams any forms and just
happens to work with Trac).  I would expect that the people using Trac
would be sophisticated enough to not click any of the links, so the
return would be zero.  But perhaps I'm overestimating people.

I feel that something needs to change.  I can see a few options:

 * Require authentication to create/modify (not view) tickets.  This
means you'd have to have a SourceForge account to report a bug or
request a feature.  SourceForge accounts are free and easy to create,
but it's likely that many Pyzor users might not have one.

 * Leave things as they are, and accept that some time (that would
otherwise be spent on development) is lost to dealing with the spam
problem, and that there will nearly always be a few spam tickets open
and visible, and there will be an ever-increasing number of closed
spam tickets.

 * I could probably arrange to have a Trac installation hosted outside
of SourceForge. On a custom installation it would be easy to (a) get
notifications and deal with issues promptly, and/or (b) require some
sort of additional hurdle (e.g. the ever-annoying captchas) to create
a ticket, that would be less of a burden than creating a SourceForge
account.  Trac only supports SVN browsing for repositories on the same
server, so this would also mean that the SVN browsing support would
need to be removed (replaced with the generic SF svnview).  Although
this gives the most flexibility and power, I'm reluctant to move the
ticket system in case people perceive it as some sort of move away
from an open, community-driven, project.

 * Consider alternative project hosting.  For example, the project
could probably be hosted on Google Code (and there are probably other
options).  I don't know whether they have a similar problem or not.
This would likely involve a considerable amount of effort, so I
wouldn't want to do it lightly.

What are people's opinions about this?  Is requiring a SourceForge
account too much of a burden for creating a ticket?  Can anyone see
any other options?

Thanks,
Tony

Re: public.pyzor.org timeouts ... Re: interested in mirror server

[Tony M. <to...@sp...>]

> time to make pyzor client code with cache,

Patches are always welcome!  Alternatively, if you think that the
client should cache responses, then please open a feature request
ticket for that.  I'm not 100% sure this is a good idea.  Generally
the client doesn't check multiple messages at once, so the cache would
have to be stored on disk somewhere.  How long should items last in
the cache?  Are clients checking duplicate messages in a short period
of time often?  Having the cached items long-lived seems problematic
since other users could be reporting the same message again (i.e.
increasing the hit count) or whitelisting the message.  Would only
hits be cached, or hits and whitelisted messages and misses?

> or make server to server digest working, and help create more mirrors,

If you want to submit a patch that enables mirroring, you're welcome
to do so.  I don't have any interest in working on that myself, sorry.
 The improved backend database engine code that's coming in the next
release (already in SVN) does make it easy to do this in some cases
(e.g. if you use a SQL database that supports some sort of
replication, like MySQL, then you can just use that to distribute the
data).  However, unless you have a database cluster setup (where you
can write to any server and have that spread out across the servers),
you'd still have to set things up so that writes only went to the
master.  The database backend changes should make it both clearer and
easier to write other backends, so that should also help (e.g. you
might want to try writing one that uses Google App Engine, and use
their BigTable storage as a way of having data in multiple places).

> acl should be so whitelist/report still is not public submits, unless its submitted to localhost or own server

Anyone running a server has complete control over the ACL.  The
public.pyzor.org ACL does not currently allow anonymous users to
whitelist, but does allow anyone to report.  I do want to have a
discussion about this (but haven't got around to starting a thread
yet).  Personally, I think reporting has to stay completely public, or
much of the value of pyzor will be lost.  It seems like there needs to
be more access to whitelisting, however.  This is related to the other
discussions about weighted scores and adding a new "score" command.

> timeout can be adjusted in sa pyzor to wait more,

The pyzor client also has a timeout, which can be set in the configuration file.

Cheers,
Tony

Re: pyzor-users@lists.sourceforge.net - please ignore

[Tony M. <to...@sp...>]

> I'm now using the latest released version (release-0-5-0) rather than
> the trunk.  The error doesn't appear now, so I guess it was something
> particular to what is currently in development, so please ignore my
> previous post.  Sorry about that!

That's ok.  Just to confirm - yes the trunk is a little bit broken at
the moment, sorry.  I'm in the middle of making the changes so that
Pyzor will run under Python 2.6 without lots of warnings (and should
run under Python 3.x after running through 2to3) and there's a bit
more to be done.  It should be done soon, but using 0.5 (or whatever
is the latest release) would still be the best idea in general.

Cheers,
Tony

Re: public.pyzor.org timeouts ... Re: interested in mirror server

[Larry N. <py...@bl...>]

I see a few of these errors every day.  Yesterday there were about 50 out
of about 5000 checks.  Sometimes there are more, sometimes less.  The
errors seem to happen in streaks.

Jul 16 11:19:48 server42 spamd[1051]: pyzor: check failed: internal error

Nedry

re: pyzor-users@lists.sourceforge.net - please ignore

[Alpana W. <al...@ut...>]

Hello,

I'm now using the latest released version (release-0-5-0) rather than 
the trunk.  The error doesn't appear now, so I guess it was something 
particular to what is currently in development, so please ignore my 
previous post.  Sorry about that!

Al

pyzor-users@lists.sourceforge.net

[Alpana W. <al...@ut...>]

Hello,

I am new to Pyzor and indeed Python.  I am trying to use Pyzor on the 
command line to check a mail and I get this:

al@pepperpot:~$ ./pyzor/trunk/pyzor/scripts/pyzor check < Breitling.eml
Traceback (most recent call last):
 File "./pyzor/trunk/pyzor/scripts/pyzor", line 7, in <module>
   import pyzor.client
 File "/home/al/pyzor/trunk/pyzor/lib/pyzor/__init__.py", line 133, in 
<module>
   class Message(email.Message, object):
TypeError: Error when calling the metaclass bases
   __init__() takes exactly 2 arguments (4 given)


Is there a problem with the code or is it something I am doing wrong?  
Any comments appreciated.

Thanks,

Al

Re: public.pyzor.org timeouts ... Re: interested in mirror server

[Dreas v. D. <dr...@sp...>]

Luis Daniel Lucio Quiroz wrote:
> Having another mirror wouldnt reduce that 9% to 4.5% because DNS RR?
>   
Yes that would happen if we would keep the server with a seemingly high 
failure percentage, and add a perfect one without failure. Therefore I 
rather solve the issue at the source so this becomes close to 0% :) We 
will add some monitors to try and determine the cause. Please contact me 
offlist when you experience issues so we can troubleshoot things.

Regards,

Dreas

Re: public.pyzor.org timeouts ... Re: interested in mirror server

[Luis D. L. Q. <lui...@gm...>]

Le jeudi 16 juillet 2009 04:00:15, Andreas Schamanek a écrit :
> On Thu, 16 Jul 2009, at 20:43, Tony Meyer wrote:
> > Is there anything about the existing public.pyzor.org that makes it
> > unsuitable for use?  i.e. is there anything that could be improved
> > that would mean that you didn't see the need to have your own mirror?
>
> My answer is no. Indeed, no matter what I think about it it's no
> because until today I managed to run my mail servers without a local
> pyzor server (though I did think about installing one quite often ;)
> during Pyzor's more troubled times of past years).
>
> Nevertheless, we do see occasional timeouts which I think a
> disrupting the whole idea of Pyzor:
>
> $ grep -ci "reporting to pyzor services" $LOGSPAMJULY
> 2409
> $ grep -ci "^public.pyzor.org:24441.*TimeoutError" $LOGSPAMJULY
> 226
>
> That's a 9 % rate in July.
> Is it just me here in Vienna, Austria?

Having another mirror wouldnt reduce that 9% to 4.5% because DNS RR?

Re: failure to parse response

[Benny P. <me...@ju...>]

On Thu, July 16, 2009 15:06, SCHUH Karl, BFI-Bgld wrote:

Non-encoded 8-bit data (char F6 hex): X-Spam-Report: ...eingegangene
      E-mail als m\366gliche "Spam"-N[...]


you email server have problem with this header, so it will get in my quarantine

maybe relayted to pyzor problem aswell ?

-- 
xpoint