[ITP] Sendmail 8.14.9

[ITP] Sendmail 8.14.9

[D. Boland]

Hi group,

I intend to package the Cygwin version of Sendmail, version 8.14.9. 

sdesc: "The Mail Transfer Agent"
ldesc: "General purpose internetwork email routing facility that supports many kinds
of
 mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH)
 used for email transport over the internet."
category: Mail
requires: m4 procmail tcp_wrappers cyrus-sasl cygrunsrv cygwin
version: 18.14.9-0

http://cygwin.boland.nl/x86/release/sendmail/

All GTG's are welcome.

Cheers,
Daniel

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Aug 14 21:05, D. Boland wrote:
> Hi group,
> 
> I intend to package the Cygwin version of Sendmail, version 8.14.9. 
> 
> sdesc: "The Mail Transfer Agent"
> ldesc: "General purpose internetwork email routing facility that supports many kinds
> of
>  mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH)
>  used for email transport over the internet."
> category: Mail
> requires: m4 procmail tcp_wrappers cyrus-sasl cygrunsrv cygwin
> version: 18.14.9-0
> 
> http://cygwin.boland.nl/x86/release/sendmail/

Same as with procmail.  There's no "version" tag and the package should
be using cygport packaging.  This also makes sure that the setup.hint
file will be crated correctly, btw., since that's automatic then.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Corinna,

Corinna Vinschen wrote:
> 
> On Aug 14 21:05, D. Boland wrote:
> > Hi group,
> >
> > I intend to package the Cygwin version of Sendmail, version 8.14.9.
> >
> > sdesc: "The Mail Transfer Agent"
> > ldesc: "General purpose internetwork email routing facility that supports many kinds
> > of
> >  mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH)
> >  used for email transport over the internet."
> > category: Mail
> > requires: m4 procmail tcp_wrappers cyrus-sasl cygrunsrv cygwin
> > version: 18.14.9-0
> >
> > http://cygwin.boland.nl/x86/release/sendmail/
> 
> Same as with procmail.  There's no "version" tag and the package should
> be using cygport packaging.  This also makes sure that the setup.hint
> file will be crated correctly, btw., since that's automatic then.

I re-packaged Sendmail with cygport. See:

http://cygwin.boland.nl/x86/release/sendmail/

Cheers,
Daniel

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

On Aug 22 07:43, D. Boland wrote:
> Hi Corinna,
> 
> Corinna Vinschen wrote:
> > 
> > On Aug 14 21:05, D. Boland wrote:
> > > Hi group,
> > >
> > > I intend to package the Cygwin version of Sendmail, version 8.14.9.
> > >
> > > sdesc: "The Mail Transfer Agent"
> > > ldesc: "General purpose internetwork email routing facility that supports many kinds
> > > of
> > >  mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH)
> > >  used for email transport over the internet."
> > > category: Mail
> > > requires: m4 procmail tcp_wrappers cyrus-sasl cygrunsrv cygwin
> > > version: 18.14.9-0
> > >
> > > http://cygwin.boland.nl/x86/release/sendmail/
> > 
> > Same as with procmail.  There's no "version" tag and the package should
> > be using cygport packaging.  This also makes sure that the setup.hint
> > file will be crated correctly, btw., since that's automatic then.
> 
> I re-packaged Sendmail with cygport. See:
> 
> http://cygwin.boland.nl/x86/release/sendmail/

Packaging looks good in theory.

Unfortunately we have a problem.

On inspection of your binary package I noticed that we have conflicts
with exim and ssmtp packages:

- /usr/bin/mailq and /usr/bin/newaliases are provided by exim and
  your sendmail package.

- /usr/sbin/sendmail is either a binary (sendmail itself) or it will
  be installed as symlink by either /usr/bin/exim-config or
  /usr/sbin/ssmtp-config.
  
If Christian Franke's postfix port will ever fly, we have YA sendmail,
mailq, and newaliases symlinks to worry about.

Exim is Pierre's package and 32 bit only, ssmtp is my package (I had
to take over because the previous maintainer disappeared) and exists
for both architectures.

What we'll have to do to fix this problem is to convert all three
packages to use alternatives.  The alternatives package exists and is
already used by a couple of other packages which would otherwise
conflict, so there's precendent.  And on Fedora, the various mail
packages all use alternatives, too, to install their packages in
parallel and conflict-free.

And no, I'm not overly familiar with alternatives myself, but I will
convert my ssmtp package ASAP.

Pierre, any chance you could convert exim pretty quickly as well?
Otherwise sendmail is hanging in a limbo...


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Corinna,

> On Aug 22 07:43, D. Boland wrote:
> > I re-packaged Sendmail with cygport. See:
> >
> > http://cygwin.boland.nl/x86/release/sendmail/
> 
> Packaging looks good in theory.
> 
> Unfortunately we have a problem.
> 
> On inspection of your binary package I noticed that we have conflicts
> with exim and ssmtp packages:
> 
> - /usr/bin/mailq and /usr/bin/newaliases are provided by exim and
>   your sendmail package.
> 
> - /usr/sbin/sendmail is either a binary (sendmail itself) or it will
>   be installed as symlink by either /usr/bin/exim-config or
>   /usr/sbin/ssmtp-config.
> 
> If Christian Franke's postfix port will ever fly, we have YA sendmail,
> mailq, and newaliases symlinks to worry about.
> 
> Exim is Pierre's package and 32 bit only, ssmtp is my package (I had
> to take over because the previous maintainer disappeared) and exists
> for both architectures.
> 
> What we'll have to do to fix this problem is to convert all three
> packages to use alternatives.  The alternatives package exists and is
> already used by a couple of other packages which would otherwise
> conflict, so there's precendent.  And on Fedora, the various mail
> packages all use alternatives, too, to install their packages in
> parallel and conflict-free.
> 
> And no, I'm not overly familiar with alternatives myself, but I will
> convert my ssmtp package ASAP.
> 
> Pierre, any chance you could convert exim pretty quickly as well?
> Otherwise sendmail is hanging in a limbo...

You already guessed it. I don't like it. It's getting very messy this way. Amateur
hour is near...

I'm sorry for the following rant, but I am inclined to defend Sendmail's honour in
the name of its creator, the great Eric Allman.

I am pissed off at those programs. Let them use their own names! I have to rename my
library, but these 'postfix', 'exim' and 'ssmtp' apparitions shamelessly use
Sendmail's program names. As Yaakov puts it in my 'libsuexec' thread: "Deliberately
inciting confusion isn't a good thing."

I always wondered why Exim looks so damn similar to Sendmail. So, let's face it:
there is only one Real mail exchanger, and its name is Sendmail. These other
programs are cheap rip-offs, created by professional spammers te get past its
rigorous rules. 

I've been studying these clones for quite some years via their MIME headers and they
can't do the job alone. Show me a version of Exim running on a server somewhere and
I'll show you a version of Sendmail in the same domain which does the actual mail
exchanging to the outside world.

Mail exchanging is not about putting text on the wire. Any text editor can do that.
Real mail exchanging is about spam control through MIME headers and the clones
really suck at them. 

Ok, that being out of the way: I am running out of time, and I still have to do the
64bit version. I've read the 'alternatives' documentation and it looks nasty: link
groups, master link, slave link, automatic mode, manual mode...

Why not let the user choose one program? Putting both Exim and Sendmail on one box
is confusing, to say the least. Sendmail is very tough to understand. You don't want
another (very similar looking) mail exchanger to add to the confusion.

You really put me on the spot here. Will Sendmail suffer? Will it dream?

Cincerely,
Daniel

Re: [ITP] Sendmail 8.14.9

[Yaakov Selkowitz]

On 2014-08-22 13:19, D. Boland wrote:
>> On Aug 22 07:43, D. Boland wrote:
>>> I re-packaged Sendmail with cygport. See:
>>>
>>> http://cygwin.boland.nl/x86/release/sendmail/
>>
>> Packaging looks good in theory.
>>
>> Unfortunately we have a problem.
>>
>> On inspection of your binary package I noticed that we have conflicts
>> with exim and ssmtp packages:
[snip]
>> What we'll have to do to fix this problem is to convert all three
>> packages to use alternatives.  The alternatives package exists and is
>> already used by a couple of other packages which would otherwise
>> conflict, so there's precendent.  And on Fedora, the various mail
>> packages all use alternatives, too, to install their packages in
>> parallel and conflict-free.
[snip]
>
> You already guessed it. I don't like it. It's getting very messy this way.

Not doing this properly will be even more messy, I assure you.

> I'm sorry for the following rant,
[snip]

Rants and flamewars really aren't helpful.  The FOSS ecosystem not only 
allows for the possibility of alternative solutions, but thrives on it. 
  So while we probably agree that sendmail is the "first" and in some 
ways a de-facto standard (at least in terms of program names and paths), 
and is certainly worthy of consideration for our distribution, it does 
not negate the legitimacy of exim/postfix/ssmtp/etc.

> Ok, that being out of the way: I am running out of time,  and I still have to do the
> 64bit version.

Running out of time for what?  Keep in mind that being a package 
maintainer is more than just shipping a release and forgetting about it; 
given the nature of this package in particular, there are certainly 
going to be issues that come up from users.  Dealing with this is part 
of the commitment of being a package maintainer.

That being said, the more time we spend upfront doing this right should 
help mitigate even worse problems down the road should we not.

