6:31 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
i've just wondered why sendmail is still the default MTA in Fedora.
Please enlighten me?
cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFI+HeU15TuH1mPaRURAr5AAJwOv5KOoZFZXdsIHlEALIfyA586xACePrlg
MtRkQuvfYTiN35lUcQFSnsQ=
=qzu9
-----END PGP SIGNATURE-----
6:35 a.m.
On Fri, Oct 17, 2008 at 01:31:32PM +0200, Lutz Lange wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
i've just wondered why sendmail is still the default MTA in Fedora.
Please enlighten me?
This is a (very) controversial issue. If I recall well, it has been
decided not to change anything for F10, but there was an heated thread
some time ago, and maybe this could be discussed in the timeframe of
F11. To sum up some people considered that local delivery was a must for
the default MTA, and that a send-only MTA wasn't good enough, eg, for
cronie. My personnal opinion is that there should not be any MTA in the
@base or @code group, and that a MTA should be chosed if it is pulled in
as a dependency, so it could be sendmail or anything else. Whether local
delivery is a must for cronie or other packages that today require
/usr/sbin/sendmail is another story that caould be discussed a bit more,
though in the end it seems to me that this should be up to the
maintainer.
But could you please elaborate a bit more on something like a proposal?
--
Pat
7:11 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrice Dumas schrieb:
On Fri, Oct 17, 2008 at 01:31:32PM +0200, Lutz Lange wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?
This is a (very) controversial issue. If I recall well, it has been
decided not to change anything for F10, but there was an heated thread
some time ago, and maybe this could be discussed in the timeframe of
F11. To sum up some people considered that local delivery was a must for
the default MTA, and that a send-only MTA wasn't good enough, eg, for
cronie. My personnal opinion is that there should not be any MTA in the
@base or @code group, and that a MTA should be chosed if it is pulled in
as a dependency, so it could be sendmail or anything else. Whether local
delivery is a must for cronie or other packages that today require
/usr/sbin/sendmail is another story that caould be discussed a bit more,
though in the end it seems to me that this should be up to the
maintainer.
But could you please elaborate a bit more on something like a proposal?
--
Pat
Hi Pat,
i'm an instructor an just had students wondering why we still ship
sendmail as default. All i was really looking for was a good
argumentation shows why we do it like that. I wanted to show that is was
a choice and that we do it for good reason.
The for me obvious alternative is using postfix as default. This seams
more up to date, easier to configure, and it's not a big blob of binary
software as sendmail seams to be. For the stability argument, i've hear
that sendmail and postfix are quite comparable and have had about the
amount of bug both in severity and count over the last few years.
But to be fair, i will confess, i'm not really that deep into Mail and
therefore the wrong person to judge from a professional perspective.
Though i think we should provide good reasons for the thinks we ship /
do. An just arguing we've done this for X years this way, doesn't seam
enough somehow.
Cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFI+IDn15TuH1mPaRURAg3OAKDUpQ5HPGoJLKmU1LUpVCpyveN90wCgh60X
/a7mg0DQDpzUFk7wGcvfrfo=
=RwNa
-----END PGP SIGNATURE-----
7:39 a.m.
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in Fedora.
Please enlighten me?
It works. It can be configured to do just about anything. Everyone who
has every worked with a unix-like system is used to it. Every program
written for unix-like systems is likely to expect it to be installed.
Even though the original design and code weren't particularly secure,
the current version is probably one of the most audited pieces of code
and the milter capability lets you extend it with features that don't
share the full permissions of the main process yet can interact in real
time during delivery.
--
Les Mikesell
lesmikesell(a)gmail.com
7:49 a.m.
Le Ven 17 octobre 2008 14:39, Les Mikesell a écrit :
Lutz Lange wrote:
>
>
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?
It works.
Sort of
It can be configured to do just about anything.
Like others
Everyone who
has every worked with a unix-like system is used to it.
No
Every program
written for unix-like systems is likely to expect it to be installed.
They only expect the sendmail interface alternatives are also providing
Even though the original design and code weren't particularly
secure,
the current version is probably one of the most audited pieces of code
and
And upstream has such a confidence in the result they're rewriting it
from scratch.
the milter capability lets you extend it with features that
don't
share the full permissions of the main process yet can interact in
real time during delivery.
Milter is supported by alternatives too
Not that I particularly want to shoot ambulances, but those are not
good arguments.
--
Nicolas Mailhot
7:57 a.m.
Nicolas Mailhot wrote:
Not that I particularly want to shoot ambulances, but those are not
good arguments.
They would be lousy arguments for changing to sendmail but they are
fairly good arguments for keeping it. One needs a fairly compelling
reason to change something that is already there. The above arguments
amount to "there is no compelling reason to change".
8:13 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
shmuel siegel schrieb:
Nicolas Mailhot wrote:
> Not that I particularly want to shoot ambulances, but those are not
> good arguments.
>
>
They would be lousy arguments for changing to sendmail but they are
fairly good arguments for keeping it. One needs a fairly compelling
reason to change something that is already there. The above arguments
amount to "there is no compelling reason to change".
What about : it's not easy to configure it right or to learn how to do
it. If you already know it, you might be fine. If not you might be in
trouble.
And: It's second choice for an MTA for most people i know.
I may know the wrong people but as an instructor i meet quite a lot of
them :)
Cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFI+I+C15TuH1mPaRURAlqYAJ4ydPwaXtQtdoyldHDMNqPcysFLjgCfXcmi
KB5FCFnHtjs83aALxzhunSU=
=xdnt
-----END PGP SIGNATURE-----
8:35 a.m.
On Fri, 2008-10-17 at 15:13 +0200, Lutz Lange wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
shmuel siegel schrieb:
> Nicolas Mailhot wrote:
>> Not that I particularly want to shoot ambulances, but those are not
>> good arguments.
>>
>>
> They would be lousy arguments for changing to sendmail but they are
> fairly good arguments for keeping it. One needs a fairly compelling
> reason to change something that is already there. The above arguments
> amount to "there is no compelling reason to change".
What about : it's not easy to configure it right or to learn how
to do
it. If you already know it, you might be fine. If not you might be in
trouble.
If you're old school and insist on editing the .cf I might agree with
you but that then contradicts your "If not" clause. If you don't know
what you're doing you might be deceived by complainers into thinking
that's how it's configured and that's how you have to do it.
OTOH... The .m4 configurations are not very complicated. Very
straight forward to enabled and disable features and configure names and
tokens and files. I don't find the m4 interface to be any more
complicated to configure than say smail or postfix and a hell of a lot
simpler than many other utilities. I find sendmail far easier to
configure than, say, squid or other complex utilities requiring acls and
filters, which we largely take for granted. I also find that sendmail
generally works just fine out of the box for simple systems.
And: It's second choice for an MTA for most people i know.
I may know the wrong people but as an instructor i meet quite a lot of
them :)
Not quite sure I know how to parse that last one. Do you mean that
sendmail is a second choice? Or what is a second choice? I'm not sure
one what the "It" is that you are referring to or how you are arguing
there.
You mean that people given a list would place sendmail second? I know
a lot of people in the business and have known a lot of them down
through the last two decades. I know people who are passionate about
QMail and I know Wietse and I happen to think Postfix is wonderful and
I've personally contributed to the Smail project many many years ago and
I've even worked with and ported and configured MMDF (anyone remember
MMDF, the default MTA on SCO Unix for many many years?). I would not
make the statement that most would put Sendmail second. I would not
make the statement that most would put Sendmail first. I know that both
Postfix and Sendmail are very popular. Sendmail is well established as
the default with a reasonably easy option to switch to Postfix, and I
see no compelling reason to switch.
Cheers
Lutz
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw(a)WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
8:13 a.m.
Nicolas Mailhot wrote:
>> i've just wondered why sendmail is still the default MTA in Fedora.
>> Please enlighten me?
> It works.
Sort of
What does that mean? It delivers most of the mail on the internet and
always has.
> Even though the original design and code weren't particularly
secure,
> the current version is probably one of the most audited pieces of code
> and
And upstream has such a confidence in the result they're rewriting it
from scratch.
And its not the first time. All good programs are periodically
rewritten and improved.
> the milter capability lets you extend it with features that
don't
> share the full permissions of the main process yet can interact in
> real time during delivery.
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Not that I particularly want to shoot ambulances, but those are not
good arguments.
Sorry, but I don't see any counterargument here. The alternatives are
all worse.
--
Les Mikesell
lesmikesell(a)gmail.com
8:28 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Les Mikesell schrieb:
What does that mean? It delivers most of the mail on the internet and
always has.
...
>
> Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
> Not that I particularly want to shoot ambulances, but those are not
> good arguments.
Sorry, but I don't see any counterargument here. The alternatives are
all worse.
The question remains, is it the best option for the most users? That's
what the default MTA should be right?
Cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFI+JLn15TuH1mPaRURAtONAKDRIaEFTxkxn2GBw6wVjchAVIbdVwCfWR3/
xAlGEz7mHPMp6DJ6ZMEKygk=
=07ts
-----END PGP SIGNATURE-----
1:55 p.m.
On Friday, 17 October 2008 at 15:13, Les Mikesell wrote:
Nicolas Mailhot wrote:
>>>i've just wondered why sendmail is still the default MTA in Fedora.
>>>Please enlighten me?
[...]
>>the milter capability lets you extend it with features that
don't
>>share the full permissions of the main process yet can interact in
>>real time during delivery.
>
>Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Postfix will: http://www.mimedefang.org/kwiki/index.cgi?Milter
...
Milter and Postfix
The Postfix MTA implemented partial Milter support in version 2.3 and more
complete support in 2.4. See http://www.postfix.org/MILTER_README.html for
details. MIMEDefang 2.63 works with Postfix.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Not that I particularly want to shoot ambulances, but those are
not
>good arguments.
Sorry, but I don't see any counterargument here. The alternatives are
all worse.
Postfix is not worse. I'd argue that's it's better in every respect,
but I guess you wouldn't listen anyway and I'm a bit short on time.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
2:33 p.m.
Dominik 'Rathann' Mierzejewski wrote:
[...]
>>> the milter capability lets you extend it with features that don't
>>> share the full permissions of the main process yet can interact in
>>> real time during delivery.
>> Milter is supported by alternatives too
> They pretend to, but won't actually run complex milters like MimeDefang.
Postfix will: http://www.mimedefang.org/kwiki/index.cgi?Milter
...
Milter and Postfix
The Postfix MTA implemented partial Milter support in version 2.3 and more
complete support in 2.4. See http://www.postfix.org/MILTER_README.html for
details. MIMEDefang 2.63 works with Postfix.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Interesting - that doesn't seem to be generally known. I hadn't seen it
mentioned on the MimeDefang list. Maybe it is just because the
distributions stable enough to be used as a mail server don't include
2.4 yet.
>> Not that I particularly want to shoot ambulances, but those
are not
>> good arguments.
> Sorry, but I don't see any counterargument here. The alternatives are
> all worse.
Postfix is not worse. I'd argue that's it's better in every respect,
but I guess you wouldn't listen anyway and I'm a bit short on time.
It's worse at backwards compatibility. Fedora seems to assume that
their users don't already have something working, so maybe that's not a
concern to anyone here. If it shipped with a decked-out, well tested
setup already integrated with MimeDefang/clamd/spamassassin it might be
enough of an improvement to switch.
--
Les Mikesell
lesmikesell(a)gmail.com
8:03 a.m.
On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
> Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like
MimeDefang.
Some of the better alternatives don't even _try_ to run milters, because
they are fully-featured enough in their own right, without needing to
rely on external software.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
9:47 a.m.
David Woodhouse wrote:
On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
>> Milter is supported by alternatives too
> They pretend to, but won't actually run complex milters like
> MimeDefang.
Some of the better alternatives don't even _try_ to run milters, because
they are fully-featured enough in their own right, without needing to
rely on external software.
Which means that you can't run your choice of tests on a message during
the smtp conversation before you accept it - at least without starting a
new process for each one which is expensive for large programs like
spamassassin. And if you accept a message but don't deliver it, you are
supposed to generate a bounce to the sender, but that is always the
wrong thing to do if you think it might be spam or a virus. Running
your checks in time to do an smtp reject eliminates that problem.
--
Les Mikesell
lesmikesell(a)gmail.com
11:38 a.m.
On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
Which means that you can't run your choice of tests on a message
during
the smtp conversation before you accept it - at least without starting a
new process for each one which is expensive for large programs like
spamassassin.
As is often the case, it seems, you are entirely incorrect.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
1:04 p.m.
David Woodhouse wrote:
On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
> Which means that you can't run your choice of tests on a message during
> the smtp conversation before you accept it - at least without starting a
> new process for each one which is expensive for large programs like
> spamassassin.
As is often the case, it seems, you are entirely incorrect.
One of my choices of tests on an inbound relay machine has been to check
that the user exists using an smtp check against the internal delivery
host. How would I do that on an MTA that does not handle milters?
--
Les Mikesell
lesmikesell(a)gmail.com
1:17 p.m.
On 10/19/2008 02:04 PM, Les Mikesell wrote:
One of my choices of tests on an inbound relay machine has been to
check
that the user exists using an smtp check against the internal delivery
host. How would I do that on an MTA that does not handle milters?
Not taking sides on milters or not but ..
This can be achieved in sendmail (et al) with virtusertable. Doesnt
use an smtp check from border to inside as you stated, and it does need
a virtusertable on the border relay.
1:29 p.m.
On Sun, Oct 19, 2008 at 2:17 PM, Mail Lists <lists(a)sapience.com> wrote:
On 10/19/2008 02:04 PM, Les Mikesell wrote:
> One of my choices of tests on an inbound relay machine has been to check
> that the user exists using an smtp check against the internal delivery
> host. How would I do that on an MTA that does not handle milters?
>
Not taking sides on milters or not but ..
This can be achieved in sendmail (et al) with virtusertable. Doesnt
use an smtp check from border to inside as you stated, and it does need
a virtusertable on the border relay.
Everyone - Mail Lists has spoken. End of thread!
1:37 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
There's two types of people using fedora:
1) People who don't run a mail server
2) People who very deliberately do
For 1), all three are wrong. Really. All you really need is some
minimalist commandline compatible thing that just forwards to some
smart host (or maybe does only local delivery). SSMTP or similar is
perfectly fine for this, while not taxing memory or boot time.
For 2) these folks have a VERY specific personal preference. This
entire discussion proves that. These folks already have to configure
their system from the default... making "pick a mail server of your
taste" part of that is the least of their worries.
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
default choice is ignoring the reality...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
1:40 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On 10/19/2008 02:37 PM, Arjan van de Ven wrote:
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
default choice is ignoring the reality...
Agreed - tho it would be nice to ship dkim-milter and dk-milter along
with sendmail/postfix etc.
2:26 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
default choice is ignoring the reality...
(+1)
Good point, but don't forget that Fedora is pretty ambivalent
distribution. It's a "desktop distribution" where some people want to
disable non-X console and other people use postfix, port packages to
s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a
base for Red Hat Enterprise distribution :-)
Karel
--
Karel Zak <kzak(a)redhat.com>
2:32 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, Oct 19, 2008 at 3:26 PM, Karel Zak <kzak(a)redhat.com> wrote:
On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
> Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> default choice is ignoring the reality...
(+1)
Good point, but don't forget that Fedora is pretty ambivalent
distribution. It's a "desktop distribution" where some people want to
disable non-X console and other people use postfix,
That's right - desktops are different from servers. Fedora's core
should be driven from the use cases, and where the use cases have
things in common, they're shared. Where they don't, they're not.
Specifically regarding an MTA, as I said before I understand there's
the "workstation" use case where you're say doing web development and
you want to install Apache or Tomcat or something locally and run
logwatch on it. We obviously will support that. But it doesn't make
sense for the default desktop OS to be sending you email about all the
junk going on under the hood.
8:47 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, 2008-10-19 at 15:32 -0400, Colin Walters wrote:
But it doesn't make
sense for the default desktop OS to be sending you email about all the
junk going on under the hood.
I understand where you are coming from but I have to say the above
statement is, imo, fundamentally wrong.
-sv
9:13 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, Oct 19, 2008 at 09:47:58PM -0400, seth vidal wrote:
> But it doesn't make sense for the default desktop OS to be
sending you
> email about all the junk going on under the hood.
I understand where you are coming from but I have to say the above
statement is, imo, fundamentally wrong.
I agree with Seth. Since most desktop users don't have a centralized
logserver but do have an e-mail account somewhere, it makes perfect sense.
We need to work some on getting e-mail going somewhere useful, though, and
on making the e-mails sent be not "junk".
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
1:06 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Matthew Miller (mattdm(a)mattdm.org) said:
> I understand where you are coming from but I have to say the
above
> statement is, imo, fundamentally wrong.
I agree with Seth. Since most desktop users don't have a centralized
logserver but do have an e-mail account somewhere, it makes perfect sense.
We need to work some on getting e-mail going somewhere useful, though, and
on making the e-mails sent be not "junk".
I'm trying to think of a single thing that logwatch (or cron) would send
about now that would be useful to forward to a random desktop user's yahoo
address. I'm failing.
Bill
1:23 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Bill Nottingham wrote:
Matthew Miller (mattdm(a)mattdm.org) said:
>> I understand where you are coming from but I have to say the above
>> statement is, imo, fundamentally wrong.
> I agree with Seth. Since most desktop users don't have a centralized
> logserver but do have an e-mail account somewhere, it makes perfect sense.
> We need to work some on getting e-mail going somewhere useful, though, and
> on making the e-mails sent be not "junk".
I'm trying to think of a single thing that logwatch (or cron) would send
about now that would be useful to forward to a random desktop user's yahoo
address. I'm failing.
Most people would probably like to know if smartctl thinks their disk
drive is likely to fail or if a raid member has already failed and they
are running in degraded mode. And maybe if a bazillion ssh login
attempts have failed. As for cron, that would be up to what the user
has scheduled. It just needs to behave as documented and expected.
--
Les Mikesell
lesmikesell(a)gmail.com
1:26 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, Oct 20, 2008 at 2:23 PM, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Most people would probably like to know if smartctl thinks their disk drive
is likely to fail or if a raid member has already failed and they are
running in degraded mode.
Should be exposed through HAL and then the desktop can listen for that
event and present it in a suitable way - e.g. a notification bubble.
1:28 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Les Mikesell (lesmikesell(a)gmail.com) said:
> I'm trying to think of a single thing that logwatch (or cron)
would send
> about now that would be useful to forward to a random desktop user's yahoo
> address. I'm failing.
Most people would probably like to know if smartctl thinks their disk
drive is likely to fail or if a raid member has already failed and they
are running in degraded mode. And maybe if a bazillion ssh login
attempts have failed.
... which should be pop-up alerts of some sort on the machine itself. Not
sent halfway across the world waiting for you to connect to the internet.
Bill
1:43 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Bill Nottingham wrote:
>> I'm trying to think of a single thing that logwatch (or cron) would send
>> about now that would be useful to forward to a random desktop user's yahoo
>> address. I'm failing.
> Most people would probably like to know if smartctl thinks their disk
> drive is likely to fail or if a raid member has already failed and they
> are running in degraded mode. And maybe if a bazillion ssh login
> attempts have failed.
... which should be pop-up alerts of some sort on the machine itself. Not
sent halfway across the world waiting for you to connect to the internet.
You are kind of missing the point of a machine with a network, automated
scheduling and the native ability to run single apps in a remote window.
Users don't need to sit in front of every machine they have for it to
be doing something useful for them. The user may in fact be halfway
around the world when you'd present that pop-up that he'll never see in
some window manager he's not running. Messages you want should come to
you, rather than having to do the reverse.
--
Les Mikesell
lesmikesell(a)gmail.com
1:50 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, Oct 20, 2008 at 2:43 PM, Les Mikesell <lesmikesell(a)gmail.com> wrote:
You are kind of missing the point of a machine with a network, automated
scheduling and the native ability to run single apps in a remote window.
Users don't need to sit in front of every machine they have for it to be
doing something useful for them. The user may in fact be halfway around the
world when you'd present that pop-up that he'll never see in some window
manager he's not running. Messages you want should come to you, rather than
having to do the reverse.
So set up logwatch or whatever other server machine monitoring
software you prefer.
2:05 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, Oct 20, 2008 at 01:43:42PM -0500, Les Mikesell wrote:
You are kind of missing the point of a machine with a network,
automated
scheduling and the native ability to run single apps in a remote window.
Users don't need to sit in front of every machine they have for it to
be doing something useful for them. The user may in fact be halfway
around the world when you'd present that pop-up that he'll never see in
some window manager he's not running. Messages you want should come to
you, rather than having to do the reverse.
Once you're beyond the typical desktop use case, then yes, an MTA
probably makes sense. But that's not an argument for an MTA in the
default desktop install.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:17 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Matthew Garrett wrote:
On Mon, Oct 20, 2008 at 01:43:42PM -0500, Les Mikesell wrote:
> You are kind of missing the point of a machine with a network, automated
> scheduling and the native ability to run single apps in a remote window.
> Users don't need to sit in front of every machine they have for it to
> be doing something useful for them. The user may in fact be halfway
> around the world when you'd present that pop-up that he'll never see in
> some window manager he's not running. Messages you want should come to
> you, rather than having to do the reverse.
Once you're beyond the typical desktop use case, then yes, an MTA
probably makes sense. But that's not an argument for an MTA in the
default desktop install.
OK, if you really are so elitist that you think typical users can't
figure out how to use standard programs, consider the case where you
install the software for one of your incapable friends or family members
and you'd like those impending failure warnings to come to you since the
user won't understand them anyway.
--
Les Mikesell
lesmikesell(a)gmail.com
2:24 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Les Mikesell (lesmikesell(a)gmail.com) said:
> Once you're beyond the typical desktop use case, then yes, an
MTA
> probably makes sense. But that's not an argument for an MTA in the
> default desktop install.
OK, if you really are so elitist that you think typical users can't
figure out how to use standard programs, consider the case where you
install the software for one of your incapable friends or family members
and you'd like those impending failure warnings to come to you since the
user won't understand them anyway.
Then you, the *administrator* of that machine (because, truly, that's
your role) can configure it to do so. It doesn't mean it should do so
out of the box.
Bill
2:33 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, Oct 20, 2008 at 3:24 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Then you, the *administrator* of that machine (because, truly, that's
your role) can configure it to do so. It doesn't mean it should do so
out of the box.
That said, I do wish Fedora made it easier to do the remote admin for
family/friends type thing. I'm not really thinking of setting up mail
servers, but more putting together something like Copilot
(https://www.copilot.com/) from the tools we have (Vino, ssh,
Telepathy). But that's another discussion...
3:55 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Colin Walters wrote:
On Mon, Oct 20, 2008 at 3:24 PM, Bill Nottingham
<notting(a)redhat.com> wrote:
> Then you, the *administrator* of that machine (because, truly, that's
> your role) can configure it to do so. It doesn't mean it should do so
> out of the box.
That said, I do wish Fedora made it easier to do the remote admin for
family/friends type thing. I'm not really thinking of setting up mail
servers, but more putting together something like Copilot
(https://www.copilot.com/) from the tools we have (Vino, ssh,
Telepathy). But that's another discussion...
I think policykit introduces some really ugly issues issues here - or at
least if it works the same as in ubuntu in terms of giving unwarranted
privileges to console sessions and requiring a console session to use
the GUI admin tools if you don't log in as root. You could use VNC or
NX/freenx session shadowing with an already logged in console user
session, but that's not exactly right for administration since it might
really be an unprivileged user sitting there.
--
Les Mikesell
lesmikesell(a)gmail.com
3:16 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Bill Nottingham wrote:
Les Mikesell (lesmikesell(a)gmail.com) said:
>> Once you're beyond the typical desktop use case, then yes, an MTA
>> probably makes sense. But that's not an argument for an MTA in the
>> default desktop install.
> OK, if you really are so elitist that you think typical users can't
> figure out how to use standard programs, consider the case where you
> install the software for one of your incapable friends or family members
> and you'd like those impending failure warnings to come to you since the
> user won't understand them anyway.
Then you, the *administrator* of that machine (because, truly, that's
your role) can configure it to do so. It doesn't mean it should do so
out of the box.
But it is even more important for the more common case where the user is
his own administrator. The right way to handle that case is not to
change it conceptually by re-inventing a less capable - and unexpected -
message transport and storage facility, but to make the standard
capability more obvious by adding a choice for the root alias at
firstboot configuration and a mail notifier applet to the default
desktop. This gives you a configuration that both an administrator and
a first-time user can understand and use, and even the first-time user
will see that the capabilities are better than he'd have on a stock MS
windows box.
--
Les Mikesell
lesmikesell(a)gmail.com
8:20 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, Oct 20, 2008 at 02:17:39PM -0500, Les Mikesell wrote:
Matthew Garrett wrote:
>Once you're beyond the typical desktop use case, then yes, an MTA
>probably makes sense. But that's not an argument for an MTA in the
>default desktop install.
OK, if you really are so elitist that you think typical users can't
figure out how to use standard programs, consider the case where you
install the software for one of your incapable friends or family members
and you'd like those impending failure warnings to come to you since the
user won't understand them anyway.
I'm pretty solidly of the opinion that email is nowhere near being the
most sensible way to get important information to a typical desktop
user. If a failure is important then the user needs to know about it as
soon as possible - mail provides no guarantees about timely delivery. We
have plenty of desktop infrastructure to give important alerts to users,
we're just failing to do so.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:52 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Matthew Garrett wrote:
On Mon, Oct 20, 2008 at 02:17:39PM -0500, Les Mikesell wrote:
> Matthew Garrett wrote:
>> Once you're beyond the typical desktop use case, then yes, an MTA
>> probably makes sense. But that's not an argument for an MTA in the
>> default desktop install.
> OK, if you really are so elitist that you think typical users can't
> figure out how to use standard programs, consider the case where you
> install the software for one of your incapable friends or family members
> and you'd like those impending failure warnings to come to you since the
> user won't understand them anyway.
I'm pretty solidly of the opinion that email is nowhere near being the
most sensible way to get important information to a typical desktop
user. If a failure is important then the user needs to know about it as
soon as possible - mail provides no guarantees about timely delivery. We
have plenty of desktop infrastructure to give important alerts to users,
we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other
notification method would have succeeded. The important point is that
the user may not be present when the event occurs, and that desktop
infrastructure may not even be running - and even if it is, the
interested party may want the notification to be forwarded elsewhere.
--
Les Mikesell
lesmikesell(a)gmail.com
9:07 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 08:52:27AM -0500, Les Mikesell wrote:
Matthew Garrett wrote:
>I'm pretty solidly of the opinion that email is nowhere near being the
>most sensible way to get important information to a typical desktop
>user. If a failure is important then the user needs to know about it as
>soon as possible - mail provides no guarantees about timely delivery. We
>have plenty of desktop infrastructure to give important alerts to users,
>we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other
notification method would have succeeded. The important point is that
the user may not be present when the event occurs, and that desktop
infrastructure may not even be running - and even if it is, the
interested party may want the notification to be forwarded elsewhere.
Local delivery of mail is a poor solution, since it provides no
indication of priority difference between "You've got spam" and "Your
hard drive is failing". If there's nobody to present it to, it can be
queued and presented at login - if the user is running on their system
but doesn't have the desktop infrastructure running, then by definition
they're already outside the standard desktop usecase.
I'm not arguing about the utility of an MTA for various situations. I'm
arguing that for one specific and very common situation, using an MTA to
deliver system alerts is a poor way of handling it. We should fix that.
As a happy side effect, it removes the need for a default MTA in the
desktop install. People who want an MTA then get to choose whichever MTA
they want and net human happiness is increased.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:33 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 03:07:13PM +0100, Matthew Garrett wrote:
queued and presented at login - if the user is running on their
system
but doesn't have the desktop infrastructure running, then by definition
they're already outside the standard desktop usecase.
You mean like boot, shutdown, being logged out, ...
As a happy side effect, it removes the need for a default MTA in the
desktop install. People who want an MTA then get to choose whichever MTA
Actually that I question somewhat. Both POSIX and the LSB require local mail
delivery services. A suprising number of applications that don't currently
specify sendmail dependancies appear to use it. Have a grep...
And if we are going to worry about desktop experiences then perhaps making
evolution not totally suck, fixing the way the desktop totally disintegrates
when you run out of disk space, a working gdm again and a few other items
would be far better use of time than macdinking with log delivery.
My own experience is that if you are using gnome and run out of local disk and
or quota the fact your mail is not delivered is the least of the problems,
and managing to log in and then having to restore half your desktop settings
are far bigger ones.
Alan
9:50 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
Actually that I question somewhat. Both POSIX and the LSB require local mail
delivery services. A suprising number of applications that don't currently
specify sendmail dependancies appear to use it. Have a grep...
Every package with application that calls /usr/sbin/sendmail should
require that file. Isn't it the case? If you know about cases like that,
tell, I'll file bugs.
Now this is only part of the story since currently programs that don't
do local delivery, or are not configured for local delivery out-of-the-box
provides /usr/sbin/sendmail. I think that is is right, but maybe a
virtual dependency, like mail(local) is needed somewhere to force
installation of an app that does local delivery, either as a dependency,
or as part of the default install, though there is no agreement on that
currently.
--
Pat
10:14 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Patrice Dumas wrote:
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
> Actually that I question somewhat. Both POSIX and the LSB require local mail
> delivery services. A suprising number of applications that don't currently
> specify sendmail dependancies appear to use it. Have a grep...
Every package with application that calls /usr/sbin/sendmail should
require that file. Isn't it the case? If you know about cases like that,
tell, I'll file bugs.
If POSIX requires it, it should be a safe assumption on any system that
claims compliance.
Now this is only part of the story since currently programs that
don't
do local delivery, or are not configured for local delivery out-of-the-box
provides /usr/sbin/sendmail. I think that is is right, but maybe a
virtual dependency, like mail(local) is needed somewhere to force
installation of an app that does local delivery, either as a dependency,
or as part of the default install, though there is no agreement on that
currently.
Apps that send mail don't and shouldn't know where delivery is going to
happen. That is entirely up to the transport.
--
Les Mikesell
lesmikesell(a)gmail.com
11:13 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 04:50:35PM +0200, Patrice Dumas wrote:
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
>
> Actually that I question somewhat. Both POSIX and the LSB require local mail
> delivery services. A suprising number of applications that don't currently
> specify sendmail dependancies appear to use it. Have a grep...
Every package with application that calls /usr/sbin/sendmail should
require that file. Isn't it the case? If you know about cases like that,
tell, I'll file bugs.
Try grep. That is how I did a scan.
11:58 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, 21 Oct 2008 12:13:57 -0400
Alan Cox <alan(a)redhat.com> wrote:
On Tue, Oct 21, 2008 at 04:50:35PM +0200, Patrice Dumas wrote:
> On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
> >
> > Actually that I question somewhat. Both POSIX and the LSB require
> > local mail delivery services. A suprising number of applications
> > that don't currently specify sendmail dependancies appear to use
> > it. Have a grep...
>
> Every package with application that calls /usr/sbin/sendmail should
> require that file. Isn't it the case? If you know about cases like
> that, tell, I'll file bugs.
Try grep. That is how I did a scan.
fwiw ssmtp and all those guys do provide a /usr/bin/sendmail, but one
that doesn't queue just does local delivery.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
5:36 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 10:36:49PM +0200, Patrice Dumas wrote:
On Tue, Oct 21, 2008 at 12:13:57PM -0400, Alan Cox wrote:
>
> Try grep. That is how I did a scan.
A grep in what? In a strings on all binaries?
source packages
12:13 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
On Tue, Oct 21, 2008 at 03:07:13PM +0100, Matthew Garrett wrote:
> queued and presented at login - if the user is running on their system
> but doesn't have the desktop infrastructure running, then by definition
> they're already outside the standard desktop usecase.
You mean like boot, shutdown, being logged out, ...
Times when mail delivery isn't a terribly effective solution either.
And if we are going to worry about desktop experiences then perhaps
making
evolution not totally suck, fixing the way the desktop totally disintegrates
when you run out of disk space, a working gdm again and a few other items
would be far better use of time than macdinking with log delivery.
Also, we should stop doing any kernel development until ipw4965 actually
works. I'm pretty sure we don't need another slab allocator.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
5:33 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 06:13:56PM +0100, Matthew Garrett wrote:
> And if we are going to worry about desktop experiences then
perhaps making
> evolution not totally suck, fixing the way the desktop totally disintegrates
> when you run out of disk space, a working gdm again and a few other items
> would be far better use of time than macdinking with log delivery.
Also, we should stop doing any kernel development until ipw4965 actually
works. I'm pretty sure we don't need another slab allocator.
And how many years as gnome out of disk been broken, or evolution crap ?
No we don't need another slab allocator, but last time I checked nobody in
Red Hat was writing one either. They are all far too busy working on stuff
that needs doing.
Alan
6:48 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 06:33:51PM -0400, Alan Cox wrote:
On Tue, Oct 21, 2008 at 06:13:56PM +0100, Matthew Garrett wrote:
> Also, we should stop doing any kernel development until ipw4965 actually
> works. I'm pretty sure we don't need another slab allocator.
And how many years as gnome out of disk been broken, or evolution crap ?
To be fair to evolution, it's getting on for being in the region of half
as big as the kernel. Making it non-crap isn't a five minute job, and
asking people to spend three years failing to get very far through it
isn't likely to win many friends. We have insane quantities of crap code
in the distribution and stopping feature development in order to fix all
of it wouldn't actually result in customers beating our door dwn.
No we don't need another slab allocator, but last time I checked
nobody in
Red Hat was writing one either. They are all far too busy working on stuff
that needs doing.
We needed Ubuntu on Sparc64? A functional desktop is something that
needs doing. We can quibble over what's actually required for a
functional desktop (and I'll agree that evolution isn't a shining
example of functionality), but I'm fairly convinced that getting system
alerts to a relevant user in a timely manner is one component of it.
Doing so via mail worked fine when most Unix systems were maintained by
people who understood cron, but that's not current reality.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:43 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 10:33 AM, Alan Cox <alan(a)redhat.com> wrote:
And if we are going to worry about desktop experiences then perhaps making
evolution not totally suck, fixing the way the desktop totally disintegrates
when you run out of disk space, a working gdm again and a few other items
would be far better use of time than macdinking with log delivery.
I agree there are some dire things broken in the desktop. The disk
space one is particularly evil - we should have at least a
notification nowadays (http://cgwalters.livejournal.com/2008/02/09/).
However, startup speed is something that impacts nearly everyone and
is an immediately visible part of the interaction with the computer.
It makes sense to prioritize fixing it.
2:35 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Colin Walters wrote:
On Tue, Oct 21, 2008 at 10:33 AM, Alan Cox <alan(a)redhat.com>
wrote:
> And if we are going to worry about desktop experiences then perhaps making
> evolution not totally suck, fixing the way the desktop totally disintegrates
> when you run out of disk space, a working gdm again and a few other items
> would be far better use of time than macdinking with log delivery.
I agree there are some dire things broken in the desktop. The disk
space one is particularly evil - we should have at least a
notification nowadays (http://cgwalters.livejournal.com/2008/02/09/).
However, startup speed is something that impacts nearly everyone and
is an immediately visible part of the interaction with the computer.
It makes sense to prioritize fixing it.
You can certainly defer the sendmail daemon startup so you don't have to
wait for it - and it doesn't need to run at all if you aren't accepting
inbound messages and nothing is in the queue.
--
Les Mikesell
lesmikesell(a)gmail.com
10:10 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Matthew Garrett wrote:
>> I'm pretty solidly of the opinion that email is nowhere near being the
>> most sensible way to get important information to a typical desktop
>> user. If a failure is important then the user needs to know about it as
>> soon as possible - mail provides no guarantees about timely delivery. We
>> have plenty of desktop infrastructure to give important alerts to users,
>> we're just failing to do so.
> If local delivery of mail fails, there's no reason to think any other
> notification method would have succeeded. The important point is that
> the user may not be present when the event occurs, and that desktop
> infrastructure may not even be running - and even if it is, the
> interested party may want the notification to be forwarded elsewhere.
Local delivery of mail is a poor solution, since it provides no
indication of priority difference between "You've got spam" and "Your
hard drive is failing".
That's a solvable problem within the context of email, whereas starting
from scratch and re-inventing delivery to arbitrary user-selectable
endpoints is somewhat insane.
If there's nobody to present it to, it can be
queued and presented at login - if the user is running on their system
but doesn't have the desktop infrastructure running, then by definition
they're already outside the standard desktop usecase.
Does that mean their system should die with no attempt at notification?
Or that desktop administration should be confusingly different than
standard systems?
I'm not arguing about the utility of an MTA for various
situations. I'm
arguing that for one specific and very common situation, using an MTA to
deliver system alerts is a poor way of handling it. We should fix that.
No, you should fix it so mail delivery is useful.
As a happy side effect, it removes the need for a default MTA in the
desktop install.
Unless, of course, you care to follow standards.
People who want an MTA then get to choose whichever MTA
they want and net human happiness is increased.
That has been the case for some time already. As long as the
alternative presents a command-line compatible /usr/sbin/sendmail,
standard programs will work.
--
Les Mikesell
lesmikesell(a)gmail.com
12:20 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 10:10:37AM -0500, Les Mikesell wrote:
Matthew Garrett wrote:
>Local delivery of mail is a poor solution, since it provides no
>indication of priority difference between "You've got spam" and
"Your
>hard drive is failing".
That's a solvable problem within the context of email, whereas starting
from scratch and re-inventing delivery to arbitrary user-selectable
endpoints is somewhat insane.
I'm sure the anti-spam companies would be delighted to hear it. Yes,
it's a solvable problem - but you're conflating two things, important
system updates and personal email. I think trying to present these two
quite different things in the same way is a bad idea.
>If there's nobody to present it to, it can be
>queued and presented at login - if the user is running on their system
>but doesn't have the desktop infrastructure running, then by definition
>they're already outside the standard desktop usecase.
Does that mean their system should die with no attempt at notification?
Or that desktop administration should be confusingly different than
standard systems?
I'm reasonably sure that I didn't suggest that, no.
>I'm not arguing about the utility of an MTA for various
situations. I'm
>arguing that for one specific and very common situation, using an MTA to
>deliver system alerts is a poor way of handling it. We should fix that.
No, you should fix it so mail delivery is useful.
And then have to modify every single MUA so it automatically flags
high-priority system information. I'm not convinced getting that into
gmail is going to happen.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:33 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Matthew Garrett wrote:
>> Local delivery of mail is a poor solution, since it provides no
>> indication of priority difference between "You've got spam" and
"Your
>> hard drive is failing".
> That's a solvable problem within the context of email, whereas starting
> from scratch and re-inventing delivery to arbitrary user-selectable
> endpoints is somewhat insane.
I'm sure the anti-spam companies would be delighted to hear it. Yes,
it's a solvable problem - but you're conflating two things, important
system updates and personal email. I think trying to present these two
quite different things in the same way is a bad idea.
I think it is a bad idea for you to decide which of those things is more
important to me or anyone else, or where I want them delivered. Just
supply the tools, please, with some convenient default setting so the
system messages are available.
>> If there's nobody to present it to, it can be
>> queued and presented at login - if the user is running on their system
>> but doesn't have the desktop infrastructure running, then by definition
>> they're already outside the standard desktop usecase.
> Does that mean their system should die with no attempt at notification?
> Or that desktop administration should be confusingly different than
> standard systems?
I'm reasonably sure that I didn't suggest that, no.
If you don't use email, you will have to invent something new that will
almost certainly be less capable and less useful.
>> I'm not arguing about the utility of an MTA for various
situations. I'm
>> arguing that for one specific and very common situation, using an MTA to
>> deliver system alerts is a poor way of handling it. We should fix that.
> No, you should fix it so mail delivery is useful.
And then have to modify every single MUA so it automatically flags
high-priority system information. I'm not convinced getting that into
gmail is going to happen.
No, you don't have to modify every MUA. You just have to let people use
the one they have had years to tune to their liking already. And supply
some reasonable default for the one or two users you might pick up that
don't already have a preference or an assortment of accounts already
created for different priority messages.
--
Les Mikesell
lesmikesell(a)gmail.com
2:41 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 3:33 PM, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Matthew Garrett wrote:
>
>>> Local delivery of mail is a poor solution, since it provides no
>>> indication of priority difference between "You've got spam" and
"Your hard
>>> drive is failing".
>>
>> That's a solvable problem within the context of email, whereas starting
>> from scratch and re-inventing delivery to arbitrary user-selectable
>> endpoints is somewhat insane.
>
> I'm sure the anti-spam companies would be delighted to hear it. Yes, it's
> a solvable problem - but you're conflating two things, important system
> updates and personal email. I think trying to present these two quite
> different things in the same way is a bad idea.
I think it is a bad idea for you to decide
Let's be clear - this is a meritocracy, not a vote-by-email-repetition system.
2:53 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Colin Walters wrote:
>>>> Local delivery of mail is a poor solution, since it provides no
>>>> indication of priority difference between "You've got spam"
and "Your hard
>>>> drive is failing".
>>> That's a solvable problem within the context of email, whereas starting
>>> from scratch and re-inventing delivery to arbitrary user-selectable
>>> endpoints is somewhat insane.
>> I'm sure the anti-spam companies would be delighted to hear it. Yes,
it's
>> a solvable problem - but you're conflating two things, important system
>> updates and personal email. I think trying to present these two quite
>> different things in the same way is a bad idea.
> I think it is a bad idea for you to decide
Let's be clear - this is a meritocracy, not a vote-by-email-repetition system.
If you don't permit the 'merit' to be decided by potential users of the
system you are designing a vote-by-feet system.
--
Les Mikesell
lesmikesell(a)gmail.com
6:51 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 02:53:59PM -0500, Les Mikesell wrote:
Colin Walters wrote:
>Let's be clear - this is a meritocracy, not a vote-by-email-repetition
>system.
If you don't permit the 'merit' to be decided by potential users of the
system you are designing a vote-by-feet system.
Nobody's talking about removing MTAs from the repository. Potential
users are always free to decide how their system works.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:29 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, 21 Oct 2008 08:52:27 -0500
Les Mikesell <lesmikesell(a)gmail.com> wrote:
> I'm pretty solidly of the opinion that email is nowhere near
being
> the most sensible way to get important information to a typical
> desktop user. If a failure is important then the user needs to know
> about it as soon as possible - mail provides no guarantees about
> timely delivery. We have plenty of desktop infrastructure to give
> important alerts to users, we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other
notification method would have succeeded.
local mail is rather taxing on a system. If a harddisk is marginal for
example... a mail delivery will cause the entire pagecache to be
written to the disk, and guess what... the MTA will get stuck on that.
And that assumes that the local user even reads "root" email.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
9:40 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 07:29:50AM -0700, Arjan van de Ven wrote:
And that assumes that the local user even reads "root"
email.
This definitely needs to be addressed as part of this discussion. There's
two parts, really:
1) Root mail needs to go somewhere useful.
2) The world needs something better than Logwatch.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
10:02 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Arjan van de Ven wrote:
On Tue, 21 Oct 2008 08:52:27 -0500
Les Mikesell <lesmikesell(a)gmail.com> wrote:
>> I'm pretty solidly of the opinion that email is nowhere near being
>> the most sensible way to get important information to a typical
>> desktop user. If a failure is important then the user needs to know
>> about it as soon as possible - mail provides no guarantees about
>> timely delivery. We have plenty of desktop infrastructure to give
>> important alerts to users, we're just failing to do so.
> If local delivery of mail fails, there's no reason to think any other
> notification method would have succeeded.
local mail is rather taxing on a system.
Which is why mail is a sensible delivery mechanism. It already knows
how to deliver elsewhere if you want.
If a harddisk is marginal for
example... a mail delivery will cause the entire pagecache to be
written to the disk, and guess what... the MTA will get stuck on that.
Which is why it is important to get the warning messages from smartctl
and the disk space check _before_ you are toast. Face it - nothing is
going to save you after the disk fries or is completely out of space.
And that assumes that the local user even reads "root"
email.
That's the piece that needs to be fixed.
--
Les Mikesell
lesmikesell(a)gmail.com
10:16 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Les Mikesell (lesmikesell(a)gmail.com) said:
Which is why mail is a sensible delivery mechanism. It already knows
how to deliver elsewhere if you want.
With built-in mechanisms to allow for easy spoofing of critical events
to the user from anyone on the internet, no less!
This is outside of the issue that any such critical notification delivered
via e-mail makes it nigh-impossible to safely and sanely undertake
specific actions on user input acting on the notice.
Should the information be sent via e-mail to an adminstrator, and
stored for later viewing in general? Yes. Does that mean e-mail is
the best mechanism for presenting it? No.
Bill
10:37 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Bill Nottingham wrote:
Les Mikesell (lesmikesell(a)gmail.com) said:
> Which is why mail is a sensible delivery mechanism. It already knows
> how to deliver elsewhere if you want.
With built-in mechanisms to allow for easy spoofing of critical events
to the user from anyone on the internet, no less!
I'm surprised you are able to do that with fedora's default mail
configuration that only accepts from localhost... Perhaps you should
let us in on the secret.
This is outside of the issue that any such critical notification
delivered
via e-mail makes it nigh-impossible to safely and sanely undertake
specific actions on user input acting on the notice.
What? If there was a specific way to fix the problem you should just do
it without bothering a user.
Should the information be sent via e-mail to an adminstrator, and
stored for later viewing in general? Yes. Does that mean e-mail is
the best mechanism for presenting it? No.
If you have a bad email mechanism, fix that problem.
--
Les Mikesell
lesmikesell(a)gmail.com
10:44 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Les Mikesell (lesmikesell(a)gmail.com) said:
Bill Nottingham wrote:
> Les Mikesell (lesmikesell(a)gmail.com) said:
>> Which is why mail is a sensible delivery mechanism. It already knows
>> how to deliver elsewhere if you want.
>
> With built-in mechanisms to allow for easy spoofing of critical events
> to the user from anyone on the internet, no less!
I'm surprised you are able to do that with fedora's default mail
configuration that only accepts from localhost... Perhaps you should
let us in on the secret.
????
We're talking about arbitrary mail delivery. It could be forwarded
to any e-mail account, anywhere. (After all, that's what you're asking
for with redirection of root e-mail.) Ergo, anyone with knowledge of
1) your e-mail address 2) your machine could send you a spoof/phishing/etc.
> Should the information be sent via e-mail to an adminstrator,
and
> stored for later viewing in general? Yes. Does that mean e-mail is
> the best mechanism for presenting it? No.
If you have a bad email mechanism, fix that problem.
I think attempting to have all cron/alert/whatever mail gpg-signed
with a host-specific key would be waaaaaaaaaaaay overkill.
Bill
12:09 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Bill Nottingham wrote:
>>> Which is why mail is a sensible delivery mechanism. It
already knows
>>> how to deliver elsewhere if you want.
>> With built-in mechanisms to allow for easy spoofing of critical events
>> to the user from anyone on the internet, no less!
> I'm surprised you are able to do that with fedora's default mail
> configuration that only accepts from localhost... Perhaps you should
> let us in on the secret.
????
We're talking about arbitrary mail delivery. It could be forwarded
to any e-mail account, anywhere. (After all, that's what you're asking
for with redirection of root e-mail.) Ergo, anyone with knowledge of
1) your e-mail address 2) your machine could send you a spoof/phishing/etc.
But that's true whether or not you use it yourself. And it is
relatively difficult to spoof the originating host IP since it is
recorded by the receiving server.
>> Should the information be sent via e-mail to an adminstrator,
and
>> stored for later viewing in general? Yes. Does that mean e-mail is
>> the best mechanism for presenting it? No.
> If you have a bad email mechanism, fix that problem.
I think attempting to have all cron/alert/whatever mail gpg-signed
with a host-specific key would be waaaaaaaaaaaay overkill.
The value of unix-like systems is that they provide the user with a
standard toolbox to be used in an appropriate way for any situation.
Good working defaults are just a plus - the tools, and the fact that
they follow standards, are the critical part.
--
Les Mikesell
lesmikesell(a)gmail.com
12:16 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 11:44:01AM -0400, Bill Nottingham wrote:
I think attempting to have all cron/alert/whatever mail gpg-signed
with a host-specific key would be waaaaaaaaaaaay overkill.
Although relatively easily-accomplished overkill. :)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
9:27 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 02:20:03PM +0100, Matthew Garrett wrote:
I'm pretty solidly of the opinion that email is nowhere near
being the
most sensible way to get important information to a typical desktop
user. If a failure is important then the user needs to know about it as
soon as possible - mail provides no guarantees about timely delivery. We
have plenty of desktop infrastructure to give important alerts to users,
we're just failing to do so.
Important does not always mean urgent, and there are a lot of cases
when the person in front of the keyboard, if any, is not the one
interested in the information.
Another way to say it is "stop thinking in Microsoft Windows terms".
OG.
1:51 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, 2008-10-20 at 13:23 -0500, Les Mikesell wrote:
And maybe if a bazillion ssh login attempts have failed.
No. SSH scanning is commonplace nowadays. All my exposed machines are
constantly pounded on by rumplestiltskin bots. Alerting on this would
equate to "Congratulations, you are using the internet!" every 5
minutes...
9:14 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, Oct 19, 2008 at 7:47 PM, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Sun, 2008-10-19 at 15:32 -0400, Colin Walters wrote:
> But it doesn't make
> sense for the default desktop OS to be sending you email about all the
> junk going on under the hood.
I understand where you are coming from but I have to say the above
statement is, imo, fundamentally wrong.
I am in mixed boat about this... trying to go through 100+ logwatches
every day is a headache as it is :). But knowing that there is a
failed cron job on some desktop because the rootkit was b0rked is
valuable... but I am not the average user.
So the first question that comes to mind.. is if the user doesn't know
that the email is being generated.. does it matter it exists? And what
environments are we dealing with?
1) Home use. Does Grandma want to know about logwatch or noisy cron
jobs? Does she even know that there is email in the root user mailbox
since she shouldn't ever log into it?
2) Small scale environment. (2-30 systems).
3) Medium environment (30-100) systems.
4) Large environment 100-1000 systems
5) Ginormouse 1000+ systems.
Each has its use case. When you get to the large to ginormous ones..
you really need to work on the tools for centralized logging, with
agents and things to track usage.
The small to medium are the ones which are probably the ones that need
more work. The Small one might have someone who knows to look at the
root mail spool but most of the time its going to be someone who has
his worn "Linux for Dummies" book from the last person who set up the
lab.
Email only makes sense for this person if
a) its easy to setup.
b) it gives useful information.
c) and they know what to do with it.
It really doesn't matter if a box has postfix, exim, ssmtp, smail, etc
if the email is just stuck on the local machine and the user has no
idea where it is, how to get it, or what it does. And in that case,
does generating the email in the first place help anything? If this
were some new service versus one that we system administrators have
been raised to think as a god-given right.. and we were looking at
adding it to the desktop environment would we? [I am talking about the
default state where email stays local, and the local user probably has
no idea its there.]
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
2:42 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, 19 Oct 2008 21:26:24 +0200
Karel Zak <kzak(a)redhat.com> wrote:
On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
> Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> default choice is ignoring the reality...
(+1)
Good point, but don't forget that Fedora is pretty ambivalent
distribution. It's a "desktop distribution" where some people want to
disable non-X console and other people use postfix, port packages to
s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a
base for Red Hat Enterprise distribution :-)
I'm all in favor having any and all of those as options.
Really.
For the people who want to run a mail server, they absolutely should.
But those already have to significantly customize their OS already.
Installing a MTA of their choice as part of that is no big deal,
and probably entirely expected by those who really want to run a mail
server.
But I stand by: The default: none of the above.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
3:54 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, Oct 19, 2008 at 12:42:17PM -0700, Arjan van de Ven wrote:
On Sun, 19 Oct 2008 21:26:24 +0200
Karel Zak <kzak(a)redhat.com> wrote:
> On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
> > Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> > default choice is ignoring the reality...
>
> (+1)
>
> Good point, but don't forget that Fedora is pretty ambivalent
> distribution. It's a "desktop distribution" where some people want
to
> disable non-X console and other people use postfix, port packages to
> s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a
> base for Red Hat Enterprise distribution :-)
I'm all in favor having any and all of those as options.
Really.
For the people who want to run a mail server, they absolutely should.
But those already have to significantly customize their OS already.
Installing a MTA of their choice as part of that is no big deal,
and probably entirely expected by those who really want to run a mail
server.
But I stand by: The default: none of the above.
I agree. Definitely. (I use esmtp(1) for years).
Karel
--
Karel Zak <kzak(a)redhat.com>
8:48 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
There's two types of people using fedora:
1) People who don't run a mail server
I think you meant to add _incoming_ in there, having mail that's
generated on the local machine go somewhere _reliably_ is a basic
feature required by all users.
For 1), all three are wrong. Really. All you really need is some
minimalist commandline compatible thing that just forwards to some
smart host (or maybe does only local delivery).
Or both, and the forwarding has to work when the network is down.
SSMTP or similar is
perfectly fine for this, while not taxing memory or boot time.
Yeh, right. SSMTP doesn't have a spool, so anything sending email when
the network is down gets their email silently deleted. hell, SSMTP
doesn't even support aliases.
Look, feel free to have the default be postfix; configured to sendmail
locally and/or remotely ... with no daemon and thus. no inbound
processing. SSMTP is just worthless for most users, hell having nothing
at all would be better (but be ready for every package that needs to
send email to point out not having an smtp sender installed by default
is retarded).
For 2) these folks have a VERY specific personal preference.
Not true.
This
entire discussion proves that.
Right, when almost everyone is saying change to postfix and one or two
people are saying "what's so wrong with sendmail" ... that must mean we
should do nothing *sigh*.
--
James Antill <james(a)fedoraproject.org>
Fedora
11:06 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Sun, 19 Oct 2008 21:48:13 -0400
James Antill <james(a)fedoraproject.org> wrote:
On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
> Forget about Sendmail. Or Exim. Or Postfix as default install.
>
> Really.
>
> There's two types of people using fedora:
> 1) People who don't run a mail server
I think you meant to add _incoming_ in there, having mail that's
generated on the local machine go somewhere _reliably_ is a basic
feature required by all users.
most users on the client side use a mail client that has its own
queuing.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
11:26 p.m.
New subject: None of the Above (was Re: Sendmail still default?)
Once upon a time, Arjan van de Ven <arjan(a)infradead.org> said:
most users on the client side use a mail client that has its own
queuing.
Most _interactive_ users do. Most automated tasks (e.g. cron) do not
have any queueing.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:03 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Chris Adams wrote:
Once upon a time, Arjan van de Ven <arjan(a)infradead.org> said:
> most users on the client side use a mail client that has its own
> queuing.
Most _interactive_ users do. Most automated tasks (e.g. cron) do not
have any queueing.
Even if you are trying to dumb the system down to a Mac's
pseudo-single-user style, you still need crontab and mail to work - as
it does on a Mac.
--
Les Mikesell
lesmikesell(a)gmail.com
10:34 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Les Mikesell wrote:
Chris Adams wrote:
> Once upon a time, Arjan van de Ven <arjan(a)infradead.org> said:
>> most users on the client side use a mail client that has its own
>> queuing.
>
> Most _interactive_ users do. Most automated tasks (e.g. cron) do not
> have any queueing.
Even if you are trying to dumb the system down to a Mac's
pseudo-single-user style, you still need crontab and mail to work - as
it does on a Mac.
What happens to emails generated on a Max OSX via crontab or any other
automated system? Does it run sendmail or some equivalent of it?
Just curious how they solve it as on a Mac i'd bet you that hardly any
typical user will know what root is.
Regards, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Team Lead Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com>
Hauptstaetterstr. 58 | Web: http://www.redhat.com/
D-70178 Stuttgart, Germany | IT executives: Red Hat #1 in value. Again.
| http://www.redhat.com/promo/vendor/
11:19 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, 2008-10-20 at 17:34 +0200, Phil Knirsch wrote:
Les Mikesell wrote:
> Chris Adams wrote:
>> Once upon a time, Arjan van de Ven <arjan(a)infradead.org> said:
>>> most users on the client side use a mail client that has its own
>>> queuing.
>>
>> Most _interactive_ users do. Most automated tasks (e.g. cron) do not
>> have any queueing.
>
> Even if you are trying to dumb the system down to a Mac's
> pseudo-single-user style, you still need crontab and mail to work - as
> it does on a Mac.
>
What happens to emails generated on a Max OSX via crontab or any other
automated system?
No clue about the MACs, but what about "mailx"?
It is mandated by POSIX and should be sufficient for local mail
delivery.
Ralf
11:28 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Ralf Corsepius <rc040203(a)freenet.de> wrote:
On Mon, 2008-10-20 at 17:34 +0200, Phil Knirsch wrote:
[...]
> What happens to emails generated on a Max OSX via crontab or any
other
> automated system?
No clue about the MACs, but what about "mailx"?
It is mandated by POSIX and should be sufficient for local mail
delivery.
Its manpage here doesn't mention local delivery, just caching and
disconnected operation for IMAP.
[Local delivery is normally handled by a separate program in any case,
today typically procmail]
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
9:01 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Phil Knirsch wrote:
Les Mikesell wrote:
> Chris Adams wrote:
>> Once upon a time, Arjan van de Ven <arjan(a)infradead.org> said:
>>> most users on the client side use a mail client that has its own
>>> queuing.
>>
>> Most _interactive_ users do. Most automated tasks (e.g. cron) do not
>> have any queueing.
>
> Even if you are trying to dumb the system down to a Mac's
> pseudo-single-user style, you still need crontab and mail to work - as
> it does on a Mac.
>
What happens to emails generated on a Max OSX via crontab or any other
automated system? Does it run sendmail or some equivalent of it?
10.5 runs postfix.
Just curious how they solve it as on a Mac i'd bet you that
hardly any
typical user will know what root is.
I don't think anything in the default install sends mail, but if as a
user you use 'crontab -e' to create a crontab entry, the output is
delivered to /var/mail/yourlogin and the command line mail and mailx
programs know where to find it as expected on any unix-like system.
Or you can set MAILTO= in the crontab if you want it elsewhere.
Following standards is a good thing...
--
Les Mikesell
lesmikesell(a)gmail.com
3:51 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Le Lun 20 octobre 2008 03:48, James Antill a écrit :
On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
> Forget about Sendmail. Or Exim. Or Postfix as default install.
>
> Really.
>
> There's two types of people using fedora:
> 1) People who don't run a mail server
I think you meant to add _incoming_ in there, having mail that's
generated on the local machine go somewhere _reliably_ is a basic
feature required by all users.
Also filtering mail on MUA startup is just trainwreak recipe.
If you want your MUA to start fast you need to pre-filter junk mail in
the background (no not everyone uses gmail and gmail is not perfect
anyway).
So far, I haven't seen anything beating fetchmail + local MTA +
server-side filters + local imap or local maildir delivery in Fedora.
--
Nicolas Mailhot
3:05 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
Also filtering mail on MUA startup is just trainwreak recipe.
If you want your MUA to start fast you need to pre-filter junk mail in
the background (no not everyone uses gmail and gmail is not perfect
anyway).
So far, I haven't seen anything beating fetchmail + local MTA +
server-side filters + local imap or local maildir delivery in Fedora.
But if you're using fetchmail, it's too late to filter -- because you
should be rejecting the stuff you don't want at SMTP time.
Filtering wants to be done on the _real_ mail server that accepts
incoming mail. Doing it after fetchmail is almost as bad as doing it in
the MUA.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
5:39 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Le Mar 21 octobre 2008 10:05, David Woodhouse a écrit :
On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
>
> Also filtering mail on MUA startup is just trainwreak recipe.
> If you want your MUA to start fast you need to pre-filter junk mail
> in
> the background (no not everyone uses gmail and gmail is not perfect
> anyway).
>
> So far, I haven't seen anything beating fetchmail + local MTA +
> server-side filters + local imap or local maildir delivery in
> Fedora.
But if you're using fetchmail, it's too late to filter -- because you
should be rejecting the stuff you don't want at SMTP time.
Filtering wants to be done on the _real_ mail server that accepts
incoming mail.
Sure but many people do not have an ISP that provides clueful
filtering, and even gmail is not so yummy when you take the privacy
and no warranty bits into account.
Doing it after fetchmail is almost as bad as doing it
in the MUA.
It's not. It means that when you start your MUA, everything is already
available and filtered, instead for waiting for (10s or more) seconds
with a massive CPU pike. That makes a huge user experience difference.
--
Nicolas Mailhot
8:11 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Nicolas Mailhot wrote:
>> Also filtering mail on MUA startup is just trainwreak recipe.
>> If you want your MUA to start fast you need to pre-filter junk mail
>> in
>> the background (no not everyone uses gmail and gmail is not perfect
>> anyway).
>>
>> So far, I haven't seen anything beating fetchmail + local MTA +
>> server-side filters + local imap or local maildir delivery in
>> Fedora.
> But if you're using fetchmail, it's too late to filter -- because you
> should be rejecting the stuff you don't want at SMTP time.
>
> Filtering wants to be done on the _real_ mail server that accepts
> incoming mail.
Sure but many people do not have an ISP that provides clueful
filtering, and even gmail is not so yummy when you take the privacy
and no warranty bits into account.
> Doing it after fetchmail is almost as bad as doing it
> in the MUA.
It's not. It means that when you start your MUA, everything is already
available and filtered, instead for waiting for (10s or more) seconds
with a massive CPU pike. That makes a huge user experience difference.
The problems are that you don't have a reasonable choice about what to
do with questionable items at that point and the mail has already been
accepted from the sender, establishing that you are a valid target if it
really is spam, probably getting it put on widely sold lists. If your
filter generates a bounce it will probably go to a forged address and
contribute to the problem. On the other hand if you don't generate a
bounce and your filter is mistaken, you lose legitimate messages - or
you have to save them in a folder that you manually check. If you can
scan during the smtp conversation with the sender you can just reject at
that point making it someone else's problem.
--
Les Mikesell
lesmikesell(a)gmail.com
5:50 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
What about this (maybe silly) idea:
The default desktop installation is not providing a mta like sendmail,
postfix or exim. A tiny local program is using syslog to collect local
emails in a file in /var/log in mailbox format. This way emails e.g.
from cron or mdadm are not lost and a local email reader could be used
to read the emails. Additionally logrotate would help to keep the amount
of emails at an acceptable level. SELinux shouldn't be a problem for
this solution.
A symlink to /var/spool/mail would be nice, but I think that SELinux
does not like this at all.
If a user needs fetchmail or a real mta, he has to install sendmail,
postfix or exim. fetchmail could have a requirement for MTA.
What do you think?
Ciao,
Thomas
David Woodhouse wrote:
On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
> Also filtering mail on MUA startup is just trainwreak recipe.
> If you want your MUA to start fast you need to pre-filter junk mail in
> the background (no not everyone uses gmail and gmail is not perfect
> anyway).
>
> So far, I haven't seen anything beating fetchmail + local MTA +
> server-side filters + local imap or local maildir delivery in Fedora.
But if you're using fetchmail, it's too late to filter -- because you
should be rejecting the stuff you don't want at SMTP time.
Filtering wants to be done on the _real_ mail server that accepts
incoming mail. Doing it after fetchmail is almost as bad as doing it in
the MUA.
--
Thomas Woerner
Software Engineer Phone: +49-711-96437-310
Red Hat GmbH Fax : +49-711-96437-111
Hauptstaetterstr. 58 Email: Thomas Woerner <twoerner(a)redhat.com>
D-70178 Stuttgart Web : http://www.redhat.de/
7:13 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
On Tue, Oct 21, 2008 at 12:50:48PM +0200, Thomas Woerner wrote:
What about this (maybe silly) idea:
The default desktop installation is not providing a mta like sendmail,
postfix or exim. A tiny local program is using syslog to collect local
emails in a file in /var/log in mailbox format. This way emails e.g.
from cron or mdadm are not lost and a local email reader could be used
to read the emails. Additionally logrotate would help to keep the amount
of emails at an acceptable level. SELinux shouldn't be a problem for
this solution.
Your tiny local program is not going to stay tiny long. Feature creep
(multiple log files, routing, filtering, locking...) is going to make
it equivalent to a mail delivery agent. So just use one.
OG.
3:47 a.m.
New subject: None of the Above (was Re: Sendmail still default?)
Le Dim 19 octobre 2008 20:37, Arjan van de Ven a écrit :
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
default choice is ignoring the reality...
Fedora is about advancing the state of free software right?
And free software does not limit itself to the desktop.
Or I don't see why all the fuss about wikipedia switching side is.
--
Nicolas Mailhot
1:48 p.m.
On Sun, 2008-10-19 at 13:04 -0500, Les Mikesell wrote:
David Woodhouse wrote:
> On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
>> Which means that you can't run your choice of tests on a message during
>> the smtp conversation before you accept it - at least without starting a
>> new process for each one which is expensive for large programs like
>> spamassassin.
>
> As is often the case, it seems, you are entirely incorrect.
One of my choices of tests on an inbound relay machine has been to check
that the user exists using an smtp check against the internal delivery
host. How would I do that on an MTA that does not handle milters?
require verify = recipient/callout=20s,use_sender
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
8:50 a.m.
Les Mikesell <lesmikesell(a)gmail.com> writes:
One of my choices of tests on an inbound relay machine has been to
check that the user exists using an smtp check against the internal
delivery host. How would I do that on an MTA that does not handle
milters?
Milters are bad for rcpt verification (at least in sendmail) because they
happen before alias/virtusertable expansion. Custom 'Local_check_rcpt'
rules plus tables like
| Kdom0_lookup hash -o /etc/mail/dom0-users
| Kdom1_lookup socket inet:480@mail-filter
are better and easier to implement.
Enrico
10:31 a.m.
Enrico Scholz wrote:
Les Mikesell <lesmikesell(a)gmail.com> writes:
> One of my choices of tests on an inbound relay machine has been to
> check that the user exists using an smtp check against the internal
> delivery host. How would I do that on an MTA that does not handle
> milters?
Milters are bad for rcpt verification (at least in sendmail) because they
happen before alias/virtusertable expansion. Custom 'Local_check_rcpt'
rules plus tables like
In my case, this happens on external relays that have neither aliases
nor users of its own. The idea is to make sure the internal target
would accept the address as a user or alias without having to update the
external relay's virtuser database every time an internal user or alias
changes.
--
Les Mikesell
lesmikesell(a)gmail.com
3:44 a.m.
Le Dim 19 octobre 2008 16:47, Les Mikesell a écrit :
David Woodhouse wrote:
> On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
>>> Milter is supported by alternatives too
>> They pretend to, but won't actually run complex milters like
>> MimeDefang.
>
> Some of the better alternatives don't even _try_ to run milters,
> because
> they are fully-featured enough in their own right, without needing
> to
> rely on external software.
Which means that you can't run your choice of tests on a message
during
the smtp conversation before you accept it - at least without starting
a
new process for each one which is expensive for large programs like
spamassassin.
Actually, you don't need milters to do this in postfix (but you can
use milters if you prefer)
--
Nicolas Mailhot
7:50 a.m.
Nicolas Mailhot wrote:
Le Dim 19 octobre 2008 16:47, Les Mikesell a écrit :
> David Woodhouse wrote:
>> On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
>>>> Milter is supported by alternatives too
>>> They pretend to, but won't actually run complex milters like
>>> MimeDefang.
>> Some of the better alternatives don't even _try_ to run milters,
>> because
>> they are fully-featured enough in their own right, without needing
>> to
>> rely on external software.
> Which means that you can't run your choice of tests on a message
> during
> the smtp conversation before you accept it - at least without starting
> a
> new process for each one which is expensive for large programs like
> spamassassin.
Actually, you don't need milters to do this in postfix (but you can
use milters if you prefer)
If you do it without milters, can you get the efficiency factor that
MimeDefang manages by unpacking the mime parts only once even if you do
multiple scans for spam and viruses? Can it multiplex a small number of
milter backends doing 'slow' steps with a much larger number of mailers
doing fast operations? (MimeDefang may be the only milter designed for
that).
--
Les Mikesell
lesmikesell(a)gmail.com
8:28 a.m.
On Fri, Oct 17, 2008 at 4:18 PM, Denis Leroy <denis(a)poolshark.org> wrote:
Les Mikesell wrote:
> It can be configured to do just about anything.
>
The sendmail configuration file is arguably one of the most complex and
obfuscated configuration format ever designed in the history of computer
science. :-)
-denis
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
....so why not try exim4 for a change?
8:28 a.m.
Alan Cox wrote:
On Fri, Oct 17, 2008 at 03:18:52PM +0200, Denis Leroy wrote:
> The sendmail configuration file is arguably one of the most complex and
> obfuscated configuration format ever designed in the history of computer
> science. :-)
You've clearly never worked with either IBM JCL or TECO
=3.4.2;;;;;;;;;;;;;;;;;;;;;;
-- bk
8:56 a.m.
Denis Leroy wrote:
Les Mikesell wrote:
> It can be configured to do just about anything.
The sendmail configuration file is arguably one of the most complex and
obfuscated configuration format ever designed in the history of computer
science. :-)
Yes, it was designed back in the days of wooden computers and iron
programmers - with a prime concern being the runtime processing needed
to interpret the configuration. But these days all of the m4 templates
anyone might ever need have already been written, so everyone just
uncomments or tweaks a few lines in sendmail.mc for options and the
default already does the right thing for most people. Or, for complex
scenarios you can drop in MimeDefang as a milter and do most of the
control steps with perl snippets.
--
Les Mikesell
lesmikesell(a)gmail.com
3:58 p.m.
On Fri, Oct 17, 2008 at 7:31 AM, Lutz Lange <llange(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
i've just wondered why sendmail is still the default MTA in Fedora.
Please enlighten me?
A note - the desktop spin would like to have no MTA by default for
F11. We'll likely change the way cron is handled so that if you have
per-user cron jobs an MTA is installed.
What MTA the server images use is up to whoever owns server stuff (I
like Postfix too personally).
7:06 p.m.
Colin Walters wrote:
A note - the desktop spin would like to have no MTA by default for
F11. We'll likely change the way cron is handled so that if you have
per-user cron jobs an MTA is installed.
What happens to root's cron jobs (e.g. logwatch)? Do they just go to
/dev/null, or do you have some cool new log monitor?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
When on POSIX, do as POSIX mandates.
7:12 p.m.
On Fri, Oct 17, 2008 at 8:06 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
Colin Walters wrote:
>
> A note - the desktop spin would like to have no MTA by default for
> F11. We'll likely change the way cron is handled so that if you have
> per-user cron jobs an MTA is installed.
What happens to root's cron jobs (e.g. logwatch)? Do they just go to
/dev/null, or do you have some cool new log monitor?
/dev/null by default. In the longer term what I would like to see is
*some* of this kind of thing integrated with:
http://fedoraproject.org/wiki/Features/CrashHandling
But most logs from a desktop machine are just pure noise.
7:17 p.m.
Colin Walters wrote:
On Fri, Oct 17, 2008 at 8:06 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> Colin Walters wrote:
>> A note - the desktop spin would like to have no MTA by default for
>> F11. We'll likely change the way cron is handled so that if you have
>> per-user cron jobs an MTA is installed.
> What happens to root's cron jobs (e.g. logwatch)? Do they just go to
> /dev/null, or do you have some cool new log monitor?
/dev/null by default. In the longer term what I would like to see is
*some* of this kind of thing integrated with:
http://fedoraproject.org/wiki/Features/CrashHandling
But most logs from a desktop machine are just pure noise.
Yes and no. I'd prefer to see some sort of event viewer that would do
logwatch, but with much more terse, consolidated output (and by default
throw out all but the last N days' entries).
Even on desktops, I'd like to watch who's logging in, but it's such a
pain to do right now...
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
When on POSIX, do as POSIX mandates.
7:26 p.m.
Matthew Woehlke wrote:
Yes and no. I'd prefer to see some sort of event viewer that would do
logwatch, but with much more terse, consolidated output (and by default
throw out all but the last N days' entries).
Even on desktops, I'd like to watch who's logging in, but it's such a
pain to do right now...
gnome-system-log (gnome-utils) might help. KDE has a log viewer as well.
Might consider working on it to do what you want it to do otherwise.
Rahul
7:07 p.m.
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in
Fedora.
Please enlighten me?
Some people (/me waves) were concerned about the element of surprise
when someone configures a new system, throws some (user) cron jobs on
it, and expects local mail delivery to Just Work.
I also suggested that setting up what happens to cron's mail in
anaconda/firstboot would be an adequate solution. However it was too
late to do this for F10.
What I'd be interested in for F11 is a screen during install that
requires you to either provide a valid e-mail address recipient for
root's mail and the default user's mail (with, I suppose, any other mail
going to whatever is set up for root), or else explicitly requesting a
local-mail capable MTA.
Um... which is actually another reason for local mail being default; in
the event a user's mail recipient is not configured, it goes to a local
spool only readable by root and that user. If Sue sets up a computer and
adds an account for Bob, it's not really ideal if Bob's mail gets sent
to sue(a)mydomain.com because Bob doesn't have a recipient specified.
True, Sue probably has root access and could read Bob's mail if she
wanted, but you've gone the extra step to tossing Bob's mail in Sue's
inbox without warning.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
When on POSIX, do as POSIX mandates.
9:54 a.m.
On Fri, 2008-10-17 at 19:07 -0500, Matthew Woehlke wrote:
Lutz Lange wrote:
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?
Some people (/me waves) were concerned about the element of surprise
when someone configures a new system, throws some (user) cron jobs on
it, and expects local mail delivery to Just Work.
sendmail isn't the only mta in fedora that just works out of the box. I
know postfix does and I believe exim does as well.
-sv
12:03 p.m.
seth vidal wrote:
On Fri, 2008-10-17 at 19:07 -0500, Matthew Woehlke wrote:
> Lutz Lange wrote:
>> i've just wondered why sendmail is still the default MTA in Fedora.
>> Please enlighten me?
> Some people (/me waves) were concerned about the element of surprise
> when someone configures a new system, throws some (user) cron jobs on
> it, and expects local mail delivery to Just Work.
>
sendmail isn't the only mta in fedora that just works out of the box. I
know postfix does and I believe exim does as well.
And did anyone have an actual problem with sendmail other than noticing
it taking time to start the daemon in the boot sequence. That's a
problem that can be solved on its own since you don't really need a
daemon then.
Removing mail from the expected services is just the wrong thing to do,
especially if the reasoning is that the service isn't understood or used
to advantage. Add a setup for a root alias in firstboot and a mail
notifier in the gnome panel to make the system more useful instead of less.
--
Les Mikesell
lesmikesell(a)gmail.com
12:30 p.m.
Le samedi 18 octobre 2008 à 12:03 -0500, Les Mikesell a écrit :
And did anyone have an actual problem with sendmail other than
noticing
it taking time to start the daemon in the boot sequence.
I think each one of us who've replaced sendmail with something else has
(despite years of RH/Fedora trying force sendmail through our throats).
Even back when postfix was just a powertools option people knew sendmail
was a poor default.
As an engineer who likes neat technical stuff and contributes to Fedora
because it tends to produce neat technical stuff it makes me cringe each
time I'm reminded we ship sendmail instead of something properly
designed for an untrusted TCP/IP network world.
You may extend years of hole-fixing and patch a sieve enough it sort of
floats but it's still a poor excuse of a boat. Even if passengers only
see the "it floats" bit.
--
Nicolas Mailhot
1:34 p.m.
Nicolas Mailhot wrote:
Le samedi 18 octobre 2008 à 12:03 -0500, Les Mikesell a écrit :
> And did anyone have an actual problem with sendmail other than noticing
> it taking time to start the daemon in the boot sequence.
I think each one of us who've replaced sendmail with something else has
(despite years of RH/Fedora trying force sendmail through our throats).
Even back when postfix was just a powertools option people knew sendmail
was a poor default.
Sendmail was a poor default back when it always ran everything as root
and accepted and delivered in the same process. Maybe you didn't notice
that has changed or the enforced separation of the queuing and delivery
steps.
As an engineer who likes neat technical stuff and contributes to
Fedora
because it tends to produce neat technical stuff it makes me cringe each
time I'm reminded we ship sendmail instead of something properly
designed for an untrusted TCP/IP network world.
Ummm, when was the last time you saw a network exploit for sendmail? As
I recall, postfix has also had some local exploits and probably more
recently than sendmail.
You may extend years of hole-fixing and patch a sieve enough it sort
of
floats but it's still a poor excuse of a boat. Even if passengers only
see the "it floats" bit.
You seem to have missed the sea change. And the capabilities added by
the milter interface that it took the other contenders many years to
duplicate properly.
--
Les Mikesell
lesmikesell(a)gmail.com
3:06 p.m.
Le samedi 18 octobre 2008 à 13:34 -0500, Les Mikesell a écrit :
You seem to have missed the sea change.
I didn't notice the "sea change" changing anything about sendmail's
terrible monolithic architecture.
And again, upstream seems more convinced than you are about current
sendmail's irremediable faults.
--
Nicolas Mailhot
3:44 p.m.
Nicolas Mailhot wrote:
Le samedi 18 octobre 2008 à 13:34 -0500, Les Mikesell a écrit :
> You seem to have missed the sea change.
I didn't notice the "sea change" changing anything about sendmail's
terrible monolithic architecture.
How are separate processes receiving to a queue, processing the queue,
delivering locally, with any number of concurrent milters all running
under potentially different non-root id's except for the operations that
require it, monolithic?
And again, upstream seems more convinced than you are about current
sendmail's irremediable faults.
The remedy was done years ago.
--
Les Mikesell
lesmikesell(a)gmail.com
10:58 p.m.
On Sat, 2008-10-18 at 13:34 -0500, Les Mikesell wrote:
Sendmail was a poor default back when it always ran everything as
root
and accepted and delivered in the same process. Maybe you didn't notice
that has changed or the enforced separation of the queuing and delivery
steps.
There is a significant difference between dropping privileges from one
giant piece of code, and having exec boundaries that do separate tasks.
Without arguing the more nuanced differences, one obvious and simple
(and beneficial) difference is that SELinux can easily confine into
separate domains on exec boundaries. Which is why everything is lumped
into one sendmail_t, while postfix has a number of separate domains.
> As an engineer who likes neat technical stuff and contributes to
Fedora
> because it tends to produce neat technical stuff it makes me cringe each
> time I'm reminded we ship sendmail instead of something properly
> designed for an untrusted TCP/IP network world.
Ummm, when was the last time you saw a network exploit for sendmail?
There has been at least one remote buffer overflow in sendmail since
postfix went 1.0.
> You may extend years of hole-fixing and patch a sieve enough it
sort of
> floats but it's still a poor excuse of a boat. Even if passengers only
> see the "it floats" bit.
You seem to have missed the sea change.
Probably, because most of us were already using something better before
sendmail decided to do the minimum of fixes to it's code base.
And the capabilities added by
the milter interface that it took the other contenders many years to
duplicate properly.
Yes, sendmail has always had "more features" in that it was the first
MTA to have a turing complete language embedded within it (and an awful
one at that).
But other MTAs have had the features everyone needs for a long time
now, and postfix has been a better default for more than long enough for
us to change it.
I'd also like to say that personally I still use exim, and I'm likely
to continue to do so ... but I'm more than happy to see postfix as the
default, because it's probably a better default than exim and an
obviously better one than the current default.
--
James Antill <james.antill(a)redhat.com>
Red Hat
3:34 p.m.
On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
And did anyone have an actual problem with sendmail other than
noticing
it taking time to start the daemon in the boot sequence. That's a
problem that can be solved on its own since you don't really need a
daemon then.
Removing mail from the expected services is just the wrong thing to do,
especially if the reasoning is that the service isn't understood or used
to advantage. Add a setup for a root alias in firstboot and a mail
notifier in the gnome panel to make the system more useful instead of less.
I never said anything about removing mail. I only said that making
postfix the default doesn't mean losing functionality.
Personally, I'm in favor of changing it just to see what shakes out that
we've forgotten or missed.
-sv
3:50 p.m.
seth vidal wrote:
On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
> And did anyone have an actual problem with sendmail other than noticing
> it taking time to start the daemon in the boot sequence. That's a
> problem that can be solved on its own since you don't really need a
> daemon then.
>
> Removing mail from the expected services is just the wrong thing to do,
> especially if the reasoning is that the service isn't understood or used
> to advantage. Add a setup for a root alias in firstboot and a mail
> notifier in the gnome panel to make the system more useful instead of less.
>
I never said anything about removing mail. I only said that making
postfix the default doesn't mean losing functionality.
It would have been earlier, but if in fact the current version is
capable of running MimeDefang as a milter maybe they are finally equivalent.
--
Les Mikesell
lesmikesell(a)gmail.com
3:57 p.m.
On Sat, 2008-10-18 at 15:50 -0500, Les Mikesell wrote:
seth vidal wrote:
> On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
>
>> And did anyone have an actual problem with sendmail other than noticing
>> it taking time to start the daemon in the boot sequence. That's a
>> problem that can be solved on its own since you don't really need a
>> daemon then.
>>
>> Removing mail from the expected services is just the wrong thing to do,
>> especially if the reasoning is that the service isn't understood or used
>> to advantage. Add a setup for a root alias in firstboot and a mail
>> notifier in the gnome panel to make the system more useful instead of less.
>>
>
> I never said anything about removing mail. I only said that making
> postfix the default doesn't mean losing functionality.
It would have been earlier, but if in fact the current version is
capable of running MimeDefang as a milter maybe they are finally equivalent.
for a couple of years now:
http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
-sv
4:13 p.m.
seth vidal wrote:
>>> And did anyone have an actual problem with sendmail other than noticing
>>> it taking time to start the daemon in the boot sequence. That's a
>>> problem that can be solved on its own since you don't really need a
>>> daemon then.
>>>
>>> Removing mail from the expected services is just the wrong thing to do,
>>> especially if the reasoning is that the service isn't understood or used
>>> to advantage. Add a setup for a root alias in firstboot and a mail
>>> notifier in the gnome panel to make the system more useful instead of less.
>>>
>> I never said anything about removing mail. I only said that making
>> postfix the default doesn't mean losing functionality.
> It would have been earlier, but if in fact the current version is
> capable of running MimeDefang as a milter maybe they are finally equivalent.
>
for a couple of years now:
http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
Supporting the milter interface and actually running existing milters
that expect sendmail on the other side are two different things. For
example, milters may need to know if the connection is authenticated or
using SSL. If you are going to claim sendmail compatibility or be a
functional replacement you have to provide the same information, the
same way whether it was described in the interface documentation or not.
Postfix pre-2.4 didn't. It looks like it does now, but I still don't
remember any mentions of people actually using it on the MimeDefang
list.
And in any case, using MimeDefang as a sendmail milter eliminates most
of the complaints anyone would have with sendmail itself since it lets
you do the complex parts with control handled in perl instead of
sendmail's internal language.
--
Les Mikesell
lesmikesell(a)gmail.com
10:37 p.m.
On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
seth vidal wrote:
> for a couple of years now:
>
> http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
>
Supporting the milter interface and actually running existing milters
that expect sendmail on the other side are two different things. For
example, milters may need to know if the connection is authenticated or
using SSL. If you are going to claim sendmail compatibility or be a
functional replacement you have to provide the same information, the
same way whether it was described in the interface documentation or not.
Postfix pre-2.4 didn't. It looks like it does now, but I still don't
remember any mentions of people actually using it on the MimeDefang
list.
So? We aren't talking about auto migrating people's existing sendmail
deployments, which would require a higher level of compatibility.
We are just talking about changing the default, to one which the
majority of users are likely to prefer (I appreciate that you have a
different preference, but even you must realize you are in a minority).
And in any case, using MimeDefang as a sendmail milter eliminates
most
of the complaints anyone would have with sendmail itself since it lets
you do the complex parts with control handled in perl instead of
sendmail's internal language.
Again, that would be your opinion ... and it is different to mine.
--
James Antill <james(a)fedoraproject.org>
Fedora
5:15 p.m.
On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
And in any case, using MimeDefang as a sendmail milter eliminates
most
of the complaints anyone would have with sendmail itself since it lets
you do the complex parts with control handled in perl instead of
sendmail's internal language.
Man, if you imply perl is anything better, no wonders you defend
sendmail :-)
SCNR.
8:08 a.m.
Simo Sorce wrote:
On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
> And in any case, using MimeDefang as a sendmail milter eliminates most
> of the complaints anyone would have with sendmail itself since it lets
> you do the complex parts with control handled in perl instead of
> sendmail's internal language.
Man, if you imply perl is anything better, no wonders you defend
sendmail :-)
Perl has done a lot of work for me (and lots of others) over the last
couple of decades, while most of the languages that claim to be better
haven't been able to work consistently from one year to the next, making
you rewrite everything because they can't pick a syntax that works.
Perl has only had one real syntax change from version 1 though 5, when
it started interpolating @ in double-quoted strings.
--
Les Mikesell
lesmikesell(a)gmail.com
2:18 a.m.
On Sat October 18 2008, Matthew Woehlke wrote:
[E-mail was changed]
Um... which is actually another reason for local mail being default;
in
the event a user's mail recipient is not configured, it goes to a local
spool only readable by root and that user. If Sue sets up a computer and
adds an account for Bob, it's not really ideal if Bob's mail gets sent
to sue(a)EXAMPLE.com because Bob doesn't have a recipient specified.
Sending log file contents that may contain sensitive data via unencrypted
e-mail is not a good thing to do imho.
Please do not quote my e-mail address unobfuscated in message bodies.
I guess the owner of your used mydomain.com e-mail has this wish, too. Unless
it is one of your e-mail addresses, you should better use @example.com e-mail
addresses. The example.com domain is there, to be used if you need an example
domain.
Regards,
Till
8:11 a.m.
Till Maas wrote:
On Sat October 18 2008, Matthew Woehlke wrote:
[E-mail was changed]
> Um... which is actually another reason for local mail being default; in
> the event a user's mail recipient is not configured, it goes to a local
> spool only readable by root and that user. If Sue sets up a computer and
> adds an account for Bob, it's not really ideal if Bob's mail gets sent
> to sue(a)EXAMPLE.com because Bob doesn't have a recipient specified.
Sending log file contents that may contain sensitive data via unencrypted
e-mail is not a good thing to do imho.
Modern MTA's can encrypt transmission if configured to.
--
Les Mikesell
lesmikesell(a)gmail.com
5:59 a.m.
On Mon October 20 2008, Les Mikesell wrote:
Till Maas wrote:
> On Sat October 18 2008, Matthew Woehlke wrote:
> [E-mail was changed]
>
>> Um... which is actually another reason for local mail being default; in
>> the event a user's mail recipient is not configured, it goes to a local
>> spool only readable by root and that user. If Sue sets up a computer and
>> adds an account for Bob, it's not really ideal if Bob's mail gets sent
>> to sue(a)EXAMPLE.com because Bob doesn't have a recipient specified.
>
> Sending log file contents that may contain sensitive data via unencrypted
> e-mail is not a good thing to do imho.
Modern MTA's can encrypt transmission if configured to.
Yes, this is possible, but how does this help a non technical user that does
not know how to this? Also only the encryption of the e-mail itself and
decrypting on a trusted machine really protects the sensitive data. This is
probably to complicated for the targeted user, so it would be a lot easier to
keep the data on the local machine.
Regards,
Till
6:43 a.m.
On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
Yes, this is possible, but how does this help a non technical user
that does not know how to this?
Our Exim package should be using TLS by default on all outgoing
connections (to mail servers which support it). And supporting TLS on
incoming connections too.
If there are any _other_ ways it can be improved to help the users who
are technical enough to want it, but not particularly familiar with it,
then please file RFE bugs. We already ship sample config snippets for
decent greylisting, spamassassin, clamav, etc.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
7:27 a.m.
On Tue October 21 2008, David Woodhouse wrote:
On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
> Yes, this is possible, but how does this help a non technical user
> that does not know how to this?
Our Exim package should be using TLS by default on all outgoing
connections (to mail servers which support it). And supporting TLS on
incoming connections too.
If there are any _other_ ways it can be improved to help the users who
are technical enough to want it, but not particularly familiar with it,
then please file RFE bugs. We already ship sample config snippets for
decent greylisting, spamassassin, clamav, etc.
I do not know, because I use gpg for encryption. And this was also not what
this sub thread initially was about. It was about adding an option to the
installer that may make unexperienced users send sensitive data via untrusted
or unencrypted paths.
Regards,
Till
7:38 a.m.
On Tue October 21 2008, David Woodhouse wrote:
If there are any _other_ ways it can be improved to help the users
who
are technical enough to want it, but not particularly familiar with it,
then please file RFE bugs. We already ship sample config snippets for
decent greylisting, spamassassin, clamav, etc.
Uh, I should have thought faster while writing my previous mail, here is my
RFE to make it easier to gpg encode mails:
https://bugzilla.redhat.com/show_bug.cgi?id=467867
Thanks & regards,
Till
8:02 a.m.
David Woodhouse wrote:
On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
> Yes, this is possible, but how does this help a non technical user
> that does not know how to this?
Our Exim package should be using TLS by default on all outgoing
connections (to mail servers which support it). And supporting TLS on
incoming connections too.
Sendmail should do that too.
If there are any _other_ ways it can be improved to help the users
who
are technical enough to want it, but not particularly familiar with it,
then please file RFE bugs. We already ship sample config snippets for
decent greylisting, spamassassin, clamav, etc.
Including a MimeDefang package configured to do the same for sendmail
would be good.
--
Les Mikesell
lesmikesell(a)gmail.com
2:46 p.m.
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in
Fedora.
Please enlighten me?
Changing defaults only makes sense if we're going to get rid of the
current default or we're going to put a lot of work into the
alternative. Sendmail isn't about to disappear, and we don't do a lot
of distro-specific work on MTAs, so there's little point to changing.
If you prefer a different MTA, use it.
-- Chris
5726
days inactive
5731
days old
123 comments
37 participants
participants (37)
-
Alan Cox -
Arjan van de Ven -
Bill Nottingham -
Bryan Kearney -
Callum Lerwick -
Chris Adams -
Chris Snook -
Colin Walters -
David Woodhouse -
Denis Leroy -
Dominik 'Rathann' Mierzejewski -
Enrico Scholz -
Genes MailLists -
Horst H. von Brand -
James Antill -
James Antill -
Karel Zak -
Les Mikesell -
Leszek Matok -
Lutz Lange -
Matthew Garrett -
Matthew Miller -
Matthew Woehlke -
Michael H. Warfield -
Nicolas Mailhot -
Olivier Galibert -
Patrice Dumas -
Phil Knirsch -
Rahul Sundaram -
Ralf Corsepius -
Rares Aioanei -
Seth Vidal -
shmuel siegel -
Simo Sorce -
Stephen John Smoogen -
Thomas Woerner -
Till Maas