[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Post ACL
- To: Timo Sirainen <tss@xxxxxx>
- Subject: Re: Post ACL
- From: Philip Guenther <guenther+imap@xxxxxxxxxxxx>
- Date: Sat, 15 Nov 2008 19:56:27 -0800
- Cc: ietf-imapext@xxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1226807879; bh=Ra+9qfIARP6RnrN9le8aHgt7w8MFyeIUCztD ls+CGFM=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=Jh3xUDS58WKoDhFNCqZOaUEuiqm35FThLtMv6 MS+d+Iak6sWPSJOruNnICsnC8g30kIePApXtE6zRo1/9Sv/ASpsECb8KEFYpXAh+MSd Ut9NleK15pmCOQpIWLusIoU/UDE2pQLKHCCIZfg7ZjwtUMleaGaMjbW8yZyvQeTxOFE =
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1226807793; bh=Ra+9qfIARP6RnrN9le8aHgt7w8MFyeIUCztDl s+CGFM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=vEWlfHgF9Do1BZFJW2ohVz1cb4 CHkOpOhKVf4kLesOVaJN3mdjpnu8L8U+tHe4o3v2p7yrv8g+FVS/12Y4B5NZYyPulED UQG3IYhZjD2mfLL+Qs4VrzPK1V8qhHLQ2BoMx03U9uQyJfBqWuN7AciS3s1K02q2eVW yiay3eqLMvc=
- In-reply-to: <>
- List-archive: <http://www.imc.org/ietf-imapext/mail-archive/>
- List-id: <ietf-imapext.imc.org>
- List-unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>
- References: <>
- Sender: owner-ietf-imapext@xxxxxxxxxxxx
- User-agent: Alpine 1.10 (BSO 962 2008-03-14)
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