Also, the 32-bit and 64-bit versions should be done together, 
particularly as we're going to have to rebuild other packages to make 
these all coexist.  Therefore, it would be helpful if you could start 
working on the 64-bit ports in the meantime.

> I've read the 'alternatives' documentation and it looks nasty: link
> groups, master link, slave link, automatic mode, manual mode...

alternatives really isn't that hard to understand, and we'll help 
coordinate a working configuration for all the potentially conflicting MTAs.

> Why not let the user choose one program? Putting both Exim and Sendmail on one box
> is confusing, to say the least. Sendmail is very tough to understand. You don't want
> another (very similar looking) mail exchanger to add to the confusion.

Cygwin's setup*.exe does not support the concept of "conflicts" (one 
package blocking others from being installed), nor does it prevent file 
clobbering if multiple packages provide the same file.  Since there is 
no way to stop multiple MTAs from being installed, it is necessary to 
insure that they do so properly.

Besides, at least in Fedora, it is possible to install multiple MTAs 
without conflicts.

> You really put me on the spot here. Will Sendmail suffer? Will it dream?

This needs to be handled properly, that's all, and that can take time. 
If Pierre doesn't respond soon, we can step in to help with exim.


Yaakov

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Yaakov,

Yaakov Selkowitz wrote:
> 
> On 2014-08-22 13:19, D. Boland wrote:
> >> On Aug 22 07:43, D. Boland wrote:
> >>> I re-packaged Sendmail with cygport. See:
> >>>
> >>> http://cygwin.boland.nl/x86/release/sendmail/
> >>
> >> Packaging looks good in theory.
> >>
> >> Unfortunately we have a problem.
> >>
> >> On inspection of your binary package I noticed that we have conflicts
> >> with exim and ssmtp packages:
> [snip]
> >> What we'll have to do to fix this problem is to convert all three
> >> packages to use alternatives.  The alternatives package exists and is
> >> already used by a couple of other packages which would otherwise
> >> conflict, so there's precendent.  And on Fedora, the various mail
> >> packages all use alternatives, too, to install their packages in
> >> parallel and conflict-free.
> [snip]
> >
> > You already guessed it. I don't like it. It's getting very messy this way.
> 
> Not doing this properly will be even more messy, I assure you.
> 
> > I'm sorry for the following rant,
> [snip]
> 
> Rants and flamewars really aren't helpful.  The FOSS ecosystem not only
> allows for the possibility of alternative solutions, but thrives on it.
>   So while we probably agree that sendmail is the "first" and in some
> ways a de-facto standard (at least in terms of program names and paths),
> and is certainly worthy of consideration for our distribution, it does
> not negate the legitimacy of exim/postfix/ssmtp/etc.
> 
> > Ok, that being out of the way: I am running out of time,  and I still have to do the
> > 64bit version.
> 
> Running out of time for what?  Keep in mind that being a package
> maintainer is more than just shipping a release and forgetting about it;
> given the nature of this package in particular, there are certainly
> going to be issues that come up from users.  Dealing with this is part
> of the commitment of being a package maintainer.
> 
> That being said, the more time we spend upfront doing this right should
> help mitigate even worse problems down the road should we not.
> 
> Also, the 32-bit and 64-bit versions should be done together,
> particularly as we're going to have to rebuild other packages to make
> these all coexist.  Therefore, it would be helpful if you could start
> working on the 64-bit ports in the meantime.
> 

Thanks for letting me have my rant. I put in my time and I will continue to do so. I
think Sendmail, and for that matter, Redhat are worth it. You guys were the original
believers in open source software, putting your own time and resources on the line.
I still have an original 6.1 version running for 14 years now. Never crashed, never
had problems.

> > I've read the 'alternatives' documentation and it looks nasty: link
> > groups, master link, slave link, automatic mode, manual mode...
> 
> alternatives really isn't that hard to understand, and we'll help
> coordinate a working configuration for all the potentially conflicting MTAs.
> 
> > Why not let the user choose one program? Putting both Exim and Sendmail on one box
> > is confusing, to say the least. Sendmail is very tough to understand. You don't want
> > another (very similar looking) mail exchanger to add to the confusion.
> 
> Cygwin's setup*.exe does not support the concept of "conflicts" (one
> package blocking others from being installed), nor does it prevent file
> clobbering if multiple packages provide the same file.  Since there is
> no way to stop multiple MTAs from being installed, it is necessary to
> insure that they do so properly.
> 
> Besides, at least in Fedora, it is possible to install multiple MTAs
> without conflicts.
> 
> > You really put me on the spot here. Will Sendmail suffer? Will it dream?
> 
> This needs to be handled properly, that's all, and that can take time.
> If Pierre doesn't respond soon, we can step in to help with exim.
> 

So I will not be left alone with this. That's a relief. I'll wait with the
uploading. In the mean time I'll update the Procmail and Sendmail code to use the
new 'fakesu' lib. 

About the 64bit version: Are there any things I have to be careful of? Like
crosscompiling? Or is it a matter of just straight forward compiling on a 64bit
Cygwin machine? 

Daniel

Re: [ITP] Sendmail 8.14.9

[Yaakov Selkowitz]

On 2014-08-24 01:35, D. Boland wrote:
> About the 64bit version: Are there any things I have to be careful of? Like
> crosscompiling? Or is it a matter of just straight forward compiling on a 64bit
> Cygwin machine?

Hopefully the latter, but sometimes it's not that simple, so be sure to 
test the resulting binaries.


Yaakov

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

On Aug 25 18:16, Yaakov Selkowitz wrote:
> On 2014-08-24 01:35, D. Boland wrote:
> >About the 64bit version: Are there any things I have to be careful of? Like
> >crosscompiling? Or is it a matter of just straight forward compiling on a 64bit
> >Cygwin machine?
> 
> Hopefully the latter, but sometimes it's not that simple, so be sure to test
> the resulting binaries.

The most simple thing to do is to install 64 bit Cygwin and do the
port natively.  Many projects have no provisions for cross-compiling,
mostly non-autotools or non-cmake projects.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: [ITP] Sendmail 8.14.9

[Pierre A. Humblet]

> -----Original Message-----
> From:  Yaakov Selkowitz
> Sent: Friday, August 22, 2014 17:40
> 
> On 2014-08-22 13:19, D. Boland wrote:
> >> On Aug 22 07:43, D. Boland wrote:
> >>> I re-packaged Sendmail with cygport. See:
> >>>
> >>> http://cygwin.boland.nl/x86/release/sendmail/
> >>
> >> Packaging looks good in theory.
> >>
> >> Unfortunately we have a problem.
> >>
> >> On inspection of your binary package I noticed that we have conflicts
> >> with exim and ssmtp packages:
> [snip]
> >> What we'll have to do to fix this problem is to convert all three
> >> packages to use alternatives.  The alternatives package exists and is
> >> already used by a couple of other packages which would otherwise
> >> conflict, so there's precendent.  And on Fedora, the various mail
> >> packages all use alternatives, too, to install their packages in
> >> parallel and conflict-free.
> [snip]
> >
> 
> > Why not let the user choose one program? Putting both Exim and
> > Sendmail on one box is confusing, to say the least. Sendmail is very
> > tough to understand. You don't want another (very similar looking) mail
> exchanger to add to the confusion.
> 
> Cygwin's setup*.exe does not support the concept of "conflicts" (one
> package blocking others from being installed), nor does it prevent file
> clobbering if multiple packages provide the same file.  Since there is no
way
> to stop multiple MTAs from being installed, it is necessary to insure that
they
> do so properly.
> 
> This needs to be handled properly, that's all, and that can take time.
> If Pierre doesn't respond soon, we can step in to help with exim.
 
I should have time one evening this week to do whatever it takes. 
However I am not sure we need alternatives to handle conflicts in this case.
In the exim package /usr/bin/mailq and /usr/bin/newaliases are just symbolic
links to exim (newaliases is just a noop provided only to keep some 3rd
party scripts from failing). It would be easy to pull them out of the
package and to recreate them under user control in the exim config script.
Hopefully other MTAs can do something similar.
The symbolic link /usr/sbin/sendmail is not used by exim. It can be set from
the exim config script to allow third party programs to find the local MTA.

Whatever we do should be transparent to users who have already installed
ssmtp or exim and are updating to a newer version.

Pierre

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4226 bytes --]

