Ilja Booij <[EMAIL PROTECTED]> said: > 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. >> [snip] > 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. >
I'd go for option 1, except that I disagree that disabling "-m mailbox creates if not found" is a minor problem... IMHO, it's a big problem, because the sysadmin creating new folders, e.g. for spam control, would have to either ask each user to create them or do some manual database work. Delivery changes at this stage in the game are not so good either, but we can debug any problems that surface by making point releases. Changing major behaviour in a point release would be really bad, so we'd be stuck with no-new-mailboxes for the life of 2.0. I'm going to keep working on the code, and if we decide against it that's fine, if we decide for it, I'll have it done. So I'll hold off on committing to CVS until we've resolved the question of the best solution. Aaron --
