Delivery Behavior

ms419 at freezone.co.uk ms419 at freezone.co.uk
Wed May 12 17:08:24 EDT 2004


Thanks - point taken.

After consideration, however, I don't clearly understand the increased 
vulnerability.

Calling "mboxlist_createmailbox" from "lmtpd" takes an "auth_state", 
which I presume must have authority to create the specified mailbox. 
For an attacker to flood the system with new mailboxes, they must have 
the required "auth_state"; if they can get this, surely they can 
connect to the IMAP server as it is and create as many mailboxes as 
desired?

Thanks for your feedback,

Jack

On May 11, 2004, at 9:22 AM, Rob Siemborski wrote:

> On Mon, 10 May 2004 ms419 at freezone.co.uk wrote:
>
>> The "[cyr]deliver" manpage explains that if delivery is attempted to a
>> mailbox, "user.userid.mailbox", and "... the  ACL  on any  such
>> mailbox does not grant the sender the "p" right ... then delivers to
>> the INBOX for the userid, regardless of the ACL on the INBOX."
>>
>> If delivery is attempted to any other mailbox, and "... the ACL on
>> mailbox does not grant the sender the "p" right, the delivery fails."
>>
>> In my experience, if delivery is attempted to a mailbox,
>> "user.userid.mailbox", and the mailbox doesn't exist, delivery is also
>> instead made to the INBOX for the userid.
>>
>> Instead of delivery failing or being made to the INBOX, I need
>> nonexistent mailboxes to be created. A patch for Sieve exists to do
>> this - http://email.uoa.gr/projects/cyrus/autosievefolder/ - but I'm
>> not using Sieve.
>>
>> I think a configuration option concerning what to do with messages
>> which couldn't be delivered would be great; reject them, deliver to an
>> INBOX, or create the missing mailbox.
>>
>> I've been through the Cyrus code endeavoring to implement this, but 
>> I'm
>> not an experienced developer. Is the code to by default deliver
>> messages to an INBOX in "[cyr]deliver" or "lmtpd"?
>
> deliver is an lmtp client, so the code is in lmtpd.
>
> However, I need to strongly stress that you very carefully consider the
> security implications of what you are proposing here -- if you were to
> configure cyrus to do this, then an attacker can easily create many
> thousands of mailboxes in short order.  Creating a mailbox is a
> substantially more expensive operation than just delivering a message, 
> and
> it can have much longer-term impact on the system (keep in mind that
> mailboxes.db is, essentially, a global lock -- and if you dump tens of
> thousands of entries into it, it will take longer to process to 
> respond to
> LIST commands and so on).
>
> -Rob
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
> Research Systems Programmer * /usr/contributed Gatekeeper
>
>

---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html




More information about the Info-cyrus mailing list