FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-13-2011, 08:34 PM
Bob Proulx
 
Default RFC: Making mail-transport-agent Priority: optional

Wouter Verhelst wrote:
> Bob Proulx wrote:
> > Doesn't popcon itself send reports by email? Meaning that 100% of all
> > reports from popcon have an MTA installed?
>
> No, popcon can also report through HTTP.

Ah... Very good. I stand corrected. And what's more, looking it
over it appears that using http is now the default.[1]

Thanks!
Bob

[1] In the /usr/share/doc/popularity-contest/FAQ.gz file:

Q) How can I prevent popularity-contest from sending reports via email?

A) This is not recommended. Reports are sent by email only when the HTTP
submission fails, which is generally caused by a temporary lack of internet
connectivity. By contrast, reports sent by email are stored in the mail server
queue until the internet connectivity is back.
 
Old 10-13-2011, 08:57 PM
Frank Steinborn
 
Default RFC: Making mail-transport-agent Priority: optional

Josh Triplett wrote:
> ...which produce output to somewhere other than a log file, in some
> scenario other than "being buggy and accidentally producing output", and
> which expect end users to read their output, and which therefore expect
> that the end user has configured root's mail to go somewhere they'll
> actually read.

I have a strong opinion on the whole thread, but I'll just want to
answer this one because I'm not a DD anyway:

Are you aware of the fact that all of roots mail gets forwarded to the
user configured in d-i? This is a non-argument. As a user, you will be
bugged everytime for new mail on login. Check /etc/aliases after a
fresh install.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013205729.GG14404@toyvm.nognu.de">http://lists.debian.org/20111013205729.GG14404@toyvm.nognu.de
 
Old 10-14-2011, 12:30 AM
Josh Triplett
 
Default RFC: Making mail-transport-agent Priority: optional

On Thu, Oct 13, 2011 at 10:57:29PM +0200, Frank Steinborn wrote:
> Josh Triplett wrote:
> > ...which produce output to somewhere other than a log file, in some
> > scenario other than "being buggy and accidentally producing output", and
> > which expect end users to read their output, and which therefore expect
> > that the end user has configured root's mail to go somewhere they'll
> > actually read.
>
> I have a strong opinion on the whole thread, but I'll just want to
> answer this one because I'm not a DD anyway:
>
> Are you aware of the fact that all of roots mail gets forwarded to the
> user configured in d-i? This is a non-argument. As a user, you will be
> bugged everytime for new mail on login. Check /etc/aliases after a
> fresh install.

Yes, I'm aware. Note that graphical logins will not normally tell the
user about new local mail, and neither will most graphical MUAs.

- Josh triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111014003037.GA23787@leaf">http://lists.debian.org/20111014003037.GA23787@leaf
 
Old 10-14-2011, 01:02 AM
Michelle Konzack
 
Default RFC: Making mail-transport-agent Priority: optional

Hello Josh Triplett,

Am 2011-10-13 13:06:49, hacktest Du folgendes herunter:
> On Thu, Oct 13, 2011 at 12:02:11PM +0200, Luca Capello wrote:
> > On Thu, 13 Oct 2011 05:34:52 +0200, Josh Triplett wrote:
> > > For most users, these questions will duplicate the process
> > > they later go through to configure their MUA.
> > . o O (simply because these MUAs do not use the local sendmail)
> Few MUAs even have that option. And why should they, when they can talk
> directly to the user's mail server rather than to a local MTA acting as
> intermediary and passing mails to the user's mail server? More
> importantly, MUAs assume (correctly) that most local MTAs don't
> necessarily know how to send external mail, if they exist at all.

But if you do not use the local MTA, you have to configure EACH client
manualy... and if you have more then one ISP or Smarthosts, it become
worse! Most MUA which support SMTP can not route correctly.

> "other things are worse" is not an argument against dropping
> exim4-daemon-light from standard.

Right, we should use "courier-mta" instead! ;-)

> That's a problem, not a feature. logrotate exists to make sure the disk
> doesn't fill with logs; no such mechanism exists to make sure the disk
> doesn't fill with mails. One of many reasons to log rather than sending
> mail. And having two independent logging mechanisms seems suboptimal at
> best.

