> p - post (send mail to submission address for mailbox, > not enforced by IMAP4 itself) What exactly does this mean? 1) Assume user+mailbox <at> domain style addresses are used. Should MDA check the ACLs before allowing delivery to the mailbox? 2) Should Sieve fileinto check the ACL before it's allowed? If answer to either one is "yes", how are the ACL identifiers matched?
Timo Sirainen wrote: >>p - post (send mail to submission address for mailbox, >> not enforced by IMAP4 itself) >> >> >What exactly does this mean? > >1) Assume user+mailbox <at> domain style addresses are used. Should MDA check >the ACLs before allowing delivery to the mailbox? > > It might. But it needs to map all senders that MDA don't recognize to anonymous. >2) Should Sieve fileinto check the ACL before it's allowed? > I guess that should work in the same way. >If answer to either one is "yes", how are the ACL identifiers matched? > > I would treat the MAIL FROM sender as the username, canonicalizing it first. If the sender has mailbox on the same server, then you can strip plus addressing from it.
On Sat, 2008-11-15 at 18:22 -0600, Alexey Melnikov wrote: > Timo Sirainen wrote: > > >>p - post (send mail to submission address for mailbox, > >> not enforced by IMAP4 itself) > >> > >> > >What exactly does this mean? Are there any other uses for 'p' other than what I mentioned? > >If answer to either one is "yes", how are the ACL identifiers matched? > > I would treat the MAIL FROM sender as the username, canonicalizing it > first. And your server really is already doing that? :) > If the sender has mailbox on the same server, then you can strip > plus addressing from it. I'm not really sure what you mean by this. Strip plus addressing from the MAIL FROM address?
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 <at> 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 <at> 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?
(Continue reading)
On Nov 16, 2008, at 5:56 AM, Philip Guenther wrote: >> 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? Sure, I was just trying to figure out some reasonable way to implement it. > 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 Thanks, this sounds good. I'll probably implement it the same way. I'm not entirely sure about the default 'p' right though. If I give(Continue reading)
On Sun, 16 Nov 2008, Timo Sirainen wrote: ... > I'm not entirely sure about the default 'p' right though. If I give > "anyone +p" right it would mean that user1's Sieve script could do > fileinto "shared/user2/INBOX", which doesn't seem like a good idea. I agree: having a default "anyone +p" is unnecessary and counter-productive when the system has filters to provide fine-grained access-control. > I guess I could create a completely separate "anonymous" user that > doesn't match any other user. Then each mailbox could have by default an > "anonymous +p" right (it would match non-INBOX only when using +detail > addresses). Given that you have per-user filters and can get authentication from that, why would you supply a default "anonymous +p" right at all? Assuming there's a case where it's necessary, are you sure it's needed for mailboxes other than INBOX? Philip Guenther
On Nov 16, 2008, at 8:29 AM, Philip Guenther wrote: >> I guess I could create a completely separate "anonymous" user that >> doesn't match any other user. Then each mailbox could have by >> default an >> "anonymous +p" right (it would match non-INBOX only when using >> +detail >> addresses). > > Given that you have per-user filters and can get authentication from > that, > why would you supply a default "anonymous +p" right at all? Not everyone are using per-user filters. Or filtering at all. > Assuming > there's a case where it's necessary, are you sure it's needed for > mailboxes other than INBOX? I was thinking about the people who are using user+mailbox <at> domain style addressing (and no filtering). Perhaps they'd want to use ACLs to restrict for which mailboxes delivery isn't allowed. The normal case seems to be that they want delivery to work to most of their mailboxes, but maybe there are some exception mailboxes such as Drafts or Sent Messages. Of course maybe I could just ignore these people and assume they don't want to use ACLs at all. :) It would make the implementation easier.
Timo Sirainen wrote: >On Sat, 2008-11-15 at 18:22 -0600, Alexey Melnikov wrote: > > >>Timo Sirainen wrote: >> >> >>>>p - post (send mail to submission address for mailbox, >>>> not enforced by IMAP4 itself) >>>> >>>> >>>What exactly does this mean? >>> >>> >Are there any other uses for 'p' other than what I mentioned? > > I can't think of any other use cases. >>>If answer to either one is "yes", how are the ACL identifiers matched? >>> >>> >>I would treat the MAIL FROM sender as the username, canonicalizing it >>first. >> >> >And your server really is already doing that? :) >(Continue reading)
On Sat, 15 Nov 2008 18:22:20 -0600 Alexey Melnikov <alexey.melnikov <at> isode.com> wrote: > >If answer to either one is "yes", how are the ACL identifiers > >matched? > > > > > I would treat the MAIL FROM sender as the username, canonicalizing it > first. If the sender has mailbox on the same server, then you can > strip plus addressing from it. And there is also the possibility of using an additional parameter in the MAIL FROM: RFC 2554 SMTP Service Extension for Authentication paragraph 5. The AUTH parameter to the MAIL FROM command -- -- Alexandros Vellis National and Kapodistrian University of Athens Network Operations Centre
Alexandros Vellis wrote: >On Sat, 15 Nov 2008 18:22:20 -0600 >Alexey Melnikov <alexey.melnikov <at> isode.com> wrote: > > >>>If answer to either one is "yes", how are the ACL identifiers >>>matched? >>> >>> >>I would treat the MAIL FROM sender as the username, canonicalizing it >>first. If the sender has mailbox on the same server, then you can >>strip plus addressing from it. >> >> > >And there is also the possibility of using an additional parameter in >the MAIL FROM: > >RFC 2554 SMTP Service Extension for Authentication >paragraph 5. The AUTH parameter to the MAIL FROM command > > Yes.
RSS Feed33 | |
|---|---|
21 | |
27 | |
8 | |
17 | |
10 | |
60 | |
6 | |
48 | |
113 | |
7 | |
16 | |
10 | |
2 | |
1 | |
15 | |
2 | |
2 | |
1 | |
2 | |
3 | |
52 | |
1 | |
5 | |
1 | |
10 | |
19 | |
2 | |
4 | |
30 | |
1 | |
12 | |
96 | |
39 | |
6 | |
30 | |
48 | |
6 | |
25 | |
61 | |
1 | |
15 | |
10 | |
68 | |
42 | |
1 | |
9 | |
9 | |
181 | |
26 | |
72 | |
63 | |
2 | |
7 | |
27 | |
43 | |
87 | |
39 | |
87 | |
69 | |
102 | |
55 | |
54 | |
35 | |
28 | |
87 | |
111 | |
18 | |
68 | |
100 | |
43 | |
18 | |
109 | |
74 | |
34 | |
56 | |
21 | |
28 | |
67 | |
35 | |
3 | |
29 | |
19 | |
31 | |
144 | |
57 | |
150 | |
17 | |
9 | |
40 | |
133 | |
24 | |
42 | |
31 | |
31 | |
36 | |
3 | |
25 | |
7 | |
5 | |
88 | |
22 | |
32 | |
30 | |
17 | |
14 | |
80 | |
19 | |
19 | |
3 | |
23 | |
72 | |
15 | |
9 | |
12 | |
34 | |
55 | |
26 | |
16 | |
63 | |
37 | |
9 | |
84 | |
9 | |
32 | |
21 | |
5 | |
26 | |
21 | |
1 | |
3 | |
26 | |
19 | |
32 | |
28 | |
30 | |
1 | |
7 | |
1 | |
2 | |
5 | |
1 | |
10 |
