courier-imap — IMAP-related discussion, both Courier specific and general IMAP topics.

Re: [Courier-imap] IMAPD-SSL and esmtp on Debian

[Sam V. <mr...@co...>]

Greg Pfister writes:

> Hi Sam,
>
> This was a working server right up until the point that the certificate  
> expired on Friday. Have made no changes to the firewall, routes, or config  
> files. All I did was shutdown Courier services, change the one file that  
> holds the certificates, etc. And started courier again. The only thing I had  
> to do manually is the 10 or so couriertls running, had to kill those.
>
> Again, no firewall changes made, nor any courier configuration files.

It never hurts to start from step 1 with basic troubleshooting.

It wasn't too long ago I forgot about a firewall rule I put in nearly a  
decade ago after I caught various I-gizmos flooding my upstream bandwidth  
uploading some garbage to 17.0.0.0/8. Now, the same meatbags that polluted  
my network with their I-gizmos had a baulky I-gizmo that I was obligated to  
factory-reset (as the only available nerd in the family), and it couldn't  
reach the mothership. The basic troubleshooting located the firewall rule  
that I forgot about.

So, eliminate the basics, and verify that port 587 is reachable from the  
client IPs. Once it's confirmed that port 587 answers a connection request  
and you get an SMTP banner (since it starts in cleartext) you've eliminated  
that part of the network stack, and can move on to the next layer in the  
software stack.

The next troubleshooting step is to attach strace with the -s 256 -f flags  
to the couriettcpd process that's listening on port 587. An incoming  
connection will log a fork and exec of courieresmtpd, which will exchange a  
few pleasantries before forking and running couriertls. couriertls's strace  
log will show:

1. Both encrypted and unencrypted traffic, since it'll be simultaneously  
talking on the encrypted socket and the unencrypted pipe to courieresmtpd

2. Which files the couriertls process opens. This will include the  
certificate files that it loads, for the connection. esmtpd-msa has its own  
config file. It's not in the default config file but it's theoretically  
possible to overwrite TLS_CERTFILE and have the port 587 daemon load its  
certificate from a different file. If, instead of overwriting the expired
cert file the new one was loaded and the esmtpd file updated, but not esmtpd- 
msa, then that would do it. strace will show it. But that's unlikely. If an  
expired cert is still being served I would expect the client to complain  
instead of hanging.

Alternatively, the new cert file's permissions could be wrong, couriertls  
complains but its error message gets lost, but strace will show it. Still,  
that should also result in a closed connection instead of a hang. A hang  
strongly suggests a firewall issue.

Re: [Courier-imap] IMAPD-SSL and esmtp on Debian

[Greg P. <gpf...@a4...>]

Hi Sam,

This was a working server right up until the point that the certificate expired on Friday.  Have made no changes to the firewall, routes, or config files.  All I did was shutdown Courier services, change the one file that holds the certificates, etc. And started courier again.  The only thing I had to do manually is the 10 or so couriertls running, had to kill those.

Again, no firewall changes made, nor any courier configuration files.



On July 24, 2022 9:00:37 PM EDT, Sam Varshavchik <mr...@co...> wrote:
>Greg Pfister writes:
>
>> Then I checked the logs and realized that I forgot to start the auth, so went back and start it.  Then I restarted all mta / imap services.  Now, I
>
>It is not necessary to restart anything after restarting authdaemon.
>
>> can send messages from outside to this server and it will properly receive and route email.  However, what I can't do, is send through it - client programs just sit and timeout.  Using port 587, and have checked using sl_client and everything looks good.  Again, no errors in log, do see connection, but nothing after that.
>
>This sounds like a firewall. But did you check from the clients' IP address?
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Courier-imap] IMAPD-SSL and esmtp on Debian

[Sam V. <mr...@co...>]

Greg Pfister writes:

> Then I checked the logs and realized that I forgot to start the auth, so  
> went back and start it.  Then I restarted all mta / imap services.  Now, I

It is not necessary to restart anything after restarting authdaemon.
 
> can send messages from outside to this server and it will properly receive  
> and route email.  However, what I can't do, is send through it - client  
> programs just sit and timeout.  Using port 587, and have checked using  
> sl_client and everything looks good.  Again, no errors in log, do see  
> connection, but nothing after that.