Normaly mail to <root> are forwarded to the <user> of the system.

Or do you wan to say, that exim does not forward the mail to the user?

If I am right, all MTAs ask, to which user the <root> mails schould be
forwarded. If you disable forwarding of mail you have broken the system
yourself.

> Would you object less if cron had an option to log to syslog instead of
> sending mail, and used that option automatically if it didn't find a
> sendmail?

Ehm? Cron is loging since more then 12 years to syslog...

Thanks, Greetings and nice Day/Evening
Michelle Konzack

--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>

itsystems@tdnet Jabber linux4michelle@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/
 
Old 10-14-2011, 01:13 AM
Michelle Konzack
 
Default RFC: Making mail-transport-agent Priority: optional

Hello Paul,

Am 2011-10-13 12:13:56, hacktest Du folgendes herunter:
> The user will not be notified even if the daemons send a mail to them.
> I don't think any of the desktops GUIs that we ship know anything
> about the local mail queue unless explicitly configured in an MUA, nor
> do they notify the user when there is new mail.

I was using long time ago (8-10 years) a grafical MUA, which was
accessing ~/mail or /var/mail/<user>. Since I use mutt, it is very good,
that mutt use by default ~/mail and the standard spool.

Maybe all MUAs in Debian should be configued by the Package Maintainers,
to support ~/mail by default or /var/mail/<user> by default?

Thanks, Greetings and nice Day/Evening
Michelle Konzack

--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>

itsystems@tdnet Jabber linux4michelle@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/
 
Old 10-14-2011, 03:54 AM
Ivan Shmakov
 
Default RFC: Making mail-transport-agent Priority: optional

>>>>> Michelle Konzack <linux4michelle@tamay-dogan.net> writes:
>>>>> Am 2011-10-13 12:13:56, hacktest Du folgendes herunter:

>> The user will not be notified even if the daemons send a mail to
>> them. I don't think any of the desktops GUIs that we ship know
>> anything about the local mail queue unless explicitly configured in
>> an MUA, nor do they notify the user when there is new mail.

> I was using long time ago (8-10 years) a grafical MUA, which was
> accessing ~/mail or /var/mail/<user>. Since I use mutt, it is very
> good, that mutt use by default ~/mail and the standard spool.

> Maybe all MUAs in Debian should be configued by the Package
> Maintainers, to support ~/mail by default or /var/mail/<user> by
> default?

I'd second on that.

However, I should note that the Unix mbox format is quite
obsolete by now, so I'd vote for the MUA's to support Maildir
(~/Maildir/) at the least (and as the default), with Unix mbox
(/var/mail/, ~/mail) possibly left as an option.

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 86zkh4xm5v.fsf@gray.siamics.net">http://lists.debian.org/86zkh4xm5v.fsf@gray.siamics.net
 
Old 10-14-2011, 05:56 AM
Josh Triplett
 
Default RFC: Making mail-transport-agent Priority: optional

> Am 2011-10-13 13:06:49, hacktest Du folgendes herunter:
> > On Thu, Oct 13, 2011 at 12:02:11PM +0200, Luca Capello wrote:
> > > On Thu, 13 Oct 2011 05:34:52 +0200, Josh Triplett wrote:
> > > > For most users, these questions will duplicate the process
> > > > they later go through to configure their MUA.
> > > . o O (simply because these MUAs do not use the local sendmail)
> > Few MUAs even have that option. And why should they, when they can talk
> > directly to the user's mail server rather than to a local MTA acting as
> > intermediary and passing mails to the user's mail server? More
> > importantly, MUAs assume (correctly) that most local MTAs don't
> > necessarily know how to send external mail, if they exist at all.
>
> But if you do not use the local MTA, you have to configure EACH client
> manualy... and if you have more then one ISP or Smarthosts, it become
> worse! Most MUA which support SMTP can not route correctly.

Few users use more than one MUA, so they only need to configure any
given SMTP server once (usually at the same time as configuring IMAP or
POP). And several MUAs have some extra smarts to very quickly configure
all of those for a given ISP based on a database of ISPs, as well as
various other helpers to make configuration simpler.

