Re: chkuser parameters via tcp.smtp environment variables

Tonix (Antonio Nati) wrote:
> 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.

Yes, there is. A simple definition is at 
http://en.wikipedia.org/wiki/E-mail_address#RFC_specification
I expect that this is correct, but would verify the values in RFC 5321 
and RFC 5322, linked to at that page.

>> 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.

Great. I'm happy to bounce ideas back and forth.

>>> 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 agree. Can we take the discussion to the qmailtoaster-devel list? I'm 
there already, as are others interested in QMT development. I use 
gmane.org for list access - it's much simpler for subscribing, and 
there's no filtering required. The list names for QMT on gmane.org are 
gmane.mail.qmail.toaster.devel and gmane.mail.qmail.toaster (users 
list). If you'd rather do it the old fashioned way, see the list 
addresses are [email protected] and 
[email protected]

> 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! :-)

I agree whole heartedly on all counts.
Can we pick up this discussion on the qmailtoaster-devel list?
Thanks.

> Ciao!
> 
> Tonino
> 
> /P.S. I have a dream....
> /
> 
>     /./configure --enable-vpopmail --enable-chkuser --enable-mysql
>     --enable-auth ...
>     make
>     make install/
> 

Sweet, and simple.

-- 
-Eric 'shubes'


!DSPAM:4be32d5732711668420504!