Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #231729 > unrolled thread

Debian switchable MTA mechanism

Back to article view | Back to linux.debian.user

Contents

  Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 10:00 +0100
    Re: Debian switchable MTA mechanism Georgi Naplatanov <gosho@oles.biz> - 2021-02-16 10:20 +0100
      Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 11:00 +0100
    Re: Debian switchable MTA mechanism Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-16 10:40 +0100
      Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 10:50 +0100
        Re: Debian switchable MTA mechanism <tomas@tuxteam.de> - 2021-02-16 11:20 +0100
          Conflicting alternatives (was: Debian switchable MTA mechanism) Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-16 15:20 +0100
            Re: Conflicting alternatives (was: Debian switchable MTA mechanism) Dan Ritter <dsr@randomstring.org> - 2021-02-16 17:10 +0100
              Re: Conflicting alternatives (was: Debian switchable MTA mechanism) didar <nosferatu@purlo.in> - 2021-02-16 17:30 +0100
            Re: Conflicting alternatives (was: Debian switchable MTA mechanism) <tomas@tuxteam.de> - 2021-02-16 17:30 +0100
              Re: Conflicting alternatives (was: Debian switchable MTA mechanism) Celejar <celejar@gmail.com> - 2021-02-16 18:00 +0100
              Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-16 20:50 +0100
                Re: Conflicting alternatives <tomas@tuxteam.de> - 2021-02-16 21:40 +0100
                  Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-17 00:20 +0100
                    Re: Conflicting alternatives tomas@tuxteam.de - 2021-02-17 09:20 +0100
                Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 02:20 +0100
                  Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-17 05:40 +0100
                Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-16 23:50 +0100
                  Re: Conflicting alternatives Stefan Monnier <monnier@iro.umontreal.ca> - 2021-02-17 01:30 +0100
                    Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-17 13:50 +0100
                      Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 16:30 +0100
                        Re: Conflicting alternatives The Wanderer <wanderer@fastmail.fm> - 2021-02-17 17:00 +0100
                          Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-17 17:10 +0100
                            Re: Conflicting alternatives Greg Wooledge <wooledg@eeg.ccf.org> - 2021-02-17 17:30 +0100
                              Re: Conflicting alternatives Richard Hector <richard@walnut.gen.nz> - 2021-02-18 05:40 +0100
                                Re: Conflicting alternatives Dan Ritter <dsr@randomstring.org> - 2021-02-18 14:20 +0100
                                  Re: Conflicting alternatives Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-18 14:40 +0100
                                    Re: Conflicting alternatives Richard Hector <richard@walnut.gen.nz> - 2021-02-19 05:30 +0100
                                      Re: Conflicting alternatives Dan Ritter <dsr@randomstring.org> - 2021-02-19 15:30 +0100
                                      Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-20 02:00 +0100
                                        Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-20 14:40 +0100
                                          Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-21 02:20 +0100
                                            Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-21 17:50 +0100
                                              Re: Conflicting alternatives Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-22 10:20 +0100
                                                Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 11:20 +0100
                                                  Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-22 12:50 +0100
                                                    Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 15:00 +0100
                                                      Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-22 15:40 +0100
                                                        Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 18:10 +0100
                                                Re: Conflicting alternatives Curt <curty@free.fr> - 2021-02-22 11:40 +0100
                          Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 17:20 +0100
                            Re: Conflicting alternatives Dan Ritter <dsr@randomstring.org> - 2021-02-17 17:40 +0100
                              Re: Conflicting alternatives David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 21:40 +0100
                                Re: Conflicting alternatives Kevin Shell <kshell@gmx.com> - 2021-02-17 23:50 +0100
        Re: Debian switchable MTA mechanism Dan Ritter <dsr@randomstring.org> - 2021-02-16 12:40 +0100
          Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 13:30 +0100
            Re: Debian switchable MTA mechanism Dan Ritter <dsr@randomstring.org> - 2021-02-16 14:40 +0100
              Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 14:50 +0100
              Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-16 14:50 +0100
                Re: Debian switchable MTA mechanism Dan Ritter <dsr@randomstring.org> - 2021-02-16 14:50 +0100
              Re: Debian switchable MTA mechanism rhkramer@gmail.com - 2021-02-16 15:20 +0100
        Re: Debian switchable MTA mechanism David Wright <deblis@lionunicorn.co.uk> - 2021-02-16 23:40 +0100
          Re: Debian switchable MTA mechanism David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 02:20 +0100
          Re: Debian switchable MTA mechanism David Wright <deblis@lionunicorn.co.uk> - 2021-02-17 02:20 +0100
          Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-17 00:40 +0100
            Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-17 00:50 +0100
              Re: Debian switchable MTA mechanism Kevin Shell <kshell@gmx.com> - 2021-02-17 01:00 +0100
    Re: Debian switchable MTA mechanism Semih Ozlem <semihozlemlinuxuser@gmail.com> - 2021-02-16 15:20 +0100
      Re: Debian switchable MTA mechanism IL Ka <kazakevichilya@gmail.com> - 2021-02-16 15:30 +0100
      Re: Debian switchable MTA mechanism Darac Marjal <mailinglist@darac.org.uk> - 2021-02-16 15:30 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#231793 — Re: Conflicting alternatives