(Unrelated to the current discussion about MTA priority, but in response
to your point: most of the graphical MUAs I've seen have options to
choose different SMTP servers for different email addresses. But most
of the mail servers I've seen tend to just require SMTP AUTH, and then
let you use any From address you want, so you can send all of your mail
with one SMTP server.)

> > "other things are worse" is not an argument against dropping
> > exim4-daemon-light from standard.
>
> Right, we should use "courier-mta" instead! ;-)



> > That's a problem, not a feature. logrotate exists to make sure the disk
> > doesn't fill with logs; no such mechanism exists to make sure the disk
> > doesn't fill with mails. One of many reasons to log rather than sending
> > mail. And having two independent logging mechanisms seems suboptimal at
> > best.
>
> Normaly mail to <root> are forwarded to the <user> of the system.
>
> Or do you wan to say, that exim does not forward the mail to the user?
>
> If I am right, all MTAs ask, to which user the <root> mails schould be
> forwarded. If you disable forwarding of mail you have broken the system
> yourself.

It doesn't matter what local user system mail gets forwarded to (and d-i
arranges to have that mail forwarded to the user created at install
time). Users don't check the local mail for their user account, either.

> > Would you object less if cron had an option to log to syslog instead of
> > sending mail, and used that option automatically if it didn't find a
> > sendmail?
>
> Ehm? Cron is loging since more then 12 years to syslog...

Cron logs the start and end of jobs, and various other status messages,
but as far as I know it can't log the output of cron jobs; it only knows
how to mail that. I was suggesting that if capturing the output of cron
remains a sticking point for making an MTA optional, it doesn't seem
that difficult to have it send the output to syslog instead. Cron seems
like the primary blocker, since anything *not* in standard could just
depend on an MTA for now.

For that matter, it seems easy enough to write a very short shell script
which just uses logger (from bsdutils) to log the command-line arguments
and stdin, and install that shell script as sendmail. Call the whole
thing "mta-syslogger", and use it as the default MTA in standard. I
don't know if doing that makes sense, or if it would make more sense to
just fix programs like cron to also talk to syslog; I'd lean towards the
latter.

Either way, I'm happy to address that or any other issues that block
making an MTA optional.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111014055627.GA25594@leaf">http://lists.debian.org/20111014055627.GA25594@leaf
 
Old 10-14-2011, 09:35 AM
Philip Hands
 
Default RFC: Making mail-transport-agent Priority: optional

On Thu, 13 Oct 2011 10:17:38 +0200, "Bernhard R. Link" <brlink@debian.org> wrote:
...
> > - Taking time to download and install, which increases the time and
> > bandwidth needed to install or upgrade a Debian system.
>
> Please drop the "upgrade". If you deinstall it there is no cost at
> upgrading.

I think the point here is that people that accept a default install are
liable to not be brave enough to remove chunks of the system, or even
perceptive enough to notice that some daemon that seems to be surplus to
requirements is running, let alone then doing the work to find out that
they can safely remove it, and then actually do so.

Also, most normal users will never remove it on the basis that it's
"standard" (assuming that they discover that fact).

That being the case, they will get every upgrade.

My brother comes to mind -- he's pretty happy with Debian and if he
didn't know me it's _just_ possible that he'd have installed it himself,
but would have simply accepted every default. He uses icedove as his
MUA, pointed at a remote SMTP/IMAP server -- I seriously doubt that he'd
ever see root mails, and even if he did, he'd ignore them as he
cheerfully did on all his windows boxen in their death throws -- I'm not
sure what we should do about that, but running exim seems unlikely to be
the answer.

The alternative group that is served by having an MTU, but naive enough
to not know they need one seems to me to be smaller, but maybe I'm
missing something.

Then of course there's the group that probably includes all the people
in this thread, that know exactly when and where they want to install
which MTU.

My preferred default would be postfix, with ssmtp on client type
machines, so I generally preseed all that to avoid pointlessly
installing exim, which of course means that my personal preferences are
totally irrelevant to this discussion, as we're trying to determine
useful defaults for people that will end up living with those defaults.

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
 
Old 10-14-2011, 12:05 PM
"Bernhard R. Link"
 
Default RFC: Making mail-transport-agent Priority: optional

