Re: [courier-users] Message delivered, but no message in INBOX

2017-05-19 Thread Markus Wanner
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

2017-05-19 Thread Markus Wanner
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

2017-05-18 Thread Ángel
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,
> 
> * testmxlookup could be moved to courier-mta,
> 
> * I don't see how maildir utilities can be useful on a standalone SMTP server.
> Perhaps they could be moved to courier-imap, courier-pop, or both.
> 
> Ale

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)


...I would like having couriertls at its own package:

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)

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 switchj libraries)

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.).


I apologize for the annoyance, tell me if there's anything I can do to
help with it.


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] Message delivered, but no message in INBOX

2017-05-18 Thread Sam Varshavchik

Alessandro Vesely writes:

Although the real issue is maildrop, let me note the following about courier- 
base:


* couriertcpd could be just suggested or recommended, not required,


It most certainly is required. The default startup script require it.

I suppose you could customize the package to use inetd. Or systemd. To  
listen on the port and start the server.


This would mostly work for imap and pop3. But this is going to lose quite a  
bit of functionality with smtp, which depends on couriertcpd for setting  
environment variables based on the connecting IP address.




pgpwicQitusdk.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] Message delivered, but no message in INBOX

2017-05-18 Thread SZÉPE Viktor
Idézem/Quoting Alessandro Vesely :

> On Thu 18/May/2017 00:19:07 +0200 Markus Wanner wrote:
>> On 17.05.2017 09:48, Alessandro Vesely wrote:
>>
>>> 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.
>
> Although the real issue is maildrop, let me note the following about  
> courier-base:
>
> * couriertcpd could be just suggested or recommended, not required,
>
> * testmxlookup could be moved to courier-mta,
>
> * I don't see how maildir utilities can be useful on a standalone  
> SMTP server.
> Perhaps they could be moved to courier-imap, courier-pop, or both.
>
> Ale
> --

Debian policy states that a software should not be in more than one package.
It may seem strange that some parts are abstracted out of a common code base.

In Debian it is usual to have one software component in one package.
For example when you update it you don't have to download and install  
the whole software.

Looking at things from inside Debian these may come handy: you never  
have to deal with building a software from source, maintainers do that  
for you.

All the best to you!


SZÉPE Viktor
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
-- 
+36-20-4242498  s...@szepe.net  skype: szepe.viktor
Budapest, III. kerület





--
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

2017-05-18 Thread Alessandro Vesely
On Thu 18/May/2017 00:19:07 +0200 Markus Wanner wrote:
> On 17.05.2017 09:48, Alessandro Vesely wrote:
> 
>> 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.

Although the real issue is maildrop, let me note the following about 
courier-base:

* couriertcpd could be just suggested or recommended, not required,

* testmxlookup could be moved to courier-mta,

* I don't see how maildir utilities can be useful on a standalone SMTP server.
Perhaps they could be moved to courier-imap, courier-pop, or both.

Ale
-- 

























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

2017-05-18 Thread Sam Varshavchik

Markus Wanner writes:


> 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?)


$ maildrop -v
maildrop 2.8.5 Copyright 1998-2015 Double Precision, Inc.
Courier-specific maildrop build. This version of maildrop should only be used
with Courier, and not any other mail server.

Fairly unambiguous. This part of the version string is only present in the  
courier-specific maildrop build.






pgpB6mBu8cYkE.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] Message delivered, but no message in INBOX

2017-05-18 Thread Markus Wanner
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

2017-05-17 Thread Sam Varshavchik

Markus Wanner writes:


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


When I refer to source releases, I always refer to http://www.courier- 
mta.org/download.html



> 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 am not familiar with the details of Debian's packaging. I can only explain  
how I package the source.



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.


There are no functional differences, except for maildrop. 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.


It should be possible to build courier, and selectively carve out the built  
imap and sqwebmail components to be individually installed without courier.


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.


Again, all of the above describes what's in the upstream source. I am not  
familiar with Debian's packaging.




pgpNgJQRfNLDy.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] Message delivered, but no message in INBOX

2017-05-17 Thread Markus Wanner
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

2017-05-17 Thread Markus Wanner
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

2017-05-17 Thread Alessandro Vesely
On Tue 16/May/2017 19:06:55 +0200 Markus Wanner wrote:
> 
> I'll check if it's feasible to re-add the courier-maildrop package in
> Debian stretch (i.e. the Courier specific variant)

I'd suggest to avoid that.  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?

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?)  The complete package should
conflict with the standalone version of maildrop.

Jm2c
Ale
-- 
















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

2017-05-16 Thread SZÉPE Viktor
Idézem/Quoting Sam Varshavchik :