On Aug 26 09:51, Pierre A. Humblet wrote:
> > -----Original Message-----
> > From:  Yaakov Selkowitz
> > Sent: Friday, August 22, 2014 17:40
> > 
> > On 2014-08-22 13:19, D. Boland wrote:
> > >> On Aug 22 07:43, D. Boland wrote:
> > >>> I re-packaged Sendmail with cygport. See:
> > >>>
> > >>> http://cygwin.boland.nl/x86/release/sendmail/
> > >>
> > >> Packaging looks good in theory.
> > >>
> > >> Unfortunately we have a problem.
> > >>
> > >> On inspection of your binary package I noticed that we have conflicts
> > >> with exim and ssmtp packages:
> > [snip]
> > >> What we'll have to do to fix this problem is to convert all three
> > >> packages to use alternatives.  The alternatives package exists and is
> > >> already used by a couple of other packages which would otherwise
> > >> conflict, so there's precendent.  And on Fedora, the various mail
> > >> packages all use alternatives, too, to install their packages in
> > >> parallel and conflict-free.
> > [snip]
> > >
> > 
> > > Why not let the user choose one program? Putting both Exim and
> > > Sendmail on one box is confusing, to say the least. Sendmail is very
> > > tough to understand. You don't want another (very similar looking) mail
> > exchanger to add to the confusion.
> > 
> > Cygwin's setup*.exe does not support the concept of "conflicts" (one
> > package blocking others from being installed), nor does it prevent file
> > clobbering if multiple packages provide the same file.  Since there is no
> way
> > to stop multiple MTAs from being installed, it is necessary to insure that
> they
> > do so properly.
> > 
> > This needs to be handled properly, that's all, and that can take time.
> > If Pierre doesn't respond soon, we can step in to help with exim.
>  
> I should have time one evening this week to do whatever it takes. 
> However I am not sure we need alternatives to handle conflicts in this case.
> In the exim package /usr/bin/mailq and /usr/bin/newaliases are just symbolic
> links to exim (newaliases is just a noop provided only to keep some 3rd
> party scripts from failing). It would be easy to pull them out of the
> package and to recreate them under user control in the exim config script.
> Hopefully other MTAs can do something similar.
> The symbolic link /usr/sbin/sendmail is not used by exim. It can be set from
> the exim config script to allow third party programs to find the local MTA.
> 
> Whatever we do should be transparent to users who have already installed
> ssmtp or exim and are updating to a newer version.

I guess that's exactly the problem.  Consider somebody has installed
exim or ssmtp and then installs sendmail accidentally or out of
curiosity.  This immediately overwrites the symlinks and even if
the user never actually uses sendmail, the MTA installation is broken.

I don't have a clear concept yet if and how we should use alternatives
to fix this problem.

Anyway, to have some working example, here's how Fedora does it:

The binaries, or symlinks to the actual binaries are called:

  /usr/sbin/sendmail.sendmail
  /usr/bin/mailq.sendmail
  /usr/bin/newaliases.sendmail

  /usr/sbin/sendmail.exim
  /usr/bin/mailq.exim
  /usr/bin/newaliases.exim

  /usr/sbin/sendmail.postfix
  /usr/bin/mailq.postfix
  /usr/bin/newaliases.postfix

  [analog for other MTAs]

Sendmail, mailq, newalias (etc.) are alternatives symlinks:

  /usr/sbin/sendmail -> /etc/alternatives/mta
  /usr/bin/mailq -> /etc/alternatives/mta-mailq
  /usr/bin/newaliases -> /etc/alternatives/mta-newaliases

And in /etc/alternatives are the symlinks to the actual binaries,
as configured by postinstall or the user:

  /etc/alternatives/mta -> /usr/sbin/sendmail.exim
  /etc/alternatives/mta-mailq -> /usr/bin/mailq.exim
  /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.exim

In fact, there are more than these three symlinks, mainly to rmail
and to the man pages for the aforementioned binaries.

Maybe we can shamelessly borrow this scheme?!?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: [ITP] Sendmail 8.14.9

[Pierre A. Humblet]

> -----Original Message-----
> From:  Corinna Vinschen
> Sent: Tuesday, August 26, 2014 14:50
> 
> On Aug 26 09:51, Pierre A. Humblet wrote:
> > > -----Original Message-----
> > > From:  Yaakov Selkowitz
> > > Sent: Friday, August 22, 2014 17:40
> > >
> > > On 2014-08-22 13:19, D. Boland wrote:
> > > >> On Aug 22 07:43, D. Boland wrote:
> > > >>> I re-packaged Sendmail with cygport. See:
> > > >>>
> > > >>> http://cygwin.boland.nl/x86/release/sendmail/
> > > >>
> > > >> Packaging looks good in theory.
> > > >>
> > > >> Unfortunately we have a problem.
> > > >>
> > > >> On inspection of your binary package I noticed that we have
> > > >> conflicts with exim and ssmtp packages:
> > > [snip]
> >
> > Whatever we do should be transparent to users who have already
> > installed ssmtp or exim and are updating to a newer version.
> 
> I guess that's exactly the problem.  Consider somebody has installed exim or
> ssmtp and then installs sendmail accidentally or out of curiosity.  This
> immediately overwrites the symlinks and even if the user never actually uses
> sendmail, the MTA installation is broken.
> 
> I don't have a clear concept yet if and how we should use alternatives to fix
> this problem.
> 
> Anyway, to have some working example, here's how Fedora does it:
> 
> The binaries, or symlinks to the actual binaries are called:
> 
>   /usr/sbin/sendmail.sendmail
>   /usr/bin/mailq.sendmail
>   /usr/bin/newaliases.sendmail
> 
>   /usr/sbin/sendmail.exim
>   /usr/bin/mailq.exim
>   /usr/bin/newaliases.exim
> 
>   /usr/sbin/sendmail.postfix
>   /usr/bin/mailq.postfix
>   /usr/bin/newaliases.postfix
> 
>   [analog for other MTAs]
> 
> Sendmail, mailq, newalias (etc.) are alternatives symlinks:
> 
>   /usr/sbin/sendmail -> /etc/alternatives/mta
>   /usr/bin/mailq -> /etc/alternatives/mta-mailq
>   /usr/bin/newaliases -> /etc/alternatives/mta-newaliases
> 
> And in /etc/alternatives are the symlinks to the actual binaries, as configured
> by postinstall or the user:
> 
>   /etc/alternatives/mta -> /usr/sbin/sendmail.exim
>   /etc/alternatives/mta-mailq -> /usr/bin/mailq.exim
>   /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.exim
> 
> In fact, there are more than these three symlinks, mainly to rmail and to the
> man pages for the aforementioned binaries.
> 
> Maybe we can shamelessly borrow this scheme?!?
> 

I am fine with the idea, except that I don’t see the need for things such as /usr/sbin/sendmail.exim
The executables can be installed in the current locations (/usr/bin for exim) and symbolic links such as /etc/alternatives/mta can point directly to the executables.
Also it looks like we don't need to use the alternatives package itself, although we reuse the /etc/alternatives directory and naming scheme

Below is what I would do in the MTA postinstall and -config files, using mailq as an example
I am assuming that /usr/bin/mailq will not be created by setup.

In the postinstall:
If /usr/bin/mailq is a symbolic link NOT already pointing to /etc/alternatives/mta-mailq {
           create a symbolic link /etc/alternative/mta-mailq pointing to /usr/bin/mailq's target
           replace the target of /usr/bin/mailq to /etc/alternatives/mta-mailq
}
else if /usr/bin/mailq is a file {
           rename /usr/bin/mailq to /usr/bin/mailq.somemta
          create a symbolic link /etc/alternatives/mta-mailq pointing to /usr/bin/mailq.somemta
          create a symbolic link /usr/bin/mailq to /etc/alternatives/mta-mailq
}
else if /usr/bin/mailq does not exist {
          create a symbolic link /usr/bin/mailq pointing to /etc/alternatives/mta-mailq
          if the MTA has been installed previously (like, old configuration or log files already exists) {
              create a symbolic link  /etc/alternatives/mta-mailq pointing to a suitable target (if any, created by setup) for the MTA being installed
          }
}
The point of the above is not to break existing installations when updating.
Unexpected cases (like /usr/bin/mailq is a directory) are handled in the MTA-config file.

In the MTA-config file executed by the user
- verify that /usr/bin/mailq is a symbolic link to /etc/alternatives/mta-mailq, fix the situation if necessary
- present a dialog to the user with the current value of the target and ask if it should be changed to the current MTA

Pierre

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4291 bytes --]

On Aug 27 11:16, Pierre A. Humblet wrote:
> > From:  Corinna Vinschen
> > Anyway, to have some working example, here's how Fedora does it:
> > 
> > The binaries, or symlinks to the actual binaries are called:
> > 
> >   /usr/sbin/sendmail.sendmail
> >   /usr/bin/mailq.sendmail
> >   /usr/bin/newaliases.sendmail
> > 
> >   /usr/sbin/sendmail.exim
> >   /usr/bin/mailq.exim
> >   /usr/bin/newaliases.exim
> > 
> >   /usr/sbin/sendmail.postfix
> >   /usr/bin/mailq.postfix
> >   /usr/bin/newaliases.postfix
> > 
> >   [analog for other MTAs]
> > 
> > Sendmail, mailq, newalias (etc.) are alternatives symlinks:
> > 
> >   /usr/sbin/sendmail -> /etc/alternatives/mta
> >   /usr/bin/mailq -> /etc/alternatives/mta-mailq
> >   /usr/bin/newaliases -> /etc/alternatives/mta-newaliases
> > 
> > And in /etc/alternatives are the symlinks to the actual binaries, as configured
> > by postinstall or the user:
> > 
> >   /etc/alternatives/mta -> /usr/sbin/sendmail.exim
> >   /etc/alternatives/mta-mailq -> /usr/bin/mailq.exim
> >   /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.exim
> > 
> > In fact, there are more than these three symlinks, mainly to rmail and to the
> > man pages for the aforementioned binaries.
> > 
> > Maybe we can shamelessly borrow this scheme?!?
> > 
> 
> I am fine with the idea, except that I don’t see the need for things
> such as /usr/sbin/sendmail.exim The executables can be installed in
> the current locations (/usr/bin for exim) and symbolic links such as
> /etc/alternatives/mta can point directly to the executables.

That's ok, I guess.