This sounds like a firewall. But did you check from the clients' IP address?

Re: [Courier-imap] IMAPD-SSL and esmtp on Debian

[Greg P. <gpf...@a4...>]

Ok, for the record, since my first certificate in 98', I've never had a 
bad issued certificate.  Well, I did.  Created a new csr, got it back, 
installed, and now working.


So, now to the next new thing.  I started all the services in this order:

courier-msa

courier

courier-mta

courier-mta-ssl

courier-imap

courier-imap-ssl

courier-pop

courier-pop-ssl


Then I checked the logs and realized that I forgot to start the auth, so 
went back and start it.  Then I restarted all mta / imap services.  Now, 
I can send messages from outside to this server and it will properly 
receive and route email.  However, what I can't do, is send through it - 
client programs just sit and timeout.  Using port 587, and have checked 
using sl_client and everything looks good.  Again, no errors in log, do 
see connection, but nothing after that.




On 7/24/22 10:50, Sam Varshavchik wrote:
> Greg Pfister writes:
>
>> Updating my GoDaddy Certificate by placing in a pem file, in order, 
>> cert, chain certificates, and key.  MTA and IMAP start in ssl, 
>> however, received while performing a openssl s_client
>>
>>
>> 139637514474880:error:0407E085:rsa 
>> routines:RSA_verify_PKCS1_PSS_mgf1:first octet 
>> invalid:../crypto/rsa/rsa_pss.c:70:
>> 139637514474880:error:1417B07B:SSL 
>> routines:tls_process_cert_verify:bad 
>> signature:../ssl/statem/statem_lib.c:504:
>>
>>
>> Nothing in server logs.
>>
>>
>> I checked each certificate prior and they seem to b in order.  I then 
>> downloaded the entire package from GoDaddy and did it again to no avail.
>
> As a diagnostic try to use couriertls for this test:
>
> addcr | TLS_VERIFYPEER=NONE couriertls -host=localhost -port=143 
> -protocol=imap
>
>
>
>
>
> _______________________________________________
> Courier-imap mailing list
> Cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap

Re: [Courier-imap] IMAPD-SSL and esmtp on Debian

[Sam V. <mr...@co...>]

Greg Pfister writes:

> Updating my GoDaddy Certificate by placing in a pem file, in order, cert,  
> chain certificates, and key.  MTA and IMAP start in ssl, however, received  
> while performing a openssl s_client
>
>
> 139637514474880:error:0407E085:rsa routines:RSA_verify_PKCS1_PSS_mgf1:first  
> octet invalid:../crypto/rsa/rsa_pss.c:70:
> 139637514474880:error:1417B07B:SSL routines:tls_process_cert_verify:bad  
> signature:../ssl/statem/statem_lib.c:504:
>
>
> Nothing in server logs.
>
>
> I checked each certificate prior and they seem to b in order.  I then  
> downloaded the entire package from GoDaddy and did it again to no avail.

As a diagnostic try to use couriertls for this test:

addcr | TLS_VERIFYPEER=NONE couriertls -host=localhost -port=143 -protocol=imap

[Courier-imap] IMAPD-SSL and esmtp on Debian

[Greg P. <gpf...@a4...>]

Updating my GoDaddy Certificate by placing in a pem file, in order, 
cert, chain certificates, and key.  MTA and IMAP start in ssl, however, 
received while performing a openssl s_client


139637514474880:error:0407E085:rsa 
routines:RSA_verify_PKCS1_PSS_mgf1:first octet 
invalid:../crypto/rsa/rsa_pss.c:70:
139637514474880:error:1417B07B:SSL routines:tls_process_cert_verify:bad 
signature:../ssl/statem/statem_lib.c:504:


Nothing in server logs.


I checked each certificate prior and they seem to b in order.  I then 
downloaded the entire package from GoDaddy and did it again to no avail.

Re: [Courier-imap] [courier-users] New releases of courier packages

[PICCORO M. L. <mck...@gm...>]

WE are already over that we must get forward.. but there's something
here that are nly based in that dead "centos" thing:

El lun, 6 jun 2022 a la(s) 21:49, Ángel (an...@16...) escribió:
>
> On 2022-06-06 at 17:58 -0400, Sam Varshavchik wrote:
> > PICCORO McKAY Lenz writes:
> >
> > > why not to be in sync with debian oficial packages, as i know the mantainer
> > > are also in this mail list
> >
> > Their purpose is different. What's packaged in Debian or Ubuntu tends
> > to be older versions; and there have been occasions where people
> > wanted something new from the current version, that's not available
... AND LATER:
>
> > If you're ok with building and deploying the just-released version of
> > courier then it stands that the same goes for courier-unicode and
> > courier-authlib.
>
> I think the point was to have the debian packaging in sync, not that
> the generated package would be an old one.

The idea its precisely that.. i praised the way as alpine does "as
upstream possible"
but something that let the upstream to "thinks" its on correct that as
Manvendra said
Courier are so so stable that some changes are not so important to
DRASTICALLY CHANGES
the generation of a package..

in fact for that there's package managers.. and the upstream are only
developer core of the software,

each people to their work .. when you SAM try to made your things as
you want just created and reinventing the wheel

in fact. many errors and problems were detected thanks to the package
manager on each distributions..

well mostly debian cos i am one of their users.. but now i wants to
support ALPINE and this behaviour fall in double work

ALSO RHEL, SLE12 are still supported and working in many servers.. but
package courier has broken compilations

check it our: the software itself has no important changes .. only
build changes.. to support those problematic constant changes in newer
fashioned distros..

inclusively i made this mail in plain text to support the policy of
the mail list.. (preferible plain text), but you cannot do same in the
other way?

El mar, 7 jun 2022 a la(s) 06:56, Sam Varshavchik
(mr...@co...) escribió:
>
> Manvendra Bhangui writes:
>
> > On Wed, 1 Jun 2022 at 09:39, Sam Varshavchik <mr...@co...> wrote:
> > >
> > > Download: https://www.courier-mta.org/download.html
> > >
> > > New development builds of all packages.
> > >
> > > Changes:
> > >
> >
> > >
> > > - all: updates for gcc 12, autotools, and OpenSSL 3.0.
> > >
> > Not very important, but I thought it could help someone still using
> > ancient distros to compile courier-imap. The latest autotools changes
> > to configure.ac removing AC_PROG_CC_C99 has broken compilation on the
> > following distributions.
> >
> > CentOS7
> > RHEL7
> > SLE12 and all SLE12 variants
> > Ubuntu 16.04
> >
> > I had to do 4 minor changes to make courier-imap compile on all
> > distributions, including the above 3
>
> Autoconf deprecated the AC_PROG_CC_C99 macro, for the ostensibly reason that
> all currently supported major platforms don't need it.
>
> There's automation on Github to automatically build everything on every
> commit, using containers. The CentOS 7 container had no issues building a
> courier-imap centos 7 rpm:




>
> https://github.com/svarshavchik/courier/runs/6764330421?check_suite_focus=true
>
> The likely explanation is that the original compiler that was released for
> CentOS 7 did not default to c++11/C99 by default, but was updated over
> CentOS 7's lifetime to a newer version that does, now.
>
> _______________________________________________
> courier-users mailing list
> cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [Courier-imap] New releases of courier packages

[Sam V. <mr...@co...>]

Manvendra Bhangui writes:

> On Wed, 1 Jun 2022 at 09:39, Sam Varshavchik <mr...@co...> wrote:
> >
> > Download: https://www.courier-mta.org/download.html
> >
> > New development builds of all packages.
> >
> > Changes:
> >
>
> >
> > - all: updates for gcc 12, autotools, and OpenSSL 3.0.
> >
> Not very important, but I thought it could help someone still using
> ancient distros to compile courier-imap. The latest autotools changes
> to configure.ac removing AC_PROG_CC_C99 has broken compilation on the
> following distributions.
>
> CentOS7
> RHEL7
> SLE12 and all SLE12 variants
> Ubuntu 16.04
>
> I had to do 4 minor changes to make courier-imap compile on all
> distributions, including the above 3

Autoconf deprecated the AC_PROG_CC_C99 macro, for the ostensibly reason that  
all currently supported major platforms don't need it.

There's automation on Github to automatically build everything on every  
commit, using containers. The CentOS 7 container had no issues building a  
courier-imap centos 7 rpm:

https://github.com/svarshavchik/courier/runs/6764330421?check_suite_focus=true