On Wed 17 Feb 2021 at 20:45:02 (+0800), Kevin Shell wrote:
> On Tue, Feb 16, 2021 at 07:19:52PM -0500, Stefan Monnier wrote:
> > 
> [...]
> > It'd be work in the DPKG/APT code, yes.  But it would require no extra
> > work from the people doing the packaging.
> 
> I know little technical details about the Debian package manager,
> from an end user's perspective, the package manager should give the user
> the choise not to uninstall a wanted package,

Call that 1.

> if the user don't give a choise, the package manager can perform the
> default action to remove the package. 

Call that 2.

> I think this method is a better default behavior for the package manager 
> for some similar packages.

Is that not true now?

$ apt-get -s install busybox-static
NOTE: This is only a simulation!
      […]
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:          ← case 2 ----------
  busybox
The following NEW packages will be installed:
  busybox-static
0 upgraded, 1 newly installed, 1 to remove and 2 not upgraded.
Remv busybox [1:1.30.1-4] [cryptsetup-initramfs:amd64 ]
Inst busybox-static (1:1.30.1-4 Debian:10.8/stable [amd64])
Conf busybox-static (1:1.30.1-4 Debian:10.8/stable [amd64])
$ 

~# aptitude hold busybox
~# 

$ apt-get -s install busybox-static
NOTE: This is only a simulation!
      […]
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 busybox : Conflicts: busybox-static but 1:1.30.1-4 is to be installed
 busybox-static : Conflicts: busybox          ← case 1 ----------
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
100 $ 

~# aptitude unhold busybox 
~# 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#231795 — Re: Conflicting alternatives

[Multipart message — attachments visible in raw view] — view raw

On 2021-02-17 at 10:25, David Wright wrote:

> On Wed 17 Feb 2021 at 20:45:02 (+0800), Kevin Shell wrote:
>
>> On Tue, Feb 16, 2021 at 07:19:52PM -0500, Stefan Monnier wrote:
>> > 
>> [...]
>> > It'd be work in the DPKG/APT code, yes.  But it would require no extra
>> > work from the people doing the packaging.
>> 
>> I know little technical details about the Debian package manager,
>> from an end user's perspective, the package manager should give the user
>> the choise not to uninstall a wanted package,
> 
> Call that 1.
> 
>> if the user don't give a choise, the package manager can perform the
>> default action to remove the package. 
> 
> Call that 2.
> 
>> I think this method is a better default behavior for the package manager 
>> for some similar packages.
> 
> Is that not true now?
> 
> $ apt-get -s install busybox-static

> The following packages will be REMOVED:          ← case 2 ----------
>   busybox
> The following NEW packages will be installed:
>   busybox-static

> ~# aptitude hold busybox
> ~# 
> 
> $ apt-get -s install busybox-static

> The following packages have unmet dependencies:
>  busybox : Conflicts: busybox-static but 1:1.30.1-4 is to be installed
>  busybox-static : Conflicts: busybox          ← case 1 ----------

I think what he's wanting is a case which would allow installing
busybox-static, but not insist on removing busybox. (Or the equivalent
in his actual use-case, where the files installed by the two packages
might not actually overlap.)

Where that runs into trouble is that even if the *files* don't overlap,
other resources which the package needs to control exclusively quite
possibly do - the most prominent example, from the discussion at hand
regarding MTAs, being port 25.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#231796 — Re: Conflicting alternatives