> Also it
> looks like we don't need to use the alternatives package itself,
> although we reuse the /etc/alternatives directory and naming scheme
> 
> Below is what I would do in the MTA postinstall and -config files,
> using mailq as an example I am assuming that /usr/bin/mailq will not
> be created by setup.
> 
> In the postinstall:
> If /usr/bin/mailq is a symbolic link NOT already pointing to
> /etc/alternatives/mta-mailq {
>            create a symbolic link /etc/alternative/mta-mailq pointing to /usr/bin/mailq's target
>            replace the target of /usr/bin/mailq to /etc/alternatives/mta-mailq
> }
> else if /usr/bin/mailq is a file {
>            rename /usr/bin/mailq to /usr/bin/mailq.somemta
>           create a symbolic link /etc/alternatives/mta-mailq pointing to /usr/bin/mailq.somemta
>           create a symbolic link /usr/bin/mailq to /etc/alternatives/mta-mailq
> }
> else if /usr/bin/mailq does not exist {
>           create a symbolic link /usr/bin/mailq pointing to /etc/alternatives/mta-mailq
>           if the MTA has been installed previously (like, old configuration or log files already exists) {
>               create a symbolic link  /etc/alternatives/mta-mailq pointing to a suitable target (if any, created by setup) for the MTA being installed
>           }
> }
> The point of the above is not to break existing installations when
> updating.  Unexpected cases (like /usr/bin/mailq is a directory) are
> handled in the MTA-config file.
> 
> In the MTA-config file executed by the user
> - verify that /usr/bin/mailq is a symbolic link to
> /etc/alternatives/mta-mailq, fix the situation if necessary
> - present a dialog to the user with the current value of the target
> and ask if it should be changed to the current MTA

The question is this:  IIUC, the above is almost exactly what the
alternatives mechanism is for.  Why reinvent the wheel if a proved
mechanism exists?  It also seems a bit unlean to reuse the directory
exclusively used by the alternatives package for non-alternatives stuff.

If Yaakov is available later today I will talk this through with him and
try to come up with a simple alternatives usage inside of ssmtp.  In
the case of ssmtp it's only a single sendmail symlink, but as a role
model it's hopefully sufficient.

That still doesn't mean we *must* use alternatives, but since it's
put to good use by Linux distros (and in Cygwin, too!), I'd like to
give it a fair chance :)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]