> Markus Wanner writes:
>
>> 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.
>
> Nothing is duplicated. It's one source repo. Packaging is a  
> completely different matter.
>
>> By that reasoning, Debian would have to ship about a dozen variants of
>> maildrop packages. That's clearly not going to happen.
>
> Only one maildrop package is needed. And one courier package, that's it.
>
>> 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).
>
> Certainly, and there's a single package that configures and installs  
> everything: courier.
>
>>   Splitting sources and duplicating efforts only
>
> Nothing is split. It's the same software, just packaged differently.
>
>> 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.
>
> Nothing is split. There are two separate packages, for two separate  
> situations. One, a single courier package, that includes everything  
> configured to work together. And the second package is the maildrop  
> package, configured without any courier dependencies, to be plugged  
> into other mail servers. That's it. It couldn't be any simpler.
>
> Did you know that there's also a separate courier-imap package? It's  
> just the IMAP server component, that can be set up independently,  
> and glued together with other mail servers. There's also the  
> sqwebmail package, a mail server-independent webmail server.
>
> And, of course, the Courier package installs everything, configured  
> to work with each other. Couldn't be any simpler.
>
> 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.

Hello Sam!

I think the Debian maintainer has to bridge the gap of "compile it,  
and install it" and the strict Debian policies.

For example I've learned packaging basics because I would like to have  
only packages on my servers not individual files without a central  
system like apt+dpkg.

I hope we will find a nice way to package your software by the  
guidelines of the Debian policies.

All the best!


SZÉPE Viktor
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
-- 
+36-20-4242498  s...@szepe.net  skype: szepe.viktor
Budapest, III. kerület





--
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

2017-05-16 Thread Sam Varshavchik

Markus Wanner writes:


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.


Nothing is duplicated. It's one source repo. Packaging is a completely  
different matter.



By that reasoning, Debian would have to ship about a dozen variants of
maildrop packages. That's clearly not going to happen.


Only one maildrop package is needed. And one courier package, that's it.


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).


Certainly, and there's a single package that configures and installs  
everything: courier.



   Splitting sources and duplicating efforts only


Nothing is split. It's the same software, just packaged differently.


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.


Nothing is split. There are two separate packages, for two separate  
situations. One, a single courier package, that includes everything  
configured to work together. And the second package is the maildrop package,  
configured without any courier dependencies, to be plugged into other mail  
servers. That's it. It couldn't be any simpler.


Did you know that there's also a separate courier-imap package? It's just  
the IMAP server component, that can be set up independently, and glued  
together with other mail servers. There's also the sqwebmail package, a mail  
server-independent webmail server.


And, of course, the Courier package installs everything, configured to work  
with each other. Couldn't be any simpler.


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.




pgpJLuPCMyOkl.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] Message delivered, but no message in INBOX

2017-05-16 Thread Markus Wanner
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

2017-05-16 Thread Sam Varshavchik

Markus Wanner writes:


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


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.



Couldn't most of this configuration be moved to runtime, rather than
compile time?


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.


pgpIGACk1jI_e.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] Message delivered, but no message in INBOX

2017-05-16 Thread Markus Wanner
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

2017-05-16 Thread SZÉPE Viktor
Idézem/Quoting Sam Varshavchik :

> Lucio Crusca writes:
>
>> but the maildrop manpage reports:
>>
>> "-V is ignored when maildrop runs in delivery mode."
>>
>> and maildropfilter manpage reports the same about the VERBOSE variable.
>
> Then run maildrop manually, yourself. Run maildrop with -V from the  
> shell, pipe a test message on standard input, and see what it logs.
>
>> is there any other switch to make maildrop log informations while  
>> in delivery mode?
>>
>> Please advice, I'm at a loss.
>
> Bottom line is that Debian's Courier package is not correctly built.  
> If you can't figure out a workaround, there's no other option  
> besides building your own Courier package, from source.

Hello Sam!

Could you point out some difference that you feel incorrect?
It would help much for maintaining the Debian package.


SZÉPE Viktor
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
-- 
+36-20-4242498  s...@szepe.net  skype: szepe.viktor
Budapest, III. kerület





--
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

2017-05-16 Thread Lucio Crusca
It now works: Markus kindly sent me his patch and his custom maildrop 
2.8.4 deb package, because he's currently short of time to keep up with 
the conversation here.

I tried to apply his patch to maildrop 2.8.5 sources. The patch gets 
applied, but configuration fails afterwards for some reason I don't 
understand (syntax errors).

I finally installed the package Markus sent me.

--
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

2017-05-16 Thread Sam Varshavchik

Lucio Crusca writes:


but the maildrop manpage reports:

"-V is ignored when maildrop runs in delivery mode."

and maildropfilter manpage reports the same about the VERBOSE variable.


Then run maildrop manually, yourself. Run maildrop with -V from the shell,  
pipe a test message on standard input, and see what it logs.


is there any other switch to make maildrop log informations while in  
delivery mode?


