[Dovecot] Another numptie question - making maildirs for shared mailboxes.
Hi there,
Sorry to have so much trouble with my Dovecot setup & to ask so many questions, but I'm having some problems with shared folders. I've read the thread at <http://dovecot.org/pipermail/dovecot/2005-January/006079.html> and added the following lines to /etc/dovecot.conf:
namespace private {
separator = /
prefix =
inbox = yes
}
namespace public {
separator = /
prefix = General/
location = maildir:/tmp/dovecot-test/
inbox = no
hidden = no
}So I create a directory /tmp/dovecot-test/ and an empty file
/tmp/dovecot-test/dovecot-shared with liberal (777 & 666 respectively)
permissions and then try to subscribe to the "General" folder in
Outlook - I get a "failed to subscribe to the folder. The server
responded the mailbox doesn't exist: General" error message, but cur,
new & tmp are created in /tmp/dovecot-test. These subfolders are owned
by the user that attempted to subscribe & have 700 permissions;
chmod'ing them 777 makes no difference.
Since "default_mail_env = maildir:%h/.maildir" in dovecot.conf I make a directory /tmp/dovecot-test/.maildir also containing cur, new, tmp & dovecot-shared. When I select "IMAP folders" in Outlook I am still unable to subscribe to "General" but am now able to subscribe to "General/maildir". The subscribed folder is shown in Outlook underneath the users' Inbox as a sub-folder of general, screenshot at <http://linux.stroller.uk.eu.org/DovecotSharedFolders.png> - see how I can't subscribe to "General" alone, but it is "brought in" by subscribing to "General/maildir"? If I try to copy a test message into General then, after a delay of a minute or so, I get "Can't move the items - this IMAP command could not be sent to the server before the connect was terminated"; if I try to copy the test message into General/maildir then I immediately get "Can't copy the items. The server responded: `Internal error occurred. Refer to server log for more information [2005-12-20 12:05:40]".
I've tried tinkering with other directory structures under /tmp/dovecot-test/ with no success - can anyone suggest what I'm doing wrong, please?
It's quite important to me that the "General" folder is a fairly high-level one - only one additional folder icon should show up for the users' shared mail. At one point I managed to create a folder General/General, but that's undesirable - the users wouldn't understand the concept of having a folder showing in Outlook that they can't write to, or which is only used as a container for another folder. (In any case, I believe I was still unable to write to it).
I was about to say, "I know I could resolve this with the use of a symlink-type shared folder, but that's undesirable because I'd have to manually add the symlink for each user that's added to the system", but writing this it occurs to me that I could resolve that by adding the symlink to the the etc/skel/. Nevertheless, I see the namespaces approach as more elegant, as it allows for different user groups having different shared folders.
I'd appreciate any advice - I suspect I'm just getting the directory hierarchies wrong, or the syntax of dovecot.conf wrong AGAIN! If anyone with a working shared folders setup could provide a copy of the appropriate section of dovecot.conf & a listing of the appropriate directories then I'd be EXTREMELY grateful.
Stroller.
I always keep a copy of messages sent.
With a particularly large message (pictures etc), being sent from a far remote location, I noticed that the message and the copy were both sent from the client - rather than having the message sent (through my mail server) and then copied locally within the mail server.
Is there a way to configure Dovecot (or postfix?) so the local copy is done?
Thanks for your time.
Bob G
On 5/8/2008 5:22 AM, Bob Gustafson wrote:
I always keep a copy of messages sent.
With a particularly large message (pictures etc), being sent from a far remote location, I noticed that the message and the copy were both sent from the client - rather than having the message sent (through my mail server) and then copied locally within the mail server.
Is there a way to configure Dovecot (or postfix?) so the local copy is done?
This has been asked more than once here and elsewhere, and sadly the short answer is 'no'... I'd love to see support for this too, but it just has to do with how smtp works.
A couple of options...
If you use postfix for your MTA, you could simply disable saving sent messages in tbird, and set up sender BCC maps in postfix so that a copy of each users sent mail is dumped into their Sent folder.
I've never felt adventurous enough to set this up, so if you give it a try I'd be interested in hearing follow-ups...
Also, if you have webmail access as an option, you could use it whenever you are sending a large message - then the attachment only has to be uploaded once.
--
Best regards,
Charles
Hi there,
Charles Marcus pisze:
On 5/8/2008 5:22 AM, Bob Gustafson wrote:
I always keep a copy of messages sent.
With a particularly large message (pictures etc), being sent from a far remote location, I noticed that the message and the copy were both sent from the client - rather than having the message sent (through my mail server) and then copied locally within the mail server.
Is there a way to configure Dovecot (or postfix?) so the local copy is done?
This has been asked more than once here and elsewhere, and sadly the short answer is 'no'... I'd love to see support for this too, but it just has to do with how smtp works.
A couple of options...
If you use postfix for your MTA, you could simply disable saving sent messages in tbird, and set up sender BCC maps in postfix so that a copy of each users sent mail is dumped into their Sent folder.
But it won't be saved in the Sent folder, will it? It will just be delivered to the mailbox?
-- Zbigniew Szalbot www.lc-words.com
On 5/8/2008, Zbigniew Szalbot (z.szalbot@lc-words.com) wrote:
If you use postfix for your MTA, you could simply disable saving sent messages in tbird, and set up sender BCC maps in postfix so that a copy of each users sent mail is dumped into their Sent folder.
But it won't be saved in the Sent folder, will it? It will just be delivered to the mailbox?
Like I said, I haven't done it (yet - I'm planning on trying to get it working someday, hopefully sooner than later) - but yes, you should be able to force the copy to the Sent folder...
Here is a link to the last message in a recent thread discussing how you might do this, if you feel adventurous - in short, a combination of sender_bcc_maps and the delivery agent (maildrop and dovecot LDA were specifically mentioned):
http://archives.neohapsis.com/archives/postfix/2008-01/0812.html
Here's the link to the beginning of the thread, if you want to read the whole thing:
http://archives.neohapsis.com/archives/postfix/2008-01/thread.html#712
--
Best regards,
Charles
Charles Marcus wrote:
On 5/8/2008, Zbigniew Szalbot (z.szalbot@lc-words.com) wrote:
If you use postfix for your MTA, you could simply disable saving sent messages in tbird, and set up sender BCC maps in postfix so that a copy of each users sent mail is dumped into their Sent folder.
But it won't be saved in the Sent folder, will it? It will just be delivered to the mailbox?
Like I said, I haven't done it (yet - I'm planning on trying to get it working someday, hopefully sooner than later) - but yes, you should be able to force the copy to the Sent folder...
Here is a link to the last message in a recent thread discussing how you might do this, if you feel adventurous - in short, a combination of sender_bcc_maps and the delivery agent (maildrop and dovecot LDA were specifically mentioned):
http://archives.neohapsis.com/archives/postfix/2008-01/0812.html
Here's the link to the beginning of the thread, if you want to read the whole thing:
http://archives.neohapsis.com/archives/postfix/2008-01/thread.html#712
Thanks much. When I get back from this trip I will try it out - and report back.
Zbigniew Szalbot wrote:
Hi there,
Charles Marcus pisze:
On 5/8/2008 5:22 AM, Bob Gustafson wrote:
I always keep a copy of messages sent.
With a particularly large message (pictures etc), being sent from a far remote location, I noticed that the message and the copy were both sent from the client - rather than having the message sent (through my mail server) and then copied locally within the mail server.
Is there a way to configure Dovecot (or postfix?) so the local copy is done?
This has been asked more than once here and elsewhere, and sadly the short answer is 'no'... I'd love to see support for this too, but it just has to do with how smtp works.
A couple of options...
If you use postfix for your MTA, you could simply disable saving sent messages in tbird, and set up sender BCC maps in postfix so that a copy of each users sent mail is dumped into their Sent folder.
But it won't be saved in the Sent folder, will it? It will just be delivered to the mailbox?
you can have it delivered wherever you want, provided you configure that.
with a pcre sender bcc like this: /(.*)@example\.com$/ $1@senderbcc.example.com
postfix will deliver a copy to user@sendrbcc.example.com. Then deliver this with
1- dovecot LDA and use Sieve to store the message in the folder you want 2- maildrop and configure it to store the message where you like, or 3- directly with postfix, provided you configure the right virtual_mailbox_maps
mouss wrote:
Zbigniew Szalbot wrote:
Hi there,
Charles Marcus pisze:
On 5/8/2008 5:22 AM, Bob Gustafson wrote:
I always keep a copy of messages sent.
With a particularly large message (pictures etc), being sent from a far remote location, I noticed that the message and the copy were both sent from the client - rather than having the message sent (through my mail server) and then copied locally within the mail server.
Is there a way to configure Dovecot (or postfix?) so the local copy is done?
This has been asked more than once here and elsewhere, and sadly the short answer is 'no'... I'd love to see support for this too, but it just has to do with how smtp works.
A couple of options...
If you use postfix for your MTA, you could simply disable saving sent messages in tbird, and set up sender BCC maps in postfix so that a copy of each users sent mail is dumped into their Sent folder.
But it won't be saved in the Sent folder, will it? It will just be delivered to the mailbox?
you can have it delivered wherever you want, provided you configure that.
with a pcre sender bcc like this: /(.*)@example\.com$/ $1@senderbcc.example.com
postfix will deliver a copy to user@sendrbcc.example.com. Then deliver this with
1- dovecot LDA and use Sieve to store the message in the folder you want 2- maildrop and configure it to store the message where you like, or 3- directly with postfix, provided you configure the right virtual_mailbox_maps or.. just add custom header line like "X-Save-Sent: 1" and use dovecot's LDA + sieve script to store message in "sent" folder. Personally I don't like fake "senderbcc" address for every user. This my catch a lots of spam in "sent" folders.
Uldis Pakuls wrote:
mouss wrote:
[snip]
This has been asked more than once here and elsewhere, and sadly the short answer is 'no'... I'd love to see support for this too, but it just has to do with how smtp works.
A couple of options...
If you use postfix for your MTA, you could simply disable saving sent messages in tbird, and set up sender BCC maps in postfix so that a copy of each users sent mail is dumped into their Sent folder.
But it won't be saved in the Sent folder, will it? It will just be delivered to the mailbox?
you can have it delivered wherever you want, provided you configure that.
with a pcre sender bcc like this: /(.*)@example\.com$/ $1@senderbcc.example.com
postfix will deliver a copy to user@sendrbcc.example.com. Then deliver this with
1- dovecot LDA and use Sieve to store the message in the folder you want 2- maildrop and configure it to store the message where you like, or 3- directly with postfix, provided you configure the right virtual_mailbox_maps or.. just add custom header line like "X-Save-Sent: 1" and use dovecot's LDA + sieve script to store message in "sent" folder.
The discussion is about outgoing mail. Outgoing mail doesn't go to dovecot unless you copy it.
Personally I don't like fake "senderbcc" address for every user. This my catch a lots of spam in "sent" folders.
you are confusing sender bcc with virtual aliases.
Personally I don't like fake "senderbcc" address for every user. This my catch a lots of spam in "sent" folders.
you are confusing sender bcc with virtual aliases.
What about spam with a faked FROM address which seems to be from a local user? I think the point is that this strategy can cause a copy of the spam to end up being added as a sent item. The extra header field was being added presumably to identify real sent mail from faked spam and hence only add real sent messages to the sent folder?
Ed W
Ed W wrote:
Personally I don't like fake "senderbcc" address for every user. This my catch a lots of spam in "sent" folders.
you are confusing sender bcc with virtual aliases.
What about spam with a faked FROM address which seems to be from a local user? I think the point is that this strategy can cause a copy of the spam to end up being added as a sent item.
there are two cases:
- you enforce authentication and sender-login match. in this case, you detect forgeries
- you don't. in this case, you can't detect forgeries. and a header won't help. the whole approach breaks.
The extra header field was being added presumably to identify real sent mail from faked spam and hence only add real sent messages to the sent folder?
and how do you add a header only to "really" sent mail? and anyway, how do you deliver a _copy_? remember that this is outgoing mail and won't naturally go through dovecot.
mouss wrote:
there are two cases:
- you enforce authentication and sender-login match. in this case, you detect forgeries
Lots of people like to allow authenticated users to send messages out with their own choice of FROM address (you paid for an smtp service - my opinion is that you should be allowed to use it for all your messages...). Possibly I misunderstand sender-login maps on postfix though and this is actually allowed (does it work by stopping you pretending to be another local user, but NOT limiting you from being a random other user, eg xxx@abcd.com ?)
- you don't. in this case, you can't detect forgeries. and a header won't help. the whole approach breaks.
His point was that the header could be added at the client end - not all that scalable, but a good idea.
What seems to be missing from postfix (my understanding), but would be very useful, is a map which is based on authenticated sender name (we have maps based on FROM, but not authenticated user...) - this would allow stuff like more flexible restrictions on what a user can do based on the user themselves rather than the FROM address they are using... Possibly my misunderstanding though?
The extra header field was being added presumably to identify real sent mail from faked spam and hence only add real sent messages to the sent folder?
and how do you add a header only to "really" sent mail? and anyway, how do you deliver a _copy_? remember that this is outgoing mail and won't naturally go through dovecot.
Perhaps I misunderstand the idea - but what I think was wanted was that every sent email from an authenticated sender would be bcc'd back to the person it came from. Then when it's being delivered back to the person who sent it (ie deliberate mail loop back) we detect that it's our own message "bouncing" back and stick it in the sent items folder instead of the inbox. The finesse is then reliably detecting which is which....
The point raised later in the thread is that it's quite hard to detect mail being bcc'd back to us for putting in sent items and mail being dropped onto the server with a forged FROM address. As you correctly point out some restrictions on authenticated user help. The previous poster pointed out that hard to guess client headers inserted in all genuine email are also useful
I think we are all trying for the same thing, but anyway...
Good luck
Ed W
Ed W wrote:
mouss wrote:
there are two cases:
- you enforce authentication and sender-login match. in this case, you detect forgeries
Lots of people like to allow authenticated users to send messages out with their own choice of FROM address (you paid for an smtp service - my opinion is that you should be allowed to use it for all your messages...). Possibly I misunderstand sender-login maps on postfix though and this is actually allowed (does it work by stopping you pretending to be another local user, but NOT limiting you from being a random other user, eg xxx@abcd.com ?)
you can use a map of allowed (login, sender) pairs. so a single login can have many authorized addresses.
if you allow any address, then that user can forge the address of someone else (including in yahoo, hotmail, ...). in this case, smtp is not the right way to implement the "copy to Sent" feature under discussion.
- you don't. in this case, you can't detect forgeries. and a header won't help. the whole approach breaks.
His point was that the header could be added at the client end - not all that scalable, but a good idea.
headers may be forged, so it's not secure either. but even if this is not a concern, you are asking users to add a header in their MUA! That's beyond the capacities of most users.
What seems to be missing from postfix (my understanding), but would be very useful, is a map which is based on authenticated sender name (we have maps based on FROM, but not authenticated user...) - this would allow stuff like more flexible restrictions on what a user can do based on the user themselves rather than the FROM address they are using... Possibly my misunderstanding though?
if you want access per login, then you need to implement this in a policy service. but in general, you don't want to allow a user to use an arbitrary sender address.
in an ISP environment, it is easier to setup multiple MSAs to implement different user classes.
The extra header field was being added presumably to identify real sent mail from faked spam and hence only add real sent messages to the sent folder?
and how do you add a header only to "really" sent mail? and anyway, how do you deliver a _copy_? remember that this is outgoing mail and won't naturally go through dovecot.
Perhaps I misunderstand the idea - but what I think was wanted was that every sent email from an authenticated sender would be bcc'd back to the person it came from. Then when it's being delivered back to the person who sent it (ie deliberate mail loop back) we detect that it's our own message "bouncing" back and stick it in the sent items folder instead of the inbox. The finesse is then reliably detecting which is which....
if mail is delivered to Sent folder instead of intended recipients, users will break your bones.
you can try whatever approach, but a COPY is needed so that the message goes both to the intended recipient AND to the Sent folder. and since the folder depends on the sender address, you need either sender bcc or pass all mail to a script or an LDA that will do the copy and resubmit the mail. but resubmitting mail this way is suboptimal.
The point raised later in the thread is that it's quite hard to detect mail being bcc'd back to us for putting in sent items and mail being dropped onto the server with a forged FROM address. As you correctly point out some restrictions on authenticated user help. The previous poster pointed out that hard to guess client headers inserted in all genuine email are also useful
you can put a header to detect forgeries if you like, but you should still use sender bcc to create a copy of outgoing mail.
participants (7)
-
Bob Gustafson
-
Charles Marcus
-
Ed W
-
mouss
-
Stroller
-
Uldis Pakuls
-
Zbigniew Szalbot