On Aug 28 12:27, Corinna Vinschen wrote:
> On Aug 27 11:16, Pierre A. Humblet wrote:
> > > From:  Corinna Vinschen
> > > Anyway, to have some working example, here's how Fedora does it:
> > > 
> > > The binaries, or symlinks to the actual binaries are called:
> > > 
> > >   /usr/sbin/sendmail.sendmail
> > >   /usr/bin/mailq.sendmail
> > >   /usr/bin/newaliases.sendmail
> > > 
> > >   /usr/sbin/sendmail.exim
> > >   /usr/bin/mailq.exim
> > >   /usr/bin/newaliases.exim
> > > 
> > >   /usr/sbin/sendmail.postfix
> > >   /usr/bin/mailq.postfix
> > >   /usr/bin/newaliases.postfix
> > > 
> > >   [analog for other MTAs]
> > > 
> > > Sendmail, mailq, newalias (etc.) are alternatives symlinks:
> > > 
> > >   /usr/sbin/sendmail -> /etc/alternatives/mta
> > >   /usr/bin/mailq -> /etc/alternatives/mta-mailq
> > >   /usr/bin/newaliases -> /etc/alternatives/mta-newaliases
> > > 
> > > And in /etc/alternatives are the symlinks to the actual binaries, as configured
> > > by postinstall or the user:
> > > 
> > >   /etc/alternatives/mta -> /usr/sbin/sendmail.exim
> > >   /etc/alternatives/mta-mailq -> /usr/bin/mailq.exim
> > >   /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.exim
> > > 
> > > In fact, there are more than these three symlinks, mainly to rmail and to the
> > > man pages for the aforementioned binaries.
> > > 
> > > Maybe we can shamelessly borrow this scheme?!?
> > > 
> > 
> > I am fine with the idea, except that I don’t see the need for things
> > such as /usr/sbin/sendmail.exim The executables can be installed in
> > the current locations (/usr/bin for exim) and symbolic links such as
> > /etc/alternatives/mta can point directly to the executables.
> 
> That's ok, I guess.
> 
> > Also it
> > looks like we don't need to use the alternatives package itself,
> > although we reuse the /etc/alternatives directory and naming scheme
> > 
> > Below is what I would do in the MTA postinstall and -config files,
> > using mailq as an example I am assuming that /usr/bin/mailq will not
> > be created by setup.
> > 
> > In the postinstall:
> > If /usr/bin/mailq is a symbolic link NOT already pointing to
> > /etc/alternatives/mta-mailq {
> >            create a symbolic link /etc/alternative/mta-mailq pointing to /usr/bin/mailq's target
> >            replace the target of /usr/bin/mailq to /etc/alternatives/mta-mailq
> > }
> > else if /usr/bin/mailq is a file {
> >            rename /usr/bin/mailq to /usr/bin/mailq.somemta
> >           create a symbolic link /etc/alternatives/mta-mailq pointing to /usr/bin/mailq.somemta
> >           create a symbolic link /usr/bin/mailq to /etc/alternatives/mta-mailq

This part won't work as expected btw.  If the sendmail package installs
the actual binaries under the names reserved for the symlinks to the
user-defined MTA tools, then you change the installation.

Consider what happens when you have an exim installation and
deliberately or accidentally install sendmail:  It will overwrite your
symlinks and break a perfectly fine exim installation.

Same when uninstalling: Assuming you have exim and sendmail installed,
with the symlinks pointing to exim, then you uninstall the sendmail
package.  Setup will remove the symlinks but the "mailq.somemta"
binaries will stay in /usr/bin since setup doesn't know about them.

I think the right thing to do would be to install either renamed
binaries, as Fedora does it, or to keep the names and install the
binaries into some different directory (perhaps something like
/usr/lib/sendmail/bin) and symlink to this dir.  


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: [ITP] Sendmail 8.14.9

[Pierre A. Humblet]

> -----Original Message-----
> From: Corinna Vinschen
> Sent: Thursday, August 28, 2014 12:00
> 
> On Aug 28 12:27, Corinna Vinschen wrote:
> > On Aug 27 11:16, Pierre A. Humblet wrote:
> > > > From:  Corinna Vinschen
> > > > Anyway, to have some working example, here's how Fedora does it:
> > > >
> > > > The binaries, or symlinks to the actual binaries are called:
> > > >
> > > >   /usr/sbin/sendmail.sendmail
> > > >   /usr/bin/mailq.sendmail
> > > >   /usr/bin/newaliases.sendmail
> > > >
> > > >   /usr/sbin/sendmail.exim
> > > >   /usr/bin/mailq.exim
> > > >   /usr/bin/newaliases.exim
> > > >
> > > >   /usr/sbin/sendmail.postfix
> > > >   /usr/bin/mailq.postfix
> > > >   /usr/bin/newaliases.postfix
> > > >
> > > >   [analog for other MTAs]
> > > >
> > > > Sendmail, mailq, newalias (etc.) are alternatives symlinks:
> > > >
> > > >   /usr/sbin/sendmail -> /etc/alternatives/mta
> > > >   /usr/bin/mailq -> /etc/alternatives/mta-mailq
> > > >   /usr/bin/newaliases -> /etc/alternatives/mta-newaliases
> > > >
> > > > And in /etc/alternatives are the symlinks to the actual binaries,
> > > > as configured by postinstall or the user:
> > > >
> > > >   /etc/alternatives/mta -> /usr/sbin/sendmail.exim
> > > >   /etc/alternatives/mta-mailq -> /usr/bin/mailq.exim
> > > >   /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.exim
> > > >
> > > > In fact, there are more than these three symlinks, mainly to rmail
> > > > and to the man pages for the aforementioned binaries.
> > > >
> > > > Maybe we can shamelessly borrow this scheme?!?
> > > >
> > >
> > > I am fine with the idea, except that I don’t see the need for things
> > > such as /usr/sbin/sendmail.exim The executables can be installed in
> > > the current locations (/usr/bin for exim) and symbolic links such as
> > > /etc/alternatives/mta can point directly to the executables.
> >
> > That's ok, I guess.
> >
> > > Also it
> > > looks like we don't need to use the alternatives package itself,
> > > although we reuse the /etc/alternatives directory and naming scheme
> > >
> > > Below is what I would do in the MTA postinstall and -config files,
> > > using mailq as an example I am assuming that /usr/bin/mailq will not
> > > be created by setup.
> > >
> > > In the postinstall:
> > > If /usr/bin/mailq is a symbolic link NOT already pointing to
> > > /etc/alternatives/mta-mailq {
> > >            create a symbolic link /etc/alternative/mta-mailq pointing to
> /usr/bin/mailq's target
> > >            replace the target of /usr/bin/mailq to
> > > /etc/alternatives/mta-mailq } else if /usr/bin/mailq is a file {
> > >            rename /usr/bin/mailq to /usr/bin/mailq.somemta
> > >           create a symbolic link /etc/alternatives/mta-mailq pointing to
> /usr/bin/mailq.somemta
> > >           create a symbolic link /usr/bin/mailq to
> > > /etc/alternatives/mta-mailq
> 
> This part won't work as expected btw.  If the sendmail package installs the
> actual binaries under the names reserved for the symlinks to the user-
> defined MTA tools, then you change the installation.
> 
> Consider what happens when you have an exim installation and deliberately
> or accidentally install sendmail:  It will overwrite your symlinks and break a
> perfectly fine exim installation.
> 
> Same when uninstalling: Assuming you have exim and sendmail installed,
> with the symlinks pointing to exim, then you uninstall the sendmail package.
> Setup will remove the symlinks but the "mailq.somemta"
> binaries will stay in /usr/bin since setup doesn't know about them.
> 
> I think the right thing to do would be to install either renamed binaries, as
> Fedora does it, or to keep the names and install the binaries into some
> different directory (perhaps something like
> /usr/lib/sendmail/bin) and symlink to this dir.

I was assuming that from now on no package would ever install /usr/bin/mailq (etc). Only postinstalls would create it. 
With that assumption, I don't understand what you mean but I may not have given enough info.

The stuff in the postinstall is only meant for the transition phase when /usr/bin/mailq (etc) is NOT pointing to /etc/alternatives/mta-mailq.

Today the only Cywin package creating /usr/bin/mailq is exim, AFAIK. It is a symlink pointing to /usr/bin/exim. If an updated exim is installed before sendmail, setup should have removed the old /usr/bin/mailq, a new one will be created in the postinstall as outlined and things will be OK.

If for some reason the old one is not removed (or if sendmail is installed before exim is reinstalled), /usr/bin/mailq will be set to point to /etc/alternatives/mta-mailq, which be set to point to /usr/bin/exim. So the exim installation is OK.

The case where /usr/bin/mailq is a file is only meant to cover the case where a user has compiled and installed some package (not through setup) that contains a binary /usr/bin/mailq. It would be renamed to mailq.somemta, not breaking anything.

But you are right that there is a flaw: if sendmail is installed before exim is updated, the sendmail postinstall will have created the new link, eventually pointing to exim. Exim would keep working fine. The user could then (during sendmail-config)  change the link to point to sendmail. If the user then uninstalls exim the /usr/bin/mailq link will be deleted (I presume), breaking sendmail.

Note that if exim was updated (instead of uninstalled), /usr/bin/mailq would also be deleted but the exim postinstall would create a new link to /etc/alternatives/mta-mailq. As that symlink already points to the sendmail.mailq the sendmail installation would be OK.
I don't see how we can handle the bad case. Renaming binaries won't help. 

Breaking mailq or newaliases doesn't bother me much as people using them should be able to handle the problem. I am more concerned by changes to the /usr/sbin/sendmail symlink, which is used by 3rd party programs. However is was not created by setup and thus the flaw discussed above does not exist.

Pierre

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Group,

I have considered your suggestions, and changed the package accordingly:

http://cygwin.boland.nl/x86/release/sendmail/

* I added the following man pages to the Alternatives system:

mailq(1), newaliases(1), aliases(5), sendmail(8).

* I separated the following functions from the postinstall script and put them in
the /usr/bin/sendmail script:

- Creation of user and group accounts.
- Installation of services.
- Setting alternatives to manual mode

* I removed the formatted man pages in /usr/share/man/cat*, and added troff versions 
in /usr/share/man/man*.

* I moved the config files to the designated location /etc/defaults/etc

Also, for Sendmail to be able to log, the syslogd from the inetutils-server package
has to be installed. I noticed that the "inetutils" package is orphaned. Could I
adopt it?

Cincerely,
Daniel

"D. Boland" wrote:
> 
> Hi group,
> 
> I intend to package the Cygwin version of Sendmail, version 8.14.9.
> 
> sdesc: "The Mail Transfer Agent"
> ldesc: "General purpose internetwork email routing facility that supports many kinds
> of
>  mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA (AUTH)
>  used for email transport over the internet."
> category: Mail
> requires: m4 procmail tcp_wrappers cyrus-sasl cygrunsrv cygwin
> version: 18.14.9-0
> 
> http://cygwin.boland.nl/x86/release/sendmail/
> 
> All GTG's are welcome.
> 
> Cheers,
> Daniel

-- 
Sent by my Altair 8800

-- boland automatisering ----------------------------------------
   Deimanstraat 354
   2522 BV Den Haag
   mailto:info@boland.nl
   http://www.boland.nl
   phoneto:+31 (0)70 3900941
-----------------------------------------------------------------

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

Hi Daniel,

On Feb 17 13:03, D. Boland wrote:
> Also, for Sendmail to be able to log, the syslogd from the
> inetutils-server package has to be installed.

If no syslog daemon is installed, the logs automatically go the the
Windows event log.  Additionally there's the syslog-ng package, so
there's no requirement to install inetutils-server to get logs.

> I noticed that the
> "inetutils" package is orphaned. Could I adopt it?

Sure, a package with maintainer beats a package without maintainer
hands down.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

Hi Daniel,

On Feb 17 13:03, D. Boland wrote:
> Hi Group,
> 
> I have considered your suggestions, and changed the package accordingly:
> 
> http://cygwin.boland.nl/x86/release/sendmail/
> 
> * I added the following man pages to the Alternatives system:
> 
> mailq(1), newaliases(1), aliases(5), sendmail(8).
> 
> * I separated the following functions from the postinstall script and put them in
> the /usr/bin/sendmail script:
> 
> - Creation of user and group accounts.
> - Installation of services.
> - Setting alternatives to manual mode
> 
> * I removed the formatted man pages in /usr/share/man/cat*, and added troff versions 
> in /usr/share/man/man*.
> 
> * I moved the config files to the designated location /etc/defaults/etc

Only two smaller problems:

- The mailq and newaliases symlinks in /usr/bin must not be part
  of the package, otherwise they potentially overwrite an existing
  configuration.  They are created by sendmail-config anyway, if
  the user chooses to run the script.

- Probably less important, but the other MTAs are installed into
  /usr/sbin, not into /usr/libexec.  Fedora installs the sendmail
  binary as /usr/sbin/sendmail.sendmail, analog to postfix, which
  is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix.
  But that's not that important, as long as there's no collision.

Other than that, I think the package is GTG.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Corinna,

Corinna Vinschen wrote:
> 
> 
> Only two smaller problems:
> 
> - The mailq and newaliases symlinks in /usr/bin must not be part
>   of the package, otherwise they potentially overwrite an existing
>   configuration.  They are created by sendmail-config anyway, if
>   the user chooses to run the script.
> 
> - Probably less important, but the other MTAs are installed into
>   /usr/sbin, not into /usr/libexec.  Fedora installs the sendmail
>   binary as /usr/sbin/sendmail.sendmail, analog to postfix, which
>   is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix.
>   But that's not that important, as long as there's no collision.
> 
> Other than that, I think the package is GTG.
> 

Thanks for the sharp eye. I'll remove the links.

Daniel

Re: [ITP] Sendmail 8.14.9

[Christian Franke]

D. Boland wrote:
> Hi Corinna,
>
> Corinna Vinschen wrote:
>>
>> Only two smaller problems:
>>
>> - The mailq and newaliases symlinks in /usr/bin must not be part
>>    of the package, otherwise they potentially overwrite an existing
>>    configuration.  They are created by sendmail-config anyway, if
>>    the user chooses to run the script.
>>
>> - Probably less important, but the other MTAs are installed into
>>    /usr/sbin, not into /usr/libexec.  Fedora installs the sendmail
>>    binary as /usr/sbin/sendmail.sendmail, analog to postfix, which
>>    is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix.
>>    But that's not that important, as long as there's no collision.
>>
>> Other than that, I think the package is GTG.
>>
> Thanks for the sharp eye. I'll remove the links.
>

Another minor issue in the last line /etc/postinstall/sendmail.sh:

chown SYSTEM:Administrators $UBINDIR/sendmail-config

This does not work with all versions of Windows because the 
"Administrators" (S-1-5-32-544) group name may be localized.

Christian

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Feb 17 23:51, Christian Franke wrote:
> D. Boland wrote:
> >Hi Corinna,
> >
> >Corinna Vinschen wrote:
> >>
> >>Only two smaller problems:
> >>
> >>- The mailq and newaliases symlinks in /usr/bin must not be part
> >>   of the package, otherwise they potentially overwrite an existing
> >>   configuration.  They are created by sendmail-config anyway, if
> >>   the user chooses to run the script.
> >>
> >>- Probably less important, but the other MTAs are installed into
> >>   /usr/sbin, not into /usr/libexec.  Fedora installs the sendmail
> >>   binary as /usr/sbin/sendmail.sendmail, analog to postfix, which
> >>   is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix.
> >>   But that's not that important, as long as there's no collision.
> >>
> >>Other than that, I think the package is GTG.
> >>
> >Thanks for the sharp eye. I'll remove the links.
> >
> 
> Another minor issue in the last line /etc/postinstall/sendmail.sh:
> 
> chown SYSTEM:Administrators $UBINDIR/sendmail-config
> 
> This does not work with all versions of Windows because the "Administrators"
> (S-1-5-32-544) group name may be localized.

Indeed.  That should use the gid 544 instead.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

Daniel,

On Feb 18 00:04, Corinna Vinschen wrote:
> On Feb 17 23:51, Christian Franke wrote:
> > D. Boland wrote:
> > >Hi Corinna,
> > >
> > >Corinna Vinschen wrote:
> > >>
> > >>Only two smaller problems:
> > >>
> > >>- The mailq and newaliases symlinks in /usr/bin must not be part
> > >>   of the package, otherwise they potentially overwrite an existing
> > >>   configuration.  They are created by sendmail-config anyway, if
> > >>   the user chooses to run the script.
> > >>
> > >>- Probably less important, but the other MTAs are installed into
> > >>   /usr/sbin, not into /usr/libexec.  Fedora installs the sendmail
> > >>   binary as /usr/sbin/sendmail.sendmail, analog to postfix, which
> > >>   is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix.
> > >>   But that's not that important, as long as there's no collision.
> > >>
> > >>Other than that, I think the package is GTG.
> > >>
> > >Thanks for the sharp eye. I'll remove the links.
> > >
> > 
> > Another minor issue in the last line /etc/postinstall/sendmail.sh:
> > 
> > chown SYSTEM:Administrators $UBINDIR/sendmail-config
> > 
> > This does not work with all versions of Windows because the "Administrators"
> > (S-1-5-32-544) group name may be localized.
> 
> Indeed.  That should use the gid 544 instead.

I removed the just uploaded 32 bit sendmail package for now.

For one thing, the 64 bit package is missing for some reason, the
other is that you didn't take the above into account.  The
Administrators account is only called Administrators on certain
language versions of Windows.  On other language versions, the
name "Administrators" is localized, for instance "Administratoren"
on german versions.

Please fix this before re-uploading.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[Daniel]

Corinna Vinschen wrote:
> Daniel,
> 
> On Feb 18 00:04, Corinna Vinschen wrote:
>> On Feb 17 23:51, Christian Franke wrote:
>>> D. Boland wrote:
>>>> Hi Corinna,
>>>>
>>>> Corinna Vinschen wrote:
>>>>> Only two smaller problems:
>>>>>
>>>>> - The mailq and newaliases symlinks in /usr/bin must not be part
>>>>>   of the package, otherwise they potentially overwrite an existing
>>>>>   configuration.  They are created by sendmail-config anyway, if
>>>>>   the user chooses to run the script.
>>>>>
>>>>> - Probably less important, but the other MTAs are installed into
>>>>>   /usr/sbin, not into /usr/libexec.  Fedora installs the sendmail
>>>>>   binary as /usr/sbin/sendmail.sendmail, analog to postfix, which
>>>>>   is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix.
>>>>>   But that's not that important, as long as there's no collision.
>>>>>
>>>>> Other than that, I think the package is GTG.
>>>>>
>>>> Thanks for the sharp eye. I'll remove the links.
>>>>
>>> Another minor issue in the last line /etc/postinstall/sendmail.sh:
>>>
>>> chown SYSTEM:Administrators $UBINDIR/sendmail-config
>>>
>>> This does not work with all versions of Windows because the "Administrators"
>>> (S-1-5-32-544) group name may be localized.
>> Indeed.  That should use the gid 544 instead.
> 
> I removed the just uploaded 32 bit sendmail package for now.
> 
> For one thing, the 64 bit package is missing for some reason, the
> other is that you didn't take the above into account.  The
> Administrators account is only called Administrators on certain
> language versions of Windows.  On other language versions, the
> name "Administrators" is localized, for instance "Administratoren"
> on german versions.
> 
> Please fix this before re-uploading.
> 
> 
> Thanks,
> Corinna
> 

I'm sorry, I didn't read the last post before uploading. I fixed it. 
Should I wait uploading until I have the 64-bit version ready?

D.

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

Hi Daniel,

On Apr  4 13:37, Daniel wrote:
> Corinna Vinschen wrote:
> >Daniel,
> >
> >On Feb 18 00:04, Corinna Vinschen wrote:
> >>On Feb 17 23:51, Christian Franke wrote:
> >>>D. Boland wrote:
> >>>>Hi Corinna,
> >>>>
> >>>>Corinna Vinschen wrote:
> >>>>>Only two smaller problems:
> >>>>>
> >>>>>- The mailq and newaliases symlinks in /usr/bin must not be part
> >>>>>  of the package, otherwise they potentially overwrite an existing
> >>>>>  configuration.  They are created by sendmail-config anyway, if
> >>>>>  the user chooses to run the script.
> >>>>>
> >>>>>- Probably less important, but the other MTAs are installed into
> >>>>>  /usr/sbin, not into /usr/libexec.  Fedora installs the sendmail
> >>>>>  binary as /usr/sbin/sendmail.sendmail, analog to postfix, which
> >>>>>  is installed on Cygwin and Linux as /usr/sbin/sendmail.postfix.
> >>>>>  But that's not that important, as long as there's no collision.
> >>>>>
> >>>>>Other than that, I think the package is GTG.
> >>>>>
> >>>>Thanks for the sharp eye. I'll remove the links.
> >>>>
> >>>Another minor issue in the last line /etc/postinstall/sendmail.sh:
> >>>
> >>>chown SYSTEM:Administrators $UBINDIR/sendmail-config
> >>>
> >>>This does not work with all versions of Windows because the "Administrators"
> >>>(S-1-5-32-544) group name may be localized.
> >>Indeed.  That should use the gid 544 instead.
> >
> >I removed the just uploaded 32 bit sendmail package for now.
> >
> >For one thing, the 64 bit package is missing for some reason, the
> >other is that you didn't take the above into account.  The
> >Administrators account is only called Administrators on certain
> >language versions of Windows.  On other language versions, the
> >name "Administrators" is localized, for instance "Administratoren"
> >on german versions.
> >
> >Please fix this before re-uploading.
> >
> >
> >Thanks,
> >Corinna
> >
> 
> I'm sorry, I didn't read the last post before uploading. I fixed it.

Cool.

> Should
> I wait uploading until I have the 64-bit version ready?

It would be nice if both versions would be available at the same time.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[ITP] Sendmail 8.14.9

[D. Boland]

Hi group,

I intend to package the Cygwin version of Sendmail, version 8.14.9. 

category: Mail
requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
sdesc: "The Mail Transfer Agent (mail server)"
ldesc: "General purpose internetwork email routing facility that supports many kinds 
 of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA 
 (AUTH) used for email transport over the internet."

I've implementented the "alternatives" mechanism, so it can be installed alongside
other Mail Transfer Agents, such as Exim, Postfix or ssmtp.

http://cygwin.boland.nl/x86/release/sendmail/

Daniel

Re: [ITP] Sendmail 8.14.9

[Christian Franke]

D. Boland wrote:
> Hi group,
>
> I intend to package the Cygwin version of Sendmail, version 8.14.9.
>
> category: Mail
> requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
> m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
> sdesc: "The Mail Transfer Agent (mail server)"
> ldesc: "General purpose internetwork email routing facility that supports many kinds
>   of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA
>   (AUTH) used for email transport over the internet."
>
> I've implementented the "alternatives" mechanism, so it can be installed alongside
> other Mail Transfer Agents, such as Exim, Postfix or ssmtp.

Please handle also the following man pages via "alternatives":

mailq(1), newaliases(1), aliases(5), sendmail(8).

These definitely will be in conflict with upcoming postfix package. Use 
e.g. aliases.sendmail.5.gz as the real filename (as done on Fedora).
See also https://cygwin.com/ml/cygwin-apps/2014-10/msg00010.html and its 
attachment.


Further suggestions:

The following should IMO never be done in a postinstall script:
- Creation of user and group accounts.
- Installation of services.
- Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
Please consider moving the above to the sendmail-config script.

- Remove formatted man pages in /usr/share/man/cat*, add troff versions 
in /usr/share/man/man*.

- Move /etc/mail/FILE.default to /etc/defaults/etc/mail/FILE, 
(post)install the files to /etc/mail if not existing, (pre)remove later 
if not changed. The cygport function make_etc_defaults is your friend :-)

- Try to provide a debug package. Try to add this to CFLAGS:
   -ggdb -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
Cygport may or may not handle the remaining details then.


Christian

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Christian,

Christian Franke wrote:
> 
> D. Boland wrote:
> > Hi group,
> >
> > I intend to package the Cygwin version of Sendmail, version 8.14.9.
> >
> > category: Mail
> > requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
> > m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
> > sdesc: "The Mail Transfer Agent (mail server)"
> > ldesc: "General purpose internetwork email routing facility that supports many kinds
> >   of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA
> >   (AUTH) used for email transport over the internet."
> >
> > I've implementented the "alternatives" mechanism, so it can be installed alongside
> > other Mail Transfer Agents, such as Exim, Postfix or ssmtp.
> 
> Please handle also the following man pages via "alternatives":
> 
> mailq(1), newaliases(1), aliases(5), sendmail(8).
> 
> These definitely will be in conflict with upcoming postfix package. Use
> e.g. aliases.sendmail.5.gz as the real filename (as done on Fedora).
> See also https://cygwin.com/ml/cygwin-apps/2014-10/msg00010.html and its
> attachment.

Is it possible for the Postfix package to not override the 'sendmail' man page? That
way one can compare the two programs without having to switch like this:

/usr/sbin/alternatives --set mta /usr/sbin/postfix
man sendmail

/usr/sbin/alternatives --set mta /usr/libexec/sendmail
man sendmail

> 
> Further suggestions:
> 
> The following should IMO never be done in a postinstall script:
> - Creation of user and group accounts.
> - Installation of services.
> - Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
> Please consider moving the above to the sendmail-config script.

All steps in postinstall are necessary for running Sendmail. The sendmail-config
script contains steps where user-intervention is needed.

I'll move the '--set' instruction to the 'sendmail-config' script. 

I will provide a pre-remove script that rolls back user-creation and
service-installation.

> 
> - Remove formatted man pages in /usr/share/man/cat*, add troff versions
> in /usr/share/man/man*.

I will comply, but consider the following. Making man pages smear lines of text
across the entire width of the screen makes the text unreadable and the layout ugly,
especially with the omnipresent wide-screen displays nowadays.

> 
> - Move /etc/mail/FILE.default to /etc/defaults/etc/mail/FILE,
> (post)install the files to /etc/mail if not existing, (pre)remove later
> if not changed. The cygport function make_etc_defaults is your friend :-)
> 
> - Try to provide a debug package. Try to add this to CFLAGS:
>    -ggdb -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
> Cygport may or may not handle the remaining details then.

