courier-users Mailing List for Courier Mail Server
Brought to you by:
mrsam
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(76) |
Jun
(293) |
Jul
(424) |
Aug
(363) |
Sep
(354) |
Oct
(471) |
Nov
(491) |
Dec
(389) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(695) |
Feb
(689) |
Mar
(504) |
Apr
(688) |
May
(563) |
Jun
(531) |
Jul
(693) |
Aug
(783) |
Sep
(695) |
Oct
(681) |
Nov
(884) |
Dec
(669) |
2002 |
Jan
(1269) |
Feb
(1011) |
Mar
(697) |
Apr
(800) |
May
(893) |
Jun
(916) |
Jul
(1013) |
Aug
(975) |
Sep
(903) |
Oct
(824) |
Nov
(675) |
Dec
(597) |
2003 |
Jan
(883) |
Feb
(918) |
Mar
(988) |
Apr
(841) |
May
(973) |
Jun
(701) |
Jul
(514) |
Aug
(602) |
Sep
(667) |
Oct
(599) |
Nov
(531) |
Dec
(536) |
2004 |
Jan
(635) |
Feb
(531) |
Mar
(510) |
Apr
(450) |
May
(509) |
Jun
(401) |
Jul
(335) |
Aug
(372) |
Sep
(310) |
Oct
(307) |
Nov
(401) |
Dec
(313) |
2005 |
Jan
(495) |
Feb
(437) |
Mar
(272) |
Apr
(321) |
May
(354) |
Jun
(380) |
Jul
(274) |
Aug
(250) |
Sep
(260) |
Oct
(251) |
Nov
(278) |
Dec
(365) |
2006 |
Jan
(339) |
Feb
(249) |
Mar
(364) |
Apr
(234) |
May
(252) |
Jun
(186) |
Jul
(253) |
Aug
(178) |
Sep
(180) |
Oct
(138) |
Nov
(222) |
Dec
(239) |
2007 |
Jan
(315) |
Feb
(193) |
Mar
(217) |
Apr
(213) |
May
(180) |
Jun
(297) |
Jul
(190) |
Aug
(214) |
Sep
(189) |
Oct
(244) |
Nov
(209) |
Dec
(86) |
2008 |
Jan
(190) |
Feb
(249) |
Mar
(282) |
Apr
(226) |
May
(180) |
Jun
(116) |
Jul
(269) |
Aug
(144) |
Sep
(148) |
Oct
(149) |
Nov
(179) |
Dec
(192) |
2009 |
Jan
(130) |
Feb
(185) |
Mar
(126) |
Apr
(162) |
May
(171) |
Jun
(58) |
Jul
(142) |
Aug
(61) |
Sep
(44) |
Oct
(108) |
Nov
(101) |
Dec
(44) |
2010 |
Jan
(139) |
Feb
(69) |
Mar
(132) |
Apr
(106) |
May
(129) |
Jun
(65) |
Jul
(106) |
Aug
(91) |
Sep
(60) |
Oct
(64) |
Nov
(61) |
Dec
(62) |
2011 |
Jan
(74) |
Feb
(42) |
Mar
(88) |
Apr
(50) |
May
(23) |
Jun
(20) |
Jul
(30) |
Aug
(33) |
Sep
(21) |
Oct
(24) |
Nov
(64) |
Dec
(48) |
2012 |
Jan
(47) |
Feb
(36) |
Mar
(46) |
Apr
(90) |
May
(39) |
Jun
(49) |
Jul
(28) |
Aug
(31) |
Sep
(42) |
Oct
(49) |
Nov
(26) |
Dec
(30) |
2013 |
Jan
(44) |
Feb
(23) |
Mar
(61) |
Apr
(39) |
May
(19) |
Jun
(20) |
Jul
(36) |
Aug
(100) |
Sep
(84) |
Oct
(19) |
Nov
(13) |
Dec
(39) |
2014 |
Jan
(35) |
Feb
(36) |
Mar
(53) |
Apr
(63) |
May
(75) |
Jun
(32) |
Jul
(16) |
Aug
(48) |
Sep
(104) |
Oct
(22) |
Nov
(48) |
Dec
(46) |
2015 |
Jan
(55) |
Feb
(104) |
Mar
(67) |
Apr
(33) |
May
(75) |
Jun
(76) |
Jul
(51) |
Aug
(35) |
Sep
(12) |
Oct
(24) |
Nov
(30) |
Dec
(17) |
2016 |
Jan
(37) |
Feb
(38) |
Mar
(93) |
Apr
(79) |
May
(91) |
Jun
(27) |
Jul
(53) |
Aug
(20) |
Sep
(37) |
Oct
(7) |
Nov
(36) |
Dec
(49) |
2017 |
Jan
(78) |
Feb
(28) |
Mar
(115) |
Apr
(5) |
May
(49) |
Jun
(10) |
Jul
(48) |
Aug
(25) |
Sep
(34) |
Oct
(60) |
Nov
(26) |
Dec
(56) |
2018 |
Jan
(32) |
Feb
(42) |
Mar
(89) |
Apr
(93) |
May
(30) |
Jun
(74) |
Jul
(32) |
Aug
(20) |
Sep
(55) |
Oct
(26) |
Nov
(25) |
Dec
(13) |
2019 |
Jan
(48) |
Feb
(25) |
Mar
(45) |
Apr
(148) |
May
(15) |
Jun
(92) |
Jul
(91) |
Aug
(31) |
Sep
(46) |
Oct
(41) |
Nov
(37) |
Dec
(45) |
2020 |
Jan
(83) |
Feb
(29) |
Mar
(70) |
Apr
(97) |
May
(62) |
Jun
(13) |
Jul
(25) |
Aug
(12) |
Sep
(68) |
Oct
(37) |
Nov
(57) |
Dec
(86) |
2021 |
Jan
(93) |
Feb
(39) |
Mar
(141) |
Apr
(66) |
May
(68) |
Jun
(41) |
Jul
(27) |
Aug
(25) |
Sep
(34) |
Oct
(25) |
Nov
(47) |
Dec
(15) |
2022 |
Jan
(60) |
Feb
(37) |
Mar
(48) |
Apr
(29) |
May
(37) |
Jun
(25) |
Jul
(22) |
Aug
(14) |
Sep
(25) |
Oct
|
Nov
(29) |
Dec
(11) |
2023 |
Jan
(35) |
Feb
(30) |
Mar
(16) |
Apr
(12) |
May
(7) |
Jun
(19) |
Jul
(32) |
Aug
(45) |
Sep
(59) |
Oct
(33) |
Nov
(10) |
Dec
(30) |
2024 |
Jan
(29) |
Feb
(10) |
Mar
(13) |
Apr
(47) |
May
(11) |
Jun
(29) |
Jul
(32) |
Aug
(19) |
Sep
(16) |
Oct
|
Nov
|
Dec
|
From: Sam V. <mr...@co...> - 2024-09-21 14:12:42
|
Download: https://www.courier-mta.org/download.html Minor bug fixes. Changes: * Fixes several issues with the cdefaultsep configuration setting, which broke mailboxes containing + characters. * rpm and deb packaging improvements. deb packages add an explicit dependency on anacron. rpm packages set the source date epoch |
From: Alessandro V. <ve...@ta...> - 2024-09-16 10:43:34
|
Hi all, some time ago I heard a fellow narrating about his having been mail bombed with so many messages per hour that he had to set his server to answer 421 to all message while he was cleaning up the affected mailboxes. I wondered what would I've done in that case. Failure to react promptly would result in filling out the mailboxes, if not the whole disk. A better way would be to deploy some kind of ratefilter. A possibility is to use iptables' hashlimit on port 25, which, however, doesn't count multiple messages per connection. Or is it worth developing a mail-oriented filter? A very desirable feature would be to tell usual correspondents from newcomers, so as to prioritize the ones, in case of mailbombing, and block the others. But how does a global filter learn which is which? Or should one use maildrop, so as to distinguish which user's folders or extensions are being targeted? Thoughts? Best Ale -- |
From: Sam V. <mr...@co...> - 2024-09-14 21:22:08
|
Bernd Wurst writes: > Am 13.09.24 um 23:51 schrieb Sam Varshavchik: >> That's no different than with dashes. authlib should not be getting the full >> address if a dash is used as a separator character, authlib always gets the >> address stripped of its extension. > > No. Remember my SQL query from the start? > > This is authdaemon log: > > SQL query: SELECT account, cryptpass, clearpass, uid, gid, homedir, > maildir, quota, fullname, options FROM courier_virtual_deliveries WHERE > 'courier' IN ('courier', 'login') AND (account='ber...@be...' > OR (account=CONCAT(SUBSTRING_INDEX('bernd-foobar', '+', 1), '@', > 'berndwurst.de') AND enableextensions=1)) > > Nothing stripped away, nothing altered, ber...@be... is > completely there. Except for that I sent to ber...@be... but > that's what we're talking about. :) Yeah. Reproducible test cases work better than narratives. I have a new build dated today that should fix this, and even with the default confuguration where either + or - is a valid separator actual mailbox names containing a + should now work. |
From: Bernd W. <be...@bw...> - 2024-09-14 05:33:36
|
Am 13.09.24 um 23:51 schrieb Sam Varshavchik: > That's no different than with dashes. authlib should not be getting the > full address if a dash is used as a separator character, authlib always > gets the address stripped of its extension. No. Remember my SQL query from the start? This is authdaemon log: SQL query: SELECT account, cryptpass, clearpass, uid, gid, homedir, maildir, quota, fullname, options FROM courier_virtual_deliveries WHERE 'courier' IN ('courier', 'login') AND (account='ber...@be...' OR (account=CONCAT(SUBSTRING_INDEX('bernd-foobar', '+', 1), '@', 'berndwurst.de') AND enableextensions=1)) Nothing stripped away, nothing altered, ber...@be... is completely there. Except for that I sent to ber...@be... but that's what we're talking about. :) |
From: Sam V. <mr...@co...> - 2024-09-13 21:51:31
|
Bernd Wurst writes: > this. It will surely solve our present issue but I still do not like the > idea that authlib does not get the literal destination address if plus is > configured as extension separator. That's no different than with dashes. authlib should not be getting the full address if a dash is used as a separator character, authlib always gets the address stripped of its extension. The only real weird thing about this is that plusses get replaced with dashes early on in the process, so that everything from that point on sees dash as a separator character. Plus are effectively replaced with dashes. |
From: Bernd W. <be...@bw...> - 2024-09-13 13:15:09
|
Am 13.09.24 um 13:27 schrieb Sam Varshavchik: > That kind of works, but the whole thing feels wobbly. I'm going to guess > that you did not come up with this kind of scaffolding on your own, you > probably followed some guide on the intertubes that explained how to do > such a thing. Wrong guess. This was our own (ever-evolving) creation after some years of courier (and qmail) experience with only real user accounts and aliases. > The same thing is done when - is used as a separator character, which > was the Courier default from the beginning. This is nothing new, only a > more widely accepted practice is now the default behavior. No, the - is never taken away or substituted, it just adds additional features. The authlib lookup for hosted domains always contained the literal destination address, that now gets altered in a destructive way. You can no longer distinguish between user-foo and user+foo. I saw you just introduced a configuration for this. So we can have the old behavior back until we decide where we want to go. Thank you very much for this. It will surely solve our present issue but I still do not like the idea that authlib does not get the literal destination address if plus is configured as extension separator. |
From: Sam V. <mr...@co...> - 2024-09-13 11:27:47
|
Bernd Wurst writes: > Am 13.09.24 um 00:38 schrieb Sam Varshavchik: >>> 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. >> >> And it can create the maildir, and the .courier file together, at the same >> time. Something has to create the maildir. Whatever that something is it can >> also create the .courier file. > > This program is called from the .courier file that is should create. :) Courier's mail delivery mechanism is very flexible and can be used to do all kinds of things. Like this kind of an arrangement, for example. But it doesn't always mean that it's a good idea. >From what I understand, you appear to be creating mail aliases that effectively point to the same account and rely on its sole .courier file to create all the scaffolding the first time a message gets delivered there, and figure out where each message goes, going forward. You might even have a welcome email that gets send immediately to the new alias, that triggers this action. I dimly recall several people, over the years, mentioning that they did something like that, too, That kind of works, but the whole thing feels wobbly. I'm going to guess that you did not come up with this kind of scaffolding on your own, you probably followed some guide on the intertubes that explained how to do such a thing. Just because there's a web site that explains how to do something doesn't mean that its advice is golden. > This procedure only works if all deliveries use the same virtual home dir as > courier would not call anything before the .courier file is created. > > >> From what I can see, plusses are used as email address extensions far more >> often than dashes. > > You are right with this but that's not the point: > You alter the address. Unconfigurable and unconditional. Plusses are taken > away from any further processing. The same thing is done when - is used as a separator character, which was the Courier default from the beginning. This is nothing new, only a more widely accepted practice is now the default behavior. |
From: Bernd W. <be...@bw...> - 2024-09-13 05:43:33
|
Am 13.09.24 um 00:38 schrieb Sam Varshavchik: >> 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. > > And it can create the maildir, and the .courier file together, at the > same time. Something has to create the maildir. Whatever that something > is it can also create the .courier file. This program is called from the .courier file that is should create. :) This procedure only works if all deliveries use the same virtual home dir as courier would not call anything before the .courier file is created. > From what I can see, plusses are used as email address extensions far > more often than dashes. You are right with this but that's not the point: You alter the address. Unconfigurable and unconditional. Plusses are taken away from any further processing. |
From: Sam V. <mr...@co...> - 2024-09-13 00:59:51
|
Download: https://www.courier-mta.org/download.html New development build. Changes: • implements the defaultsep configuration file, that controls which characters are recognized as separators between the mailbox name and an extension. There's a capsule summary of how it works in the dot-courier man page (with some typos). |
From: Sam V. <mr...@co...> - 2024-09-12 22:39:06
|
Bernd Wurst writes: > 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? I meant: the same .courier file does not need to be repeatedly created by a cron job, if it disappears for some mysterious reason. >> 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. And it can create the maildir, and the .courier file together, at the same time. Something has to create the maildir. Whatever that something is it can also create the .courier file. > 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. >From what I can see, plusses are used as email address extensions far more often than dashes. |
From: Alessandro V. <ve...@ta...> - 2024-09-12 16:49:49
|
This version has a few DB and config changes. New parameters support xtag_value (arbitrary tags in the signature) and checkhelo_if_no_auth (a sort of restricted BOFHCHECKHELO). DMARC lookup is done according to the Tree Walk procedure, see https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis#name-dns-tree-walk thus, psddmarc and original_ri have to be removed from config and DB. https://www.tana.it/sw/zdkimfilter/ Best Ale -- |
From: Bernd W. <be...@bw...> - 2024-09-12 15:23:14
|
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. |
From: Sam V. <mr...@co...> - 2024-09-12 11:23:30
|
Bernd Wurst writes: >> But that kind of setup is problematic in other ways, as it does not allow >> other things as well – it would not be possible, for example, to use a per- >> account ~/.mailfilter, unless it twists itself into contortions by looking >> at the environment in order to figure out the right maildir. > > I disagree, this setup did not have any problems until now. > > If we would like to set up a .courier file for each user, we would have to > do this via a cron job and accounts would take some time to be generated. We 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. 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. > avoid this delay as the database has the needed information just in time. > > We deliver messages to maildirs via dovecot-mda that supports SIEVE filters > for each user. So filters are manageable from the MUA. You are combining bits and pieces of two different things (Courier and Dovecot) that work in different ways. You'll find it easier to stick to just one goose in the pot. With Courier, the equivalent functionality is done by using the entire Courier package, enabling sqwebmail, and mail filtering, and then define mail filters after logging in to the account's webmail. sqwebmail's UI is old, and does not play buzzword bingo games with current UI fads (material design, etc…), but it does not require Javascript, and works well with assistive tools just as screen readers, for visually impaired. > So your suggestion is to create and manage hundreds of homedirs and .courier > files for every virtual account via cron jobs? You are already creating a bunch of directories for every user: the maildir itself. This is just one more directory. 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. |
From: Bernd W. <be...@bw...> - 2024-09-12 06:10:58
|
Hi Sam. Thank you for taking time to look into this. Am 11.09.24 um 23:57 schrieb Sam Varshavchik: > The only situation where this won't work would be an unusual setup where > all virtual accounts have the same pseudo-home directory but the maildir > attribute sets a different maildir directory for each virtual account. Bingo. :) Sorry, I forgot to mention this part. It's about virtual accounts where users do not have access to the file system and therefore cannot place .courier files. We deliver all mail to a delivery program we wrote that uses the information from the environment to get mail in the right maildir. This program handles forwardings, autoresponders and other things as per configuration from the database. > But that kind of setup is problematic in other ways, as it does not > allow other things as well – it would not be possible, for example, to > use a per-account ~/.mailfilter, unless it twists itself into > contortions by looking at the environment in order to figure out the > right maildir. I disagree, this setup did not have any problems until now. If we would like to set up a .courier file for each user, we would have to do this via a cron job and accounts would take some time to be generated. We avoid this delay as the database has the needed information just in time. We deliver messages to maildirs via dovecot-mda that supports SIEVE filters for each user. So filters are manageable from the MUA. So your suggestion is to create and manage hundreds of homedirs and .courier files for every virtual account via cron jobs? |
From: Sam V. <mr...@co...> - 2024-09-11 21:58:06
|
Bernd Wurst writes: > In this query, using some SQL magic, I search for a plus sign and discard > everything afterwards to return back the "real" mailbox. SQL looks like this: > > MYSQL_SELECT_CLAUSE SELECT \ > account, cryptpass, clearpass, uid, gid, homedir, maildir, quota, > fullname, options \ > FROM courier_virtual_deliveries \ > WHERE '$(service)' IN ('courier', 'login') \ > AND (account='$(local_part)@$(domain)' OR \ > (account=CONCAT(SUBSTRING_INDEX('$(local_part)', '+', 1),'@', '$ > (domain)') AND \ > enableextensions=1)) \ > [...] > > > With the latest courier upgrade, this SQL lost its magic because the $ > (local_part) gets substituted by courier to never contain any plus sign any > more BEFORE it's handed over to SQL. To translate this into the New World Order: accounts that had enableextensions=1 should simply have a .courier-default file, and everything should continue to work as before, and the second half of this SQL can be simply dropped because it will not do anything. > I'd really like this behavior to be configurable altogether or find a way to > do this only for local .courier file lookups and not for virtual address > handling. It's still configurable, it's just that one would install a .courier-default in the account's home directory, instead of setting enableextensions=1. The only situation where this won't work would be an unusual setup where all virtual accounts have the same pseudo-home directory but the maildir attribute sets a different maildir directory for each virtual account. But that kind of setup is problematic in other ways, as it does not allow other things as well – it would not be possible, for example, to use a per- account ~/.mailfilter, unless it twists itself into contortions by looking at the environment in order to figure out the right maildir. It's unclear from your description whether this is what you have. But if you don't, if all your mailboxes have different home directories, then replacing enableextension with a .courier-default file containing (presumably): ./Maildir then you'll be right back where you started. |
From: Bernd W. <be...@bw...> - 2024-09-11 13:23:55
|
Hi Sam. Am 26.07.24 um 02:25 schrieb Sam Varshavchik: > • Allow using + instead of - as separators for extensions to local email > addresses. I'd like to inform you that this little change has killed our setup of using plus extensions with virtual accounts. We keep our users for our hosted domains in a SQL table and use a custom SQL query in authmysqlrc. In this query, using some SQL magic, I search for a plus sign and discard everything afterwards to return back the "real" mailbox. SQL looks like this: MYSQL_SELECT_CLAUSE SELECT \ account, cryptpass, clearpass, uid, gid, homedir, maildir, quota, fullname, options \ FROM courier_virtual_deliveries \ WHERE '$(service)' IN ('courier', 'login') \ AND (account='$(local_part)@$(domain)' OR \ (account=CONCAT(SUBSTRING_INDEX('$(local_part)', '+', 1),'@', '$(domain)') AND \ enableextensions=1)) \ [...] With the latest courier upgrade, this SQL lost its magic because the $(local_part) gets substituted by courier to never contain any plus sign any more BEFORE it's handed over to SQL. Doing the same magic with "-" will not work because people use this sign regularly in their addresses and we got a good chance to split on the wrong hyphen. I'd really like this behavior to be configurable altogether or find a way to do this only for local .courier file lookups and not for virtual address handling. Don't get my wrong, I like the plus as extension sign and it's okay to extend the hyphen-extension-system to using plus sign but this was propably a bit hasty and has serious side effects. Is there another way to use extension addresses (sub-level-catchall) working with virtual accounts e.g. from SQL? regards, Bernd |
From: Sam V. <mr...@co...> - 2024-08-31 18:35:10
|
Download: https://www.courier-mta.org/download.html New minor releases of courier and courier-imap packages. Changes: * Fixes a bug with correctly enabling UTF8 mode in a proxied POP3 connection. |
From: Bertrand C. <b.c...@ca...> - 2024-08-29 22:09:49
|
> « HTML content follows > > OK, I found why ... > > > Escape character is '^]'. > +OK Hello there. > USER be...@do...d > +OK Password required. > PASS ********* > +OK Connected to proxy server. > UTF8 > -ERR Invalid command. > Connection closed by foreign host. Can you verify that the proxied-to server is also running the same version of Courier. * Good point ! Thank you Sam, it works know ! Incidentally, while looking into this, I discovered a different issue with POP3 UTF8 that I'll need to fix… * Hope it will be not to hard to fix 🙂 Thank you Sam and Krystal for your help and your quick answers. Everything is working know as expected. Bertrand. |
From: Sam V. <mr...@co...> - 2024-08-29 11:49:22
|
Bertrand COTTENET via courier-users writes: > « HTML content follows > > OK, I found why ... > > > Escape character is '^]'. > +OK Hello there. > USER be...@do...d > +OK Password required. > PASS ********* > +OK Connected to proxy server. > UTF8 > -ERR Invalid command. > Connection closed by foreign host. Can you verify that the proxied-to server is also running the same version of Courier. Incidentally, while looking into this, I discovered a different issue with POP3 UTF8 that I'll need to fix… |
From: Bertrand C. <b.c...@ca...> - 2024-08-29 05:22:49
|
OK, I found why ... Escape character is '^]'. +OK Hello there. USER be...@do...d +OK Password required. PASS ********* +OK Connected to proxy server. UTF8 -ERR Invalid command. Connection closed by foreign host. Looking closely to the output you provided, message "OK Logged in" is different in my situation, as we use POP3_PROXY=1 (mailboxes are stored elsewhere). I tried with a local Maildir and POP3_PROXY=0 and the error is gone ... As the mailbox ... Why UTF8 capa is not valid in this context ? Should I do things a different way ? Thank you Regards, [cid:d033eba0-94ac-46e9-abaf-4e9b9d09d487]<https://pro.canl.nc> Bertrand Cottenet RESPONSABLE TECHNIQUE Mob. : (+687) 74 51 25<tel:+68774%2051%2025> b.c...@ca...<mailto:b.c...@ca...> 34 rue Galllieni, BP 49 - 98845 Nouméa Cedex pro.canl.nc<https://pro.canl.nc> [cid:724ecb16-24b1-429a-b759-18ba78bc96ea]<https://www.facebook.com/canlnc> <https://www.facebook.com/canlnc> [cid:b7993581-2a42-4168-8919-ec97de7c23f6] <https://www.linkedin.com/company/canl-nc> Pour l'environnement, n'imprimez ce mail que si nécessaire. ________________________________ De : Sam Varshavchik <mr...@co...> Envoyé : vendredi 16 août 2024 22:38 À : cou...@li... <cou...@li...> Objet : Re: [courier-users] Disable capability UTF8 USER Bertrand COTTENET via courier-users writes: > Hello, > > Sorry, but after installed the latest version (1.3.11) , I still have the > issue with outlook and UTF8. This is not a lot of information to go on. > Imho the real issue is how outlook handles UTF8 capability ... > > So is a way to disable the UTF8 capability ? > I tested another mta and it does not advertise UTF8 USER and don't have the > issue ... ☹ No, the UTF8 capability cannot be disabled. The current version of Courier should accept UTF8 after logging in: [root@jack ~]# telnet localhost pop-3 Trying ::1… Connected to localhost. Escape character is '^]'. +OK Hello there. USER mrsam +OK Password required. PASS ***** +OK logged in. UTF8 +OK UTF8 enabled |
From: Alessandro V. <ve...@ta...> - 2024-08-18 11:27:44
|
Patched, thank you. Best Ale On Sat 17/Aug/2024 22:41:20 +0200 Zenon Panoussis wrote: > > Hi > > I tried to build the 3.20 rpm in mock. It failed with "C compiler > cannot create executables". The solution was easier than it seemed > at first: > > --- zdkimfilter.spec.orig 2024-08-17 14:39:13.317000000 +0000 > +++ zdkimfilter.spec 2024-08-17 14:39:48.949000000 +0000 > @@ -8,6 +8,7 @@ > Group: Applications/Mail > URL: http://www.tana.it/sw/zdkimfilter/ > Source0: http://www.tana.it/sw/zdkimfilter/%{name}-%{version}.tar.gz > +BuildRequires: gcc, make > BuildRequires: courier, opendbx-devel, nettle-devel, libidn2-devel > BuildRequires: libunistring-devel, zlib-devel, uuid, gnutls-devel, libbsd-devel > Requires: courier, opendbx, nettle, libidn2 > > That's because mock does not install the build tools by default. > > Cheers, > > Z > > |
From: Zenon P. <or...@pr...> - 2024-08-18 10:50:17
|
> Maybe you did not notice. The build process does not fail > but produces unstripped binaries. Aha, that's new to me. My build does fail if strip fails. My mock and rpm macros are pristine, so there might be a difference in behaviour between el9 and fedora. Another question mark is over the mock user. I run as user zenon group mock, but I saw courier's login self-tests run as mockbuilder. No idea where that came from, but I became uncertain as to who really runs strip, hence my "a+rw". Cheers, Z -- Слава Україні! Путлер хуйло! |
From: Joost R. <jo...@ru...> - 2024-08-18 08:12:20
|
On 18-08-2024 01:50, Sam Varshavchik wrote: > Zenon Panoussis writes: > >> A completely separate problem with the current src.rpm is >> that it fails to build in mock because too tight permissions >> prevent strip from doing its job. This patch fixes that: >> >> --- courier.spec.orig 2024-08-17 21:08:10.688000000 +0000 >> +++ courier.spec 2024-08-17 21:07:33.825000000 +0000 >> @@ -673,6 +673,13 @@ >> %{__ln_s} `realpath --relative-to /etc/cron.monthly -m >> %{_sbindir}/mkdhparams` >> $RPM_BUILD_ROOT/etc/cron.monthly/courier-mkdhparams >> echo "/etc/cron.monthly/courier-mkdhparams" >>filelist >> >> +## Loosen up permissions in BUILDROOT bindirs to prevent strip >> +## "unable to copy file -- permission denied" in mock. >> +chmod -R a+rw %{buildroot}/usr/lib/courier/libexec/courier >> +chmod -R a+rw %{buildroot}/usr/lib/courier/sbin >> +chmod -R a+rw %{buildroot}/usr/lib/courier/bin >> +chmod -R a+rw %{buildroot}/var/www/cgi-bin >> + >> # >> # Make up some /etc/profile.d scripts >> # >> >> Loosening up permissions at this stage doesn't matter, because >> they are set again as they should be in %files. > > Strange. I use mock occasionally to build Courier for a new Fedora > release before updating to it, and I don't have a recollection of this > build failure. But it doesn't matter, it's simple enough to add this. Maybe you did not notice. The build process does not fail but produces unstripped binaries. I have been using a similar hack for some five years now to build regular packages on Fedora. It is not just affecting the mock build. My dirty hack: sed -i '/^%post$/i chmod -R u+w $RPM_BUILD_ROOT' courier.spec |
From: Sam V. <mr...@co...> - 2024-08-17 23:50:11
|
Zenon Panoussis writes: > A completely separate problem with the current src.rpm is > that it fails to build in mock because too tight permissions > prevent strip from doing its job. This patch fixes that: > > --- courier.spec.orig 2024-08-17 21:08:10.688000000 +0000 > +++ courier.spec 2024-08-17 21:07:33.825000000 +0000 > @@ -673,6 +673,13 @@ > %{__ln_s} `realpath --relative-to /etc/cron.monthly -m % > {_sbindir}/mkdhparams` $RPM_BUILD_ROOT/etc/cron.monthly/courier-mkdhparams > echo "/etc/cron.monthly/courier-mkdhparams" >>filelist > > +## Loosen up permissions in BUILDROOT bindirs to prevent strip > +## "unable to copy file -- permission denied" in mock. > +chmod -R a+rw %{buildroot}/usr/lib/courier/libexec/courier > +chmod -R a+rw %{buildroot}/usr/lib/courier/sbin > +chmod -R a+rw %{buildroot}/usr/lib/courier/bin > +chmod -R a+rw %{buildroot}/var/www/cgi-bin > + > # > # Make up some /etc/profile.d scripts > # > > Loosening up permissions at this stage doesn't matter, because > they are set again as they should be in %files. Strange. I use mock occasionally to build Courier for a new Fedora release before updating to it, and I don't have a recollection of this build failure. But it doesn't matter, it's simple enough to add this. |
From: Zenon P. <or...@pr...> - 2024-08-17 21:31:16
|
Hi Having built and installed the 1.3.11-101 rpm, I got a working courier except for LDAP aliases. Receiving mail fails with authldaplib: refuse to authenticate alias@domain: uid=0, gid=0 (zero uid or gid not permitted) I've had this once before, twenty years ago. I don't remember how I solved it then, but I do remember that it was a lot of pain. Anyway, troubleshooting now from scratch, I realise there is no courierldapaliasd, although courier-ldap is installed: # rpm -ql courier-ldap /usr/lib/courier/share/courierwebadmin/admin-15ldap.html /usr/lib/courier/share/courierwebadmin/admin-15ldap.pl /usr/lib/courier/share/courierwebadmin/admin-15ldapa.html /usr/lib/courier/share/courierwebadmin/admin-15ldapa.pl /usr/share/man/man8/courierldapaliasd.8.gz The binary in /usr/lib/courier/sbin/ is not there. And there is no ldapaliasrc.dist either. I found the latter in the rpm buildroot, but it's not packaged. Adding "BuildRequires: openldap-devel" to the courier-ldap package section of courier.spec produced and packaged courierldapaliasd. Reinstalling the new courier-ldap rpm, as well as courier and courier-maildrop for good measure, fixed the uid=0 problem. It did not fix the missing ldapaliasrc.dist. *** A completely separate problem with the current src.rpm is that it fails to build in mock because too tight permissions prevent strip from doing its job. This patch fixes that: --- courier.spec.orig 2024-08-17 21:08:10.688000000 +0000 +++ courier.spec 2024-08-17 21:07:33.825000000 +0000 @@ -673,6 +673,13 @@ %{__ln_s} `realpath --relative-to /etc/cron.monthly -m %{_sbindir}/mkdhparams` $RPM_BUILD_ROOT/etc/cron.monthly/courier-mkdhparams echo "/etc/cron.monthly/courier-mkdhparams" >>filelist +## Loosen up permissions in BUILDROOT bindirs to prevent strip +## "unable to copy file -- permission denied" in mock. +chmod -R a+rw %{buildroot}/usr/lib/courier/libexec/courier +chmod -R a+rw %{buildroot}/usr/lib/courier/sbin +chmod -R a+rw %{buildroot}/usr/lib/courier/bin +chmod -R a+rw %{buildroot}/var/www/cgi-bin + # # Make up some /etc/profile.d scripts # Loosening up permissions at this stage doesn't matter, because they are set again as they should be in %files. *** Yet another oddity that I noticed while rebuilding the rpm, is that it installed courier in the build environment: # mock -r alma+epel-9-x86_64 --define "debug_package %{nil}" \ --define "mailuser courier" --define "mailgroup courier" \ --define 'notice_option --with-notice=unicode' \ /home/zenon/rpmbuild/SRPMS/courier-1.3.11-101.el9.src.rpm <snip> Installing: courier-authlib-devel x86_64 0.72.3-101.el9 localrepo 48 k courier-unicode-devel x86_64 2.3.0-1.el9 localrepo 227 k expect x86_64 5.45.4-16.el9 appstream 245 k gcc-c++ x86_64 11.4.1-3.el9.alma.1 appstream 13 M gdbm-devel x86_64 1:1.19-4.el9 crb 58 k ghostscript x86_64 9.54.0-16.el9_4 appstream 36 k glibc-langpack-en x86_64 2.34-100.el9_4.2.alma.2 baseos 552 k gnupg2 x86_64 2.3.3-4.el9 baseos 2.5 M gnutls-devel x86_64 3.8.3-4.el9_4 appstream 2.2 M gnutls-utils x86_64 3.8.3-4.el9_4 appstream 287 k groff x86_64 1.22.4-10.el9 appstream 1.2 M hunspell x86_64 1.7.0-11.el9 appstream 322 k libgcrypt-devel x86_64 1.10.0-10.el9_2 appstream 143 k libidn2-devel x86_64 2.3.0-7.el9 appstream 56 k mailcap noarch 2.1.49-5.el9 baseos 32 k make x86_64 1:4.3-8.el9 baseos 530 k mgetty-sendfax x86_64 1.2.1-19.el9 localrepo 146 k netpbm-progs x86_64 10.95.00-2.el9 appstream 2.3 M openldap-devel x86_64 2.6.6-3.el9 appstream 684 k pam-devel x86_64 1.5.1-19.el9 appstream 140 k pcre2-devel x86_64 10.40-5.el9 appstream 471 k perl x86_64 4:5.32.1-481.el9 appstream 11 k perl-ExtUtils-Embed noarch 1.35-481.el9 appstream 16 k procps-ng x86_64 3.3.17-14.el9 baseos 332 k systemd-rpm-macros noarch 252-32.el9_4.6 baseos 69 k wget x86_64 1.21.1-7.el9 appstream 772 k Installing dependencies: acl x86_64 2.3.1-4.el9 baseos 69 k adobe-mappings-cmap noarch 20171205-12.el9 appstream 1.9 M adobe-mappings-cmap-deprecated noarch 20171205-12.el9 appstream 106 k adobe-mappings-pdf noarch 20180407-10.el9 appstream 637 k annobin x86_64 12.31-2.el9 appstream 1.0 M avahi-libs x86_64 0.8-20.el9 baseos 67 k courier x86_64 1.3.11-101.el9 localrepo 1.2 M courier-authlib x86_64 0.72.3-101.el9 localrepo 156 k courier-authlib-config-courier-courier x86_64 0.72.3-101.el9 localrepo 7.1 k courier-unicode <snip> I happened to have an earlier courier in my local repo before I started with 1.3.11-101, so this self-dependency didn't create a problem for me. But it will for anyone trying to build a courier rpm for the first time. I didn't check where the circularity came from. Note: if some very sharp eye catches mgetty-sendfax on this el9 and wonders wtf, it is not a specfile miss. In this aspect the specfile works exactly as intended, but I commented out an %if, %else and %endif in the fax section. , Cheers, Z -- Слава Україні! Путлер хуйло! |