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 qmailtoaster-devel-subscr...@qmailtoaster.com and
qmailtoaster-list-subscr...@qmailtoaster.com
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!