I'll try that.

Cincerely,
Daniel

Re: [ITP] Sendmail 8.14.9

[Christian Franke]

D. Boland wrote:
> Hi Christian,
>
> Christian Franke wrote:
>> D. Boland wrote:
>>> Hi group,
>>>
>>> I intend to package the Cygwin version of Sendmail, version 8.14.9.
>>>
>>> category: Mail
>>> requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
>>> m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
>>> sdesc: "The Mail Transfer Agent (mail server)"
>>> ldesc: "General purpose internetwork email routing facility that supports many kinds
>>>    of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA
>>>    (AUTH) used for email transport over the internet."
>>>
>>> I've implementented the "alternatives" mechanism, so it can be installed alongside
>>> other Mail Transfer Agents, such as Exim, Postfix or ssmtp.
>> Please handle also the following man pages via "alternatives":
>>
>> mailq(1), newaliases(1), aliases(5), sendmail(8).
>>
>> These definitely will be in conflict with upcoming postfix package. Use
>> e.g. aliases.sendmail.5.gz as the real filename (as done on Fedora).
>> See also https://cygwin.com/ml/cygwin-apps/2014-10/msg00010.html and its
>> attachment.
> Is it possible for the Postfix package to not override the 'sendmail' man page? That
> way one can compare the two programs without having to switch like this:
>
> /usr/sbin/alternatives --set mta /usr/sbin/postfix
> man sendmail
>
> /usr/sbin/alternatives --set mta /usr/libexec/sendmail
> man sendmail

