[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Post ACL



On Sat, 15 Nov 2008, Timo Sirainen wrote:
> > p - post (send mail to submission address for mailbox,
> >        not enforced by IMAP4 itself)
> 
> What exactly does this mean?

That depends on what mail store supports.  If the mail store doesn't have 
any means of injecting messages other than IMAP, then it means nothing.  
If it supports injection of messages to specific mailboxes via SMTP/LMTP, 
then the 'p' right should be used in deciding whether a given injection 
should be permitted.  How it selects an ACL entry (i.e., which authid to 
act as) and whether there are exceptional situations is unspecified and 
therefore implementation dependent.

For example, I would expect most mail stores to permit anonymous delivery 
to a user's INBOX by default, perhaps via a general rule ("don't check the 
ACL for plain <user@domain> delivery") or by initially giving each user's 
INBOX an ACL that gives 'anonymous' the 'p' right.  Alternatively, a 
system that supported filtering via Sieve might treat a user's filter as 
the 'authenticated agent', so that a message delivered via a 'keep' would 
involve checking the ACL as that user instead of as anonymous.


> 1) Assume user+mailbox@domain style addresses are used. Should MDA check 
> the ACLs before allowing delivery to the mailbox?

Sure.


> 2) Should Sieve fileinto check the ACL before it's allowed?

Sure.  I would expect that check to use the identity of the sieve script 
'owner' for that check, where such an identity can be established.


> If answer to either one is "yes", how are the ACL identifiers matched?

Unspecified and implementation dependent, but that's true of basically all 
authentication ID handling in IMAP, no?


How I eventually ended up handling this in Sendmail's product was roughly 
as follows:
- if delivery was specified by an action in a user's sieve filter, the ACL
  check would be as that user
- if a user didn't have a sieve filter then, by default, delivery will be
  to the user's INBOX (+detail will be ignored) and will be permitted
  regardless of the mailbox's ACL
  - alternatively, it can be configured to pass through +detail info
    and check for anonymous having 'p' right when a +detail is supplied
- delivery that's specified by an adminstrative filter generally skips
  the ACL check


Philip Guenther