Paul J Stevens wrote:
Aaron Stone wrote:
Ok, it's a plan :-) I'm going to start porting the dsnuser changes
from my
May tree into the current CVS. I figure this'll take one evening to code
and another evening to test. Should be in CVS by this weekend.
Uhm, I hope you're not planning on commiting this to cvs head! This
doesn't sound like something we want to see changed before 2.0-final.
Not that I want to discourage you from doing this.
I guess we really need a more finegrained approach to versioning,
branching and releasing... sigh. Something like mozilla's roadmap
perhaps? So, is it time to branch off the 2_0_something branch to
serve as a base for 2.0.x releases? We can than all continue to work
on HEAD that would serve as a base for preparing 2.1.x unstable
releases, while working toward a 2_2_something branch to springboard
the next stable 2.2.x release series.
I don't think we can do think in a really formal way like Mozilla (or
any other large project) does, because we're just too small for that.
But you're right, we need a better way of doing versioning. Personally,
I'd like to see changes committed earlier (release early & often). This
way, new stuff will probably get tested a lot more. Also, we can keep
the differences between versions a lot smaller.
On the current situation:
Let me state the situation as I think it currently is (correct me if I'm
wrong):
Situation:
If we send a message to [EMAIL PROTECTED], the message will always be
delivered to that mailbox. That means
that if the mailbox does not exist, it will be created on the fly.
Problem:
An attacker can force dbmail to create unlimited numbers of mailboxes by
sending messages to a user, with changing mailbox names.
Possible Solutions:
1. allow only INBOX to be created on the fly, by restricting
db_find_create_mailbox() to only create INBOX.
-> problem: dbmail-smtp user -m mailbox will not work with non-existing
mailboxes anymore.
2. do the restriction in the MTA.
-> problem: we don't know how to do this, and it would be different from
MTA to MTA
3. do some major changes to the delivery chain.
-> problem: we don't want any major changes at this moment.
This is my take on things. I'm in favour of going for solution 1. The
only thing it breaks is the fact that dbmail-smtp -u user -m mailbox
will only succeed if we send to an existing mailbox.
Ilja
--
Ilja Booij
IC&S B.V.
Stadhouderslaan 57
3583 JD Utrecht
www.ic-s.nl
T algemeen: 030 6355730
T direct: 030 6355739
F: 030 6355731
E: [EMAIL PROTECTED]
