Re: default MTA
It might help if we used a bit more precision in terimonolgy. Not a full blown MTA as described here is a Mail Submission Agent (MSA). See RFC 5598 for details: OpenSMTPD has quite recently been released for production and is rather good and worth adding to the review list. http://opensmtpd.org/ -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/405396.90524...@smtp120.mail.ir2.yahoo.com
Re: default MTA
Le 17/06/2013 06:12, Bob Proulx a écrit : David Weinehall wrote: Bjørn Mork wrote: The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. I'm having a hard time understanding this particular gripe. If you're running a non-desktop system (by this I take it to mean that you're not using a GUI), why would you worry about GNOME's dependencies anyhow? Here is an example: The emacs24-nox package, a typical headless server package for many of us, depends upon dbus. Feature creep. Putting emacs (which I use as my primary editor) and feature creep in the same sentence is quite funny: You are at a dead end of a dirt road. The road goes to the east. In the distance you can see that it will eventually fork off. The trees here are very tall royal palms, and they are spaced equidistant from each other. There is a shovel here. Please remarke that there is libasound2 in there, too. I can see why notifications (and not desktop notifications) are useful on a headless server. Much less for sound. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: default MTA
On 15/06/13 13:04, David Weinehall wrote: On Thu, May 30, 2013 at 12:15:03PM +0200, Bjørn Mork wrote: The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. I'm having a hard time understanding this particular gripe. If you're running a non-desktop system (by this I take it to mean that you're not using a GUI), why would you worry about GNOME's dependencies anyhow? If you're using a desktop system it doesn't feel like a stretch to use functionality that fits in with the desktop system. And vice versa, obviously. This concern could be put another way: that if the mailer is not present, developers will no longer assume it is present and will choose other dependencies (maybe just syslog or maybe a GUI) as a way of raising alerts I prefer to look at it the other way though: how can we make mail integration so effective that developers will want to use it for everything and it works more seamlessly with or without a GUI? I agree that mail works, but in a default deployment, it does little to prioritize or de-duplicate alerts from applications and the OS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bdbc98.5040...@pocock.com.au
Re: default MTA
David Weinehall wrote: Bjørn Mork wrote: The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. I'm having a hard time understanding this particular gripe. If you're running a non-desktop system (by this I take it to mean that you're not using a GUI), why would you worry about GNOME's dependencies anyhow? Here is an example: The emacs24-nox package, a typical headless server package for many of us, depends upon dbus. Feature creep. Bob signature.asc Description: Digital signature
Re: default MTA
On 31/05/13 08:41, Jean-Christophe Dubacq wrote: A utility to scan syslog and convey important information to the user would be much more useful than configuring all mailers in Debian to read root's local mail by default. I know how to redirect root's mail elsewhere, thank you for not making another mail account to check. This utility already exists on Debian: is called logcheck. Unfortunately (from your point of view) it requires that the user is able to configure the mailer. So maybe instead of trying to reinvent the wheel [1] we could fix the current one, and make sure that the default configuration of the mailer ensures that local mails are read by root or by the default system user. [1] http://tr.im/44jc8 signature.asc Description: OpenPGP digital signature
Re: default MTA
On Fri, 14 Jun 2013 21:49:59 -0400, Chris Knadle chris.kna...@coredump.us wrote: On Friday, June 14, 2013 02:31:45, Marc Haber wrote: On Thu, 13 Jun 2013 16:42:15 -0400, Chris Knadle chris.kna...@coredump.us wrote: So right now I think that I probably just didn't know that this had been fixed, because I haven't been using the split file configuration for along time. I clearly remember having _upgrade_ problems in 2003 with Exim on Debian Testing, but I might be confusing the root cause of those problems at that time; there are occasional required configuration changes, and that's another possible cause. I should explain the above a bit further; when using the split file configuration and choosing N to certain config file updates, that leaves behind several .dpkg-dist config files. And if you choose Y, .dpkg-old config files are left. That's basic dpkg functionality, and it has always been the case that files that don't match the [-a-z0-9] rule are ignored. .dpkg-foo files have a period and get ignored. See run-parts(8) Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1unk3x-0001da...@swivel.zugschlus.de
Re: default MTA
On 30/05/13 12:15, Bjørn Mork wrote: Ben Hutchings b...@decadent.org.uk writes: On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote: On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : Take for example, smartmoontools [1]. Currently, if an end-user installs smartmoontools and a hard-disk fails (i.e. smartd detects a problem with one HD) he will *not* see any notification: the failure is sent through local e-mail. He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c (The code is different but already here in squeeze and wheezy.) What you propose requires: * adding desktop environment specific code to every facility that may need to send notifications * adding such notifications to every other desktop environment Wrong, we already have org.freedesktop.Notifications in GNOME, KDE and Xfce. So those two points become: * adding cross-desktop code to every facility that may need to send notifications * adding a notification daemon to task-lxde There are libraries to help with the first point, of course. Wouldn't a daemon watching /var/mail/root and turning any mail into desktop notifications solve most of this, while still allowing the same notifications to reach a sysadmin on non-desktop systems? I really think this is the way to go: By default install some application on the debian-desktop tasksel that displays on the desktop unread mails sent to root. Installing logcheck by default also would be nice. The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. This issue is easily solved by ensuring that programs sending notifications do it by mail to root@localhost and not to some fancy new dbus thing. signature.asc Description: OpenPGP digital signature
Re: default MTA
On Thu, May 30, 2013 at 12:15:03PM +0200, Bjørn Mork wrote: The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. I'm having a hard time understanding this particular gripe. If you're running a non-desktop system (by this I take it to mean that you're not using a GUI), why would you worry about GNOME's dependencies anyhow? If you're using a desktop system it doesn't feel like a stretch to use functionality that fits in with the desktop system. And vice versa, obviously. Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130615110439.gc26...@hirohito.acc.umu.se
Re: default MTA
On Thu, 13 Jun 2013 16:42:15 -0400, Chris Knadle chris.kna...@coredump.us wrote: So right now I think that I probably just didn't know that this had been fixed, because I haven't been using the split file configuration for along time. I clearly remember having _upgrade_ problems in 2003 with Exim on Debian Testing, but I might be confusing the root cause of those problems at that time; there are occasional required configuration changes, and that's another possible cause. In 2003 the exim4 packages were in a kind of steady flux, everything was new back than. The old exim 3 packages worked totally different. I fully understand that exim4 2003 might have had serious and bad bugs, but I think that most of them have been ironed out by now. That doesn't mean that I am not going to break exim during the jessie release cycle, but Andreas is there to fix it ;-) Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1unny1-0002ot...@swivel.zugschlus.de
Re: default MTA
On 06/13/2013 04:03 AM, Jakub Wilk wrote: * Daniel Pocock dan...@pocock.com.au, 2013-06-12, 21:41: #4: Our priorities are our users and free software In any Debian discussion, given enough time, someone inevitably mentions SC§4. Once this occurs, the thread is over, and the person who mentioned it has automatically lost the argument. I agree. SC§4 is the godwin of Debian. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bb2d50.7010...@debian.org
Re: default MTA
On Friday, June 14, 2013 02:31:45, Marc Haber wrote: On Thu, 13 Jun 2013 16:42:15 -0400, Chris Knadle chris.kna...@coredump.us wrote: So right now I think that I probably just didn't know that this had been fixed, because I haven't been using the split file configuration for along time. I clearly remember having _upgrade_ problems in 2003 with Exim on Debian Testing, but I might be confusing the root cause of those problems at that time; there are occasional required configuration changes, and that's another possible cause. I should explain the above a bit further; when using the split file configuration and choosing N to certain config file updates, that leaves behind several .dpkg-dist config files. If the upgrade goes badly because of required configuration changes, the first thing that catches one's eye are the .dpkg-dist files, making it _seem_ as though they could have been the root cause, even if they're not. ;-) In 2003 the exim4 packages were in a kind of steady flux, everything was new back than. The old exim 3 packages worked totally different. I fully understand that exim4 2003 might have had serious and bad bugs, but I think that most of them have been ironed out by now. Yes I ran Exim3 for a while also, so I know what you mean. With Exim4 I think it was the in flux part that got me at the time concerning upgrades, which was exaserbated by my running Testing on the server. That doesn't mean that I am not going to break exim during the jessie release cycle, but Andreas is there to fix it ;-) If that happens, it's fixable. ;-) -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306142149.59458.chris.kna...@coredump.us
Re: default MTA
On Wed, 2013-06-12 at 23:50 -0400, Chris Knadle wrote: One snag I ran into concerning the abstraction layer concerned customizing the split file configuration via conf.d/ files. Upon upgrades dpkg recongizes the changes in configuration files and prompts the user; choosing not to replace the file with the maintain'er sversion drops a new .dpkg-dist file next to the modified one, which is expected. However what's _not_ expected is to use both the customized configuration file as well as the .dpkg-dist one. :-/ Unfortunately in my experience, that's what happens. And in this condition Exim may fail to start, or might start and then reject mail with a temporary failure. I therefore consider the split configuration to be dangerous. I had another look at this: it appears that in /usr/sbin/update-exim4.conf, the cat_parts() function doesn't avoid files containing .dpkg-, but this funtionality might be able to be added to the run_parts() function that cat_parts() uses. This sounds quite obviously like a bug to me, did you report it? I've just tried this on Wheezy and stuff written in in /etc/exim4/conf.d/acl/00-test.dpkg-dist didn't get included: $ sudo update-exim4.conf --verbose using split configuration scheme from /etc/exim4/conf.d internal run-parts: ignoring file: /etc/exim4/conf.d/acl/00-test.dpkg-dist So it seems it has already been fixed. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371107831.25232.17.ca...@dagon.hellion.org.uk
Re: default MTA
On Sb, 08 iun 13, 14:11:33, Andrei POPESCU wrote: If there are no objections within a few days I would like to make some major changes to that page as follows: * the only options left under debate are: - exim (status quo) - postfix - dma - no MTA at all - (did I miss or forget something?) * popularity is irrelevant (the default MTA will always be much more popular) the entire section will be removed * advanced use cases are irrelevant, since the admin of such a system will install what she needs anyway, regardless of the default Instead of doing that I followed Stefano's suggestion to have each position in its own subpage and simply added links to these sub-pages (not created yet): http://wiki.debian.org/Debate/DefaultMTA/Exim http://wiki.debian.org/Debate/DefaultMTA/Postfix http://wiki.debian.org/Debate/DefaultMTA/DMA http://wiki.debian.org/Debate/DefaultMTA/NoMTA I might be working on either DMA or NoMTA (or both) myself, but people supporting the Exim and Postfix options should probably write these. The old content is still there, but it should probably be moved to the corresponding sub-page (if still relevant) or just deleted. Most of it seams to deal with installs that are meant to handle real mail and it is my impression that this use case is not relevant for this debate; admins can simply apt-get their preferred MTA. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: default MTA
On Thu, 13 Jun 2013 08:17:11 +0100, Ian Campbell i...@hellion.org.uk
wrote:
I've just tried this on Wheezy and stuff written in
in /etc/exim4/conf.d/acl/00-test.dpkg-dist didn't get included:
$ sudo update-exim4.conf --verbose
using split configuration scheme from /etc/exim4/conf.d
internal run-parts: ignoring file:
/etc/exim4/conf.d/acl/00-test.dpkg-dist
So it seems it has already been fixed.
Before 2003, yes.
I checked out an early version of update-exim4.conf and found this
code:
|for F in $(ls $1); do
|if expr $F : '[[:alnum:]_-]\+$' /dev/null 21; then
|if [ -f $1/$F ] [ ! -f $1/${F}.disabled ] ; then
|echo $1/$F
|fi
|fi
|done;
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1un4xw-0006dn...@swivel.zugschlus.de
Re: default MTA
On Wed, Jun 12, 2013 at 09:41:27PM +0200, Daniel Pocock wrote: DFSG #4: Our priorities are our users and free software A court prosecuting/persecuting one of our users is not in scope I'm now struggling to understand which side of the argument you are arguing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130613105956.GB3956@debian
Re: default MTA
On Thursday, June 13, 2013 06:41:16, Marc Haber wrote: On Thu, 13 Jun 2013 08:17:11 +0100, Ian Campbell i...@hellion.org.uk wrote: I've just tried this on Wheezy and stuff written in in /etc/exim4/conf.d/acl/00-test.dpkg-dist didn't get included: $ sudo update-exim4.conf --verbose using split configuration scheme from /etc/exim4/conf.d internal run-parts: ignoring file: /etc/exim4/conf.d/acl/00-test.dpkg-dist So it seems it has already been fixed. Yes, I just did some testing myself and also find that it had been fixed. I don't recall reporting a bug at the time -- when I last used the split configuration I think it was back before I was reporting bugs. I think my first bug report was in early 2005. Before 2003, yes. I remember still running into trouble with this in mid-2003 on Debian Testing. However the exact timeframe of the fix doesn't matter much -- what matters is that it's fixed. ;-) -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306130725.35335.chris.kna...@coredump.us
Re: default MTA
On 13/06/13 12:59, Jonathan Dowland wrote: On Wed, Jun 12, 2013 at 09:41:27PM +0200, Daniel Pocock wrote: DFSG #4: Our priorities are our users and free software A court prosecuting/persecuting one of our users is not in scope I'm now struggling to understand which side of the argument you are arguing. Just that the user can make their own choice about whether they want to enable or disable privacy features and we shouldn't worry about the side-effects of those user decisions It is my preference to make such features more easily accessible or available by default, just like hashed passwords and other things that are generally considered healthy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b9b483.3040...@pocock.com.au
Re: default MTA
On Thu, 13 Jun 2013 07:25:34 -0400, Chris Knadle chris.kna...@coredump.us wrote: On Thursday, June 13, 2013 06:41:16, Marc Haber wrote: On Thu, 13 Jun 2013 08:17:11 +0100, Ian Campbell i...@hellion.org.uk wrote: I've just tried this on Wheezy and stuff written in in /etc/exim4/conf.d/acl/00-test.dpkg-dist didn't get included: $ sudo update-exim4.conf --verbose using split configuration scheme from /etc/exim4/conf.d internal run-parts: ignoring file: /etc/exim4/conf.d/acl/00-test.dpkg-dist So it seems it has already been fixed. Yes, I just did some testing myself and also find that it had been fixed. I don't recall reporting a bug at the time -- when I last used the split configuration I think it was back before I was reporting bugs. I think my first bug report was in early 2005. Before 2003, yes. I remember still running into trouble with this in mid-2003 on Debian Testing. If there was a bug in 2005, there still is. The code cited above is in place since 2003. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1un6re-00075h...@swivel.zugschlus.de
Re: default MTA
On Thursday, June 13, 2013 08:16:02, Marc Haber wrote: On Thu, 13 Jun 2013 07:25:34 -0400, Chris Knadle chris.kna...@coredump.us wrote: On Thursday, June 13, 2013 06:41:16, Marc Haber wrote: On Thu, 13 Jun 2013 08:17:11 +0100, Ian Campbell i...@hellion.org.uk wrote: I've just tried this on Wheezy and stuff written in in /etc/exim4/conf.d/acl/00-test.dpkg-dist didn't get included: $ sudo update-exim4.conf --verbose using split configuration scheme from /etc/exim4/conf.d internal run-parts: ignoring file: /etc/exim4/conf.d/acl/00-test.dpkg-dist So it seems it has already been fixed. Yes, I just did some testing myself and also find that it had been fixed. I don't recall reporting a bug at the time -- when I last used the split configuration I think it was back before I was reporting bugs. I think my first bug report was in early 2005. Before 2003, yes. I remember still running into trouble with this in mid-2003 on Debian Testing. If there was a bug in 2005, there still is. The code cited above is in place since 2003. The testing I did this morning was copying a default Wheezy VM and reconfiguring Exim to use a split file config, and verifying that the contents of an added /etc/exim4/conf.d/main/04_exim-config_testing.dpkg-dist file doesn't get included in the generated configuration in /var/lib/exim4/config.autogenerated. So right now I think that I probably just didn't know that this had been fixed, because I haven't been using the split file configuration for along time. I clearly remember having _upgrade_ problems in 2003 with Exim on Debian Testing, but I might be confusing the root cause of those problems at that time; there are occasional required configuration changes, and that's another possible cause. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306131642.15126.chris.kna...@coredump.us
Re: default MTA
On 11-06-13 18:37, Jonathan Dowland wrote: On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: Sendmail has just one more layer of indirection by virtue of the m4 macros. Postfix has most of its behavior hard coded in the C sources, while exim's behavior can be controlled by run-time configuration if an advanced user wants to do things that Debian's abstraction layer was not designed to handle. There are a class of users between beginner and exim expert for which the current state of affairs is not optimal. I don't know how big that class is but I've been in it for ten years. To this exim expert, configuring exim is done as follows: zcat /usr/share/doc/exim4/examples/example.conf.gz /etc/exim4/exim4.conf $EDITOR /etc/exim4/exim4.conf the comments in that file are pretty self-explanatory, and the example configuration is a good default in that it is a functional one for local mail (possibly received through SMTP) while not being an open relay. (this is not meant as criticism for the exim4-config stuff. I understand and agree there's a need for this kind of thing for people who don't need a lot of complex stuff; it just doesn't work for me, that's all) -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b80e71.6050...@debian.org
Re: default MTA
On 12/06/13 00:02, Jeremy Stanley wrote: On 2013-06-11 23:50:01 +0200 (+0200), Daniel Pocock wrote: Something that doesn't have these limitations: http://tools.ietf.org/html/rfc2487#section-7 [...] That basically just makes the case for relying on (E)SMTP only for transporting messages, but leveraging OpenPGP or S/MIME to provide authentication and confidentiality where required (or for anonymity, Mixmaster et al). OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't really) encrypt the headers/envelope That is the type of `metadata' that allows a hostile party to start building a social graph of who knows who. Even if they can't see the contents of the communications, those social graphs are undesirable and an ideal solution would prevent that. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b81051.8060...@pocock.com.au
Re: default MTA
On Wed, Jun 12, 2013 at 08:08:17AM +0200, Daniel Pocock wrote: On 12/06/13 00:02, Jeremy Stanley wrote: On 2013-06-11 23:50:01 +0200 (+0200), Daniel Pocock wrote: Something that doesn't have these limitations: http://tools.ietf.org/html/rfc2487#section-7 [...] That basically just makes the case for relying on (E)SMTP only for transporting messages, but leveraging OpenPGP or S/MIME to provide authentication and confidentiality where required (or for anonymity, Mixmaster et al). OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't really) encrypt the headers/envelope That is the type of `metadata' that allows a hostile party to start building a social graph of who knows who. Even if they can't see the contents of the communications, those social graphs are undesirable and an ideal solution would prevent that. Can I just check - have we really gone from a (far too long, IMO) discussion on what default MTA we provide, to replacing SMTP? Just so I know if it's worth killfiling the entire thread. Neil -- signature.asc Description: Digital signature
Re: default MTA
On Wed, Jun 12, 2013 at 08:00:17AM +0200, Wouter Verhelst wrote: To this exim expert, configuring exim is done as follows: zcat /usr/share/doc/exim4/examples/example.conf.gz /etc/exim4/exim4.conf Absolutely. At some point in the last few years I was recommended this course of action by a friend in the Debian community and it has greatly improved my experiences. I got the impression that this is quite commonly done. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612123828.GA24063@debian
Re: default MTA
On Tue, Jun 11, 2013 at 11:05:24PM +0200, Bernhard R. Link wrote: The only class of users I can imagine the current situation not optional is someone being used to postfix[1]. Well, that's not me… When I remember learning exim I found it quite nice that the config is quite self-explaining what it is actually doing. The exim config — once I started to actually use it — is indeed, very comfortable to understand and manipulate, in my experience to. The point I'm making is the current arrangement gets in the way of doing that. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612123928.GB24063@debian
Re: default MTA
On Wed, Jun 12, 2013 at 08:08:17AM +0200, Daniel Pocock wrote: OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't really) encrypt the headers/envelope Erm, they also identify the recipients, as it's the recipients key to which the messages are encrypted. (and typically the sender is listed as a recipient for convenience). That is the type of `metadata' that allows a hostile party to start building a social graph of who knows who. Even if they can't see the contents of the communications, those social graphs are undesirable and an ideal solution would prevent that. Indeed, there are court cases where this has been key. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612124123.GC24063@debian
Re: default MTA
On Tue, Jun 11, 2013 at 11:50:01PM +0200, Daniel Pocock wrote: Something that doesn't have these limitations: http://tools.ietf.org/html/rfc2487#section-7 This is also relevant (not just for Postfix): http://www.postfix.org/TLS_README.html#client_tls_encrypt Despite the potential for eliminating passive eavesdropping attacks, mandatory TLS encryption is not viable as a default security level for mail delivery to the public Internet. Most MX hosts do not support TLS at all, and some of those that do have broken implementations. On a host that delivers mail to the Internet, you should not configure mandatory TLS encryption as the default security level. So you want DANE. That's the only reasonable way for mandatory TLS encryption; too bad, server support is pretty bad currently. Other TLS schemes provide at most opportunist encryption: all it takes for an attacker is to redirect a connection elsewhere. With DANE, you can securely tell whether your recipient supports encryption or not, and obtain the TLS certificate. Of course, this is for values of securely that trust ICANN, but at least this is strictly better than the CA cartel. And if we shipped (tz style) keys of individual TLDs, even ICANN could be avoided. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612134354.ga29...@angband.pl
Re: default MTA
On Wed, 12 Jun 2013 13:39:28 +0100, Jonathan Dowland j...@debian.org wrote: On Tue, Jun 11, 2013 at 11:05:24PM +0200, Bernhard R. Link wrote: When I remember learning exim I found it quite nice that the config is quite self-explaining what it is actually doing. The exim config — once I started to actually use it — is indeed, very comfortable to understand and manipulate, in my experience to. The point I'm making is the current arrangement gets in the way of doing that. It is not. The contrary is true. Btw, we go to lengths to make our configuration resemble upstream's default configuration as closely as possible. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ummv6-0007ls...@swivel.zugschlus.de
Re: default MTA
On Wed, 12 Jun 2013 13:38:28 +0100, Jonathan Dowland j...@debian.org wrote: On Wed, Jun 12, 2013 at 08:00:17AM +0200, Wouter Verhelst wrote: To this exim expert, configuring exim is done as follows: zcat /usr/share/doc/exim4/examples/example.conf.gz /etc/exim4/exim4.conf Absolutely. At some point in the last few years I was recommended this course of action by a friend in the Debian community and it has greatly improved my experiences. I got the impression that this is quite commonly done. It is common with people who prefer to configure exim in the traditional way. This is perfectly OK if you know what you're doing. I violently object to people recommending this to novices. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ummwb-00089j...@swivel.zugschlus.de
Re: default MTA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/06/13 12:29, Neil McGovern wrote: On Wed, Jun 12, 2013 at 08:08:17AM +0200, Daniel Pocock wrote: On 12/06/13 00:02, Jeremy Stanley wrote: On 2013-06-11 23:50:01 +0200 (+0200), Daniel Pocock wrote: Something that doesn't have these limitations: http://tools.ietf.org/html/rfc2487#section-7 [...] That basically just makes the case for relying on (E)SMTP only for transporting messages, but leveraging OpenPGP or S/MIME to provide authentication and confidentiality where required (or for anonymity, Mixmaster et al). OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't really) encrypt the headers/envelope That is the type of `metadata' that allows a hostile party to start building a social graph of who knows who. Even if they can't see the contents of the communications, those social graphs are undesirable and an ideal solution would prevent that. Can I just check - have we really gone from a (far too long, IMO) discussion on what default MTA we provide, to replacing SMTP? Not quite, but SMTP encryption (and alternatives) are a relevant factor for many mail server users Whether it is relevant enough to the choice of default MTA is another question, but for me it is relevant, because if encryption/privacy is not there by default, then it is harder to get critical mass for (name your solution) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRuK9oAAoJEOm1uwJp1aqDjUEP/0abkqtXdAgQyyBDr3dAYVEK GdKyNM/tRClVW7f6vxEYc6cClqhMHnP1LVXbZzPRkdnXXl88N0tY0Vl8M0wLCttC qIVG5m4Nna7tIQSfcjgNlJbUR7/2jfvLKC6ofonOTsDZMHtSQI902giOOUno8+/U JznCdDpjTmylgHPFhRR8E+6LZgrGPzmzmmQJ+Zs8FZmK3JbdDRpoct/iQiVBvzfT +jnsOpqZXZBAh3wvE4tK8XcX2Bxgc/MJtm65oTd1QRq7zzUqFoOhANfSMgcKuIe5 xF5OahMlnnMSDYWEqmr7urE5zk4vS551+eXMAPyB09DBqDAssE96uPyGse8zgnD4 /od6+ry+5b0YebHJYaKLxRw5kduFczjkdyCWqIoFWtvw0T7SKMmir8i6T986/PEJ SyqVvY+hKU6udfjCbhvVVWbYuFPFn/bG1cr09efC3z2tnRcS1gLDRFd0RWbmbvuZ ieAqK+5vCKCnJvQwjuy3uN/ZJKnNBC1gavwbcSL2tC5nN9lUI5m6Hv9tQomjHtZi 0OGcT7ff3LkIQi9vPTp6sgJaydiKwi80BA99R50LGAtGOWVspu/XUDmQ4gVq9V5B De92pQ2t041neNtReK/JMAjb7ZwYgibee40S+v4Di7ACPYjskc3Gj2xu5sSxip8H 5czvvEtRIm15lfUQuvi2 =N1IS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b8af69.5050...@pocock.com.au
[OT] SMTP bad (was: default MTA)
On 2013-06-12 08:08:17 +0200 (+0200), Daniel Pocock wrote:
On 12/06/13 00:02, Jeremy Stanley wrote:
That basically just makes the case for relying on (E)SMTP only for
transporting messages, but leveraging OpenPGP or S/MIME to provide
authentication and confidentiality where required (or for anonymity,
Mixmaster et al).
OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't
really) encrypt the headers/envelope
[...]
Apologies if that message made it past the sarcasm filter, but I was
being flippant. As for anonymity, that's why I mentioned a type II
remailer... you can use Mixmaster without nyms as long as you don't
care about the recipient being able to respond to you. And if you
do, well that's pseudonymity not anonymity. (Though I really think
you meant confidentiality when you wrote anonymity there?)
The situation with SMTP is not so dire as you paint it, you simply
need to implement your own cryptography on top of it and be aware of
the characteristics it provides (for example put your real subject
in the message body if using OpenPGP, onion-routing/remailers if you
don't want an eavesdropper to know who you're talking to, et
cetera). Hop-by-hop opportunistic encryption on the honor system
does little more than give a false sense of security, but mailadmins
hopefully already know this long before they contemplate twisting
the shiny STARTTLS knob for remote deliveries?
In short, encrypted SMTP is there to protect your login credentials
when connecting directly to a known smarthost, and if you're doing
it right you're using proper certificate validation (at least TOFU
anyway). Any use beyond that is either misguided fantasy or a sales
pitch for the PKI (CA/TTP) cartels. As long as you accept the nature
of SMTP and use it in the ways it's intended, it's a perfectly fine
protocol which has withstood several decades of pounding while its
detractors have never managed to successfully replace it with
something better.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130612193519.gd1...@yuggoth.org
Re: default MTA
On 12/06/13 14:41, Jonathan Dowland wrote: On Wed, Jun 12, 2013 at 08:08:17AM +0200, Daniel Pocock wrote: OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't really) encrypt the headers/envelope Erm, they also identify the recipients, as it's the recipients key to which the messages are encrypted. (and typically the sender is listed as a recipient for convenience). That is the type of `metadata' that allows a hostile party to start building a social graph of who knows who. Even if they can't see the contents of the communications, those social graphs are undesirable and an ideal solution would prevent that. Indeed, there are court cases where this has been key. DFSG #4: Our priorities are our users and free software A court prosecuting/persecuting one of our users is not in scope -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b8cee7.7090...@pocock.com.au
Re: default MTA
On 12-06-13 16:59, Marc Haber wrote: On Wed, 12 Jun 2013 13:38:28 +0100, Jonathan Dowland j...@debian.org wrote: On Wed, Jun 12, 2013 at 08:00:17AM +0200, Wouter Verhelst wrote: To this exim expert, configuring exim is done as follows: zcat /usr/share/doc/exim4/examples/example.conf.gz /etc/exim4/exim4.conf [...] I violently object to people recommending this to novices. Yes, me too. It only works for me because I know exim pretty well, and then the single-file approach is more transparent than any approach involving generated files. However, it's a large file containing many details which are uninteresting to users who want a simple system. In that case, an abstraction layer is a good thing. That being said, personally I *do* recommend that people with less common needs read the excellent exim documentation and start off the example.conf file; if your needs are uncommon, making the investment to learn how exim works pays off a lot more than trying to twist an abstraction layer into doing things it wasn't meant to do. And once you do know how it works, any abstraction layer (IMO) just gets in the way. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b8d436.9070...@debian.org
Re: default MTA
* Daniel Pocock dan...@pocock.com.au, 2013-06-12, 21:41: #4: Our priorities are our users and free software In any Debian discussion, given enough time, someone inevitably mentions SC§4. Once this occurs, the thread is over, and the person who mentioned it has automatically lost the argument. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612200325.ga3...@jwilk.net
Re: default MTA
On Wed, 12 Jun 2013 22:04:06 +0200, Wouter Verhelst wou...@debian.org wrote: Yes, me too. It only works for me because I know exim pretty well, and then the single-file approach is more transparent than any approach involving generated files. Exim's abstraction layer uses a single file as well (by default), which accidentally looks a lot like Upstream's example conf. It just has many more macros. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1umrzy-0004yp...@swivel.zugschlus.de
Re: default MTA
On Wednesday, June 12, 2013 16:04:06, Wouter Verhelst wrote: On 12-06-13 16:59, Marc Haber wrote: On Wed, 12 Jun 2013 13:38:28 +0100, Jonathan Dowland j...@debian.org wrote: On Wed, Jun 12, 2013 at 08:00:17AM +0200, Wouter Verhelst wrote: To this exim expert, configuring exim is done as follows: zcat /usr/share/doc/exim4/examples/example.conf.gz /etc/exim4/exim4.conf [...] I violently object to people recommending this to novices. Yes, me too. It only works for me because I know exim pretty well, and then the single-file approach is more transparent than any approach involving generated files. However, it's a large file containing many details which are uninteresting to users who want a simple system. In that case, an abstraction layer is a good thing. Yes. That being said, personally I *do* recommend that people with less common needs read the excellent exim documentation and start off the example.conf file; if your needs are uncommon, making the investment to learn how exim works pays off a lot more than trying to twist an abstraction layer into doing things it wasn't meant to do. And once you do know how it works, any abstraction layer (IMO) just gets in the way. I think that's true. One snag I ran into concerning the abstraction layer concerned customizing the split file configuration via conf.d/ files. Upon upgrades dpkg recongizes the changes in configuration files and prompts the user; choosing not to replace the file with the maintain'er sversion drops a new .dpkg-dist file next to the modified one, which is expected. However what's _not_ expected is to use both the customized configuration file as well as the .dpkg-dist one. :-/ Unfortunately in my experience, that's what happens. And in this condition Exim may fail to start, or might start and then reject mail with a temporary failure. I therefore consider the split configuration to be dangerous. I had another look at this: it appears that in /usr/sbin/update-exim4.conf, the cat_parts() function doesn't avoid files containing .dpkg-, but this funtionality might be able to be added to the run_parts() function that cat_parts() uses. On servers I'm still using the abstraction via the single config method, but I've repeatedly been tempted to use a straight exim4.conf file. [I probably should.] -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306122350.29844.chris.kna...@coredump.us
Re: default MTA
On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: Sendmail has just one more layer of indirection by virtue of the m4 macros. Postfix has most of its behavior hard coded in the C sources, while exim's behavior can be controlled by run-time configuration if an advanced user wants to do things that Debian's abstraction layer was not designed to handle. There are a class of users between beginner and exim expert for which the current state of affairs is not optimal. I don't know how big that class is but I've been in it for ten years. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611163701.GB10760@debian
Re: default MTA
On 28/05/13 03:02, Marco d'Itri wrote: Now that we are done with systemd for the time being, can we have the flame war about replacing Exim with Postfix as the default MTA? Are there any objections other than but I like it this way!? What about replacing SMTP? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b76616.5060...@pocock.com.au
Re: default MTA
On Tue, Jun 11, 2013 at 08:01:58PM +0200, Daniel Pocock wrote: On 28/05/13 03:02, Marco d'Itri wrote: Now that we are done with systemd for the time being, can we have the flame war about replacing Exim with Postfix as the default MTA? Are there any objections other than but I like it this way!? What about replacing SMTP? With what? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: default MTA
On 2013-06-12 02:09:24 +0800 (+0800), Chow Loong Jin wrote:
On Tue, Jun 11, 2013 at 08:01:58PM +0200, Daniel Pocock wrote:
What about replacing SMTP?
With what?
With ESMTP, of course!
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130611205635.ga1...@yuggoth.org
Re: default MTA
* Jonathan Dowland j...@debian.org [130611 18:35]: On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: Sendmail has just one more layer of indirection by virtue of the m4 macros. Postfix has most of its behavior hard coded in the C sources, while exim's behavior can be controlled by run-time configuration if an advanced user wants to do things that Debian's abstraction layer was not designed to handle. There are a class of users between beginner and exim expert for which the current state of affairs is not optimal. I don't know how big that class is but I've been in it for ten years. The only class of users I can imagine the current situation not optional is someone being used to postfix[1]. When I remember learning exim I found it quite nice that the config is quite self-explaining what it is actually doing. With postfix the config is just black magic, where one has hardly any chance to understand what it does and how to change it to do what you want to change. [1] And those can simply install postfix and be done with it. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611210523.gb3...@client.brlink.eu
Re: default MTA
On 11/06/13 22:56, Jeremy Stanley wrote: On 2013-06-12 02:09:24 +0800 (+0800), Chow Loong Jin wrote: On Tue, Jun 11, 2013 at 08:01:58PM +0200, Daniel Pocock wrote: What about replacing SMTP? With what? With ESMTP, of course! Something that doesn't have these limitations: http://tools.ietf.org/html/rfc2487#section-7 This is also relevant (not just for Postfix): http://www.postfix.org/TLS_README.html#client_tls_encrypt Despite the potential for eliminating passive eavesdropping attacks, mandatory TLS encryption is not viable as a default security level for mail delivery to the public Internet. Most MX hosts do not support TLS at all, and some of those that do have broken implementations. On a host that delivers mail to the Internet, you should not configure mandatory TLS encryption as the default security level. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b79b89.50...@pocock.com.au
Re: default MTA
On 2013-06-11 23:50:01 +0200 (+0200), Daniel Pocock wrote:
Something that doesn't have these limitations:
http://tools.ietf.org/html/rfc2487#section-7
[...]
That basically just makes the case for relying on (E)SMTP only for
transporting messages, but leveraging OpenPGP or S/MIME to provide
authentication and confidentiality where required (or for anonymity,
Mixmaster et al).
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130611220230.gb1...@yuggoth.org
Re: default MTA
On Ma, 28 mai 13, 03:02:22, Marco d'Itri wrote: Now that we are done with systemd for the time being, can we have the flame war about replacing Exim with Postfix as the default MTA? Are there any objections other than but I like it this way!? I just moved the DefaultMTA page to Debate/DefaultMTA and did some small additions/changes. If there are no objections within a few days I would like to make some major changes to that page as follows: * the only options left under debate are: - exim (status quo) - postfix - dma - no MTA at all - (did I miss or forget something?) * popularity is irrelevant (the default MTA will always be much more popular) the entire section will be removed * advanced use cases are irrelevant, since the admin of such a system will install what she needs anyway, regardless of the default Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: default MTA
On Thu, Jun 06, 2013 at 11:36:21PM +0800, Thomas Goirand wrote: Well, in that case, it failed to be as simple to configure as qmail. Is ease of configuration an important criteria for default MTA? More important than sensible-default? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130607084341.GB6619@debian
Re: default MTA
On Thu, 6 Jun 2013 14:07:38 +0100, Jonathan Dowland j...@debian.org wrote: On Thu, May 30, 2013 at 06:38:52PM +0200, Marc Haber wrote: On Thu, 30 May 2013 16:53:56 +0200, m...@linux.it (Marco d'Itri) wrote: I think that ease of configurability is a major plus for Postfix when compared to Exim, since a common configurations is just a few lines long. How many lines does an average update-exim4.conf.conf have? You're right, in that the interface that a user has to exim-on-debian is update-exim4.conf.conf, rather than exim4's configuration directly; however, length aside, I don't see this as a strength, but a serious source of confusion. Sendmail has just one more layer of indirection by virtue of the m4 macros. Postfix has most of its behavior hard coded in the C sources, while exim's behavior can be controlled by run-time configuration if an advanced user wants to do things that Debian's abstraction layer was not designed to handle. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ukuan-0002iq...@swivel.zugschlus.de
Re: default MTA
On Thu, 6 Jun 2013 20:06:56 -0400, Chris Knadle chris.kna...@coredump.us wrote: On Thursday, June 06, 2013 16:30:48, Roger Lynn wrote: The smarthosts run by ISPs that most people will be using by default have to accept mail direct from MUAs such as Outlook and Thunderbird which will often be unable to generate compliant greetings. The pickier settings are more often used on incoming servers which expect to have proper SMTP servers speaking to them. I think that's true, however I'd still rather not _count on_ that always being the case. I have not seen an ISP smarthost that didn't accept any rubbish in the EHLO string in years. Smarthosts can be configured to be even more forgiving on Port 587. For example, Debian's default exim configuration is configured to not do recipient verification if the message comes in from a host for which we are a smarthost (by virtue of being listed in relay_from_hosts or by successful authentication) since we assume that MUAs might hide SMTP error messages from the user. Exim, in this case, will create a regular bounce for messages for non-existing recipients instead of rejecting it at SMTP time which is the normal mode of operation. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ukuf3-0002m4...@swivel.zugschlus.de
Re: default MTA
On Wednesday, June 05, 2013 15:35:14, Marc Haber wrote: On Sun, 2 Jun 2013 19:53:59 -0400, Chris Knadle chris.kna...@coredump.us wrote: On Sunday, June 02, 2013 17:10:02, Marc Haber wrote: Exim's default in the packages is not to send authentication data over a non-encrypted connection. The debconf code could try to check whether the smarthost allowes TLS, and if not, query the user whether it is ok to send the password over a non-encrypted connection. Yeah I see why this test could be useful; gnutls-bin is listed as a Suggests by exim4-base, so the TLS libraries may not be locally available. The TLS libraries are not in gnutls-bin. gnutls-bin contains debugging tools. Exim can, of course, use encryption by default. Ah... okay. The normal way I know to check for TLS availability is to telnet to the SMTP port, give an EHLO FQDN (and it must be an EHLO) or EHLO [IP_address], and then look for a STARTTLS advertisement in the response from the server. Unfortunately this isn't always possible; some systems filter telnet from reaching the MTA. Selinux? or how do they do that? I'm glad you asked this, because it prompted me to investigate further. This was something I was told was commonly done, but it looks now like it might be a misnomer. I'm not able to find a concrete example of a system that allows SMTP MTA transfers but doesn't allow telnet to the SMTP port. [The instances that seemed to fit the symptoms look like they have more normal root causes, such as ISP port 25 filtering.] Because I had repeatedly been told that telnet to the MTA was a security problem, prior to now I had suspected that blocking telnet to SMTP might be possible via firewall filtering that distinguished the type of service somehow, but after doing some packet sniffing and examining the resulting packet internals I'm starting to doubt this is possible. Attempting to use an FQDN is also troublesome, because Exim tries to use DNS to look up the FQDN, and falls back to using 'uname -n' which returns the local hostname without a domain name. The SMTP RFCs require the HELO/HELO information to contain an FQDN or an IP address in [] brackets, and some mail systems reject connections containing non-conforming HELO/EHLO greetings. Smarthosts are usually a lot more forgiving in that regard. Maybe so, but the smarthosts I run aren't, so I don't have the expectation that others are. ACL rules for both Exim and Postfix for blocking noncompliant EHLO/HELO greetings are commonly suggested. In this example, the FQDN of the local machine is orac.example.com and the smarthost machine is smtp.example.com Create new file /etc/exim4/exim4.conf.localmacros containing: MAIN_TLS_ENABLE = true primary_hostname = orac.example.com I don't think you need MAIN_TLS_ENABLE to to TLS as a client. Tested this... looks like this is true. :-) Cool. [I'm pretty sure this wasn't always the case, but I'm glad it is now.] Afair, it was always the case. Okay -- I'll take your word for it. ;-) You can set sc_smarthost to hostname::587 without having to change the transport, see update-exim4.conf(8) or the debconf template for dc_smarthost. Sweet. Thanks! This really helps because it means I can avoid having to modify exim4.conf.template altogether, which will simplify upgrades Indeed. The configuration was carefully crafted to allow this. Cool. Somehow I missed this particular setting. On the mail server machine (i.e. smtp.example.com), make an MD5 passowrd hash of the password used on the client machine via command: #mkpasswd -H md5 SillyPassword $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1 Then modify /etc/exim4/passwd on the server to add a username:hashed_passwd:passwd triplet for the client: Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword You also can a more modern hash if the server is Debian exim as well. The exim4_files(5) man page recommends MD5, which is why I was using it, and thee README.Debian.gz document simply refers to this man page. However crypt(3) indicates that sha-256 is supported too, so I tried it with Exim's passwd file... sure enough, that works. ;-) I have committed a fix for the manpage that hasn't been touched in years. I hope that I pushed to the correct repository. That's cool. Thanks! -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306060852.13676.chris.kna...@coredump.us
Re: default MTA
On Thu, May 30, 2013 at 06:38:52PM +0200, Marc Haber wrote: On Thu, 30 May 2013 16:53:56 +0200, m...@linux.it (Marco d'Itri) wrote: I think that ease of configurability is a major plus for Postfix when compared to Exim, since a common configurations is just a few lines long. How many lines does an average update-exim4.conf.conf have? You're right, in that the interface that a user has to exim-on-debian is update-exim4.conf.conf, rather than exim4's configuration directly; however, length aside, I don't see this as a strength, but a serious source of confusion. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606130738.GA22156@debian
Re: default MTA
On Thu, Jun 06, 2013 at 02:07:38PM +0100, Jonathan Dowland wrote: You're right, in that the interface that a user has to exim-on-debian is update-exim4.conf.conf, rather than exim4's configuration directly; however, length aside, I don't see this as a strength, but a serious source of confusion. And the .conf.conf part contributes quite a lot of that. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606130859.gc27...@belkar.wrar.name
Re: default MTA
On 05/31/2013 12:27 AM, Philip Hands wrote: Well, I'd say that at least part of the motivation was actually to write a qmail replacement, that didn't have someone with DJB's atitute to licensing as upstream -- it was for a long time called vmailer (v==vapour) as coined by DJB, and adopted by Wietse because it amused him. Given that it was qmail inspired, which was writen with the similar approach of having a crowd of distinct daemons perfornming one task each, with a UID for each, I'd say that the intent was to match qmail's security focus. If one were simply trying to replace Sendmail, the result might well have looked a lot more like Exim, with a monolithic executable, that forks into the various roles required. Well, in that case, it failed to be as simple to configure as qmail. Even though I've switch to Postfix so long ago that I can't remember, I still prefer the way to configure Qmail. Which I don't use anymore for unrelated very valid reasons... like the deferred bounce (which since have been fixed), but that's not all, and I believe any (old) Qmail user know what I have in mind! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b0ac75.7020...@debian.org
Re: default MTA
* Chris Knadle chris.kna...@coredump.us [130606 14:53]: I'm glad you asked this, because it prompted me to investigate further. This was something I was told was commonly done, but it looks now like it might be a misnomer. I'm not able to find a concrete example of a system that allows SMTP MTA transfers but doesn't allow telnet to the SMTP port. [The instances that seemed to fit the symptoms look like they have more normal root causes, such as ISP port 25 filtering.] Because I had repeatedly been told that telnet to the MTA was a security problem, prior to now I had suspected that blocking telnet to SMTP might be possible via firewall filtering that distinguished the type of service somehow, but after doing some packet sniffing and examining the resulting packet internals I'm starting to doubt this is possible. Actually, it is possible to block telnet (and I've seen some ISPs do it). In unrelated news, using telnet is a bad idea. If you want to connect to some port and see what you get, use netcat. Telnet is not a tool to show things coming from a port but a tool to speak the telnet protocol. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606171839.ga3...@client.brlink.eu
Re: default MTA
On Thursday, June 06, 2013 13:18:39, Bernhard R. Link wrote: * Chris Knadle chris.kna...@coredump.us [130606 14:53]: I'm glad you asked this, because it prompted me to investigate further. This was something I was told was commonly done, but it looks now like it might be a misnomer. I'm not able to find a concrete example of a system that allows SMTP MTA transfers but doesn't allow telnet to the SMTP port. [The instances that seemed to fit the symptoms look like they have more normal root causes, such as ISP port 25 filtering.] Because I had repeatedly been told that telnet to the MTA was a security problem, prior to now I had suspected that blocking telnet to SMTP might be possible via firewall filtering that distinguished the type of service somehow, but after doing some packet sniffing and examining the resulting packet internals I'm starting to doubt this is possible. Actually, it is possible to block telnet (and I've seen some ISPs do it). Okay. I'm going to try to figure out how this is done, as this has been one of those things in the back of my mind for a bit too long. In unrelated news, using telnet is a bad idea. If you want to connect to some port and see what you get, use netcat. Yep, netcat looks like the better tool for this. Thanks for the hint! -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306061337.55807.chris.kna...@coredump.us
Re: default MTA
If you do discover how to do this reliably, I'd be interested in your solution. If you/someone else feels it's too unrelated to this list, feel free to email me directly, but I think this is generally interesting. Ron Scott-Adams r...@tohuw.net The truth is incontrovertible. Malice may attack it, ignorance may deride it, but in the end, there it is. (Winston Churchill) On Jun 6, 2013, at 13:37 , Chris Knadle chris.kna...@coredump.us wrote: On Thursday, June 06, 2013 13:18:39, Bernhard R. Link wrote: * Chris Knadle chris.kna...@coredump.us [130606 14:53]: I'm glad you asked this, because it prompted me to investigate further. This was something I was told was commonly done, but it looks now like it might be a misnomer. I'm not able to find a concrete example of a system that allows SMTP MTA transfers but doesn't allow telnet to the SMTP port. [The instances that seemed to fit the symptoms look like they have more normal root causes, such as ISP port 25 filtering.] Because I had repeatedly been told that telnet to the MTA was a security problem, prior to now I had suspected that blocking telnet to SMTP might be possible via firewall filtering that distinguished the type of service somehow, but after doing some packet sniffing and examining the resulting packet internals I'm starting to doubt this is possible. Actually, it is possible to block telnet (and I've seen some ISPs do it). Okay. I'm going to try to figure out how this is done, as this has been one of those things in the back of my mind for a bit too long. In unrelated news, using telnet is a bad idea. If you want to connect to some port and see what you get, use netcat. Yep, netcat looks like the better tool for this. Thanks for the hint! -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306061337.55807.chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/928757f7-fe35-43bd-a784-1c83ac755...@tohuw.net
Re: default MTA
On 06/06/13 14:00, Chris Knadle wrote: On Wednesday, June 05, 2013 15:35:14, Marc Haber wrote: On Sun, 2 Jun 2013 19:53:59 -0400, Chris Knadle chris.kna...@coredump.us wrote: Attempting to use an FQDN is also troublesome, because Exim tries to use DNS to look up the FQDN, and falls back to using 'uname -n' which returns the local hostname without a domain name. The SMTP RFCs require the HELO/HELO information to contain an FQDN or an IP address in [] brackets, and some mail systems reject connections containing non-conforming HELO/EHLO greetings. Smarthosts are usually a lot more forgiving in that regard. Maybe so, but the smarthosts I run aren't, so I don't have the expectation that others are. ACL rules for both Exim and Postfix for blocking noncompliant EHLO/HELO greetings are commonly suggested. The smarthosts run by ISPs that most people will be using by default have to accept mail direct from MUAs such as Outlook and Thunderbird which will often be unable to generate compliant greetings. The pickier settings are more often used on incoming servers which expect to have proper SMTP servers speaking to them. I don't think you need MAIN_TLS_ENABLE to to TLS as a client. Tested this... looks like this is true. :-) Cool. [I'm pretty sure this wasn't always the case, but I'm glad it is now.] Afair, it was always the case. Okay -- I'll take your word for it. ;-) The upstream spec for Exim 3.30 from 2001 says: It is not necessary to set any options to have TLS work in the smtp transport. If TLS is advertised by a server, the smtp transport will attempt to start a TLS session. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/o4878a-c84@silverstone.rilynn.me.uk
Re: default MTA
On Thursday, June 06, 2013 16:30:48, Roger Lynn wrote: On 06/06/13 14:00, Chris Knadle wrote: On Wednesday, June 05, 2013 15:35:14, Marc Haber wrote: On Sun, 2 Jun 2013 19:53:59 -0400, Chris Knadle chris.kna...@coredump.us wrote: Attempting to use an FQDN is also troublesome, because Exim tries to use DNS to look up the FQDN, and falls back to using 'uname -n' which returns the local hostname without a domain name. The SMTP RFCs require the HELO/HELO information to contain an FQDN or an IP address in [] brackets, and some mail systems reject connections containing non-conforming HELO/EHLO greetings. Smarthosts are usually a lot more forgiving in that regard. Maybe so, but the smarthosts I run aren't, so I don't have the expectation that others are. ACL rules for both Exim and Postfix for blocking noncompliant EHLO/HELO greetings are commonly suggested. The smarthosts run by ISPs that most people will be using by default have to accept mail direct from MUAs such as Outlook and Thunderbird which will often be unable to generate compliant greetings. The pickier settings are more often used on incoming servers which expect to have proper SMTP servers speaking to them. I think that's true, however I'd still rather not _count on_ that always being the case. The RFCs accept [IP_address] such as [192.168.1.1] as a EHLO/HELO greeting, and that's something that's always available and should work with smarthosts that have more strict EHLO/HELO checks. I don't think you need MAIN_TLS_ENABLE to to TLS as a client. Tested this... looks like this is true. :-) Cool. [I'm pretty sure this wasn't always the case, but I'm glad it is now.] Afair, it was always the case. Okay -- I'll take your word for it. ;-) The upstream spec for Exim 3.30 from 2001 says: It is not necessary to set any options to have TLS work in the smtp transport. If TLS is advertised by a server, the smtp transport will attempt to start a TLS session. Yep, that's definitive. Thanks for taking the time to look this up. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306062006.57082.chris.kna...@coredump.us
Re: default MTA
On Sun, 2 Jun 2013 19:53:59 -0400, Chris Knadle chris.kna...@coredump.us wrote: On Sunday, June 02, 2013 17:10:02, Marc Haber wrote: Exim's default in the packages is not to send authentication data over a non-encrypted connection. The debconf code could try to check whether the smarthost allowes TLS, and if not, query the user whether it is ok to send the password over a non-encrypted connection. Yeah I see why this test could be useful; gnutls-bin is listed as a Suggests by exim4-base, so the TLS libraries may not be locally available. The TLS libraries are not in gnutls-bin. gnutls-bin contains debugging tools. Exim can, of course, use encryption by default. The normal way I know to check for TLS availability is to telnet to the SMTP port, give an EHLO FQDN (and it must be an EHLO) or EHLO [IP_address], and then look for a STARTTLS advertisement in the response from the server. Unfortunately this isn't always possible; some systems filter telnet from reaching the MTA. Selinux? or how do they do that? Attempting to use an FQDN is also troublesome, because Exim tries to use DNS to look up the FQDN, and falls back to using 'uname -n' which returns the local hostname without a domain name. The SMTP RFCs require the HELO/HELO information to contain an FQDN or an IP address in [] brackets, and some mail systems reject connections containing non-conforming HELO/EHLO greetings. Smarthosts are usually a lot more forgiving in that regard. In this example, the FQDN of the local machine is orac.example.com and the smarthost machine is smtp.example.com Create new file /etc/exim4/exim4.conf.localmacros containing: MAIN_TLS_ENABLE = true primary_hostname = orac.example.com I don't think you need MAIN_TLS_ENABLE to to TLS as a client. Tested this... looks like this is true. :-) Cool. [I'm pretty sure this wasn't always the case, but I'm glad it is now.] Afair, it was always the case. You can set sc_smarthost to hostname::587 without having to change the transport, see update-exim4.conf(8) or the debconf template for dc_smarthost. Sweet. Thanks! This really helps because it means I can avoid having to modify exim4.conf.template altogether, which will simplify upgrades Indeed. The configuration was carefully crafted to allow this. On the mail server machine (i.e. smtp.example.com), make an MD5 passowrd hash of the password used on the client machine via command: #mkpasswd -H md5 SillyPassword $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1 Then modify /etc/exim4/passwd on the server to add a username:hashed_passwd:passwd triplet for the client: Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword You also can a more modern hash if the server is Debian exim as well. The exim4_files(5) man page recommends MD5, which is why I was using it, and thee README.Debian.gz document simply refers to this man page. However crypt(3) indicates that sha-256 is supported too, so I tried it with Exim's passwd file... sure enough, that works. ;-) I have committed a fix for the manpage that hasn't been touched in years. I hope that I pushed to the correct repository. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ukjui-n6...@swivel.zugschlus.de
Re: default MTA
On Sun, 02 Jun 2013 14:26:31 -0700, Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Certificates are usually only used in E-Mail when a server authenticates itself to a client before the client sends its authentication data. SMTP with client certificates is possible, but I have only seen this two times in 15 years of running E-Mail servers. All mail servers I run are configured with TLS certificates because that's how you encrypt SMTP traffic between servers. That's not a contradiction to what I have written. You said that certificates are usually only used in e-mail when a server authenticates itself to a client. That's the statement with which I'm partly disagreeing. Now I see that I didn't write what I wanted to write. I just wanted to say that client certificates are really seldomly used in SMTP. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ukjvd-ne...@swivel.zugschlus.de
Re: default MTA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 29/05/2013 21:52, Marc Haber a écrit : But, alas, people are going to report every single mail in the local mailbox als Spam to their ISP. MUAs tend to present mail in folders by accounts. They can be configured to display local mail in a folder with an explicit title. In addition, we can push a localized mail to each newly created local account, such as Welcome to Debian, this mail folder usually contains only system messages blah blah so that people know what to expect here, especially for the user to which root's mail is forwarded. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRraoIAAoJEJOUU0jg3ChA084QAKMOZiyCor47O8pf4ZGwwome SMShYEVTw0it2hhCE5oeX35cfOVvPg0CDBnxXSwwDQzqaoUD4TmuQ+Cyni8O30pN Zv5sJ/uaFcK3Wsz5UGd89uaDDoZLlUwLhJ0bhVtONW545/QpNLYUea1uefSBRBe5 HdF5O2GabkMwkYJ+ekmrhxqfUOIpi4N7u7qDHViWqUYQsIDKrvCcA8+Q5ihnEswd Y6JnDy7V3yuk4GeVyi+WAakmuoe6vmpX+4PS+E/Me5zCUZEhRFycrgHVDw230zsg 9lB0CDMcxVX9XZbL+173Ibs+uIyk0xxN57LW9OQ3p8yg4yoQQS6N6KQsiL7LKnR6 mIzaP/HzTOn1x3+Lkg832gHTtYoWLB5GwqsRJFurSQkEMKvLTPZTA92bWWYgq8SO QLWitVg/OxQGjdrIxRG25vBgHy5lMxAM+qjLTkhwhsGyvSCBfyRyTDhJsA2s4pMP fC3rUsUaqIMVi/j5z5JWJfPEi3hQprQ9AqGJH+qEW/BUVvn0Xo9US0M/DWOeharH O+ATodog1WTAxWfvlVf8SE6rJima9moelnJzxFhVfKGykHKO3+L4F4wohck0DZiY UaccKVwgpjaKvJ7H/+WY+XNrE+Q5VBKpfe1THE8FouG3H5YOcxdas9Hyks1ZyrBH /SfWpZCvewEwHL4EW0/d =JBsQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51adaa08.5080...@debian.org
Re: default MTA
Le 31/05/2013 13:10, Marc Haber a écrit : On Fri, 31 May 2013 08:41:56 +0200, Jean-Christophe Dubacq jcduba...@free.fr wrote: Le 30/05/2013 18:29, Marc Haber a écrit : On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters o...@vitters.nl wrote: Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. It is not a good idea to drop the way that 90 % of programs use to deliver messages. I really hate the idea of having a thing as fragile as dbus on a server just to collect status messages. 73.6% of all statistics are made up. You have a point here. I shold have written the vast majority. The way most programs deliver messages is actually syslog. Which is an epic nightmare to parse automatically if one needs to put messages in relation to each other and is only readable if all messages are shorter than, say, 160 characters. Even firewall log messages are way longer than that already. And yet, I remain convinced that I do redirect many root accounts to my own account, and I have yet to see very important messages coming that way. When I stop receiving useless messages from one machine, *that* means something, namely, that the machine is broken. But anyone seriously keeping an eye on server will install some kind of munin/nagios, and on desktops, disk tools will notify the user when the computer is used. All the rest belongs to syslog. I seem to recall that some init system has a specific additional format to store logs and make them easily searchable, by the way. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: default MTA
On Sat, 1 Jun 2013 15:06:40 -0400, Chris Knadle chris.kna...@coredump.us wrote: I can understand why one would want this, but I can also understand why it hasn't been done. Without first setting up TLS, this would involve passing a username/password over the 'net in the clear, which is something I try hard to never ever have happen. This is especially something you don't want to do if it's your own personal email login, which is a likely use case for this proposed debconf code. :-/ Exim's default in the packages is not to send authentication data over a non-encrypted connection. The debconf code could try to check whether the smarthost allowes TLS, and if not, query the user whether it is ok to send the password over a non-encrypted connection. In this example, the FQDN of the local machine is orac.example.com and the smarthost machine is smtp.example.com Create new file /etc/exim4/exim4.conf.localmacros containing: MAIN_TLS_ENABLE = true primary_hostname = orac.example.com I don't think you need MAIN_TLS_ENABLE to to TLS as a client. Modify /etc/exim4/exim4.conf.template for the remote_smtp_smarthost to change the sending port to 587. (In the U.S. there are a lot of ISPs that block outbound port 25 except for the ISP's mail servers): ... remote_smtp_smarthost: debug_print = T: remote_smtp_smarthost for $local_part@$domain driver = smtp port = 587# --- add this line ... You can set sc_smarthost to hostname::587 without having to change the transport, see update-exim4.conf(8) or the debconf template for dc_smarthost. Modify /etc/exim4/passwd.client to add a smarthost:username:password triplet for sending email: smtp.example.com:Orac:SillyPassword That's what I'd want to be debconfed On the mail server machine (i.e. smtp.example.com), make an MD5 passowrd hash of the password used on the client machine via command: #mkpasswd -H md5 SillyPassword $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1 Then modify /etc/exim4/passwd on the server to add a username:hashed_passwd:passwd triplet for the client: Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword You also can a more modern hash if the server is Debian exim as well. As I mentioned previously, the reason I go through making a new username/password pair for each client is so that I don't risk a personal email account, and so that I can revoke any one machine's email login at the server in case of a client compromise of some kind. Wise. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ujfxo-0005bm...@swivel.zugschlus.de
Re: default MTA
On Sat, 01 Jun 2013 12:16:11 -0700, Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Certificates are usually only used in E-Mail when a server authenticates itself to a client before the client sends its authentication data. SMTP with client certificates is possible, but I have only seen this two times in 15 years of running E-Mail servers. All mail servers I run are configured with TLS certificates because that's how you encrypt SMTP traffic between servers. That's not a contradiction to what I have written. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ujfys-0005bv...@swivel.zugschlus.de
Re: default MTA
Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Certificates are usually only used in E-Mail when a server authenticates itself to a client before the client sends its authentication data. SMTP with client certificates is possible, but I have only seen this two times in 15 years of running E-Mail servers. All mail servers I run are configured with TLS certificates because that's how you encrypt SMTP traffic between servers. That's not a contradiction to what I have written. You said that certificates are usually only used in e-mail when a server authenticates itself to a client. That's the statement with which I'm partly disagreeing. I run multiple mail servers (and Stanford University runs quite a few more) that have TLS certificates that have nothing to do with authentication. TLS certificates are a poor authentication system unless you restrict them to only CAs under your control, but they're great as an easy way of configuring effectively anonymous encryption. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li6sfblk@windlord.stanford.edu
Re: default MTA
On Sunday, June 02, 2013 17:10:02, Marc Haber wrote: On Sat, 1 Jun 2013 15:06:40 -0400, Chris Knadle chris.kna...@coredump.us wrote: I can understand why one would want this, but I can also understand why it hasn't been done. Without first setting up TLS, this would involve passing a username/password over the 'net in the clear, which is something I try hard to never ever have happen. This is especially something you don't want to do if it's your own personal email login, which is a likely use case for this proposed debconf code. :-/ Exim's default in the packages is not to send authentication data over a non-encrypted connection. The debconf code could try to check whether the smarthost allowes TLS, and if not, query the user whether it is ok to send the password over a non-encrypted connection. Yeah I see why this test could be useful; gnutls-bin is listed as a Suggests by exim4-base, so the TLS libraries may not be locally available. The normal way I know to check for TLS availability is to telnet to the SMTP port, give an EHLO FQDN (and it must be an EHLO) or EHLO [IP_address], and then look for a STARTTLS advertisement in the response from the server. Unfortunately this isn't always possible; some systems filter telnet from reaching the MTA. I don't yet know how to check a remote server for this using a local Exim binary; there's an -MCT option mentioned in the Exim man page for this, but it's an option used internally by Exim and not meant to be used by an external caller. Attempting to use an FQDN is also troublesome, because Exim tries to use DNS to look up the FQDN, and falls back to using 'uname -n' which returns the local hostname without a domain name. The SMTP RFCs require the HELO/HELO information to contain an FQDN or an IP address in [] brackets, and some mail systems reject connections containing non-conforming HELO/EHLO greetings. I think swaks may be able to do this via something like: swaks --ehlo [192.168.1.1] --server smarthost_FQDN -p port \ -tls -q TLS ... but swaks is a package Suggested by exim4-base rather than a Depends, so swaks may not be available for use with debconf. Let me know if you have suggestions. In this example, the FQDN of the local machine is orac.example.com and the smarthost machine is smtp.example.com Create new file /etc/exim4/exim4.conf.localmacros containing: MAIN_TLS_ENABLE = true primary_hostname = orac.example.com I don't think you need MAIN_TLS_ENABLE to to TLS as a client. Tested this... looks like this is true. :-) Cool. [I'm pretty sure this wasn't always the case, but I'm glad it is now.] Modify /etc/exim4/exim4.conf.template for the remote_smtp_smarthost to change the sending port to 587. (In the U.S. there are a lot of ISPs that block outbound port 25 except for the ISP's mail servers): ... remote_smtp_smarthost: debug_print = T: remote_smtp_smarthost for $local_part@$domain driver = smtp port = 587# --- add this line ... You can set sc_smarthost to hostname::587 without having to change the transport, see update-exim4.conf(8) or the debconf template for dc_smarthost. Sweet. Thanks! This really helps because it means I can avoid having to modify exim4.conf.template altogether, which will simplify upgrades. Modify /etc/exim4/passwd.client to add a smarthost:username:password triplet for sending email: smtp.example.com:Orac:SillyPassword That's what I'd want to be debconfed Right. On the mail server machine (i.e. smtp.example.com), make an MD5 passowrd hash of the password used on the client machine via command: #mkpasswd -H md5 SillyPassword $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1 Then modify /etc/exim4/passwd on the server to add a username:hashed_passwd:passwd triplet for the client: Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword You also can a more modern hash if the server is Debian exim as well. The exim4_files(5) man page recommends MD5, which is why I was using it, and thee README.Debian.gz document simply refers to this man page. However crypt(3) indicates that sha-256 is supported too, so I tried it with Exim's passwd file... sure enough, that works. ;-) Thanks for letting me know about this. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: default MTA
]] Russ Allbery Basically, what we're looking for here is the equivalent of a check engine light (except, of course, with better user-visible diagnostics available). That's what the end user actually wants: something clear and visible indicating that something is wrong, which they can drill down and see the details and dismiss the error condition if they want, or have all the details available to consult someone who knows more about computers if they don't know what to do with it themselves. Historically, root cron mail has been exactly that, and that's still a great way of handling it for servers, since that mail can be sent off somewhere centrally, analyzed and assigned to sysadmins, used to open internal trouble tickets, etc. I don't think it's a good way at all, since far too often, cron mails aren't actionable. I'll get a mail from some automated process that tried to run apt-get update and that failed (during the middle of the night). Since that process runs every hour, it'll have succeeded afterwards, and there's nothing I can do about the mail. I wish we had a better system where some, but not all errors would latch and need acknowledgment, there would be correlation (between hosts and between messages, so if the router's down, you get a message about data centre A not being able to successfully complete $process, rather than a zillion individual messages), there would be merging of identical messages, so I get a message about $process being broken for the last $time period (or having a failure rate above $threshold), rather than a thousand mails because of some error. Oh, and a pony. Don't forget the pony. Or an otter, I like otters. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m238t2maxt@rahvafeir.err.no
Re: default MTA
On 2013-05-28 13:05:25 +0200, Josselin Mouette wrote: Le mardi 28 mai 2013 à 12:13 +0200, Adam Borowski a écrit : Being able to send outgoing mail, and to handle local (such as SMTP rejects or notifications from system daemons) seems plenty useful to me. Most clients (apart maybe from mailx) can use an external SMTP server to send email. Is there a central configuration (when the SMTP connection is done by the clients)? And on desktop systems, nobody reads local email. I do (possibly remotely after synchronization). We might want to think of a better notification system, but email is definitely not fit for that anymore. Email should still be available. Otherwise make sure that notification is available remotely... -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130601185246.gb12...@xvii.vinc17.org
Re: default MTA
On Friday, May 31, 2013 07:15:36, Marc Haber wrote: On Thu, 30 May 2013 19:51:04 -0400, Chris Knadle chris.kna...@coredump.us wrote: For Exim, the one thing I would want to change would be to ship a configuration that by default created an SSL certificate and enabled MAIN_TLS_ENABLE to enable TLS SMTP transfers. For e-mail coming in from other clients, with the local exim acting as a server? Interesting possibility, but no that's not what I had in mind. Certificates are usually only used in E-Mail when a server authenticates itself to a client before the client sends its authentication data. Yes, you're right. After I had pointed out the existence of Section 2.2 in /usr/share/doc/exim4-base/README.Debian.gz I re-read it, and it points out that the SSL certificates are only required for TLS when Exim is acting as a server, and are _not_ necessary when Exim is passing along email as a client to another MTA. SMTP with client certificates is possible, but I have only seen this two times in 15 years of running E-Mail servers. Yes I'd expect this to be rare, and I can't recall using them for SMTP. [The Postfix package in Debian does this.] There's documentation and help for doing this for Exim in/usr/share/doc/exim4-base/README.Debian.gz in Section 2.2 though, and so I suspect there's a _reason_ why this isn't the default. Noone has yet written code to do that, and volunteered to document and support it. Personally, I think that before we improve Exim's packaging in Debian to be an SMTP server, we should first make it easiert to use Exim as a client with a smart host, thus debconfing the username/password and authentication scheme. Noone has volunteered to write that code, either. I can understand why one would want this, but I can also understand why it hasn't been done. Without first setting up TLS, this would involve passing a username/password over the 'net in the clear, which is something I try hard to never ever have happen. This is especially something you don't want to do if it's your own personal email login, which is a likely use case for this proposed debconf code. :-/ I'll list the steps _I_ take for setting up an Exim4 client (now that I've finally formally documented them for myself). This enables TLS, sets primary_hostname to set the full FQDN for the HELO greeting sent, and sends email to a smarthost with destination port 587 via SMTP AUTH. In this example, the FQDN of the local machine is orac.example.com and the smarthost machine is smtp.example.com Create new file /etc/exim4/exim4.conf.localmacros containing: MAIN_TLS_ENABLE = true primary_hostname = orac.example.com Modify /etc/exim4/exim4.conf.template for the remote_smtp_smarthost to change the sending port to 587. (In the U.S. there are a lot of ISPs that block outbound port 25 except for the ISP's mail servers): ... remote_smtp_smarthost: debug_print = T: remote_smtp_smarthost for $local_part@$domain driver = smtp port = 587# --- add this line ... Run '/etc/init.d/exim4 reload' to pull in the new configuration Modify /etc/exim4/passwd.client to add a smarthost:username:password triplet for sending email: smtp.example.com:Orac:SillyPassword On the mail server machine (i.e. smtp.example.com), make an MD5 passowrd hash of the password used on the client machine via command: #mkpasswd -H md5 SillyPassword $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1 Then modify /etc/exim4/passwd on the server to add a username:hashed_passwd:passwd triplet for the client: Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword As I mentioned previously, the reason I go through making a new username/password pair for each client is so that I don't risk a personal email account, and so that I can revoke any one machine's email login at the server in case of a client compromise of some kind. [It's never happened, but I try to plan for it anyway.] This wiki page has a nice summary http://wiki.debian.org/DefaultMTA I think the negative point of Support community limited outside of Debian is untrue. The exim-us...@exim.org mailing list is very active and responsive, and Exim has become the most popular MTA since sometime in 2008. Agreed, but exim's development speed has considerably slowed down since Philip Hazel retired. The exim community is still alive, but I'd say it's in limbo. Which is a real shame. I know what you mean -- the community has slowed a bit, but I don't (personally) feel that it's gotten down to limbo, because there are people still supporting the code and making new features and improvements. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: default MTA
Marc Haber mh+debian-de...@zugschlus.de writes: For e-mail coming in from other clients, with the local exim acting as a server? Certificates are usually only used in E-Mail when a server authenticates itself to a client before the client sends its authentication data. SMTP with client certificates is possible, but I have only seen this two times in 15 years of running E-Mail servers. All mail servers I run are configured with TLS certificates because that's how you encrypt SMTP traffic between servers. (Self-signed certificates are fine for that purpose since the point is wire encryption, not authentication.) I don't see any reason to send my email in the clear over the network when there's a simple alternative that's widely supported. Among other reasons, any little thing we can do to make life harder for governments who think they should be able to wiretap network traffic without a warrant seems like a good idea to me. I don't know how Exim works in this regard, but for Postfix: # Enable opportunistic TLS. smtp_tls_loglevel = 1 smtp_tls_security_level = may # Present a server certificate to clients. smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level= may smtpd_tls_cert_file = /etc/ssl/certs/hostname.pem smtpd_tls_key_file = /etc/ssl/private/hostname.key will enable opportunistic TLS both sending and receiving without interfering with one's ability to talk to mail servers that aren't willing or configured to do TLS. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738t1fxqc@windlord.stanford.edu
Re: default MTA
On Saturday, June 01, 2013 05:34:22, Tollef Fog Heen wrote: ]] Russ Allbery Basically, what we're looking for here is the equivalent of a check engine light (except, of course, with better user-visible diagnostics available). That's what the end user actually wants: something clear and visible indicating that something is wrong, which they can drill down and see the details and dismiss the error condition if they want, or have all the details available to consult someone who knows more about computers if they don't know what to do with it themselves. Historically, root cron mail has been exactly that, and that's still a great way of handling it for servers, since that mail can be sent off somewhere centrally, analyzed and assigned to sysadmins, used to open internal trouble tickets, etc. I don't think it's a good way at all, since far too often, cron mails aren't actionable. I'll get a mail from some automated process that tried to run apt-get update and that failed (during the middle of the night). Since that process runs every hour, it'll have succeeded afterwards, and there's nothing I can do about the mail. I wish we had a better system where some, but not all errors would latch and need acknowledgment, there would be correlation (between hosts and between messages, so if the router's down, you get a message about data centre A not being able to successfully complete $process, rather than a zillion individual messages), there would be merging of identical messages, so I get a message about $process being broken for the last $time period (or having a failure rate above $threshold), rather than a thousand mails because of some error. Ugh. :-/ Yeah these are good points. The thinking was to change notifications (a) for Desktop boxes only and (b) the messages received and needing acknowledgement being from the local machine only. However -- if there are many repeat events of some error that all have to be separately acknowledged, I can easily see how that could be very annoying. Oh, and a pony. Don't forget the pony. Or an otter, I like otters. Otters are pretty cute looking. They remind me of gophers. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: default MTA
On Wednesday, May 29, 2013 20:02:42, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us writes: On Wednesday, May 29, 2013 15:46:15, Russ Allbery wrote: That's exactly the point, and is why I would prefer not to write those notifications into a file that no one ever looks at. (Which is why I don't find sending them to syslog much more appealing, since the average desktop user is never going to look there either.) Somehow this problem reminds me of the event log used on a popular operating system. Most users don't read that log either. Yes, but what users *do* read is some sort of event log that throws an attention icon (or spawns a window) on login or on event that doesn't go away until the user looks through the messages. Yes. I know we probably don't have something like this right now, but it's something that can be done, and would be much superior to email for a lot of users (including myself on a lot of systems). One could easily solve the persistent problem in a similar way if a history of such notifications were kept and could be retrieved by the user by manually launching the application. None of this seems particularly novel (we've written similar things at Stanford for managed desktop situations and deployed commercial products that do something similar, not to mention that it's how most anti-virus updators and now the OS patch updators work), which makes me wonder if someone is already working on (or has finished) a mechanism of corraling some desktop notifications into that sort of framework. It at least has the potential to be a good solution, yes. There are a number of notification packages in Debian that I'm having a look through. At the moment I'm looking at notify-osd. https://wiki.ubuntu.com/NotifyOSD -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: default MTA
On 31/05/13 07:50, Jean-Christophe Dubacq wrote: A utility to scan syslog and convey important information to the user would be much more useful than configuring all mailers in Debian to read root's local mail by default. I know how to redirect root's mail elsewhere, thank you for not making another mail account to check. The mailers don't need to read root's mail, they just need to read the user's own mail, which is something they should do anyway. The fact that many apparently still don't is quite a startling omission. I remember being surprised many years ago that Netscape and Mozilla apparently didn't support reading local mail, which should be a basic function of any Unix MUA. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/lk0q7a-69p@silverstone.rilynn.me.uk
Re: default MTA
On Sat, 2013-06-01 at 15:06 -0400, Chris Knadle wrote: On Friday, May 31, 2013 07:15:36, Marc Haber wrote: [...] SMTP with client certificates is possible, but I have only seen this two times in 15 years of running E-Mail servers. Yes I'd expect this to be rare, and I can't recall using them for SMTP. [...] I set up my smarthost to allow relaying from external servers that present a CAcert-signed client certificate for a name under decadent.org.uk. Any machine outside the home LAN then needs such a certificate installed before using this smarthost. It wasn't that easy to set up, and the certificates need to be renewed regularly (every 6 months for CAcert), but the credentials are now clearly associated with a machine rather than a person and it effectively validates that I'm using TLS for outgoing mail from my laptop. (But did I correctly enable validation of the smarthost's server certificate? Not sure.) Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Re: default MTA
Le 30/05/2013 18:29, Marc Haber a écrit : On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters o...@vitters.nl wrote: Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. It is not a good idea to drop the way that 90 % of programs use to deliver messages. I really hate the idea of having a thing as fragile as dbus on a server just to collect status messages. 73.6% of all statistics are made up. And in my experience, email tends to be much more fragile than dbus. How many times have I suddenly looked at the queue of a computer that has been mis-configured and that accumulated thousands of email from its system trying to repeatedly warn the user that, well, the email smarthost cannot be contacted? The way most programs deliver messages is actually syslog. The most important of them being the kernel. We've been over it several times. As far as I know, the kernel does not send emails. Exaggerating this way just removes credit from all your mails. I can see you are passionate about this issue (and several others), but this does not help. Most logs I receive on my email account come from cron (also a few from the fetchmail daemon, but I suppose that one can live with sending local emails, due to its nature). And I use a large variety of services. By the way, parts of cron can even be replaced by systemd's services, and at this point this will use whatever system for information transmission systemd uses (I do not use systemd, I am not interested yet in knowing how information is conveyed in systemd to the user or admin; I doubt this is email). A utility to scan syslog and convey important information to the user would be much more useful than configuring all mailers in Debian to read root's local mail by default. I know how to redirect root's mail elsewhere, thank you for not making another mail account to check. Sincerly, -- -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: default MTA
Jean-Christophe Dubacq jcduba...@free.fr writes: And in my experience, email tends to be much more fragile than dbus. The warm fuzzy feeling you get when you don't know there is a problem... How many times have I suddenly looked at the queue of a computer that has been mis-configured and that accumulated thousands of email from its system trying to repeatedly warn the user that, well, the email smarthost cannot be contacted? Yes, and dbus would have just dropped the messages that couldn't be delivered instead of queueing them. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761xzlg2n@nemi.mork.no
Re: default MTA
On Thu, 30 May 2013 23:25:15 +0300, Christian PERRIER bubu...@debian.org wrote: MTA on average people's desktop machine are point less. Is there anyone who is *not* a Linux geek to deny this? Non-Geeks are probably not aware that a system holds many packages of software that expects to be able to deliver status messages as e-mail via either /usr/lib/sendmail or tcp port 25 to localhost. Geeks might be aware that there is relatively few software that can accept e-mail messages by one of this means and is able to queue such messages in case the real target is unavailable for some reason and that is not called MTA. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uin90-0001dd...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 20:25:12 -0400, Chris Knadle chris.kna...@coredump.us wrote: It's somewhat depressing when I ask for the person's email address and their response is I don't email, and they ask me for my Facebook ID and my response is I don't use Facebook. It's a cultural divide that ends up causing an electronic communications divide. Not ever having used Facebook, what is a facebook ID? From what I have seen, Facebook uses the real name of people while not having something that deserves to be called search, so people looking for Chris Scott are basically hosed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uinau-0001dn...@swivel.zugschlus.de
Re: default MTA
On Fri, 31 May 2013 08:41:56 +0200, Jean-Christophe Dubacq jcduba...@free.fr wrote: Le 30/05/2013 18:29, Marc Haber a écrit : On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters o...@vitters.nl wrote: Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. It is not a good idea to drop the way that 90 % of programs use to deliver messages. I really hate the idea of having a thing as fragile as dbus on a server just to collect status messages. 73.6% of all statistics are made up. You have a point here. I shold have written the vast majority. The way most programs deliver messages is actually syslog. Which is an epic nightmare to parse automatically if one needs to put messages in relation to each other and is only readable if all messages are shorter than, say, 160 characters. Even firewall log messages are way longer than that already. The most important of them being the kernel. We've been over it several times. As far as I know, the kernel does not send emails. The kernel does not use syslog as well. It just dumps the messages into a ring buffer and relies on some user space software to process those in time. If that user space software fails, messages are eventually overwritten and lost. A utility to scan syslog and convey important information to the user would be much more useful than configuring all mailers in Debian to read root's local mail by default. Alas, I would really love to have such an utility, I would even participate in crowdfunding such an utiltiy, but it does not exist yet. MTAs and MUAs exist and work. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uindz-0001df...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 19:51:04 -0400, Chris Knadle chris.kna...@coredump.us wrote: For Exim, the one thing I would want to change would be to ship a configuration that by default created an SSL certificate and enabled MAIN_TLS_ENABLE to enable TLS SMTP transfers. For e-mail coming in from other clients, with the local exim acting as a server? Certificates are usually only used in E-Mail when a server authenticates itself to a client before the client sends its authentication data. SMTP with client certificates is possible, but I have only seen this two times in 15 years of running E-Mail servers. [The Postfix package in Debian does this.] There's documentation and help for doing this for Exim in /usr/share/doc/exim4-base/README.Debian.gz in Section 2.2 though, and so I suspect there's a _reason_ why this isn't the default. Noone has yet written code to do that, and volunteered to document and support it. Personally, I think that before we improve Exim's packaging in Debian to be an SMTP server, we should first make it easiert to use Exim as a client with a smart host, thus debconfing the username/password and authentication scheme. Noone has volunteered to write that code, either. This wiki page has a nice summary http://wiki.debian.org/DefaultMTA I think the negative point of Support community limited outside of Debian is untrue. The exim-us...@exim.org mailing list is very active and responsive, and Exim has become the most popular MTA since sometime in 2008. Agreed, but exim's development speed has considerably slowed down since Philip Hazel retired. The exim community is still alive, but I'd say it's in limbo. Which is a real shame. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uinj2-0001ec...@swivel.zugschlus.de
Re: default MTA
On Mi, 29 mai 13, 15:59:35, Russ Allbery wrote: Andrei POPESCU andreimpope...@gmail.com writes: Exim is a listening daemon, even if it listens only on localhost in the default configuration. I'd prefer dma instead. It's better to have a listening daemon on localhost. There's no security threat, and there's some software that can't handle invoking a sendmail binary and always wants to speak SMTP to some port. I've run into this with both Java and PHP applications. This is, of course, possible to fix, but I can understand why Java programmers aren't thrilled by the idea of adding UNIX-specific code to fork and execute a program (which is something that you generally don't want to do in Java, since it's very expensive, and which is not portable), and similarly why web developers aren't enthused by fork and exec in a mod_php or similar context inside a possibly threaded web server. Maybe it makes sense to have virtual packages like mta-daemon, mta-forwarder, etc.? (regardless of which, if any, is installed by default) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: default MTA
* Chris Knadle chris.kna...@coredump.us [130529 08:29]: - Exim configuration is more human readable than Postifx's, IMHO. Postfix configuration is concise but terse, and there are typically blocks of options separated by commas that doesn't easily allow commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from kitchen parts with only the transparent tape for office use. The only positive thing you can say about Postfix' configuration is that it might be better than sendmail's. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530091105.ga3...@client.brlink.eu
Re: default MTA
On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. signature.asc Description: OpenPGP digital signature
Re: default MTA
On Wed, 29 May 2013 23:12:39 +0300, Andrei POPESCU andreimpope...@gmail.com wrote: On Mi, 29 mai 13, 21:52:04, Marc Haber wrote: Yes. And many systems have intermittent connectivity, which rules out non-queueing mini-MTAs. Exim does the Job pretty well, and people who know what an MTA is will probably install their own anyway, so there is no need to change. Exim is a listening daemon, even if it listens only on localhost in the default configuration. It comes listening on localhost in default configuration. It can be trivially configured not to listen at all, or to listen on all interfaces. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ui00y-0008jk...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 10:18:07 +0300, Andrei POPESCU andreimpope...@gmail.com wrote: Maybe it makes sense to have virtual packages like mta-daemon, mta-forwarder, etc.? (regardless of which, if any, is installed by default) Show code, or at least an explanation about how you intend to do that. How will, for example, the virtual package provided by exim change depending on the setting for the QUEUERUNNER config option? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ui02t-0008jy...@swivel.zugschlus.de
Re: default MTA
On Thu, May 30, 2013 at 12:16:38PM +0200, Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Indeed it is interesting. Whereas Debian has a majority of GNU/Linux installation for _web_ servers according to: http://w3techs.com/technologies/details/os-linux/all/all it's a _relative_ majority, smaller than the sum of the other distros you've cited. Here's an experimental way to test the assumption of Debian leadership on the mail server market: let's switch our default to Postfix and see if the figures change :-) /SCNR -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: default MTA
On Thu, 30 May 2013 04:04:14 +0800, Thomas Goirand z...@debian.org wrote: On 05/29/2013 11:32 PM, Javier Fernandez-Sanguino wrote: On 29 May 2013 17:11, Josselin Mouette j...@debian.org wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c (The code is different but already here in squeeze and wheezy.) I'm happy to see this use case is covered in GNOME. Me as well. Though not everyone uses GNOME (someone pointed out earlier in this list that we have more than 40 window managers in Debian!), and it is desirable, IMO, to also handle their use case. I think that people who are able to replace the default desktop with the desktop of their choice should be trusted to read their local mail as well. We may document this, but I don't think that we should spend personpower to provide a technical solution to that. There are things more important than that. We should make local mail or other messages trivially and automatically visible for people who have installed Debian in NNF[1] compliant way, but if one has gone to length to use something non-default, I think we can safely trust those people with taking other measures as well. Greetings Marc [1] Next, next, finish -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ui04x-0008k9...@swivel.zugschlus.de
Re: default MTA
On Thursday, May 30, 2013 12:16:38 PM Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Since ~80% of the Exim installations are for an ancient version that AFAIK tell from a few moments of checking was never the version in a Debian release, I don't think that's it. Scott K signature.asc Description: This is a digitally signed message part.
Re: default MTA
Ben Hutchings b...@decadent.org.uk writes: On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote: On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : Take for example, smartmoontools [1]. Currently, if an end-user installs smartmoontools and a hard-disk fails (i.e. smartd detects a problem with one HD) he will *not* see any notification: the failure is sent through local e-mail. He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c (The code is different but already here in squeeze and wheezy.) What you propose requires: * adding desktop environment specific code to every facility that may need to send notifications * adding such notifications to every other desktop environment Wrong, we already have org.freedesktop.Notifications in GNOME, KDE and Xfce. So those two points become: * adding cross-desktop code to every facility that may need to send notifications * adding a notification daemon to task-lxde There are libraries to help with the first point, of course. Wouldn't a daemon watching /var/mail/root and turning any mail into desktop notifications solve most of this, while still allowing the same notifications to reach a sysadmin on non-desktop systems? The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. The Clear, understandable and translated in his configured language point is unrelated the notification system. That requirement should be at least as strict for any mail to root. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u8opye0@nemi.mork.no
Re: default MTA
On Wed, 29 May 2013 19:45:06 -0400, Chris Knadle chris.kna...@coredump.us wrote: I don't like the fact that the /etc/exim4/passwd.client file is in a plaintext format, but there are usually several such files on systems such that realistically we're only really safe as long as the machines we run haven't been broken into. And if you think about things, it is clear that the client needs the plaintext password to be able to use it. Even if certificate authentication, the most secure authentication scheme available today, is used, you need the private key on the client. That's exactly the point, and is why I would prefer not to write those notifications into a file that no one ever looks at. (Which is why I don't find sending them to syslog much more appealing, since the average desktop user is never going to look there either.) Somehow this problem reminds me of the event log used on a popular operating system. Most users don't read that log either. This is partly caused by the utter unusability of the default program delivered to read that binary log. Even the best Jvaqbjf people I know need to be poked to use Rirag Ivrjre. Usually, this results in a quick solution since the Jvaqbjf Event Log isn't as bad as its reputation past the usual access method. But people rather continue blind trial-and-error methods before taking a look at their logs. Btw, I fear that systemd's binary logs are going to import this method of inefficient work in our world. I surely hope I am wrong on this count. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ui08g-0008ps...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 11:11:06 +0200, Bernhard R. Link brl...@debian.org wrote: * Chris Knadle chris.kna...@coredump.us [130529 08:29]: - Exim configuration is more human readable than Postifx's, IMHO. Postfix configuration is concise but terse, and there are typically blocks of options separated by commas that doesn't easily allow commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from kitchen parts with only the transparent tape for office use. While I don't consider postfix as bad as you describe, I tend to describe Postfix as the menu in a better restaurant: A relatively small number of sophisticated dishes which you can choose from, and if you like them, you will be perfectly satisfied. If you want fries instead of plain potatoes, you're basically hosed. Exim, on the other hand, is the fully equipped kitchen with a full larder and fridge, allowing you to cook exactly what you want, if you're willing to learn cooking or already bring some cooking knowledge. This approach might lead to something uneatable, though. Both solutions have their advantages and disadvantages. People should be able to choose. For the default case of an user not knowing what an MTA is, both exim and postfix are suitable to be the default in Debian. Exim's design is a bit 1990ies, with a big suid root binary, while Postfix's design is more modern regarding process structure and privilege separation. Being biased myself, I'd say not to change a running system and to keep exim as default. It would be nice to debconfize SMTP auth in the exim is the client case though, as this is a quite common use case. With my maintainer hat on, Patches are appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ui0gx-kg...@swivel.zugschlus.de
Re: default MTA
On Wednesday, May 29, 2013 05:11:35 PM Josselin Mouette wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : Take for example, smartmoontools [1]. Currently, if an end-user installs smartmoontools and a hard-disk fails (i.e. smartd detects a problem with one HD) he will *not* see any notification: the failure is sent through local e-mail. He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor .c (The code is different but already here in squeeze and wheezy.) I don’t see why he would need to see it again in a cryptic English e-mail. You are really looking for a solution to a nonexistent problem. Desktop notifications are really only useful for informing the user of things as they happen. If the user doesn't happen to be sitting at the screen when the notification happens, they'll never know. Even if they are using a system that allows them to go back and review their notification history when they return to their system, that's not the normal usage pattern. Desktop notifications are no more a complete solution to the problem of letting the user know than local mail is. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5100284.2cAPWE0nHA@scott-latitude-e6320
Re: default MTA
On 30/05/13 12:27, Scott Kitterman wrote: On Thursday, May 30, 2013 12:16:38 PM Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Since ~80% of the Exim installations are for an ancient version that AFAIK tell from a few moments of checking was never the version in a Debian release, I don't think that's it. Scott K Exim 4.69 was shipped with Debian 5.0 (Lenny) http://archive.debian.net/lenny/exim4 signature.asc Description: OpenPGP digital signature
Re: default MTA
On Thursday, May 30, 2013 01:01:46 PM Carlos Alberto Lopez Perez wrote: On 30/05/13 12:27, Scott Kitterman wrote: On Thursday, May 30, 2013 12:16:38 PM Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Since ~80% of the Exim installations are for an ancient version that AFAIK tell from a few moments of checking was never the version in a Debian release, I don't think that's it. Scott K Exim 4.69 was shipped with Debian 5.0 (Lenny) http://archive.debian.net/lenny/exim4 Thanks. I was looking at it wrong. It would, however, be a bit surprising if 1/3 of the mail servers on the internet were running Lenny at this point. It's also worth noting that only something like half the servers that provided a banner provided enough information to identify the software in use, so I'm not sure how much it really tells us. Scott K signature.asc Description: This is a digitally signed message part.
Re: default MTA
On 30-05-13 12:27, Marc Haber wrote: We should make local mail or other messages trivially and automatically visible for people who have installed Debian in NNF[1] compliant way, but if one has gone to length to use something non-default, I think we can safely trust those people with taking other measures as well. While that's true, if we're going to be make the effort to make sure such notifications are trivially and automatically visibe for NNF users, it would be a waste if we didn't do it in such a way that people who make only the slightest of modifications could benefit from it as well. If we're making something GNOME-specific, we don't do that. If we make an application that fits into any fdo-compliant notification area, we do. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a73882.4010...@debian.org
Re: default MTA
On 30-05-13 12:16, Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. From the bottom of that page: Exim (465,731 servers) Version Number of Servers Percent 4.69368,005 79.02% 4.7636,227 7.78% 4.7220,387 4.38% 4.7710,824 2.32% 4.678,297 1.78% 4.635,689 1.22% Other 16,302 3.50% 4.69 was the version of exim that shipped with Lenny; squeeze shipped with 4.72, wheezy with 4.80. If these are indeed all Debian servers, that would mean that 79.02% of 44.23% of 45.88% of all MX servers queried by these people use a no longer supported version of Debian. (79.02%: all exim servers running 4.69; 44.23%: percentage of all identifiable servers that is running exim; 45.88%: percentage of all MX servers that is running an identifiable mail server) -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a73b72.6020...@debian.org
Re: default MTA
On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman deb...@kitterman.com wrote: Even if they are using a system that allows them to go back and review their notification history when they return to their system, It just occurred to me that you are describing a mail client. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ui1nv-0001ra...@swivel.zugschlus.de
Re: default MTA
On Thursday, May 30, 2013 05:11:06, Bernhard R. Link wrote: * Chris Knadle chris.kna...@coredump.us [130529 08:29]: - Exim configuration is more human readable than Postifx's, IMHO. Postfix configuration is concise but terse, and there are typically blocks of options separated by commas that doesn't easily allow commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. There's a reason it feels like this. Postfix was designed with security in mind, but wasn't focused on being a general purpose MTA. It happens to /work/ pretty well in that role in many cases, though. http://shearer.org/MTA_Comparison#Postfix Exim is exactly the opposite: its design was focused on being a general purpose MTA, but wasn't focused on security. Yet this doesn't mean that Exim is insecure. http://shearer.org/MTA_Comparison#Exim Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from kitchen parts with only the transparent tape for office use. This feels like a fitting description. [Postfix's master.cf file is what I find the most confusing.] The only positive thing you can say about Postfix' configuration is that it might be better than sendmail's. Sendmail's configuration is so unreadable that nobody [in their right mind] configures it in the native format and instead does it with m4 scripts. However with m4 scripts I think Sendmail configuration might actually be less confusing than Postfix's. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: default MTA
On Thu, May 30, 2013 at 12:31:22PM +0200, Marc Haber wrote: Btw, I fear that systemd's binary logs are going to import this method of inefficient work in our world. I surely hope I am wrong on this count. journalctl gives pretty much exactly the same output as /var/log/messages and so on. As a side-benefit, instead of using grep, it indexes various things so you can more quickly filter. For most use caes though, the switch is rather easy: journalctl | grep something vs grep something /var/log/messages and journalctl -f vs tail -f /var/log/messages So if you don't want to know anything, you don't need to know much. Further, you can keep another syslog running. In any case, journal is quite efficient. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530114817.ga16...@bkor.dhs.org
Re: default MTA
On Thu, May 30, 2013 at 01:31:14PM +0200, Wouter Verhelst wrote: If we're making something GNOME-specific, we don't do that. If we make an application that fits into any fdo-compliant notification area, we do. Within GNOME we usually create a freedesktop.org solution, then use that within GNOME. This is how udisks works. A large generic part, then another GNOME-specific component. Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530115601.gb16...@bkor.dhs.org
Re: default MTA
On Thu, May 30, 2013 at 01:51:11PM +0200, Marc Haber wrote: On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman deb...@kitterman.com wrote: Even if they are using a system that allows them to go back and review their notification history when they return to their system, It just occurred to me that you are describing a mail client. Suggest receiving nagios notifications via email. Sometimes when you're busy your inbox is overloaded with stuff that is already up. Email is one way of getting notifications, but for desktop things, it is rather imperfect. Would be kind of funny to receive an email notification via email though :P -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530120057.gc16...@bkor.dhs.org
Re: default MTA
On 30-05-13 13:56, Olav Vitters wrote: On Thu, May 30, 2013 at 01:31:14PM +0200, Wouter Verhelst wrote: If we're making something GNOME-specific, we don't do that. If we make an application that fits into any fdo-compliant notification area, we do. Within GNOME we usually create a freedesktop.org solution, then use that within GNOME. This is how udisks works. A large generic part, then another GNOME-specific component. Sure. Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. No, that's not how I interpret the discussion. Doing important notifications through mail only means that many people won't see the important notifications due to the way we handle mail by default currently. So we need to fix that. However, the mail approach does have certain upsides for large installations and multi-user systems: - Regular users can't always see what's in syslog, so getting the output of their cron or at jobs there won't help them. - For the things that really really matter, it makes sense to have them sent to a central root mail address, so that in case of a large multi-system installation, the sysadmin knows when things go really really wrong. If we configure things so that root mail gets sent to the user that was created at install time by default, and then install some fdo notification thing that allows a user to read and mark read or delete (or both) mails in their local mailbox by default, that should work for both use cases. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a7457e.6020...@debian.org
Re: default MTA
Marc Haber mh+debian-de...@zugschlus.de writes: On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman deb...@kitterman.com wrote: Even if they are using a system that allows them to go back and review their notification history when they return to their system, It just occurred to me that you are describing a mail client. Let's add biff and we have cross-desktop real-time notification in place :) Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738t4oe7z@nemi.mork.no
