Re: Courier 20240725 development build

Am 12.09.24 um 13:23 schrieb Sam Varshavchik:
> I don't see why cron has to be involved. It's not like the same .courier 
> file needs to be created over, and over again.

How would you do it without creating the same .courier files in every 
virtual home dir?


> You must have some process in place for provisioning new mailboxes. > Something already has to create that maildir when the record for the new
> account gets added to your user database. Well, that something simply 
> needs to install that .courier file, too, as part of the deal.

The account data is set via web. The web process shall not have access 
to the user account that handles the mailboxes.
As our delivery goes to a program, this queries the database and simply 
creates the maildir as needed.


> You are combining bits and pieces of two different things (Courier and 
> Dovecot) that work in different ways.

Yes. But we're unix fellows, for every part of the work I use the tool 
that does its work best.

Courier is great as a mail server but it's webmail is ridiculous 
nowadays. We have had squirrelmail - not a huge difference - for years 
but dropped it because customers did not use it. SIEVE filters are 
supported in thunderbird and roundcube webmail, so this is a huge 
benefit. Courier IMAP was in place for a long time but as mailboxes had 
grown a bit, it's a major improvement to get folders with 20k messages 
opened in no time with dovecot instead of waiting a half a minute for 
courier-imap.

Don't get me wrong, I like the core concepts of courier, some of our 
customers happily keep their own .courier files. Courier's modular 
structure make all of this possible, we could not have this setup with 
any other mail server I'm aware of.

These pieces do not really work in different ways, maildrop in delivery 
mode is just the same as dovecot-mda from the perspective of 
courierlocal. They're both modular and give an excellent stack of software.


> Having said all that, it wouldn't be too complicated to make the 
> alternative + separator character optional, that just adds a little bit 
> more complexity.

My first intuition is that it's not a good idea to hard code a 
replacement of a (valid) character in an email address before looking it 
up in any kind of account database.

The plus sign is often used for extension addresses but technically, 
it's a valid character that one can use in their address. The change 
makes it impossible to have this char in a regular address. The user now 
must be aware of courier's replacement and must define the address with 
a - instead of +. I don't like this in general.




_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users