Please advice, I'm at a loss.


Bottom line is that Debian's Courier package is not correctly built. If you  
can't figure out a workaround, there's no other option besides building your  
own Courier package, from source.





pgpZSidxVvAEO.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] Message delivered, but no message in INBOX

2017-05-16 Thread Lucio Crusca
I wrote:
> Is it enough to edit that line, make it look like

> #ifndef HAVE_COURIER
>#define HAVE_COURIER
> #endif
>
> and configure/make/install?

I answer myself: no it isn't, because I've tried and that leads to a 
compile error. Then I've also tried just commenting out the #undef, 
building, installing, making it SUID root, configuring Courier to use 
that maildrop as DEFAULTDELIVERY, but still the messages are not 
actually being delivered into the virtual accounts maildirs, despite the 
logs not reporting any problem.

Sam Varshavchik writes:
 > look in the .mailfilter file

The virtual account I'm testing with has no .mailfilter.
I've tried a few things in the default /etc/maildroprc:

DEFAULT="$HOME/Maildir" # leads to message not being delivered

DEFAULT=./Maildir # same as above

DEFAULT=./Maildir/ # maildrop: Unable to open mailbox.

# empty file # maildrop: Unable to open mailbox.

logfile "/var/log/maildrop.log" # Unable to create log file.

During all these tests Courier was using my custom setuid maildrop.


Sam Varshavchik writes:
 > maildrop also has a verbose flag, that causes it to generate its own
 > logging.

but the maildrop manpage reports:

"-V is ignored when maildrop runs in delivery mode."

and maildropfilter manpage reports the same about the VERBOSE variable.

is there any other switch to make maildrop log informations while in 
delivery mode?

Please advice, I'm at a loss.

--
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

2017-05-16 Thread Lucio Crusca
I wrote:
> What does exactly mean to compile maildrop with HAVE_COURIER? I coulnd't find 
> any
> such option in ./configure and the generated Makefile does not include
> it either.

I've had a look at the current maildrop stable sources (2.8.5). In the 
file libs/maildrop/config.h.in I see:

#undef HAVE_COURIER

at line 7. Is it enough to edit that line, make it look like

#ifndef HAVE_COURIER
   #define HAVE_COURIER
#endif

and configure/make/install?

--
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

2017-05-14 Thread Lucio Crusca
Markus Wanner writes:
> Is this the Debian stretch installation mentioned?
>

Yes it is.

> I'm successfully running a courier installation on Debian stretch with
> maildrop compiled manually, ATM.

Thanks for sharing, I'm afraid that's what I need to do too. What does 
exactly mean to compile maildrop with HAVE_COURIER? I coulnd't find any 
such option in ./configure and the generated Makefile does not include 
it either.

--
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

2017-05-14 Thread Markus Wanner
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] Message delivered, but no message in INBOX

2017-05-14 Thread Sam Varshavchik

Lucio Crusca writes:


Sam Varshavchik writes:
> From the logs, you've configured spamd to be responsible for delivering
> mail
 >
 > You have to take smaller steps, and get one thing working, at a time.

I've now moved spamd out of the way. My previous DEFAULTDELIVERY was

DEFAULTDELIVERY="|/usr/bin/spamc|/usr/bin/maildrop"

The current one is:

DEFAULTDELIVERY=./Maildir

and everyting works. 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.


Then, look in the .mailfilter file to see what the delivery instructions are.

maildrop also has a verbose flag, that causes it to generate its own logging.




pgpB8shQVlAMs.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] Message delivered, but no message in INBOX

2017-05-14 Thread Lucio Crusca
Sam Varshavchik writes:
> From the logs, you've configured spamd to be responsible for delivering
> mail
 >
 > You have to take smaller steps, and get one thing working, at a time.

I've now moved spamd out of the way. My previous DEFAULTDELIVERY was

DEFAULTDELIVERY="|/usr/bin/spamc|/usr/bin/maildrop"

The current one is:

DEFAULTDELIVERY=./Maildir

and everyting works. 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.

--
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

2017-05-14 Thread Sam Varshavchik

Lucio Crusca writes:



E.g. no files written into the Maildir, despite the "Message delivered"
log. I've also tried to access the Maildir with Thunderbird and
RoundCube and they both confirm there aren't any messages.

I have no clue about what I should check... please help.


From the logs, you've configured spamd to be responsible for delivering  

mail, so you'll have to look in that direction.

You can start by completely removing spamd from your configuration, so that  
it's out of the picture, and with Courier delivering mail directly to the  
mailbox, confirming that mail delivery works. Once that's settled, you can  
then bring spamd back into the picture, and work on it.


When trying to do too many things at once, if something is broken somewhere  
it is often not clear where exactly the issue is. You have to take smaller  
steps, and get one thing working, at a time.




pgprDAtl_A3Ms.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