* Philip Hands <phil@hands.com> [111014 11:50]:
> On Thu, 13 Oct 2011 10:17:38 +0200, "Bernhard R. Link" <brlink@debian.org> wrote:
> > > - Taking time to download and install, which increases the time and
> > > bandwidth needed to install or upgrade a Debian system.
> >
> > Please drop the "upgrade". If you deinstall it there is no cost at
> > upgrading.
>
> I think the point here is that people that accept a default install are
> liable to not be brave enough to remove chunks of the system, or even
> perceptive enough to notice that some daemon that seems to be surplus to
> requirements is running, let alone then doing the work to find out that
> they can safely remove it, and then actually do so.
>
> Also, most normal users will never remove it on the basis that it's
> "standard" (assuming that they discover that fact).
>
> That being the case, they will get every upgrade.

Now are you spealing about normal users or about users that know enough
to know they do not need a MTA?

If you do not know that you do not need one then you should have one
installed. Being able to invoke sendmail to notify a user about
something is a core part of a UNIXoid system. It'd not that core as
having /bin/true or other parts. But not having it is special.

> My brother comes to mind -- he's pretty happy with Debian and if he
> didn't know me it's _just_ possible that he'd have installed it himself,
> but would have simply accepted every default. He uses icedove as his
> MUA, pointed at a remote SMTP/IMAP server -- I seriously doubt that he'd
> ever see root mails, and even if he did, he'd ignore them as he
> cheerfully did on all his windows boxen in their death throws -- I'm not
> sure what we should do about that, but running exim seems unlikely to be
> the answer.

Every shell will usually tell you some "You have new mail". So in case
some part of the system wants to notify, there will at least some
information.

> My preferred default would be postfix, with ssmtp on client type
> machines, so I generally preseed all that to avoid pointlessly
> installing exim, which of course means that my personal preferences are
> totally irrelevant to this discussion, as we're trying to determine
> useful defaults for people that will end up living with those defaults.

ssmtp had no queue last I looked (and is buggy like hell). This means
having shortly no connection to the mail server means mails are lost.
Having exim as satellite is really perferably there.

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111014120534.GA19595@server.brlink.eu">http://lists.debian.org/20111014120534.GA19595@server.brlink.eu
 
Old 10-14-2011, 12:17 PM
"Bernhard R. Link"
 
Default RFC: Making mail-transport-agent Priority: optional

* Josh Triplett <josh@joshtriplett.org> [111013 22:42]:
> > Then deinstall it.
>
> Every point you just stated applies equally well to every daemon we
> don't install by default; you haven't given any reason why an MTA needs
> to exist by default.

Those points are only there to make clear that your counter-arguments
(to which they were the answer) are no arguments in my eyes at all.

> > Please note that an MTA perfectly fits into the
> > 'If the expectation is that an experienced Unix person who found it
> > missing would say "What on earth is going on, where is foo?", it must
> > be an important package.' criterion. So only having priority standard
> > is already a compromise (and I guess historically due to there being
> > alternative implementations).
>
> Given the prevalence of LAMP, quite a few people might say "What on
> earth is going on, where is mysql?".

That why it says "an experiences Unix person". No experienced Unix
person will find it suprising to not have a mysql server installed by
default. Every one experienced will consider not having one special.
(An experienced one will know that you do not necessarily need one and
which services will no longer be able to contact the user, but they
will recognize it as "special"):

> More seriously, "what on earth is going on, where is foo?" applies quite
> well to things like ps, a pager, an editor, and many other things
> hard-wired into people's command-line finger memory.

Ang guess what is installed by default?

> Why does an MTA
> fall in that category? Remembering the good old days of multiuser
> systems with vibrant local mail conversations will not bring them back.

Local mail may no longer be the default for non-system mails. But that
does not change that the majority of daemons currently running was
written in a time where mail was a given. Cron uses it, some mail spoolers
use it to notify users, syslog servers used it if they could not write
logfiles, sudo can write mails (am not sure if it is still on by
default) and so on...

Bernhard R. Link

P.S: Please not not CC me.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111014121757.GB19595@server.brlink.eu">http://lists.debian.org/20111014121757.GB19595@server.brlink.eu
 

Thread Tools




All times are GMT. The time now is 07:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org