[courier-users] Patches from FreeBSD
While working on updating the FreeBSD port, I noticed a few patches that
may be appropriate for merging.
First, the test for -lcourier-unicode seems to be slightly deficient.
All of the AC_CHECK_LIB checks successfully locate libs in
/usr/local/lib, but AC_LINK_IFELSE doesn't seem to.I think that's
because that part of configure.ac stashes $LIBS where -L/usr/local/lib
will be? Regardless, maybe this section can be refactored to use
AC_CHECK_LIB...
Second, courier/perms.sh.in sets a number of executables to 555, and
others to 755. The FreeBSD maintainer makes those consistent, removing
write access.
The last patch appears to clarify an error message when messages exceed
the administrative limit.
Could you check these over, Sam?
--- configure.orig 2017-01-25 20:41:21.217193416 -0800
+++ configure 2017-01-25 20:41:52.000581482 -0800
@@ -16418,7 +16418,7 @@
save_LIBS="$LIBS"
-LIBS="-lcourier-unicode"
+LIBS="-lcourier-unicode -L/usr/local/lib"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
--- courier/perms.sh.in.orig2007-07-01 11:36:31.0 -0400
+++ courier/perms.sh.in 2007-07-01 11:36:31.0 -0400
@@ -11,9 +11,6 @@
datarootdir="@datarootdir@"
PERMS="
-. 755
-
-@localstatedir@755 x bin bin
@localstatedir@/tmp770
@localstatedir@/msgs 750
@localstatedir@/msgq 750
@@ -47,7 +44,6 @@
@sysconfdir@/rfcerr2046.txt444 config
@sysconfdir@/rfcerr2047.txt444 config
-@libexecdir@ 755 x bin bin
@libexecdir@/courier 755 x bin bin
@libexecdir@/courier/modules 755 x bin bin
@libexecdir@/courier/submitmkdir 4550
@@ -61,14 +57,13 @@
@libexecdir@/courier/makedatprog 555
@libexecdir@/courier/imaplogin 555 x bin bin
@libexecdir@/courier/pcpd 555 x bin bin
-@libexecdir@/courier/webmail 700 x rootbin
+@libexecdir@/courier/webmail 500 x rootbin
@libexecdir@/courier/webmail/webmail 555 x rootbin
@libexecdir@/courier/webmail/webmlm555 x rootbin
@libexecdir@/courier/sqwebmaild555
-@libexecdir@/courier/sqwebpasswd 2755
-@libexecdir@/courier/webmail/webadmin 4555x rootbin
+@libexecdir@/courier/sqwebpasswd 2555
+@libexecdir@/courier/webmail/webadmin 4511x rootbin
-@sbindir@ 755 x bin bin
@sbindir@/courier 555
@sbindir@/showconfig 555
@sbindir@/showmodules 550
@@ -82,7 +77,6 @@
@datadir@/imapd555 x bin bin
@datadir@/imapd-ssl555 x bin bin
-@bindir@ 755 x bin bin
@bindir@/cancelmsg 6555
@bindir@/courier-config555
@bindir@/mailq 2555
@@ -109,10 +109,10 @@
@sbindir@/makehosteddomains555
@datadir@/makeimapaccess 555
@sbindir@/makeimapaccess 555
-@datadir@/pop3d755
-@sbindir@/pop3d755
-@datadir@/pop3d-ssl755
-@sbindir@/pop3d-ssl755
+@datadir@/pop3d555
+@sbindir@/pop3d555
+@datadir@/pop3d-ssl555
+@sbindir@/pop3d-ssl555
@sbindir@/webgpg 555
@datadir@ 755 x bin bin
@@ -226,7 +220,7 @@
if test "@HAVE_LDAP@" != 0
then
echo @sysconfdir@/ldapaliasrc.dist 640 @mailuser@ @mailgroup@ config
- echo @sbindir@/courierldapaliasd 700 @mailuser@ @mailgroup@
+ echo @sbindir@/courierldapaliasd 500 @mailuser@ @mailgroup@
fi
echo @datadir@/sqwebmail/images 755 @mailuser@ @mailgroup@
--- courier/submit2.C.orig 2008-01-29 13:06:47.0 +0100
+++ courier/submit2.C 2009-10-03 22:34:47.0 +0200
@@ -860,7 +860,7 @@
if (sizelimit && bytecount > sizelimit)
{
std::cout << "523 Message length (" <<
- sizelimit << " bytes) exceeds administrative limit."
+ bytecount << " bytes) exceeds administrative limit(" <<
sizelimit << ")."
<< std::endl << std::flush;
return (1);
}
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Configure Scripts Not Finding Resources Installed on FreeBSD
On 12/26/2016 08:57 PM, Michael S. Scaramella, Esq. wrote: My project to install and configure Courier on our DigitalOcean hosted FreeBSD 11.0 based VPS is now substantially further along. It's a little late to be of help, but I've sent patches for the courier-authlib and courier "ports" to their respective maintainers. Hopefully they'll be up to date soon. ports-courier.patch.gz Description: application/gzip ports-courier-authlib.patch.gz Description: application/gzip ports-courier-files.patch.gz Description: application/gzip -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Fwd: Looking for new Debian maintainers for courier-mta packages
On 01/25/2017 06:33 PM, Ángel wrote: > As for the debian bug reports, the work seems to lie in the list of > normal unclassified bugs that would need to be reviewed and most likely > tested. If you are interested in bugs, you should also try to go look up all the bugs Ondrej closed too. he closed them in large batches without review. Many were still valid issues at the time of closing. This was one of the many complaints people had with the way he mismanaged the packages. I applaud your work and hope someone will pick up courier, but I've already started working on migrating all of the systems I am responsible to other packages/systems. At this point, the removal of Courier from Debian and derivatives is almost certain and administrators should be acting accordingly (move to other packages or compile their own). -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Fwd: Looking for new Debian maintainers for courier-mta packages
As someone interested in keeping courier in Debian, I had been interested in looking at Ondřej changes (and its consequences) since I first saw this thread. I have now compiled the new packages and performed a (really basic) local install. I'm not too keen on the move of couriertls into courier-base, though. In my view, it is itself an independent package, and it shouldn't require eg. the authdaemon (while it did have a depends to courier-base, I seem recall it wasn't really needed). A bug I noticed on install is that although courier-base is using /usr/sbin/mkdhparams to create properly-sized 4096 DH parameters in /etc/courier/dhparams.pem, the smtpd certificate was created with /usr/lib/courier/mkesmtpdcert which, after generating the certificate, appends a 512-byte (weak) dh parameter. This openssl gendh line was removed upstream in 2014 on 1e1b535b440b93474d243fe363635f0ec18427cd, but gets readded by patch 12. (d0e8408cc changes it from gendh to dhparam, but still adds it to the autogenerated certificate. It should be removed) I would recommend automatically adding mkdhparams to /etc/cron.monthly, too. As for the debian bug reports, the work seems to lie in the list of normal unclassified bugs that would need to be reviewed and most likely tested. Also, looking at the patches carried by debian, the numbers 1, 2, 3, 5, 6, 7, 9, 12*, 13, 14, 17, 20, 21, 23 and 25 seem quite uncontroversial for being applied upstream. Could you add them to your queue to ponder their inclusion, Sam? Best regards -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SASL for authpipe -- a sticky note for Courier Authlib
Alessandro Vesely writes:
On Wed 25/Jan/2017 14:33:16 +0100 Sam Varshavchik wrote:
> Alessandro Vesely writes:
>>
>> while reviewing my Courier installation, I stumbled upon how my
authProg.c is
>> compiled. It uses -I/my/path/to/auth/cur -L/usr/path/to/courier-authlib
and
>> -lcourierauthsasl, on a server with courier-authlib-0.66.4.20160106. On a
>> stock Debian jessie (0.66.1) I have to add two more libraries. The main
>> difficulty is to get the sources for the include files:
>>
>> I include courierauth.h and courierauthsasl.h from authlib-devel. But I
also
>> need:
>>
>> #include"libs/libhmac/hmac.h" // for struct hmac_hashinfo
>> #include"cramlib.h" // for auth_cram_callback
>>
>> In addition, I also need auth.h, because cramlib.h includes it (it would
>> suffice to declare "struct authinfo;" to avoid the inclusion). All file
names
>> in include_HEADER start with "courier", so some renaming would be in
order if
>> this issue is ever addressed.
>>
>> I don't think I'm going to switch to binary versions of Courier any time
soon,
>> so I don't really need a cleaner compiling environment for authpipe.
However,
>> since a courier-authlib-dev package exists, I wonder why it doesn't
support
>> SASL. I use authsasl_frombase64, auth_cram_callback, and hmac_list.
What do
>> everybody else do?
>
> It should be possible for you to support SASL authentication by using
> authsasl_list, that's declared in courierauthsasl.h. You shouldn't need to
look
> at the lower-level functions.
Ehm, I may be dumb but I don't get it. That struct is something like:
struct authsasl_info authsasl_list[] = {
{"EXTERNAL", 0},
{"PLAIN", authsasl_plain},
{"LOGIN", authsasl_login},
{"CRAM-MD5", authsasl_cram},
{"CRAM-SHA1", authsasl_cram},
{"CRAM-SHA256", authsasl_cram},
{ 0, 0}};
Yes, I can find which cram types are available. However,
auth_cram_callback()
wants a struct hmac_hashinfo *h in its cci parameter. The authsasl_cram
function declared in courierauthsasl.h seems to be designed to be called
/during/ the dialog. In authProg, instead, I read stuff more or less like:
AUTH 30\nesmtp\nlogin\njoe@spam\npassword
/after/ the dialog is already terminated. If it was SASL instead of login,
the
last two lines read would contain challenge and response, which I decode with
authsasl_frombase64(); then I pass cleartext password, challenge and response
to auth_cram_callback(), and based on its return code either authenticate the
user or fail. Can I do that with some of the exported functions?
Yeah, ok.
These exported functions are meant to be used for developing authentication
clients, not servers.
Looks like all you need are the functions in cramlib.h
Specifically, auth_get_cram() is going to decode the challenge and response
into a struct cram_callback_info.
Then, auth_cram_callback() takes a pointer to authinfo, where it only really
looks at clearpasswd. The second argument is the pointer to the decoded
cram_callback_info, which also contains a pointer to callback_func, that's
going to get invoked if the challenge was successful.
pgpw3FJ5DAhLZ.pgp
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SASL for authpipe -- a sticky note for Courier Authlib
On Wed 25/Jan/2017 14:33:16 +0100 Sam Varshavchik wrote:
> Alessandro Vesely writes:
>>
>> while reviewing my Courier installation, I stumbled upon how my authProg.c is
>> compiled. It uses -I/my/path/to/auth/cur -L/usr/path/to/courier-authlib and
>> -lcourierauthsasl, on a server with courier-authlib-0.66.4.20160106. On a
>> stock Debian jessie (0.66.1) I have to add two more libraries. The main
>> difficulty is to get the sources for the include files:
>>
>> I include courierauth.h and courierauthsasl.h from authlib-devel. But I also
>> need:
>>
>> #include"libs/libhmac/hmac.h" // for struct hmac_hashinfo
>> #include"cramlib.h" // for auth_cram_callback
>>
>> In addition, I also need auth.h, because cramlib.h includes it (it would
>> suffice to declare "struct authinfo;" to avoid the inclusion). All file
>> names
>> in include_HEADER start with "courier", so some renaming would be in order if
>> this issue is ever addressed.
>>
>> I don't think I'm going to switch to binary versions of Courier any time
>> soon,
>> so I don't really need a cleaner compiling environment for authpipe.
>> However,
>> since a courier-authlib-dev package exists, I wonder why it doesn't support
>> SASL. I use authsasl_frombase64, auth_cram_callback, and hmac_list. What do
>> everybody else do?
>
> It should be possible for you to support SASL authentication by using
> authsasl_list, that's declared in courierauthsasl.h. You shouldn't need to
> look
> at the lower-level functions.
Ehm, I may be dumb but I don't get it. That struct is something like:
struct authsasl_info authsasl_list[] = {
{"EXTERNAL", 0},
{"PLAIN", authsasl_plain},
{"LOGIN", authsasl_login},
{"CRAM-MD5", authsasl_cram},
{"CRAM-SHA1", authsasl_cram},
{"CRAM-SHA256", authsasl_cram},
{ 0, 0}};
Yes, I can find which cram types are available. However, auth_cram_callback()
wants a struct hmac_hashinfo *h in its cci parameter. The authsasl_cram
function declared in courierauthsasl.h seems to be designed to be called
/during/ the dialog. In authProg, instead, I read stuff more or less like:
AUTH 30\nesmtp\nlogin\njoe@spam\npassword
/after/ the dialog is already terminated. If it was SASL instead of login, the
last two lines read would contain challenge and response, which I decode with
authsasl_frombase64(); then I pass cleartext password, challenge and response
to auth_cram_callback(), and based on its return code either authenticate the
user or fail. Can I do that with some of the exported functions?
Calling auth_sasl_extract_userid() I nearly get the job done, but still haven't
verified the password. I didn't find a function which calls
auth_verify_cram(), except auth_cram_callback(). The latter is also called by
auth_custom(), but that's a different thing, isn't it?
Ale
--
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SASL for authpipe -- a sticky note for Courier Authlib
Alessandro Vesely writes: Hi all, while reviewing my Courier installation, I stumbled upon how my authProg.c is compiled. It uses -I/my/path/to/auth/cur -L/usr/path/to/courier-authlib and -lcourierauthsasl, on a server with courier-authlib-0.66.4.20160106. On a stock Debian jessie (0.66.1) I have to add two more libraries. The main difficulty is to get the sources for the include files: I include courierauth.h and courierauthsasl.h from authlib-devel. But I also need: #include"libs/libhmac/hmac.h" // for struct hmac_hashinfo #include"cramlib.h" // for auth_cram_callback In addition, I also need auth.h, because cramlib.h includes it (it would suffice to declare "struct authinfo;" to avoid the inclusion). All file names in include_HEADER start with "courier", so some renaming would be in order if this issue is ever addressed. I don't think I'm going to switch to binary versions of Courier any time soon, so I don't really need a cleaner compiling environment for authpipe. However, since a courier-authlib-dev package exists, I wonder why it doesn't support SASL. I use authsasl_frombase64, auth_cram_callback, and hmac_list. What do everybody else do? It should be possible for you to support SASL authentication by using authsasl_list, that's declared in courierauthsasl.h. You shouldn't need to look at the lower-level functions. pgpai6QTTRanb.pgp Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] SASL for authpipe -- a sticky note for Courier Authlib
Hi all, while reviewing my Courier installation, I stumbled upon how my authProg.c is compiled. It uses -I/my/path/to/auth/cur -L/usr/path/to/courier-authlib and -lcourierauthsasl, on a server with courier-authlib-0.66.4.20160106. On a stock Debian jessie (0.66.1) I have to add two more libraries. The main difficulty is to get the sources for the include files: I include courierauth.h and courierauthsasl.h from authlib-devel. But I also need: #include"libs/libhmac/hmac.h" // for struct hmac_hashinfo #include"cramlib.h" // for auth_cram_callback In addition, I also need auth.h, because cramlib.h includes it (it would suffice to declare "struct authinfo;" to avoid the inclusion). All file names in include_HEADER start with "courier", so some renaming would be in order if this issue is ever addressed. I don't think I'm going to switch to binary versions of Courier any time soon, so I don't really need a cleaner compiling environment for authpipe. However, since a courier-authlib-dev package exists, I wonder why it doesn't support SASL. I use authsasl_frombase64, auth_cram_callback, and hmac_list. What do everybody else do? Ale -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