On Wed, Feb 17, 2021 at 10:49:35AM -0500, The Wanderer wrote:
> On 2021-02-17 at 10:25, David Wright wrote:
> 
[...]
> I think what he's wanting is a case which would allow installing
> busybox-static, but not insist on removing busybox. (Or the equivalent
> in his actual use-case, where the files installed by the two packages
> might not actually overlap.)
> 
yes.
Supose my system
have installed these packages exim4-base exim4-config exim4-daemon-heavy


What I'd hope apt to do is
# apt install postfix

Output:
[...]
The following packages will be REMOVED:
  exim4-base exim4-config exim4-daemon-heavy
The following NEW packages will be installed:
  postfix


Case 1 the default: User hit Enter key and apt remove exim4 and install
postfix
Case 2: user choose to keep exim4 and apt keep it and install postfix

> Where that runs into trouble is that even if the *files* don't overlap,
> other resources which the package needs to control exclusively quite
> possibly do - the most prominent example, from the discussion at hand
> regarding MTAs, being port 25.

You could stop one and start the other,
there's no resources or port conflict.
I want to just keep both, not run them at the same time.

-- 
kevin

[toc] | [prev] | [next] | [standalone]

#231799 — Re: Conflicting alternatives

On Thu, Feb 18, 2021 at 12:06:37AM +0800, Kevin Shell wrote:
> You could stop one and start the other,
> there's no resources or port conflict.
> I want to just keep both, not run them at the same time.

Again, as stated at the start of this fiasco of a thread, Debian policy
says that all daemons must be started up by default.

Well anyway, everything that is relevant has already been stated, and
we're in the reruns now, so ... enjoy reliving this time loop as many
times as it takes.

[toc] | [prev] | [next] | [standalone]

#231818 — Re: Conflicting alternatives

On 18/02/21 5:22 am, Greg Wooledge wrote:
> On Thu, Feb 18, 2021 at 12:06:37AM +0800, Kevin Shell wrote:
>> You could stop one and start the other,
>> there's no resources or port conflict.
>> I want to just keep both, not run them at the same time.
> 
> Again, as stated at the start of this fiasco of a thread, Debian policy
> says that all daemons must be started up by default.

It is possible to install both nginx and apache2 at the same time. Both 
presumably try to get port 80? Not sure how that resolves; I don't have 
a machine I want to try it on at the moment.

Richard

[toc] | [prev] | [next] | [standalone]

#231822 — Re: Conflicting alternatives

Richard Hector wrote: 
> On 18/02/21 5:22 am, Greg Wooledge wrote:
> > On Thu, Feb 18, 2021 at 12:06:37AM +0800, Kevin Shell wrote:
> > > You could stop one and start the other,
> > > there's no resources or port conflict.
> > > I want to just keep both, not run them at the same time.
> > 
> > Again, as stated at the start of this fiasco of a thread, Debian policy
> > says that all daemons must be started up by default.
> 
> It is possible to install both nginx and apache2 at the same time. Both
> presumably try to get port 80? Not sure how that resolves; I don't have a
> machine I want to try it on at the moment.

The order of events is:

- install one. Change the listening port to something other than
  80.

- install the next.

Web servers are built to interoperate with each other; it is not
ridiculous to have a dozen web servers on a machine each
listening to different ports, or listening on sockets and being
proxied by a different web server.

-dsr-

[toc] | [prev] | [next] | [standalone]

#231823 — Re: Conflicting alternatives

[Multipart message — attachments visible in raw view] — view raw

On Jo, 18 feb 21, 08:15:39, Dan Ritter wrote:
> Richard Hector wrote: 
> > On 18/02/21 5:22 am, Greg Wooledge wrote:
> > > On Thu, Feb 18, 2021 at 12:06:37AM +0800, Kevin Shell wrote:
> > > > You could stop one and start the other,
> > > > there's no resources or port conflict.
> > > > I want to just keep both, not run them at the same time.
> > > 
> > > Again, as stated at the start of this fiasco of a thread, Debian policy
> > > says that all daemons must be started up by default.
> > 
> > It is possible to install both nginx and apache2 at the same time. Both
> > presumably try to get port 80? Not sure how that resolves; I don't have a
> > machine I want to try it on at the moment.
> 
> The order of events is:
> 
> - install one. Change the listening port to something other than
>   80.
> 
> - install the next.
> 
> Web servers are built to interoperate with each other; it is not
> ridiculous to have a dozen web servers on a machine each
> listening to different ports, or listening on sockets and being
> proxied by a different web server.

