Why are you posting these agitated bug reports? Can I suggest that you first
calm down and try to compose your thoughts, and then put that in writing
while bearing in mind that an assumption of good faith is the only proper
way to operate?

On Mon, Nov 16, 2020 at 04:08:21AM -0400, PICCORO McKAY Lenz wrote:
> Package: maildrop
> Version: 2.9.3-2
> Severity: important
> 
> The maildrop package in debian is severely out of sync and outdated:
> 
> First of all stop of "Upstream is not willing to add another feature",
> seems people dont understan maildrop are made for courier, and if need
> can proposed a fork for that!
> 
> Second: **several problems where aborted upstream**, the most
> important ones are:
> * libs/maildrop/deliver.C (delivery): Always return 75 upon
> delivery failure, for the standalone maildrop build. related to #481223
> * libs/maildir/maildirmake.c (main): maildirmake's -q option
> will create the maildir if it does not exist. related to #501557
> * libs/rfc2045/reformime.c (main2): Fix crash when the -s option is
> not valid. related to #71625
> * rfc2045/reformime.c (main2): fix crash if -x or -X is specified
> without the corresponding -s option. related to #71625
> 
> A new maildrop pack is required and this must either come from the
> same courier sources (#867121) or update the one... this last seems
> quite stupid as courier is the official sources of maildrop and
> although it is offered separately by the author upstream, unifying it
> will improve maintenance from a team, and as you guys notice lack of
> interest/avaliable time in the courier suite (reading the last
> changelog, seems changes are more to complain with debian package
> policy that is innecesary respect real issues)
> 
> ... and as far as I can see you are looking for the sources in sf
> instead of the right place which is the courier oficial download page,
> additional while the courier-mta sources are up to date in
> salsa-debian, the maildrop one in salsa-debian are too old respect the
> mta suite!
> 
> while I made my own package on OBS vegnuli home for Devuan and Debian,
> is you guys need help i'm a often user of the complete suite and not
> just parts or toys of, maildrop can be build with two ways:
>  * set GID mail without restricted caller (maildrop)
>  * set UID root with restricted caller for courier-mta
>    (maildrop-courier) -- missing and the way i set in my package cos
> is the need by the original suite the courier-mta
> 
> 
> NOTE: Courier maildrop in debian present a very not proper behaviour..
> original sources are from courier and any other implementation are
> non-related and users can fork the software, cases like #375589 are
> not valid cos seems maildrop (as author make it for courier filtering)
> is a courier implementation if applies! so any external specific usage
> are purely optional
> 
> This are related to #910380 (separate makemime from sources) #204187,
> #596057 & #375589#26 (bad usage  cos is not made for), #481223
> (changed behaviour cos is not made for, what?), #592585 (dovecot
> specific crap) and go and go.. seems people thinks that maildrop are
> made for others rather than the courier suite... funny please close
> all of those package cos seems many of them are not supported by
> upstream and community must make a fork in those several cases!
> 
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com

-- 
Josip Rodin

Reply via email to