From: Victor Duchovni (no email)
Date: Mon May 16 2005 - 17:21:19 EDT
On Mon, May 16, 2005 at 04:39:22PM -0400, Scott Balmos wrote:
> > Just refile the message into the shared folder. Works for all IMAP
> > clients I have seen.
> >
>
> Uhhh, yes that does work... That would be unacceptable to general users,
> though. That would essentially involve
>
> 1) Writing the message
> 2) Saving to a temporary spot in the mail program (the Drafts folder?)
> 3) Moving that saved message from Drafts into the appropriate folder
Some mail clients support "Fcc:" (e.g. mutt), others allow saving
drafts or copying from "Sent". MUAs with macro support may be able
combine saving into a folder and sending... Thunderbird has:
Options->Save a copy To->IMAP Account Name->Folder:
Message-ID: <42890B3E dot 6070803 at domain dot org>
Date: Mon, 16 May 2005 17:06:06 -0400
From: Viktor Dukhovni <>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:
Subject: test
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
test with Thunderbird
> and would also negate other email distribution functionality, such as
> replying both to the shared folder and users (like is common on this list)
> in one operation.
Well if the shared folder needs to appear in Cc: or Reply-To: mail
headers, then it really is an RFC822 mailbox, and it that case, use
ordirnary email addresses, and the usual restriction classes based
access control. This is not usually the case with access controlled
folders.
> The point is I'm trying to treat the shared folder submission point as
> normal email addresses. I understand the security implications that you
> are suggesting, and that what's being requested is essentially an ugly
> hack. The same thing was said about my policy server two months ago when I
> asked about it, yet it's working fine and sufficiently securely. This is
> also why I know this will probably remain an internal change that is not
> used in the open, which I'm okay with.
>
You want access control without direct authentication (because mail
arrives indirectly via SMTP). This is not available.
The LMTP delivery could be ehhanced to disclose the SASL username, but
this only helps for single hop environments and in any case raises the
serious question of the meaning of the AUTH=addr-spec primitive.
The RFC is remarkably opaque on what information AUTH=addr-spec is
expected to convey... Is it an email address or a principal name? If a
principal name, relative to what realm and mechanism? If an email
address, how is the LMTP server to associate the address with a
security principal (that's the MTA's job)?
What you are asking for is only possible in closed systems where the
MUA is tightly integrated with the store. A direct IMAP client is one
lightweight model. An single fully-featured groupware system is another.
Outside the boundaries of groupware systems or single IMAP servers, the
secure end-to-end delivery (with sender authentication) to an access
controlled mailbox is not really possible (unless you want to use
S/MIME or PGP :-).
-- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: <mailto:?body=unsubscribe%20postfix-users>
|
|
|