Re: Delivery Behavior
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 [EMAIL PROTECTED] 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
Re: Delivery Behavior
On Mon, 10 May 2004 [EMAIL PROTECTED] 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
Re: Delivery Behavior
[EMAIL PROTECTED] 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"? All of the delivery code is in lmtpd. deliver is just an LMTP client which talks to lmtpd. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp --- 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
Delivery Behavior
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"? Thanks very much! Jack --- 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
