Paul J Stevens wrote:
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.
Yup.. that's solution number four.
Because it's such a recent addition, (almost) nobody has been using it.
So there's less pain when we remove it.
grumpy sez...
--
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]