It seems to me the important difference is that it is comparatively easy 
and common to interact with a webserver on a non-standard port, whereas 
running a SMTP server on a non-standard port might be useful only in 
very specific corner cases.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#231851 — Re: Conflicting alternatives

On 19/02/21 2:34 am, Andrei POPESCU wrote:
> On Jo, 18 feb 21, 08:15:39, Dan Ritter wrote:
>> Richard Hector wrote: 
>> > On 18/02/21 5:22 am, Greg Wooledge wrote:
>> > > On Thu, Feb 18, 2021 at 12:06:37AM +0800, Kevin Shell wrote:
>> > > > You could stop one and start the other,
>> > > > there's no resources or port conflict.
>> > > > I want to just keep both, not run them at the same time.
>> > > 
>> > > Again, as stated at the start of this fiasco of a thread, Debian policy
>> > > says that all daemons must be started up by default.
>> > 
>> > It is possible to install both nginx and apache2 at the same time. Both
>> > presumably try to get port 80? Not sure how that resolves; I don't have a
>> > machine I want to try it on at the moment.
>> 
>> The order of events is:
>> 
>> - install one. Change the listening port to something other than
>>   80.
>> 
>> - install the next.
>> 
>> Web servers are built to interoperate with each other; it is not
>> ridiculous to have a dozen web servers on a machine each
>> listening to different ports, or listening on sockets and being
>> proxied by a different web server.
> 
> It seems to me the important difference is that it is comparatively easy
> and common to interact with a webserver on a non-standard port, whereas
> running a SMTP server on a non-standard port might be useful only in
> very specific corner cases.

There are multiple standard ports, though. E.g. one could easily run one 
MTA on port 25 for incoming mail, and another on 587 for outgoing.

My point, though, was that there's a precedent for daemons that default 
to listening on the same port, yet are co-installable. And which will, 
IIRC, throw errors on installation if you try it without paying special 
attention.

Richard

[toc] | [prev] | [next] | [standalone]

#231861 — Re: Conflicting alternatives

Richard Hector wrote: 
> There are multiple standard ports, though. E.g. one could easily run one MTA
> on port 25 for incoming mail, and another on 587 for outgoing.
> 
> My point, though, was that there's a precedent for daemons that default to
> listening on the same port, yet are co-installable. And which will, IIRC,
> throw errors on installation if you try it without paying special attention.

I think several people in this discussion are missing a cultural
point.

The web is not special. Some people will care about whether the
webservers fail, some will not. This is an individual,
circumstantial thing. If you run a minecraft server or a
database or a calendar service, you might care about those
things and want to install monitors, but ultimately all those
services are not integral to the functioning of the system.

Mail is special. Mail is sacred. Screwing up your mail system is
a big deal. Mail is how the system informs the sysadmin of what
went wrong in the middle of the night. Even if the mail system
is configured not to talk to other machines, it serves as a
primary communications method for cron jobs and daemons to send
messages to humans.

Culturally, people who do not care about whether mail fails are not
people who can be trusted to run systems.

That is, I think, why Debian offers a choice of MTAs but does not allow
them to be co-installed.

-dsr-

[toc] | [prev] | [next] | [standalone]

#231877 — Re: Conflicting alternatives

On Fri 19 Feb 2021 at 17:22:25 (+1300), Richard Hector wrote:
> On 19/02/21 2:34 am, Andrei POPESCU wrote:
> > On Jo, 18 feb 21, 08:15:39, Dan Ritter wrote:
> > > Richard Hector wrote:
> > > > On 18/02/21 5:22 am, Greg Wooledge wrote:
> > > > > On Thu, Feb 18, 2021 at 12:06:37AM +0800, Kevin Shell wrote:
> > > > > > You could stop one and start the other,
> > > > > > there's no resources or port conflict.
> > > > > > I want to just keep both, not run them at the same time.
> > > > > Again, as stated at the start of this fiasco of a thread, Debian policy
> > > > > says that all daemons must be started up by default.
> > > > It is possible to install both nginx and apache2 at the same time. Both
> > > > presumably try to get port 80? Not sure how that resolves; I don't have a
> > > > machine I want to try it on at the moment.
> > > 
> > > The order of events is:
> > > 
> > > - install one. Change the listening port to something other than 80.
> > > 
> > > - install the next.
> > > 
> > > Web servers are built to interoperate with each other; it is not
> > > ridiculous to have a dozen web servers on a machine each
> > > listening to different ports, or listening on sockets and being
> > > proxied by a different web server.
> > 
> > It seems to me the important difference is that it is comparatively easy
> > and common to interact with a webserver on a non-standard port, whereas
> > running a SMTP server on a non-standard port might be useful only in
> > very specific corner cases.
> 
> There are multiple standard ports, though. E.g. one could easily run
> one MTA on port 25 for incoming mail, and another on 587 for outgoing.

