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 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 "", 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 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 for list access - it's much simpler for subscribing, and there's no filtering required. The list names for QMT on 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 and

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?



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

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

Sweet, and simple.

-Eric 'shubes'


Reply via email to