Not needed, because both man pages would be still accessible via 'man 
sendmail.sendmail' and 'man sendmail.postfix'.

The /usr/bin/postfix-config script will link sendmail1.gz -> 
sendmail.postfix.1.gz via alternatives because then the user has then 
*decided* to run postfix as an MTA.
The /etc/postinstall/postfix.sh script will only copy the 
/etc/defaults/etc/postfix files (no alternatives, no user/group 
creation, no service installation).



>> Further suggestions:
>>
>> The following should IMO never be done in a postinstall script:
>> - Creation of user and group accounts.
>> - Installation of services.
>> - Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
>> Please consider moving the above to the sendmail-config script.
> All steps in postinstall are necessary for running Sendmail.

Note that the above steps are re-done on each package update.

The installation of sendmail does not imply that the user wants to run 
it immediately.

> The sendmail-config
> script contains steps where user-intervention is needed.

An MTA typically cannot be run without some manual local configuration.

Then it IMO does not make sense to do intrusive changes like creation of 
Windows user and group creation early in an unattended postinstall script.

> I'll move the '--set' instruction to the 'sendmail-config' script.
>
> I will provide a pre-remove script that rolls back user-creation and
> service-installation.

In /etc/preremove?

Note that this script is also run on each package update.

>> - Remove formatted man pages in /usr/share/man/cat*, add troff versions
>> in /usr/share/man/man*.
> I will comply, but consider the following. Making man pages smear lines of text
> across the entire width of the screen makes the text unreadable and the layout ugly,
> especially with the omnipresent wide-screen displays nowadays.

I disagree.

These formatted man page *with embedded terminal escape sequences* are 
useless for non-terminal output (printing, conversion to pdf, ...).

According to Cygwin package search, only the libfltk-devel package 
provides formatted man pages, but it also includes the troff versions.

Christian

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On Nov  2 13:43, Christian Franke wrote:
> D. Boland wrote:
> >Christian Franke wrote:
> >>The following should IMO never be done in a postinstall script:
> >>- Creation of user and group accounts.
> >>- Installation of services.
> >>- Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
> >>Please consider moving the above to the sendmail-config script.
> >All steps in postinstall are necessary for running Sendmail.
> 
> Note that the above steps are re-done on each package update.
> 
> The installation of sendmail does not imply that the user wants to run it
> immediately.

These are important points.

For other services we never create the accounts without the user
explicitely requesting them by calling the <service>-config script.

The other problem is that you don't know if creating the a local account
is the right thing to do.  In many companies there are restrictions on
creating a local account and a domain account has to be created instead.
Your config script has to take that into account by checking if a matching
user account exists already or to ask the user if it should be created.

There's a helper script framework available for that, called csih.  It's
used, for instance, by the cron-config or ssh-host-config scripts.  It
has functions to check for predefined accounts and to install them on
user request, see for instance the call to csih_create_unprivileged_user()
in /bin/ssh-host-config.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[Christian Franke]

Corinna Vinschen wrote:
> On Nov  2 13:43, Christian Franke wrote:
>> D. Boland wrote:
>>> Christian Franke wrote:
>>>> The following should IMO never be done in a postinstall script:
>>>> - Creation of user and group accounts.
>>>> - Installation of services.
>>>> - Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
>>>> Please consider moving the above to the sendmail-config script.
>>> All steps in postinstall are necessary for running Sendmail.
>> Note that the above steps are re-done on each package update.
>>
>> The installation of sendmail does not imply that the user wants to run it
>> immediately.
> These are important points.
>
> For other services we never create the accounts without the user
> explicitely requesting them by calling the <service>-config script.
>
> The other problem is that you don't know if creating the a local account
> is the right thing to do.  In many companies there are restrictions on
> creating a local account and a domain account has to be created instead.
> Your config script has to take that into account by checking if a matching
> user account exists already or to ask the user if it should be created.

BTW: The procmail package is also affected. Its postinstall script 
creates a local group 'mail' using 'net localgroup ...'. This should be 
changed, IMO.

Christian

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Nov  3 18:16, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Nov  2 13:43, Christian Franke wrote:
> >>D. Boland wrote:
> >>>Christian Franke wrote:
> >>>>The following should IMO never be done in a postinstall script:
> >>>>- Creation of user and group accounts.
> >>>>- Installation of services.
> >>>>- Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
> >>>>Please consider moving the above to the sendmail-config script.
> >>>All steps in postinstall are necessary for running Sendmail.
> >>Note that the above steps are re-done on each package update.
> >>
> >>The installation of sendmail does not imply that the user wants to run it
> >>immediately.
> >These are important points.
> >
> >For other services we never create the accounts without the user
> >explicitely requesting them by calling the <service>-config script.
> >
> >The other problem is that you don't know if creating the a local account
> >is the right thing to do.  In many companies there are restrictions on
> >creating a local account and a domain account has to be created instead.
> >Your config script has to take that into account by checking if a matching
> >user account exists already or to ask the user if it should be created.
> 
> BTW: The procmail package is also affected. Its postinstall script creates a
> local group 'mail' using 'net localgroup ...'. This should be changed, IMO.

Ouch, I didn't see that when I GTGed the package :(

Yes, that should definitely be changed for the same reasons.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Corinna,

Corinna Vinschen wrote:
> 
> On Nov  3 18:16, Christian Franke wrote:
> > Corinna Vinschen wrote:
> > >On Nov  2 13:43, Christian Franke wrote:
> > >>D. Boland wrote:
> > >>>Christian Franke wrote:
> > >>>>The following should IMO never be done in a postinstall script:
> > >>>>- Creation of user and group accounts.
> > >>>>- Installation of services.
> > >>>>- Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
> > >>>>Please consider moving the above to the sendmail-config script.
> > >>>All steps in postinstall are necessary for running Sendmail.
> > >>Note that the above steps are re-done on each package update.
> > >>
> > >>The installation of sendmail does not imply that the user wants to run it
> > >>immediately.
> > >These are important points.
> > >
> > >For other services we never create the accounts without the user
> > >explicitely requesting them by calling the <service>-config script.
> > >
> > >The other problem is that you don't know if creating the a local account
> > >is the right thing to do.  In many companies there are restrictions on
> > >creating a local account and a domain account has to be created instead.
> > >Your config script has to take that into account by checking if a matching
> > >user account exists already or to ask the user if it should be created.
> >
> > BTW: The procmail package is also affected. Its postinstall script creates a
> > local group 'mail' using 'net localgroup ...'. This should be changed, IMO.
> 
> Ouch, I didn't see that when I GTGed the package :(
> 
> Yes, that should definitely be changed for the same reasons.

I understand. I'll come up with an elegant solution for procmail ASAP.

D.

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Corinna,