That's just a statement of the desired outcome, but you can only
"easily run" that if you can easily configure it so.

So from Debian's point of view, you have to come up with simple
configurations (ie through those curses screens that dpkg-reconfigure
displays) that reliably set up either or neither or both MTAs in roles
that not only don't conflict with one another, but also dovetail so
that all the many necessary roles are covered. And that would be for
every pair of MTAs that Debian deemed co-installable,

For each MTA, you also have to ensure that their well-known recipes
for passing off work to other software (like MDAs) still work, else
Debian gets lumbered with supporting all the breakages that occur
(or, worse, loses reputation).

> My point, though, was that there's a precedent for daemons that
> default to listening on the same port, yet are co-installable. And
> which will, IIRC, throw errors on installation if you try it without
> paying special attention.

As Dan pointed out, Mail is Different. Fine; throw errors during
the installation—that's static. Throw some more during
configuration—ditto. That doesn't help much when you actually
start using the MTAs in anger. If you get something wrong, you
might never see the errors. Someone at the other end might.
I can well understand why Debian wouldn't want to support
such a scheme.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#231887 — Re: Conflicting alternatives

On 2021-02-20, David Wright <deblis@lionunicorn.co.uk> wrote:
>
> For each MTA, you also have to ensure that their well-known recipes
> for passing off work to other software (like MDAs) still work, else
> Debian gets lumbered with supporting all the breakages that occur
> (or, worse, loses reputation).
>

Did someone mention (I have neglected to read most of the thread) that
Fedora has a switching mechanism?

 Fedora 12 provides three MTAs: Sendmail, Postfix, and Exim. If all
 three are installed, sendmail is the default MTA. The Mail Transport
 Agent Switcher allows for the selection of either sendmail, postfix, or
 exim as the default MTA for the system.

https://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/s1-email-switchmail.html

The Mail Transport Agent Switcher. Almost sounds like a name invented by
the marketing department. Anyway, I guess the MTAS is irrelevant because
we're not concerned with Fedora here. But I suppose its existence proves
its usefulness---or maybe the word is practicality---at least for
Fedora users. 

[toc] | [prev] | [next] | [standalone]

#231907 — Re: Conflicting alternatives

On Sat 20 Feb 2021 at 13:12:39 (+0000), Curt wrote:
> On 2021-02-20, David Wright <deblis@lionunicorn.co.uk> wrote:
> >
> > For each MTA, you also have to ensure that their well-known recipes
> > for passing off work to other software (like MDAs) still work, else
> > Debian gets lumbered with supporting all the breakages that occur
> > (or, worse, loses reputation).
> 
> Did someone mention (I have neglected to read most of the thread) that
> Fedora has a switching mechanism?

Yes, in the OP. In case you missed it:

 "Why Debian does't have a switchable MTA mechanism
  to allow install multiple MTAs at the same time?

 "Fedora, Centos etc. allow users to install
  multiple MTAs at the same time.
  There's a "alternatives --config mta" command
  to allow to choose between alternative MTA."

>  Fedora 12 provides three MTAs: Sendmail, Postfix, and Exim. If all
>  three are installed, sendmail is the default MTA. The Mail Transport
>  Agent Switcher allows for the selection of either sendmail, postfix, or
>  exim as the default MTA for the system.
> 
> https://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/s1-email-switchmail.html
> 
> The Mail Transport Agent Switcher. Almost sounds like a name invented by
> the marketing department. Anyway, I guess the MTAS is irrelevant because
> we're not concerned with Fedora here. But I suppose its existence proves
> its usefulness---or maybe the word is practicality---at least for
> Fedora users. 

I think Andrei answered it in the third post of the thread:

 "Installing and removing/purging packages has traditionally been very
  easy in Debian, such a mechanism would have limited benefits for
  significant added complexity."

I have no experience of Fedora installations myself.

Then, as frequently happens, the thread expanded into such options as
distributing different tasks, that one MTA normally does, amongst
several different MTAs. Even more complexity. No thanks. Configuring
just one is enough for me.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#231917 — Re: Conflicting alternatives