The likely explanation is that the original compiler that was released for  
CentOS 7 did not default to c++11/C99 by default, but was updated over  
CentOS 7's lifetime to a newer version that does, now.

Re: [Courier-imap] New releases of courier packages

[Manvendra B. <mbh...@gm...>]

On Wed, 1 Jun 2022 at 09:39, Sam Varshavchik <mr...@co...> wrote:
>
> Download: https://www.courier-mta.org/download.html
>
> New development builds of all packages.
>
> Changes:
>

>
> - all: updates for gcc 12, autotools, and OpenSSL 3.0.
>
Not very important, but I thought it could help someone still using
ancient distros to compile courier-imap. The latest autotools changes
to configure.ac removing AC_PROG_CC_C99 has broken compilation on the
following distributions.

CentOS7
RHEL7
SLE12 and all SLE12 variants
Ubuntu 16.04

I had to do 4 minor changes to make courier-imap compile on all
distributions, including the above 3

1) unicode/configure.ac
add AC_PROG_CC_C99
add -std=c++11 to CXXFLAGS

2) libs/rfc1035
add -std=c99 to CFLAGS

3) libs/rfc2045
add -std=c++11 to CXXFLAGS

4) libs/maildir
add -std=c++11 to CXXFLAGS

Without the above changes courier-imap, unicode compiles on all the
below distributions.

Arch Linux, CentOS8, CentOS8_stream, oracle 8, almalinux 8 Debian 9,
Debian 10, Debian 11, FC35, FC36, SLE15, Univention 4.3, Univention
4.4, openSUSE leap 15.3, openSUSE Leap 15.4, openSUSE Tumbleweed,
Ubuntu 18.04, Ubuntu 19.04, Ubuntui 20.04, Ubuntu 21.04, Ubuntu 21.10,
Ubuntu 22.04

Re: [Courier-imap] [courier-users] New releases of courier packages

[Ángel <an...@16...>]

On 2022-06-06 at 17:58 -0400, Sam Varshavchik wrote:
> PICCORO McKAY Lenz writes:
> 
> > why not to be in sync with debian oficial packages, as i know the mantainer  
> > are also in this mail list
> 
> Their purpose is different. What's packaged in Debian or Ubuntu tends
> to be older versions; and there have been occasions where people
> wanted something new from the current version, that's not available
> in the older versions.
> 
> There isn't much of a use case of mixing and matching. You either
> want what's in the distribution, or you want the latest and greatest.
> If you're ok with building and deploying the just-released version of
> courier then it stands that the same goes for courier-unicode and
> courier-authlib.

I think the point was to have the debian packaging in sync, not that
the generated package would be an old one.

I haven't looked yet into the native deb packaging, but it would indeed
be desirable that the resulting packages are as "compatible" as
possible with the official ones, as in, that the package manager
produces a working courier no matter which packages were already
installed or the user switches to (it is not necessarily that they
could be mixed, only that the package manager sorted them out).

Best regards

Re: [Courier-imap] [courier-users] New releases of courier packages

[Sam V. <mr...@co...>]

PICCORO McKAY Lenz writes:

> why not to be in sync with debian oficial packages, as i know the mantainer  
> are also in this mail list

Their purpose is different. What's packaged in Debian or Ubuntu tends to be  
older versions; and there have been occasions where people wanted something  
new from the current version, that's not available in the older versions.

There isn't much of a use case of mixing and matching. You either want  
what's in the distribution, or you want the latest and greatest. If you're  
ok with building and deploying the just-released version of courier then it  
stands that the same goes for courier-unicode and courier-authlib.

Having said all of that: I tried not to mess up the Debian or Ubuntu  
packaging, it should remain unaffected. I did not create my own debian  
directory at the top of the source tree, it's tucked away elsewhere, and the  
build script puts it in the right place before running debuild. Overall, the  
packaging avoids deviating from the default settings, to be consistent with  
the documentation. Some provisions have been made for notable Debian and  
Ubuntu-specific differences (i.e., a separate subpackage for shared  
libraries and deletion of rpaths, which was a pain to make work).

Re: [Courier-imap] [courier-users] New releases of courier packages

[PICCORO M. L. <mck...@gm...>]

El vie, 3 jun 2022 a la(s) 18:16, Sam Varshavchik (mr...@co...)
escribió:

