Re: Re: chkuser parameters via tcp.smtp environment variables

Eric Shubert ha scritto:
> I agree with this as well, for the most part. This is why I think that 
> the option(s) would be better suited as CHKUSER_DISALLOW. IOW, start 
> with things wide open, and let admins specify which characters they 
> choose not to allow.
>
I did not consider it this way. It is reasonable.

> The problem I see with the present implementation is that there is 
> nothing (optional or otherwise) which checks for RFC compliance. There 
> does need to be some sort of sanity check. In situations where the 
> system is configured with a catchall account, there would be no other 
> mechanism for ensuring that the recipient address contained only 
> RFC-compliant characters. There should also be a check on the sender 
> address, as it's easily modified by end users. I would like to see 
> chkuser check for RFC compliance of both sender and recipient 
> addresses. I can see no reason why anyone would not want this feature 
> enabled. If it is optional, I think the default should be enabled, as 
> it's consistent with RFC rules.

Is there a list of defined RFC permitted chars?
In the past I looked for simple RFC rules to check, but probably i did 
not check very deeply. I remember all characters were permitted.

> So to sum this up, I'd like to see chkuser enforce RFC rules by 
> default. Optional parameters would be to loosen things with 
> CHKUSER_ALLOW characters, and to tighten things up with 
> CHKUSER_DISALLOW characters. The default behavior would be strict RFC 
> compliance (the starting point). I believe this would give the best 
> flexibility, along with configuration simplicity.
>
>> But, as said before, it is not easy to chose the right settings, so 
>> I'm open to discuss.
>
> I hear you on that. It takes discussion to arrive at the best 
> solution. While one size won't fit all, I think we can come up a 
> reasonable default which allows for easy tailoring for the exceptions.
>

OK. Let me think on all again. What you say is a good starting point.

>> Anyway, speaking in a wider way, I'm going to plan new changes on 
>> chkuser, but I'm having the impression qmail limits now are limiting 
>> me more than chkuser limits, so I'm thinking if it would be the case 
>> to start a wider project, integrating and extending qmail.
>>
>> I've registered "openqmail.org", and thinking to what can be done in 
>> order to extend qmail in a simpler way.
>>
>> I've done small changes to qmail, besides chkuser,and I'm willing to 
>> make more changes, and I feel what I need (I'm an ISP) probably is 
>> what others need, and viceversa.
>>
>> What do you think?
>
> I'm happy to hear this. Rather than starting something on your own 
> though, I'd really like to see you join with us on the qmail-toaster 
> project. I believe that QMT has a promising future for qmail. There is 
> a large (estimated 12k+ hosts) user base, many of which are ISPs. We 
> have lists for users and development, both of which are fairly active 
> and responsive. We can certainly use your expertise and abilities, and 
> I'm sure your participation will be well received. See 
> http://wiki.qmailtoaster.com/index.php/Main_Page for info about QMT.
>

This is a good point for starting another thread...

I like the idea, but I'd love to stop with patching. Now qmail is in 
public domain, so I don't see reasons why we should not have a decent 
Makefile, a complete source distribution, decent common libraries, mysql 
integration, and a rewrite/improvement of some (a lot) parts of code. A 
lot could be improved, but the horrible DJB coding makes it hard.

Just for example:  actually, you don't have a way to associate together 
all logs for a single message. So, I've changed a lot of coding for 
adding message and delivery numbers to logs, but internal qmail 
behaviour make it impossible to have it working as it should.
Numbers associated to emails and deliveries are the i-node numbers of 
messages, so when you use again a file i-node just released, you use the 
same message and delivery numbers of previous messages!

I'm going to improve and change internal logic for message and delivery 
numbers, but no more patches! :-)

Ciao!

Tonino

/P.S. I have a dream....
/

    /./configure --enable-vpopmail --enable-chkuser --enable-mysql
    --enable-auth ...
    make
    make install/

-- 

------------------------------------------------------------
        Inter@zioni            Interazioni di Antonio Nati 
   http://www.interazioni.it      [email protected]           
------------------------------------------------------------



!DSPAM:4be3133d32711470415542!