On 2021-02-21, David Wright <deblis@lionunicorn.co.uk> wrote:
>> 
>> The Mail Transport Agent Switcher. Almost sounds like a name invented by
>> the marketing department. Anyway, I guess the MTAS is irrelevant because
>> we're not concerned with Fedora here. But I suppose its existence proves
>> its usefulness---or maybe the word is practicality---at least for
>> Fedora users. 
>
> I think Andrei answered it in the third post of the thread:
>
>  "Installing and removing/purging packages has traditionally been very
>   easy in Debian, such a mechanism would have limited benefits for
>   significant added complexity."

For some reason his posts never seem to make it through to my news
server. Maybe there exists a special switch he toggles on or something. 

> I have no experience of Fedora installations myself.
>
> Then, as frequently happens, the thread expanded into such options as
> distributing different tasks, that one MTA normally does, amongst
> several different MTAs. Even more complexity. No thanks. Configuring
> just one is enough for me.
>
> Cheers,
> David.


-- 

[toc] | [prev] | [next] | [standalone]

#231926 — Re: Conflicting alternatives

[Multipart message — attachments visible in raw view] — view raw

On Du, 21 feb 21, 16:23:31, Curt wrote:
> On 2021-02-21, David Wright <deblis@lionunicorn.co.uk> wrote:
> >> 
> >> The Mail Transport Agent Switcher. Almost sounds like a name invented by
> >> the marketing department. Anyway, I guess the MTAS is irrelevant because
> >> we're not concerned with Fedora here. But I suppose its existence proves
> >> its usefulness---or maybe the word is practicality---at least for
> >> Fedora users. 
> >
> > I think Andrei answered it in the third post of the thread:
> >
> >  "Installing and removing/purging packages has traditionally been very
> >   easy in Debian, such a mechanism would have limited benefits for
> >   significant added complexity."
> 
> For some reason his posts never seem to make it through to my news
> server. Maybe there exists a special switch he toggles on or something. 

I'm not aware of doing anything special, just reply-to-list (Cc'd you on 
this message though).

Is it only my messages you are missing?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#231929 — Re: Conflicting alternatives

On 2021-02-22, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
> I'm not aware of doing anything special, just reply-to-list (Cc'd you on=20
> this message though).
>
> Is it only my messages you are missing?
>

You do appear here on the gmane server, but remain MIA on news.free.fr.

Maybe it's some problem specific to news.free.fr.

[toc] | [prev] | [next] | [standalone]

#231931 — Re: Conflicting alternatives

On Mon, Feb 22, 2021 at 10:18:36AM -0000, Curt wrote:
> On 2021-02-22, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >
> > I'm not aware of doing anything special, just reply-to-list (Cc'd you on=20
> > this message though).
> >
> > Is it only my messages you are missing?
> >
> 
> You do appear here on the gmane server, but remain MIA on news.free.fr.
> 
> Maybe it's some problem specific to news.free.fr.
> 

How the two sites news.bofh.it/erode.bofh.it news.free.fr are connected?
Is news.bofh.it feeding articles to news.free.fr?

By the way,
the site news.bofh.it/erode.bofh.it 's gateway scripts
rewrite the "In-Reply-To" and "References" header values(xxx@gated-at.bofh.it),
breaking mail reader's threading.

> 

-- 
kevin

[toc] | [prev] | [next] | [standalone]

#231940 — Re: Conflicting alternatives

On 2021-02-22, Kevin Shell <kshell@gmx.com> wrote:
>> 
>> Maybe it's some problem specific to news.free.fr.
>> 
>
> How the two sites news.bofh.it/erode.bofh.it news.free.fr are connected?
> Is news.bofh.it feeding articles to news.free.fr?

They are not connected.

> By the way,
> the site news.bofh.it/erode.bofh.it 's gateway scripts
> rewrite the "In-Reply-To" and "References" header values(xxx@gated-at.bofh.it),
> breaking mail reader's threading.
>

I regret this, if true, but have no control over it (other than using
news.free.fr, the newserver of my ISP, which is and was my intention
(but to which some posts never seem to arrive)).

[toc] | [prev] | [next] | [standalone]

#231941 — Re: Conflicting alternatives

On Mon, Feb 22, 2021 at 01:39:18PM +0000, Curt wrote:
> On 2021-02-22, Kevin Shell <kshell@gmx.com> wrote:
> >> 
> >> Maybe it's some problem specific to news.free.fr.
> >> 
> >
> > How the two sites news.bofh.it/erode.bofh.it news.free.fr are connected?
> > Is news.bofh.it feeding articles to news.free.fr?
> 
> They are not connected.
> 
But I see your posts are coming into
the debian user list thru  news.bofh.it / erode.bofh.it?

Received: from erode.bofh.it (erode.bofh.it [85.94.204.147])
        by bendel.debian.org (Postfix) with ESMTP id D507E20160
        for <debian-user@lists.debian.org>; Mon, 22 Feb 2021 13:40:05 +0000 (UTC)
Received: from erode.bofh.it (localhost [IPv6:::1])
        by erode.bofh.it (Postfix) with ESMTP id AD584907E04
        for <debian-user@lists.debian.org>; Mon, 22 Feb 2021 14:40:02 +0100 (CET)

> > By the way,
> > the site news.bofh.it/erode.bofh.it 's gateway scripts
> > rewrite the "In-Reply-To" and "References" header values(xxx@gated-at.bofh.it),
> > breaking mail reader's threading.
> >
> 
> I regret this, if true, but have no control over it (other than using
> news.free.fr, the newserver of my ISP, which is and was my intention
> (but to which some posts never seem to arrive)).
> 
The server news.bofh.it / erode.bofh.it rewrites "Message-ID" field value,
which it should't as it breaks message threading.

-- 
kevin

[toc] | [prev] | [next] | [standalone]

#231944 — Re: Conflicting alternatives

On 2021-02-22, Kevin Shell <kshell@gmx.com> wrote:
>> 
> But I see your posts are coming into
> the debian user list thru  news.bofh.it / erode.bofh.it?
>
> Received: from erode.bofh.it (erode.bofh.it [85.94.204.147])
>         by bendel.debian.org (Postfix) with ESMTP id D507E20160
>         for <debian-user@lists.debian.org>; Mon, 22 Feb 2021 13:40:05 +0000 (UTC)
> Received: from erode.bofh.it (localhost [IPv6:::1])
>         by erode.bofh.it (Postfix) with ESMTP id AD584907E04
>         for <debian-user@lists.debian.org>; Mon, 22 Feb 2021 14:40:02 +0100 (CET)

I believed you asked what connection there was between the *NNTP* server where
Andrei's posts appear normally (news.gmane.io) and the server where they do not
(news.free.fr). There is no connection between the two. When I post via 
news.free.fr, the article transits through the mail gateway(s) shown above. 

>> > By the way,
>> > the site news.bofh.it/erode.bofh.it 's gateway scripts
>> > rewrite the "In-Reply-To" and "References" header values(xxx@gated-at.bofh.it),
>> > breaking mail reader's threading.
>> >
>> 
>> I regret this, if true, but have no control over it (other than using
>> news.free.fr, the newserver of my ISP, which is and was my intention
>> (but to which some posts never seem to arrive)).
>> 
> The server news.bofh.it / erode.bofh.it rewrites "Message-ID" field value,
> which it should't as it breaks message threading.
>

I

[toc] | [prev] | [next] | [standalone]

#231930 — Re: Conflicting alternatives

On Mon, 22 Feb 2021, Andrei POPESCU wrote:

> On Du, 21 feb 21, 16:23:31, Curt wrote:
>> On 2021-02-21, David Wright <deblis@lionunicorn.co.uk> wrote:
>>>>
>>>> The Mail Transport Agent Switcher. Almost sounds like a name invented by
>>>> the marketing department. Anyway, I guess the MTAS is irrelevant because
>>>> we're not concerned with Fedora here. But I suppose its existence proves
>>>> its usefulness---or maybe the word is practicality---at least for
>>>> Fedora users.
>>>
>>> I think Andrei answered it in the third post of the thread:
>>>
>>>  "Installing and removing/purging packages has traditionally been very
>>>   easy in Debian, such a mechanism would have limited benefits for
>>>   significant added complexity."
>>
>> For some reason his posts never seem to make it through to my news
>> server. Maybe there exists a special switch he toggles on or something.
>
> I'm not aware of doing anything special, just reply-to-list (Cc'd you on
> this message though).

I received this in my free.fr inbox but don't see it on my free.fr news server.

> Is it only my messages you are missing?

I think I also noticed Nicholas Georges' posts as being missing on news.free.fr. There
may, of course, be others.


> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser
>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web