Ilja Booij wrote:
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'm sorry to disagree here. The user+mailbox format was committed only two weeks
ago (july 27). If that's creating problems it should be backed out. Solution 1
will break functionality that has been around for a *long* time.
In my view, the untested user+mailbox format hack should not have been allowed
in during the rc phase. Discussion on the bugtracker does not constitute a
proper procedure for inclusion during such a critical phase in my view. Only
bugfixes and critical cleanups (getopt was ok) should be let in.
grumpy sez...
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