> Jakob Bohm via Courier-imap writes:
>
> > FYI: Debian has an entire manual detailing rules and procedures for
> > such practical details, it's packaged in the "debian-policy" and
> > "doc-debian" .deb files (different documents, you'll need both).
> > There's apparently a similar Ubuntu document in
> > ubuntu-packaging-guide*.deb .
> >
> > Parts of those manuals are criteria for inclusion in the "main"
> > download section, parts are practical considerations to make
> > packages build automatically across all CPU architectures.
>
> I sort-of came across some of that while working on this. I have my own
> thoughts on some of that, but that would be off-topic here. Suffice to
> say,
> these deb packages should be agreeable with all the major packaging
> guidelines; but deviate on minor, insignificant details.
>

i dont noted that debian dir inside courier sources.. but as i know having
different "details" will harm production servers, so inclusivelly testing
ones will mess with those taks to admins that just want to upgrade or
manage the future releases..

why not to be in sync with debian oficial packages, as i know the mantainer
are also in this mail list



>
> _______________________________________________
> Courier-imap mailing list
> Cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
>

Re: [Courier-imap] [courier-users] New releases of courier packages

[Sam V. <mr...@co...>]

Jakob Bohm via Courier-imap writes:

> FYI: Debian has an entire manual detailing rules and procedures for
> such practical details, it's packaged in the "debian-policy" and
> "doc-debian" .deb files (different documents, you'll need both).
> There's apparently a similar Ubuntu document in
> ubuntu-packaging-guide*.deb .
>
> Parts of those manuals are criteria for inclusion in the "main"
> download section, parts are practical considerations to make
> packages build automatically across all CPU architectures.

I sort-of came across some of that while working on this. I have my own  
thoughts on some of that, but that would be off-topic here. Suffice to say,  
these deb packages should be agreeable with all the major packaging  
guidelines; but deviate on minor, insignificant details.

Re: [Courier-imap] [courier-users] New releases of courier packages

[Jakob B. <jb-...@wi...>]

On 2022-06-02 13:06, Sam Varshavchik wrote:
> Pramathesh Ambasta writes:
>
>> Thanks for uploading the new version.
>>
>> Among the dependencies listed for the deb package build is 
>> libcourierauthlib-dev. The correct library name in a debian system is 
>> courier-authlib-dev. Debian build fails because of this
>
> courier-authlib's package produces libcourier-auth and 
> libcourier-auth-dev packages, so that's what all the others build 
> against.
>
> I was looking around how things were named on Ubuntu, and it seems 
> that nearly every "something>lib" stuff was carrying a 
> "lib<something>" name. I.e. libfakeroot, libgdbm, etc. So that's the 
> naming convention I went with.
>
> The deb packaging scripts in these packages are not based on existing 
> deb packages.
>
FYI: Debian has an entire manual detailing rules and procedures for
such practical details, it's packaged in the "debian-policy" and
"doc-debian" .deb files (different documents, you'll need both).
There's apparently a similar Ubuntu document in
ubuntu-packaging-guide*.deb .

Parts of those manuals are criteria for inclusion in the "main"
download section, parts are practical considerations to make
packages build automatically across all CPU architectures.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: [Courier-imap] [courier-users] New releases of courier packages

[Sam V. <mr...@co...>]

Pramathesh Ambasta writes:

>> The deb packaging scripts in these packages are not based on existing deb  
>> packages.
>>
>>
> Many thanks for your very quick response. So the correct process would be to  
> first download and build courier-authlib from source and then build the deb  
> packages for courier. I will try that

This goes for all packages. The order in which things get built are: courier- 
unicode, courier-authlib, courier-sox (optional), then the rest of the  
packages. This is mentioned in the INSTALL:

   NOTE: If a distribution package is already installed it should be removed
   completely before switching to the upstream version (dnf remove or apt
   purge). Preserve any existing configuration files, beforehand, in order to
   restore it after switching packages. This applies to all Courier packages.
   A switch to this courier package requires switching the courier-unicode
   and courier-authlib packages too.

Re: [Courier-imap] [courier-users] New releases of courier packages

[Sam V. <mr...@co...>]

Pramathesh Ambasta writes:

> Thanks for uploading the new version.
>
> Among the dependencies listed for the deb package build is libcourierauthlib- 
> dev. The correct library name in a debian system is courier-authlib-dev.  
> Debian build fails because of this

courier-authlib's package produces libcourier-auth and libcourier-auth-dev  
packages, so that's what all the others build against.

I was looking around how things were named on Ubuntu, and it seems that  
nearly every "something>lib" stuff was carrying a "lib<something>" name.  
I.e. libfakeroot, libgdbm, etc. So that's the naming convention I went with.

The deb packaging scripts in these packages are not based on existing deb  
packages.

[Courier-imap] New releases of courier packages

[Sam V. <mr...@co...>]

Download: https://www.courier-mta.org/download.html

New development builds of all packages.

Changes:

- all: add build scripts that create installable deb packages, directly from  
source .tar.bz2 files, similar to how rpm packages get built. This was  
implemented on Ubuntu 20 and may or may not work on other Debian-derived  
distributions (the most likely determining factor is going to be names of  
build requirements). The instructions are found in each package's INSTALL  
and are mostly the same for all packages.

- sqwebmail: Fix minor use after free bugs: when showing links to decoded  
PGP attachments, and if the calendar module is enabled, and the calendaring  
server runs out of disk space; when updating the index file. Freed memory  
was read before any additional allocations took place, this reduces  
potential exposure. A diff patch is attached for earlier versions, if an  
immediate update is not possible (this patch should apply to the libs  
subdirectory of courier and sqwebmail packages).

- all: updates for gcc 12, autotools, and OpenSSL 3.0.

- sqwebmail: remove duplicate manpages from standalone sqwebmail install.

- cone: fixes an incompatibility with OpenSSL 3.0

- sysconftool: add sysconftoolize man page, clean up the hierarchy,  
eliminating the docbook symlink.

- courier-imap: fix csh profile script's adjustment of env variables. Fix  
RPM packages' installation script to automatically create temporary self- 
signed certs.

- courier-authlib: remove obsolete configure script code for migrating from  
pre-courier-authlib versions of courier packages. Remove obsolete userdb- 
test-md5 script.

- courier: remove obsolete initialization of /etc/courier/userdb*, this was  
moved to courier-authlib. Replace the webadmin suid binary with a socket- 
based daemon, like sqwebmail.

- courier-analog: add --journal option to read logs from the system journal.

- courier, courier-imap's configure script will run correctly as root.

- courier: Removed fixed uid and gid values that get determined at compile  
time and baked into Courier. courier/mail's uid and gid gets looked up at  
runtime, with minimal cost.

- courier: Fix obscure SASL authentication breakage.

- courier, courier-imap: Additional internal automated tests.

[Courier-imap] New developmer releases of all Courier packages

[Sam V. <mr...@co...>]

Download: https://www.courier-mta.org/download.html

New development builds of all packages.

Changes:

- all: add build scripts that create installable deb packages, directly from  
source .tar.bz2 files, similar to how rpm packages get built. This was  
implemented on Ubuntu 20 and may or may not work on other Debian-derived  
distributions (the most likely determining factor is going to be names of  
build requirements). The instructions are found in each package's INSTALL  
and are mostly the same for all packages.

- sysconftool: add sysconftoolize man page, clean up the hierarchy, eliminating
the docbook symlink.

- sqwebmail: remove duplicate manpages from standalone sqwebmail install.

- courier-imap: fix csh profile script's adjustment of env variables. Fix  
RPM packages' installation script to automatically create temporary self- 
signed certs.

- courier-authlib: remove obsolete configure script code for migrating from  
pre-courier-authlib versions of courier packages. Remove obsolete userdb- 
test-md5 script.

- courier: remove obsolete initialization of /etc/courier/userdb*, this was  
moved to courier-authlib. Replace the webadmin suid binary with a socket- 
based daemon, like sqwebmail.

- courier-analog: add --journal option to read logs from the system journal.

Other changes since the last release:

- courier: Removed fixed uid and gid values that get determined at compile  
time and baked into Courier. courier/mail's uid and gid gets looked up at  
runtime, with minimal cost.

- courier: Fix obscure SASL authentication breakage.

- courier, courier-imap: Additional internal automated tests.

[Courier-imap] New versions of courier, courier-imap, sqwebmail, maildrop, and cone packages released

[Sam V. <mr...@co...>]

Download: https://www.courier-mta.org/download.html

Changes:

- all: update to the the current version of the PCRE library, PCRE2. PCRE2 is
now a build requirement.

- courier, courier-imap: fix minor memory leaks. If valgrind is installed,
"make check" runs it to check for memory leaks.

- courier-imap: use a short timer to kill the couriertls helper if the
server process terminates but openssl hangs trying to shut down the socket.

- courier: fix a parsing bug in the bofh badfrom check.

- courier: do not reject null MX records when validing the sending IP address
against the sender's HELO/EHLO identifier.

[Courier-imap] Courier 1.1.5/Courier-IMAP 5.1.4 released

[Sam V. <mr...@co...>]

Download: https://www.courier-mta.org/download.html

New releases of courier and courier-imap packages.

Changes:

- all: code changes so that courier can be compiled with -Wall -Werror gcc  
flags. The default compilation flags are not changed. This also includes  
changes to the configuration scripts, which includes removing outdated  
configuration settings.

- courier: fix configuration scripts' --with-certsdir option.

- courier: do not specify SMTPUTF8 when sending 7-bit mail.

- pop3: buffer input by ourselves, clear input buffer before switching to  
TLS.

- imap: fix crash if the connection to the client is terminated at the  
wrong/right time.

[Courier-imap] (no subject)

[Sam V. <mr...@co...>]

Download: https://www.courier-mta.org/download.html

New releases of courier and courier-imap packages.

Changes:

- all: code changes so that courier can be compiled with -Wall -Werror gcc  
flags. The default compilation flags are not changed. This also includes  
changes to the configuration scripts, which includes removing outdated  
configuration settings.

- courier: fix configuration scripts' --with-certsdir option.

- courier: do not specify SMTPUTF8 when sending 7-bit mail.

- pop3: buffer input by ourselves, clear input buffer before switching to TLS.

- imap: fix crash if the connection to the client is terminated at the  
wrong/right time.

Re: [Courier-imap] disabling IMAP_MAILBOX_SANITY_CHECK=0 permits mixed account into another?

[PICCORO M. L. <mck...@gm...>]

El mié, 21 de jul. de 2021 a la(s) 08:11, Jakob Bohm via Courier-imap
(cou...@li...) escribió:
>
> On 2021-07-18 02:55, Sam Varshavchik wrote:
> > PICCORO McKAY Lenz writes:
> >> In fact documentation lacks that uid and gid must match directory of
> >> maildir, https://www.courier-mta.org/authlib/README.authmysql.html it
> >> not poin "required"m but if you dont input the uid and gid
> >> virtualusers never work, cos we need to know the owner of the mail box
> >> for delivering.. same problem with maildrop and spamassasing
> >> integration for virtual users
that is the same as:

> Such assumptions/requirements need to be documented, even
> if they happen to be a consequence of a specific code and
> process structure and how that interacts with the uid/gid
> system calls.

YEAH that-s correct and that-s i try to explain!

> Other multi-user daemons such as Exim and Apache already
> document their uid/gid settings and requirements.

AS MUST BE

>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
>
> _______________________________________________
> Courier-imap mailing list
> Cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap

Re: [Courier-imap] disabling IMAP_MAILBOX_SANITY_CHECK=0 permits mixed account into another?

[Jakob B. <jb-...@wi...>]

On 2021-07-18 02:55, Sam Varshavchik wrote:
> PICCORO McKAY Lenz writes:
>
>> El vie, 6 de mar. de 2020 a la(s) 18:49, Sam Varshavchik
>> (mr...@co...) escribió:
>> > There is no law that says all sql records must have the same uid or 
>> gid,
>> > either explicitly or the SQL query in the configuration file 
>> hardcoding them.
>>
>> In fact documentation lacks that uid and gid must match directory of
>> maildir, https://www.courier-mta.org/authlib/README.authmysql.html it
>> not poin "required"m but if you dont input the uid and gid
>> virtualusers never work, cos we need to know the owner of the mail box
>> for delivering.. same problem with maildrop and spamassasing
>> integration for virtual users
>
> Courier cannot alter the fundamental way that Linux/BSD/others work. 
> It is no different than any other program or process. And this is how 
> permissions have worked, for over 50 years, dating back to the 
> original UNIX. A process can only read or write a file, or a 
> directory, if it has permissions on it, which is determined by the 
> process and the file's uid and gid.
>
> If the file, or a directory, does not have global read/write 
> permissions, if it is readable or writable only by a process with the 
> same uid/gid, then you must arrive at this conclusion, and figure this 
> out without really needing any documentation that spells this out.
>
That a Courier method for non-UNIX authentication has
particular requirements/assumptions for the corresponding
UNIX uid/gid is entirely Courier specific, as the relevant
Courier daemons are presumably started by root and can
design their internal management of UNIX uid/gid values
in many different ways within the limitations of the
setuid/setgid system calls on the actual UNIX variant.

Such assumptions/requirements need to be documented, even
if they happen to be a consequence of a specific code and
process structure and how that interacts with the uid/gid
system calls.

Other multi-user daemons such as Exim and Apache already
document their uid/gid settings and requirements.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: [Courier-imap] disabling IMAP_MAILBOX_SANITY_CHECK=0 permits mixed account into another?

[Sam V. <mr...@co...>]

PICCORO McKAY Lenz writes:

> El vie, 6 de mar. de 2020 a la(s) 18:49, Sam Varshavchik
> (mr...@co...) escribió:
> > There is no law that says all sql records must have the same uid or gid,
> > either explicitly or the SQL query in the configuration file hardcoding  
> them.
>
> In fact documentation lacks that uid and gid must match directory of
> maildir,  https://www.courier-mta.org/authlib/README.authmysql.html it
> not poin "required"m but if you dont input the uid and gid
> virtualusers never work, cos we need to know the owner of the mail box
> for delivering.. same problem with maildrop and spamassasing
> integration for virtual users

Courier cannot alter the fundamental way that Linux/BSD/others work. It is  
no different than any other program or process. And this is how permissions  
have worked, for over 50 years, dating back to the original UNIX. A process  
can only read or write a file, or a directory, if it has permissions on it,  
which is determined by the process and the file's uid and gid.

If the file, or a directory, does not have global read/write permissions, if  
it is readable or writable only by a process with the same uid/gid, then you  
must arrive at this conclusion, and figure this out without really needing  
any documentation that spells this out.

> The problem, a lot of confusion and lack of good implementations on
> the internet.. so novice administrator starting to learn cannot
> implements

Yes, this is something that novice administrators always learn, at some  
point. Everyone goes through this learning process.

Re: [Courier-imap] disabling IMAP_MAILBOX_SANITY_CHECK=0 permits mixed account into another?

[PICCORO M. L. <mck...@gm...>]

El vie, 6 de mar. de 2020 a la(s) 18:49, Sam Varshavchik
(mr...@co...) escribió:
>
> PICCORO McKAY Lenz writes:
> >    userid, groupid, and home directory. At which point the actual
> >    authentication module becomes irrelevant.
> > no sam! seems if you uses sql db based the uuid and giid must mach with a
> > virtual users that will represent the undercover users on auth module in the
> > database table.
> There is no law that says all sql records must have the same uid or gid,
> either explicitly or the SQL query in the configuration file hardcoding them.

In fact documentation lacks that uid and gid must match directory of
maildir,  https://www.courier-mta.org/authlib/README.authmysql.html it
not poin "required"m but if you dont input the uid and gid
virtualusers never work, cos we need to know the owner of the mail box
for delivering.. same problem with maildrop and spamassasing
integration for virtual users

When setting up virtual users in courier, I found that you need one
real user per virtual user domain. This means that it is mandatory to
configure the giud and uig in the users DB, which is not mentioned in
the documentation, this is based on the fact that for each domain you
need to know the owner of the folders if this flag is activated.

The important part is that as dotcourier is used to do the delivery
from the real to the virtual folders, this same behaviour is
impossible for real users, which seems to me illogical from a human
point of view, but logical from system courier logial workflow,
disabling IMAP_MAILBOX_SANITY_CHECK this can be done of course.. but
never documented ..

The problem, a lot of confusion and lack of good implementations on
the internet.. so novice administrator starting to learn cannot
implements

You must FIX THE DOCS and point that UID and GID are mandatory always,
and pint that i said in those mails



>
>
> _______________________________________________
> Courier-imap mailing list
> Cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap