[Kolab-devel] drawbacks if kolabmailboxfilter.php is removed

[Fabio Pietrosanti]

Steffen Hansen ha scritto:

>On Sunday 05 June 2005 14:45, Fabio Pietrosanti wrote:
>  
>
>>Fabio Pietrosanti ha scritto:
>>    
>>
>>>In such situation, would be possible to move the
>>>kolabmailboxfilter.php functionality inside kolabmailfilter.php?
>>>      
>>>
>>Sorry for the typo, kolabmailfilter.php functionality inside
>>kolabfilter.php .
>>    
>>
>
>Actually we had it like this (only one filter -- kolabfilter.php) until 
>some time ago. Problem was that automatic invitation handling (the iCal 
>stuff in the filter) really has to be performed at just before delivery 
>and the other things (like verifying To headers and dealing with 
>Outlook problems etc.) have to be performed before that. So the only 
>solution was to split the filter in two.
>
>If this OpenPEC can accept mail through LMTP, why can't it be placed 
>between kolabmailboxfilter and Cyrus' lmtpd?
>  
>
Sorry for my other typo, OpenPEC could accept only SMTP and output LMTP.

I could also modify kolabmailboxfilter.php using KolabSMTP call (defined
from KolabTransport) but i need to use only one instance of OpenPEC.

OpenPEC will get emails from the frontend postfix and then will deliver to:

 - SMTP (port 10026) envelope signed by OpenPEC
   Those emails are sent to certified isp users and certified isp
mainteiner and are signed with the key of the PEC server (PEC in italian
is Posta Elettronica Certificata which means Certified Electronic Mail)

 - LMTP directly to the mailbox user.
   Those emails are sent to local users and OpenPEC need to be guaranted
that email is delivered.

The test infrastructure is now as follow:
                                                10026 <------
[SMTP FRONTEND->kolabfilter.php] -----> [OpenPEC SERVER] ----LMTP---->
[Cyrus LMTP Server]

This completelly bypass kolabmailboxfilter.php and i don't want that.

I created a "quick and dirty" hacks with amavis because it accept LMTP.

                                                 10026 <------
[SMTP FRONTEND->kolabfilter.php] -----> [OpenPEC SERVER] ----LMTP---->
[Amavis->Postfix->kolabmailboxfilter.php->Cyrus LMTP Server]

But in this second situation Amavis accept email and give an OK to
OpenPEC even if the kolabmailboxfilter.php return an error (let say
quota exceeded or non existing user).
This means a non italian law compliant infrastructure.

OpenPEC during the LMTP session need to know for sure if the email is
delivered or not.
Also i cannot modify easily OpenPEC cause, even if opensource, it's
certified trough a testing procedure from the italian government.

I'm looking for some solutions:
1) Move all kolabmailboxfilter.php functionality to kolabfilter.php and
remove the LMTP delivery functionality to have postfix do the LMTP
delivery job.
    I don't know the impact of this modification and if it broke kolab
design.
   This would be the better solution for me.

2) Write an LMTP Proxy using net-server-mail
(http://rs.rhapsodyk.net/devel/net-server-mail/) that sit between
OpenPEC and kolabmailboxfilter.php giving the "OK" to OpenPEC only then
kolabmailboxfilter.php receive the OK from the Cyrus LTMP Server.
Something like OpenPEC-> LMTP Proxy->kolabmailboxfilter.php->Cyrus LMTP
Server.

What could be the best and most clean solution?

Fabio