Gavin Conway | 2 Mar 17:20 2006
Picon

Re: Speed of Perdition

Horms wrote:

>Hugh Messenger <hugh <at> alaweb.com> wrote:
>  
>
>>Gavin Conway wrote:
>>    
>>
>>>After setting up the IMAP capabilities on Perdition we have seen a
>>>marked increase in speed and now have perdition running comfortably
>>>alongside our other implementations. Thanks to Hugh Messenger for the
>>>pointers.
>>>      
>>>
>>Glad I could help.
>>
>>    
>>
>>>One outstanding question though, how does Perdition react when you have
>>>IMAP servers that have different capabilites set? Does it default to the
>>>lowest common denominator?
>>>      
>>>
>>Good question, and I wondered the same when setting up perdition.  The way I
>>understand it, this issue is pretty much outside perdition's control.  The
>>problem is, the client requests the capability list BEFORE logging the user
>>in.  So if you have multiple IMAP servers which you distribute connections
>>to depending on who is logging in, perdition has no idea which server it is
>>going to put the connection through to when the request for capabilities is
>>made.  Hence the requirement to specify the capabilities in perdition.conf
(Continue reading)

Hugh Messenger | 2 Mar 17:51 2006

Re: Speed of Perdition

Gavin Conway wrote:
[snip]
> I don't know how feasible this is but could Perdition not query and then 
> store the capabilities of each server once it has connected to it once? On 
> first connect it stores the capabilities of the server in memory so that 
> each subsequent connection is running with as many capabilities as 
> possible.

Unless I'm having a brain burp (which isn't unusual at this time of day), I 
don't think this would solve the problem, because Perdition still doesn't 
know which server a given client will be connecting to when the capabilities 
are requested. It goes back to the same problem ... the client makes the 
capabilities request BEFORE it logs the user on.  So when the capabilities 
request is made, Perdition doesn't have the username, hence can't look it up 
in whatever database is being used to map users to servers.

Personally I don't see any solution to this problem (beyond the existing 
"lowest common denominator" approach Perdition currently uses) that doesn't 
involve seperate proxies, each serving a specific group of users / IMAP 
servers which have different capabilities.

Fortunately, as things stand, I don't think the common denominator approach 
is a huge problem, as there are not really that many capabilities which make 
a significant difference that aren't supported by any decent, relatively up 
to date IMAP server.  But that isn't to say future RFC's and server 
development efforts might not introduce such variations, and make this a 
bigger deal than it is right now.

As usual, this is just my opinion, I'm no Perdition or IMAP expert, YMMV, 
etc etc.
(Continue reading)

prueba nevera | 3 Mar 15:34 2006
Picon

Re: perdition vanessa logger and thunderbird

Horms wrote:
> connor <connor <at> fuerzag.ulatina.ac.cr> wrote:
>   
>> hello i??m testing perdition and works great for a couple of days, i have
>> the error with vanessa logger fixed with:
>> --- perdition.c.orig    2006-02-19 09:48:29.000000000 -0600
>> +++ perdition.c 2006-02-19 10:36:00.000000000 -0600
>>  <at>  <at>  -530,7 +530,7  <at>  <at> 
>>     pid_file = NULL;
>>
>>     /* Reopen the logger, the child gets its own FDs */
>> -    vanessa_logger_reopen(vanessa_logger_get());
>> +    /*vanessa_logger_reopen(vanessa_logger_get());*/
>>
>>     if((client_io=io_create_fd(s, s, PERDITION_LOG_STR_CLIENT))==NULL){
>>       VANESSA_LOGGER_DEBUG("io_create_fd 2");
>>
>> but when i try to send a message with thunderbird i get this in the console:
>>
>> 2006-02-22_14:55:13.87679 Feb 22 08:55:13 perdition[9270]: CLIENT: "366
>> list \"\" \"Sent\"\r\n"
>> 2006-02-22_14:55:13.88038 Feb 22 08:55:13 perdition[9270]: REAL:   "366
>> OK LIST completed\r\n"
>> 2006-02-22_14:55:13.88290 Feb 22 08:55:13 perdition[9270]: CLIENT: "367
>> create \"Sent\"\r\n"
>> 2006-02-22_14:55:13.88365 Feb 22 08:55:13 perdition[9270]: REAL:   "367
>> NO Invalid mailbox name.\r\n"
>>
>> i think this should be Inbox.Sent.
>>     
(Continue reading)

Emmanuel Tubacher | 6 Mar 10:49 2006
Picon

makebdb usage help please.

Hello,

I have just subscribed to this list.

I am trying to set up a user/server Berkeley DB for perdition using the
makebdb tool.

But the documentation is very simple and I can't figure how to input
the key:value pairs on the command line for each entry of user/email/server.
I have tried taking a look at the C source code, but it didn't make
sense, except for the following comment ;)
/*Warning: This loop contains some of the worst code ever written*/

I feel silly because I'm sure it is straightforward to use, so any help
is welcome !

Thanks in advance.

Emmanuel.

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.