Corinna Vinschen wrote:
> 
> On Nov  3 18:16, Christian Franke wrote:
> > Corinna Vinschen wrote:
> > >On Nov  2 13:43, Christian Franke wrote:
> > >>D. Boland wrote:
> > >>>Christian Franke wrote:
> > >>>>The following should IMO never be done in a postinstall script:
> > >>>>- Creation of user and group accounts.
> > >>>>- Installation of services.
> > >>>>- Setting alternatives to manual mode (/usr/sbin/alternatives --set ...)
> > >>>>Please consider moving the above to the sendmail-config script.
> > >>>All steps in postinstall are necessary for running Sendmail.
> > >>Note that the above steps are re-done on each package update.
> > >>
> > >>The installation of sendmail does not imply that the user wants to run it
> > >>immediately.
> > >These are important points.
> > >
> > >For other services we never create the accounts without the user
> > >explicitely requesting them by calling the <service>-config script.
> > >
> > >The other problem is that you don't know if creating the a local account
> > >is the right thing to do.  In many companies there are restrictions on
> > >creating a local account and a domain account has to be created instead.
> > >Your config script has to take that into account by checking if a matching
> > >user account exists already or to ask the user if it should be created.
> >
> > BTW: The procmail package is also affected. Its postinstall script creates a
> > local group 'mail' using 'net localgroup ...'. This should be changed, IMO.
> 
> Ouch, I didn't see that when I GTGed the package :(
> 
> Yes, that should definitely be changed for the same reasons.

I uploaded version 15 of the Procmail 3.22 package (see my announcement in the
cygwin group). The group-creation is now done in the procmail-config script. The
default group 'mail' can optionally be changed to another one.

Cheers,
Daniel

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

Hi Daniel,

On Nov 15 19:40, D. Boland wrote:
> > > BTW: The procmail package is also affected. Its postinstall script creates a
> > > local group 'mail' using 'net localgroup ...'. This should be changed, IMO.
> > 
> > Ouch, I didn't see that when I GTGed the package :(
> > 
> > Yes, that should definitely be changed for the same reasons.
> 
> I uploaded version 15 of the Procmail 3.22 package (see my
> announcement in the cygwin group).

Thanks.

Just FYI for the next time: You sent the announcement message to the
wrong mailing list.  Announcements should go to the (moderated)
cygwin-announce mailing list, without the leading "[ANNOUNCEMENT]" in
the subject line.  After approval, they go to the cygwin-announce ML and
are automatically bounced to the cygwin ML with the leading
"[ANNOUNCEMENT]" text.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Corinna Vinschen wrote:
> 
> Hi Daniel,
> 
> On Nov 15 19:40, D. Boland wrote:
> > > > BTW: The procmail package is also affected. Its postinstall script creates a
> > > > local group 'mail' using 'net localgroup ...'. This should be changed, IMO.
> > >
> > > Ouch, I didn't see that when I GTGed the package :(
> > >
> > > Yes, that should definitely be changed for the same reasons.
> >
> > I uploaded version 15 of the Procmail 3.22 package (see my
> > announcement in the cygwin group).
> 
> Thanks.
> 
> Just FYI for the next time: You sent the announcement message to the
> wrong mailing list.  Announcements should go to the (moderated)
> cygwin-announce mailing list, without the leading "[ANNOUNCEMENT]" in
> the subject line.  After approval, they go to the cygwin-announce ML and
> are automatically bounced to the cygwin ML with the leading
> "[ANNOUNCEMENT]" text.

The last time I did that, all my subsequent posts where seen as spam and I had to
ask the postmaster to unblock my emails. The postmaster (Faylor) wrote that announce
at cygwin is a spam trap and I shouldn't post there.

I *did* have the leading [ANNOUNCEMENT] in the subject text. Could that be the
problem?

D.

Re: [ITP] Sendmail 8.14.9

[Yaakov Selkowitz]

On 2014-11-18 22:51, D. Boland wrote:
> Corinna Vinschen wrote:
>> Just FYI for the next time: You sent the announcement message to the
>> wrong mailing list.  Announcements should go to the (moderated)
>> cygwin-announce mailing list, without the leading "[ANNOUNCEMENT]" in
>> the subject line.  After approval, they go to the cygwin-announce ML and
>> are automatically bounced to the cygwin ML with the leading
>> "[ANNOUNCEMENT]" text.
>
> The last time I did that, all my subsequent posts where seen as spam and I had to
> ask the postmaster to unblock my emails. The postmaster (Faylor) wrote that announce
> at cygwin is a spam trap and I shouldn't post there.

The list is cygwin-announce AT cygwin.com, not announce.

--
Yaakov

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Yaakov,

Yaakov Selkowitz wrote:
> 
> On 2014-11-18 22:51, D. Boland wrote:
> > Corinna Vinschen wrote:
> >> Just FYI for the next time: You sent the announcement message to the
> >> wrong mailing list.  Announcements should go to the (moderated)
> >> cygwin-announce mailing list, without the leading "[ANNOUNCEMENT]" in
> >> the subject line.  After approval, they go to the cygwin-announce ML and
> >> are automatically bounced to the cygwin ML with the leading
> >> "[ANNOUNCEMENT]" text.
> >
> > The last time I did that, all my subsequent posts where seen as spam and I had to
> > ask the postmaster to unblock my emails. The postmaster (Faylor) wrote that announce
> > at cygwin is a spam trap and I shouldn't post there.
> 
> The list is cygwin-announce AT cygwin.com, not announce.

Thanks. Could you also look at my post for "SSH key for upload"? I had to update it,
due to a re-install.

D.

Re: [ITP] Sendmail 8.14.9

[Yaakov Selkowitz]

On 2014-11-20 02:29, D. Boland wrote:
> Thanks. Could you also look at my post for "SSH key for upload"? I had to update it,
> due to a re-install.

Done.

--
Yaakov

[ITP] Sendmail 8.14.9

[D. Boland]

Hi group,

I intend to package the Cygwin version of Sendmail, version 8.14.9. 

category: Mail
requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
sdesc: "The Mail Transfer Agent (mail server)"
ldesc: "General purpose internetwork email routing facility that supports many kinds 
 of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA 
 (AUTH) used for email transport over the internet."

I've implementented the "alternatives" mechanism, so it can be installed alongside
other Mail Transfer Agents, such as Exim, Postfix or ssmtp.

http://cygwin.boland.nl/x86/release/sendmail/

Daniel

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

Hi Daniel,

On Oct 30 18:41, D. Boland wrote:
> Hi group,
> 
> I intend to package the Cygwin version of Sendmail, version 8.14.9. 
> 
> category: Mail
> requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
> m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
> sdesc: "The Mail Transfer Agent (mail server)"
> ldesc: "General purpose internetwork email routing facility that supports many kinds 
>  of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA 
>  (AUTH) used for email transport over the internet."
> 
> I've implementented the "alternatives" mechanism, so it can be installed alongside
> other Mail Transfer Agents, such as Exim, Postfix or ssmtp.
> 
> http://cygwin.boland.nl/x86/release/sendmail/

did you see Christian's reply to your ITP from the 26th?
https://cygwin.com/ml/cygwin-apps/2014-10/msg00058.html


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] Sendmail 8.14.9

[D. Boland]

Hi Corinna,

Corinna Vinschen wrote:
> 
> Hi Daniel,
> 
> On Oct 30 18:41, D. Boland wrote:
> > Hi group,
> >
> > I intend to package the Cygwin version of Sendmail, version 8.14.9.
> >
> > category: Mail
> > requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
> > m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
> > sdesc: "The Mail Transfer Agent (mail server)"
> > ldesc: "General purpose internetwork email routing facility that supports many kinds
> >  of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA
> >  (AUTH) used for email transport over the internet."
> >
> > I've implementented the "alternatives" mechanism, so it can be installed alongside
> > other Mail Transfer Agents, such as Exim, Postfix or ssmtp.
> >
> > http://cygwin.boland.nl/x86/release/sendmail/
> 
> did you see Christian's reply to your ITP from the 26th?
> https://cygwin.com/ml/cygwin-apps/2014-10/msg00058.html

I just did. I posted twice because I didn't find my post on top of the list, not
realizing that my post would be added to the existing thread :-).

D.

Re: [ITP] Sendmail 8.14.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

On Nov  1 06:43, D. Boland wrote:
> Hi Corinna,
> 
> Corinna Vinschen wrote:
> > 
> > Hi Daniel,
> > 
> > On Oct 30 18:41, D. Boland wrote:
> > > Hi group,
> > >
> > > I intend to package the Cygwin version of Sendmail, version 8.14.9.
> > >
> > > category: Mail
> > > requires: bash libdb4.8 libgcc1 libopenssl100 libsasl2_3 libwrap0 inetutils-server
> > > m4  procmail tcp_wrappers cyrus-sasl cygrunsrv
> > > sdesc: "The Mail Transfer Agent (mail server)"
> > > ldesc: "General purpose internetwork email routing facility that supports many kinds
> > >  of mail-transfer and delivery methods, including SMTP, SMTPS (STARTTLS), SMTPA
> > >  (AUTH) used for email transport over the internet."
> > >
> > > I've implementented the "alternatives" mechanism, so it can be installed alongside
> > > other Mail Transfer Agents, such as Exim, Postfix or ssmtp.
> > >
> > > http://cygwin.boland.nl/x86/release/sendmail/
> > 
> > did you see Christian's reply to your ITP from the 26th?
> > https://cygwin.com/ml/cygwin-apps/2014-10/msg00058.html
> 
> I just did. I posted twice because I didn't find my post on top of the list, not
> realizing that my post would be added to the existing thread :-).

No worries.  Your post also reminds me that I originally wrote I'd
create an ssmtp package with the new altenatives based postinstall
soon.  Uhm... hopefully I get it done next week.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]