Re: [courier-users] courieresmtpd: STARTTLS failed: Certificate is bad
Hello Lucio, On 07/19/2017 11:26 AM, Lucio Crusca wrote: > So far I've enabled courier-mta and courier-msa systemd services, > changed the ports they listed on and created a real system account for > mail relay (authpam). I've also let > > TLS_VERIFYPEER=NONE Could it be an invalid peer certificate none the less? Does the same message appear if you try with openssl as the client, i.e.: openssl s_client -starttls smtp -crlf -connect $HOST:587 > Jul 19 04:48:17 mrelay courieresmtpd: started,ip=[:::80.180.158.103] > Jul 19 04:48:18 mrelay courieresmtpd: courieresmtpd: STARTTLS failed: > Certificate is bad > > I don't know what to try next. Permissions of /etc/courier/esmtpd.pem? Is it a PRIVATE KEY followed by the CERTIFICATE(s)? ..just a few checks that come to mind, might well be irrelevant, though. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] Blacklisted email addresses not cleared
Hi, On 07/05/2017 11:54 PM, Sam Varshavchik wrote: > Bernd Plagge writes: >> I recently found some cases were blacklisted email addresses (recorded >> in /var/lib/courier/track) were not cleared by the "courier clear >> user@domain" command. I run into a similar issue recently and figured other files in that directory were blocking the user, which `courier clear` didn't clear. You might want to check those files as well. > That's the expected result. An email address gets cleared by adding an A > record, so this looks ok. > > Reviewing the code in question I only see a potential problem with > "clear all" not working correctly, but clearing an individual address > should work. Unfortunately I'm not sure if I can reproduce this, but in my case, `courier clear mar...@bluegap.ch` didn't help. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] setuid/setgid problem, mail from website not sent
On 07/06/2017 12:13 PM, Matus UHLAR - fantomas wrote: > On 06.07.17 12:43, Bernd Plagge wrote: >> thank you VERY much! >> This was the answer. >> >> Just for the record: >> I had to downgrade my Debian system due to issues with the new Debian >> packages. >> Seems that the permissions on the sendmail wrapper were not set >> correctly by the installation program. > > I believe debian developer either knows what permissions to set up, or > should be informed if that causes troubles... I'd rather guess the OP had to downgrade due to the maildrop issue in stretch, which I'm still trying to solve. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] Message delivered, but no message in INBOX
On 05/18/2017 12:35 PM, Sam Varshavchik wrote: > Fairly unambiguous. This part of the version string is only present in > the courier-specific maildrop build. Cool, thanks. Markus signature.asc Description: OpenPGP digital 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] Message delivered, but no message in INBOX
Hi, On 05/19/2017 02:53 AM, Ángel wrote: > On 2017-05-18 at 19:03 +0200, Alessandro Vesely wrote: >> Although the real issue is maildrop, let me note the following about >> courier-base: >> >> * couriertcpd could be just suggested or recommended, not required, as Sam mentioned, the current startup scripts do required couriertcpd (even the adjusted ones in Debian). >> * testmxlookup could be moved to courier-mta, Hm.. sounds like a courier-utils package might be useful. >> * I don't see how maildir utilities can be useful on a standalone SMTP >> server. Well, it could still be an MTA delivering mail to maildirs. Doesn't seem far fetched to me. But if we add a courier-utils or such, that would probably be the right place. > While we are on the topic of debian package wishlists... > (not sure if this is the best venue, but otoh I feel it's good to > discuss it first rather than simply filing a bug) Thanks for your consideration. Yes, I appreciate that. OTOH I tend to forget discussions, if they don't result in a bug, so please file wishlist bugs as a result of the discussion. (And it's sometimes helpful if it's users filing the issues, rather than the maintainer himself.) > ...I would like having couriertls at its own package: Sounds like a good idea to me, yes. > 1) It is a standalone tool, useful on its own. > It can be used as a cli tool (as a "tls telnet"), as well as by other > programs (I have used it that way to support TLS) > > 2) It used to be at a different package, so it would be consistent with > previous practice > (kind of, it had an -apparently unneeded- depends on courier-base) I wasn't aware of that. In this case, I should better check why the separate package was dropped. > 3) That would allow having a virtual package with two versions, so that > the sysadmin could choose whether to have it linked against openssl or > gnutls (they used to have slightly different features, so in the past I > ended up recompiling the courier-ssl package to switch libraries) Hm.. IIRC I had to compile courier against GnuTLS to work. I don't currently find the exact issue, though. > This is specially interesting from a security point of view imho, since > should a problem develop on either of these libraries, you could easily > switch to the other library while keeping the upper level server > unchanged (assuming the config used compatible ciphers, etc.). Well, that however means we'd always have to support both. But yes, I can see merit in having a separate package. > I apologize for the annoyance, tell me if there's anything I can do to > help with it. No need to apologize. Scanning through the Debian bug list would help. There are lots of very old issues and I think many of them do not apply any more. https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;src=courier Even just prioritizing the list would be helpful. I'm focusing on the stretch release, ATM. Kind Regards Markus Wanner -- 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] Message delivered, but no message in INBOX
Sam, On 05/18/2017 12:29 AM, Sam Varshavchik wrote: > When I refer to source releases, I always refer to > http://www.courier-mta.org/download.html Thanks for clarifying, that's usually referred to as upstream in Debian, whereas "the package" is the result of packaging for Debian. Please excuse the confusion this may have caused, I'll be more specific in the future. > I am not familiar with the details of Debian's packaging. I can only > explain how I package the source. Fair enough, you don't need to be. I not familiar with upstream sources, either. And despite you thinking it's simple, it had quite some surprises for me. I'm glad we uncovered those and I hope to find ways that work well for both of us. > There are no functional differences, except for maildrop. I'm glad to hear. > The > differences are in the configuration. The biggest difference is > maildrop, because it ties in directly into mail delivery, and it has > Courier-specific features, and Courier has maildrop-specific features as > well. Understood. (If you're provided a maildrop binary, how do you tell which variant it is?) > It should be possible to build courier, and selectively carve out the > built imap and sqwebmail components to be individually installed without > courier. I think that's how it's done for Debian, up until now. > But that's going to require writing custom startup scripts. There's only > one startup script for courier, that starts everything. It's fairly easy > to carve out imap and webmail as an optional subpackage. Courier's > startup script will try starting them only if it finds them installed. > But left to their own merits, the subpackages won't do anything without > writing and adding some startup scripts into the subpackages. Then they > can be installed independently and use without Courier. But then, you'll > also have to fix courier's startup script not to try starting them > itself, since the subpackage will take care of with its own startup script. Yes, I think all of those startup scripts are in place, including systemd units. This allows Debian users to control (and install) the services individually, which I think is an important feature. Sounds like the only remaining issue is maildrop. I'll investigate further on possible solutions. Thank you for explaining and for your understanding of the Debian specific requirements. I'm well aware those may seem weird sometimes and are often hard to meet. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] Message delivered, but no message in INBOX
Hi, On 17.05.2017 09:48, Alessandro Vesely wrote: > I'd suggest to avoid that. I'd love not having to reintroduce a second maildrop variant. > I use subjunctive because I install Courier from > tarballs rather than Debian packages, except for off-hand tests. In the > latter > case, I get confused by the bewildering amount of Courier packages available > in > the Debian distro —there are 27 of them, correct? Why does that confuse you? An MTA and an IMAP server are clearly distinct things. Just install what you need. I personally didn't ever think of installing "courier". I installed their MTA, their IMAP or POP server. And - I have to admit - not ever their Webmail. I didn't ever want nor need the entire bundle. But I could (in theory), by simply installing all the parts. > My suggestion is to avoid disassembling the Courier tarball. That is, have > maildrop included by default in courier-mta, and possibly merge it with > courier-base as well (why were they split, BTW?) Flexibility. And separation of concerns. I like being able to install courier-imap, but not courier-pop, for example. Or running just the courier-mta without either of the other two. That's quite common for Debian, I'd say. Take the modules for apache's httpd as another example of that practice. Or the fact that Debian ships separate client and server packages for most databases. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] Message delivered, but no message in INBOX
Hi, On 17.05.2017 02:44, Sam Varshavchik wrote: > Only one maildrop package is needed. And one courier package, that's it. Unfortunately, there is not separate courier-mta source release. Only the bundle. That's problematic for distributions per se. That's not a Debian specific issue, but generally bad for any distribution. A good read may be: https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies Or Debian's upstream guide, see the section "Pristine Upstream Source": https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source > Did you know that there's also a separate courier-imap package? There is a courier-imap package for Debian, built from the courier sources. Are you saying this one is incompatible to the separate courier-imap source release? I strongly hope it's not. (And I had the very same hope for maildrop, but that was utterly wrong in a very non-obvious way, despite proclaimed simplicity...) > And things have been this simpler for over 20 years now. That's how long > things have worked this way, with no issues. People get the right > package for them, compile it, and install it. That's it. Several issues were filed against the duplication in Debian packages for the two different maildrop variants. And the two packages were often out of sync. Please note that there's nothing speaking against a bundle for users who want to compile for themselves (in contrast to using distro packages) and appreciate the bundling. However, for Debian, I'd greatly appreciate separate source tarballs for each individual component. And to live up to the simplicity you're advocating, I'd recommend eliminating any difference between individual components and the bundle. I'm not the first one to be caught by surprise, and I certainly won't be the last one. I'm looking forward to support Courier for Debian. However, I need a bit of understanding and support from upstream. Thank you. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] Message delivered, but no message in INBOX
On 05/16/2017 05:10 PM, Sam Varshavchik wrote: > They should not be. maildrop is a separate source package. It's a > tarball in of itself, that's built independently. > > Now, the fact that this tarball contains code that's also found in > another, larger, package, that's a different subject. I don't quite see how that matters. It's the same set of source files, which would need the same set of security fixes, for example. What does the duplication of efforts buy us? I'd rather state that duplication of code is never a good idea, but a sign for bad modularization. > The Courier build of maildrop implements a Courier-specific option > that's got ...a bit of juice to it, taking advantage of its temporary > root permissions. > > Although the relevant bits in question do all their due diligence, > checking that the real uid/gid is the one that's baked into the source, > and thusly is only available to Courier, etc., it's good practice to > remove stuff that's not needed. Multiple layers of security. It's better > to keep that code out of the non-Courier specific maildrop, altogether. By that reasoning, Debian would have to ship about a dozen variants of maildrop packages. That's clearly not going to happen. While I generally agree that it's good practice to remove stuff that's really not needed, the courier variant *is* needed (by some users, including myself). Splitting sources and duplicating efforts only reduces overall test coverage and availability of security fixes, so I don't quite see this as an overall gain in security. If nothing else, it would have saved us the current confusion and trouble with maildrop being available in multiple incompatible variants, which aren't clearly distinguishable by name. I'll check if it's feasible to re-add the courier-maildrop package in Debian stretch (i.e. the Courier specific variant), but I'd greatly appreciate if you could reconsider this split. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] Message delivered, but no message in INBOX
Hi, On 05/16/2017 02:27 PM, Sam Varshavchik wrote: > This has been discussed already – that package replaces the maildrop > component with the standalone version of maildrop. This doesn't work > correctly, or rather it won't work without some additional > configuration. I'd quickly like to elaborate on why the former Debian maintainer decided to do that and hope for your understanding: Before, there was a courier-maildrop as well as a (stand-alone) maildrop package. Meaning those two are built from the very same source, but built with different configuration options. From a maintenance and security perspective, that's unfortunate and Debian strives to eliminate duplicate source packages. However, I certainly agree that the current situation is even worse. > That, for all intents and purposes, is maildrop getting > installed with some standalone mail server, and maildrop needs to be set > up to use the same configuration as the mail server, in terms of where > the mail accounts are, who owns them, and each one's userid and groupid. > It's no longer just something that get me dropped in, and work > automatically. Couldn't most of this configuration be moved to runtime, rather than compile time? Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] Message delivered, but no message in INBOX
On 14.05.2017 20:16, Lucio Crusca wrote: > However if I try to use maildrop alone, with: > > DEFAULTDELIVERY="| /usr/bin/maildrop" > > it stops working again, so I think I have a problem with maildrop rather > than spamd. Is this the Debian stretch installation mentioned? You might have run into an issue caused by the recent removal of the courier-maildrop package, see this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818377 It boils down to maildrop being compiled without HAVE_COURIER, where as the courier MTA (unsurprisingly) expects that #define to be set. I'm successfully running a courier installation on Debian stretch with maildrop compiled manually, ATM. Kind Regards Markus Wanner Disclaimer: I'm a Debian Developer and recently took over maintenance of the Courier MTA suite. However, I'm not sure we can still solve this maildrop issue in time for the stretch release. Sorry. signature.asc Description: OpenPGP digital 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] courier-authlib: exported symbols
Hello Alessandro, On 03/31/2017 10:49 AM, Alessandro Vesely wrote: > I, for one, run my own pipeauth > > ldd /etc/courier/authlib/authProg > linux-vdso.so.1 => (0x7fffb59bc000) > libcourierauthsasl.so => > /usr/local/lib/courier-authlib/libcourierauthsasl.so (0x7ff1e44cd000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ff1e414) > libcourierauthcommon.so => > /usr/local/lib/courier-authlib/libcourierauthcommon.so (0x7ff1e3f37000) > libcourierauth.so => /usr/local/lib/courier-authlib/libcourierauth.so > (0x7ff1e3d2a000) > /lib64/ld-linux-x86-64.so.2 (0x7ff1e46d) > libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7ff1e3a23000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ff1e37a1000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7ff1e358b000) > libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 > (0x7ff1e3354000) The interesting question here would be whether you're linking against libcourierauthsasl (and using its symbols only) or if your authProg depends on libcourierauthcommon, directly. (Indirectly, via libcourierauthsasl, libcourierauthcommon will always be linked in either case.) (Other than that I note that you're not using Debian packages, in the first place, so you wouldn't be affected. I still appreciate your inputs. Maybe there are Debian users doing or wanting to do the same.) Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] courier-authlib: exported symbols
Sam, On 03/31/2017 12:26 AM, Sam Varshavchik wrote: > libcourierauthcommon is not solely an externally-linked library. It's > also linked to by other .so-s in the package. These symbols correspond > to internal APIs. Am I correct to assume that libcourierauthcommon is an internal library and not part of the public API of courier-auth, i.e. users of courier-auth shouldn't ever directly link to it? Do libauthpam.so and libauthcustom.so exposed a public API? Kind Regards Markus Wanner signature.asc Description: OpenPGP digital 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] courier-authlib: exported symbols
<std::__cxx11::basic_string<char, > std::char_traits, std::allocator > const, > std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > > >::_M_get_insert_unique_pos(std::__cxx11::basic_string<char, > std::char_traits, std::allocator > const&)@Base" 0.67.0 > (c++)"std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits, > std::allocator >, std::pair<std::__cxx11::basic_string<char, > std::char_traits, std::allocator > const, > std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, > std::char_traits, std::allocator > const, > std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > >, std::less<std::__cxx11::basic_string<char, std::char_traits, > std::allocator > >, > std::allocator<std::pair<std::__cxx11::basic_string<char, > std::char_traits, std::allocator > const, > std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > > > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<std::__cxx11::basic_string<char, > std::char_traits, std::allocator > const, > std::__cxx11::basic_string<char, std::char_traits, std::alloca tor > > >, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)@Base" 0.67.0 > (c++)"__gnu_cxx::__normal_iterator std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > std::__find_if<__gnu_cxx::__normal_iterator std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >, __gnu_cxx::__ops::_Iter_equals_val > >(__gnu_cxx::__normal_iterator std::char_traits, std::allocator > >, > __gnu_cxx::__normal_iterator std::char_traits, std::allocator > >, > __gnu_cxx::__ops::_Iter_equals_val, > std::random_access_iterator_tag)@Base" 0.67.0 > (c++)"__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, > std::char_traits, std::allocator > > > std::__find_if<__gnu_cxx::__normal_iterator<char*, > std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >, __gnu_cxx::__ops::_Iter_pred > >(__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, > std::char_traits, std::allocator > >, > __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, > std::char_traits, std::allocator > >, > __gnu_cxx::__ops::_Iter_pred, > std::random_access_iterator_tag)@Base" 0.67.0 > (c++)"__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, > std::char_traits, std::allocator > > > std::__find_if<__gnu_cxx::__normal_iterator<char*, > std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >, __gnu_cxx::__ops::_Iter_pred > >(__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, > std::char_traits, std::allocator > >, > __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, > std::char_traits, std::allocator > >, > __gnu_cxx::__ops::_Iter_pred, > std::random_access_iterator_tag)@Base" 0.67.0 > (c++)"typeinfo for courier::auth::config_file@Base" 0.67.0 > (c++)"typeinfo name for courier::auth::config_file@Base" 0.67.0 > (c++)"vtable for courier::auth::config_file@Base" 0.67.0 Do all of these really need to be visible? Kind Regards Markus Wanner -- 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