Horms | 9 Mar 11:24 2006
Picon

Re: makebdb usage help please.

Emmanuel Tubacher <Emmanuel.Tubacher <at> cephb.fr> wrote:
> Hello,
> 
> I have just subscribed to this list.
> 
> I am trying to set up a user/server Berkeley DB for perdition using the
> makebdb tool.
> 
> But the documentation is very simple and I can't figure how to input
> the key:value pairs on the command line for each entry of user/email/server.
> I have tried taking a look at the C source code, but it didn't make
> sense, except for the following comment ;)
> /*Warning: This loop contains some of the worst code ever written*/
> 
> I feel silly because I'm sure it is straightforward to use, so any help
> is welcome !

There should be a Makefile installed into /etc/perdition which
will create the db file for you as long as you put the
plaintext into a file called popmap

Otherwise, just run this command

makebdb popmap.bdb.db < popmap

Where, popmap is the plaintext input, and popmap.bdb.db is the binary output.

--

-- 
Horms

(Continue reading)

Emmanuel Tubacher | 9 Mar 12:03 2006
Picon

Re: makebdb usage help please.

Horms a écrit :

>Emmanuel Tubacher <Emmanuel.Tubacher <at> cephb.fr> wrote:
>  
>
>>Hello,
>>
>>I have just subscribed to this list.
>>
>>I am trying to set up a user/server Berkeley DB for perdition using the
>>makebdb tool.
>>
>>But the documentation is very simple and I can't figure how to input
>>the key:value pairs on the command line for each entry of user/email/server.
>>I have tried taking a look at the C source code, but it didn't make
>>sense, except for the following comment ;)
>>/*Warning: This loop contains some of the worst code ever written*/
>>
>>I feel silly because I'm sure it is straightforward to use, so any help
>>is welcome !
>>    
>>
>
>There should be a Makefile installed into /etc/perdition which
>will create the db file for you as long as you put the
>plaintext into a file called popmap
>
>Otherwise, just run this command
>
>makebdb popmap.bdb.db < popmap
(Continue reading)

Ier Zak | 12 Mar 15:49 2006
Picon

log perdition in perdition 1.13

hello all,

my perdition will down if the log file size is more
than 2 Gb, it is bug in perdition 1.13 or what ? 

any one help me about this problem ? 
or someone have script for break log file when the
file more than 2 Gb ?

thx
zakier

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.

G.W. Haywood | 12 Mar 16:56 2006
Picon

Re: log perdition in perdition 1.13

Hi there,

On Sun, 12 Mar 2006, Ier Zak wrote:

> my perdition will down if the log file size is more
> than 2 Gb, it is bug in perdition 1.13 or what ?

It is not really a bug so much as an executable which cannot handle
large files (files greater than 2^31 bits in size).

Instead of letting perdition write log files directly, you can use the
'syslog' daemon to write them, alternatively you can use 'logrotate'
to, er, rotate your logfiles before they get too big.  (My feeling is
that 2GByte log files are too big. :)

See the following manpages:

man syslogd
man logrotate

73,
Ged.

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.

(Continue reading)

Peter Mann | 12 Mar 19:48 2006
Picon

Re: log perdition in perdition 1.13

On Sun, Mar 12, 2006 at 06:49:07AM -0800, Ier Zak wrote:
> my perdition will down if the log file size is more
> than 2 Gb, it is bug in perdition 1.13 or what ? 
> 
> any one help me about this problem ? 
> or someone have script for break log file when the
> file more than 2 Gb ?

try logrotate

-- 

5o   Peter.Mann at tuke.sk

--

-- 
Perdition - http://www.vergenet.net/linux/perdition/
To UNSUBSCRIBE, email to lisa <at> vergenet.net, with a body:
unsubscribe perdition-users your-email-address <at> some.domain
where "your-email-address <at> some.domain" is YOUR email address.

Graham Leggett | 15 Mar 00:31 2006

imaps works, imap + tls doesn't

Hi all,

I have an existing perdition installation currently installed --ssl_mode 
ssl_all (imaps on port 993 connecting to imaps 993 backend, over an 
insecure network), and this works fine.

I am now trying to configure a parallel perdition installation with 
--ssl_mode tls_all_force, in other words IMAP+TLS to IMAP+TLS on the 
backend, and this is giving me a cryptic error.

The backend is courier-imap, and both SSL(993) and TLS(143) works fine.

When I try to connect using TLS over port 143 from Thunderbird, I get 
this in the log:

Mar 14 17:04:13 chandler perdition[1897]: username_mangle: username_strip
Mar 14 17:04:13 chandler perdition[1897]: main: username_mangle 
STATE_GET_SERVER

Mar 14 17:04:13 chandler perdition[1897]: Fatal error manipulating 
username for
client "yy.yy.yy.yy": Exiting child

The usernames are email addresses, and in my case should not be mangled, 
thus the query_key setting of \U.

The usernames are not mangled in the SSL case which works correctly, 
which leaves me very confused.

Does anyone know what this error is trying to tell me?
(Continue reading)


Gmane