| |||||||||||||
Fedora keeps sendmail — for nowFedora keeps sendmail — for nowPosted Aug 9, 2013 11:02 UTC (Fri) by cas (subscriber, #52554)In reply to: Fedora keeps sendmail — for now by josh Parent article: Fedora keeps sendmail — for now
why are you "fixing" this? what is there to actually "fix"?
the whole point of having /usr/sbin/sendmail on a system (whether that's provided by sendmail, exim, postfix, ssmtpd or anything else) is that other programs don't have to know how to route or deliver mail, they just pipe it to /usr/sbin/sendmail.
you know, the unix "small tools" approach.
the alternative is every app implementing their own crappy, partial, half-arsed version of an MTA (calibre is an excellently example of why this job should not be left to application developers).
(Log in to post comments)
Fedora keeps sendmail — for now Posted Aug 9, 2013 11:04 UTC (Fri) by cas (subscriber, #52554) [Link]
s/excellently/excellently bad/
Fedora keeps sendmail — for now Posted Aug 9, 2013 11:39 UTC (Fri) by josh (subscriber, #17465) [Link]
There is exactly one program on my system that has any business sending mail, and that's my mail client. And it already knows how to speak SMTPS and IMAP.
Fedora keeps sendmail — for now Posted Aug 9, 2013 17:23 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
I disagree. I think being able to fire up my client wherever it is needed and as needed is much better than having to keep it open all the time to check email (and taking however much RAM thick email clients take these days). Having the sender separate allows for a queue to work without your client needing to run.
Fedora keeps sendmail — for now Posted Aug 9, 2013 18:17 UTC (Fri) by josh (subscriber, #17465) [Link]
Given that I use mutt, I'm not too worried about "RAM thick email clients". :)
I'm not sure what you mean by your first point, though; what does an MTA queue have to do with keeping your mail client open to *check* email?
Fedora keeps sendmail — for now Posted Aug 9, 2013 19:06 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
It was poorly worded. I was trying to get across that keeping your client open should not be a prerequisite for checking *or* sending email. Personally, I use esmtp (without a queue), mutt, offlineimap, and notmuch to deal with my email.
Fedora keeps sendmail — for now Posted Aug 11, 2013 10:52 UTC (Sun) by cas (subscriber, #52554) [Link]
1. it's nice to know that your particular needs exactly suit everyone else, and that nobody would ever want or need to do something that you don't think is necessary. because a single-user desktop or laptop is the perfect model for the future of unix.
2. there's more to sending mail than just speaking smtp.
queuing and routing are the most obvious - routing is less important these days where 99+% of MTAs on the net speak SMTP but still useful in many cases, e.g. routing some mail via a specific authenticated/encrypted MTA.
queuing is still important if your network link is down, or the recipient's MTA is busy/over-loaded/greylisting or just offline for whatever reason.
it's merely crazy to think that every app that might need to send mail should speak smtp (and possibly several other protocols), but it's gibberingly insane to think they should maintain their own queue, routing table, and delivery scheduler.
Fedora keeps sendmail — for now Posted Aug 11, 2013 14:01 UTC (Sun) by raven667 (subscriber, #5198) [Link]
Every device on the Internet, including Fedora devices, is not actually an MTA by default, so why should we pretend? Only devices set up to be mail servers, by ISPs, companies and webmail providers, who require authenticated submission for relaying, actually speak server-to-server SMTP.
Pretty much every mail client already speaks SMTP and doesn't use /usr/sbin/sendmail and it has been that way for decades, they will also hold mail in an Outbox so aren't reliant on the local MTA for queueing. This is not just GUI clients like Evolution, KMail or Thunderbird but also PINE and mutt speak SMTP. Only crazy people are still using mailx as their day-to-day MUA 8-)
Also, local delivery to /var/lib/mail is bad for the default system because only a few utilities like mailx still can read from there, and most messages are destined to users who don't interactively log in at all. Those messages disappear down a black hole and we would all be better served if they went to syslog by default. Of course if you want cron mail, install ssmtp and configure it to go to your central mail hub.
This isn't to say that /usr/sbin/sendmail isn't an API for scripts and programs to send mail, but that is a small case which doesn't _require_ a full MTA such as sendmail or postfix, a small shim like ssmtp is more appropriate, and should be listed as a dependency for programs which require it.
Fedora keeps sendmail — for now Posted Aug 11, 2013 14:19 UTC (Sun) by cas (subscriber, #52554) [Link]
> Every device on the Internet, including Fedora devices, is not
> actually an MTA by default, so why should we pretend? [...]
did you ever notice that the internet is a peer to peer network and not a producer to consumer network?
> Also, local delivery to /var/lib/mail is bad for the default system
you must be using some crappy distribution that doesn't have or enforce packaging policy and standards. a decent distribution *requires* all mail-clients that can access local mail stores to access them in the same location...not doing so is a serious bug.
> This isn't to say that /usr/sbin/sendmail isn't an API for scripts and
thank you for re-iterating my point. it really doesn't matter whether /usr/sbin/sendmail is provided by postfix, exim, sendmail, smail, qmail, ssmtp or some hacked up shell script as long as it reacts correctly to the input and the command-line options.
Fedora keeps sendmail — for now Posted Aug 11, 2013 16:59 UTC (Sun) by josh (subscriber, #17465) [Link]
> 1. it's nice to know that your particular needs exactly suit everyone else, and that nobody would ever want or need to do something that you don't think is necessary. because a single-user desktop or laptop is the perfect model for the future of unix.
I never suggested that my preferences applied universally. I stated what applied to my own system. Nothing stops people from installing and configuring an MTA on their system if that's their preferred way of handling email. I don't, however, believe that's the right default for end-user client systems, because most users will either use webmail or configure a MUA to talk directly to their real mailserver; thus, I'd argue that when installing such systems, distros should not install an MTA by default.
> queuing is still important if your network link is down, or the recipient's MTA is busy/over-loaded/greylisting or just offline for whatever reason.
My MUA does talk to a proper queuing MTA (via SMTPS) for exactly that reason; that MTA just doesn't live on my laptop. MUAs certainly shouldn't talk directly to recipient MTAs, nor would I advocate the elimination of MTAs in general; I'd simply suggest that the majority of systems want to talk to a mail server elsewhere rather than running one locally.
> it's merely crazy to think that every app that might need to send mail should speak smtp (and possibly several other protocols),
A MUA just needs to speak SMTP(S) to send mail, no other protocol. And that's no crazier than expecting every app to fork and exec sendmail to send mail; it's just different.
Any app other than the user's a MUA that wants to send mail on behalf of the user can invoke the user's MUA to do so. See https://lwn.net/Articles/562141/ , in particular the discussion about evolution as a desktop service, for some discussion of that approach.
That also fixes a major bug present when apps think they can just chat with sendmail to send mail: making sure that every outgoing mail ends up in the Sent folder in the user's MUA.
> but it's gibberingly insane to think they should maintain their own queue, routing table, and delivery scheduler.
Of course not. A MUA should not be queuing and scheduling mail; at most, a MUA might have an outbox of mail it couldn't send to the user's MTA due to being offline, and it can retry sending that mail when online again. That's not a complicated policy.
Fedora keeps sendmail — for now Posted Aug 11, 2013 23:39 UTC (Sun) by cas (subscriber, #52554) [Link]
> A MUA just needs to speak SMTP(S) to send mail, no other protocol.
> And that's no crazier than expecting every app to fork and exec > sendmail to send mail; it's just different.
IMO it is crazier. it's certainly less functional, and requires a hell of a lot of code duplication and re-implementation because every app or script that *might* need to send mail has to have their own smtp implementation (with, at least, sending and simple queueing abilities) rather than relying on a standard executable they can pipe to.
worse, it makes sending mail from shell scripts far more difficult - instead of piping to /usr/sbin/sendmail, you now have to implement a minimal smtp in sh or bash (perl or python would be a little easier because they already have smtp libraries - but you'd still have to implement a queue in case the remote MTA was down or unreachable).
and each one of those apps and scripts has to be configured with the user's credentials if the remote MTA requires authentication...so lots of duplication of credentials too.
> Any app other than the user's a MUA that wants to send mail on
and how, exactly, is another app or script supposed to figure out which MUA the user uses? or what it's command line options are? or even if it has command-line options to send mail (i mostly use mutt, but i occasionally use icedove - 'icedove --help' doesn't seem to show any capability to be used by another program to send mail)
what if multiple MUAs are installed - how does the app tell which one the user uses or prefers, or which one is actually configured to send mail?
it makes far more sense to just rely on the presence of a /usr/sbin/sendmail executable with standardised command line options (and a man page to document those options). that's what it's for.
Henry Spencer's line seems appropriate here:
"Those who don't understand Unix are condemned to reinvent it, poorly."
Fedora keeps sendmail — for now Posted Aug 12, 2013 2:27 UTC (Mon) by josh (subscriber, #17465) [Link]
>> A MUA just needs to speak SMTP(S) to send mail, no other protocol.
>> And that's no crazier than expecting every app to fork and exec >> sendmail to send mail; it's just different.
> worse, it makes sending mail from shell scripts far more difficult
I said a MUA, not a shell script. I don't expect shell scripts to speak SMTPS (though something like Python or Perl certainly can). See below.
>> Any app other than the user's a MUA that wants to send mail on
> and how, exactly, is another app or script supposed to figure out which
There's an "xdg-email" command which opens a draft mail in the user's preferred mail client. Desktop environments also have standard mechanisms of asking what program they should run, which they use to implement the "Send via email" commands and similar.
I'd also point out that you seem to be taking personal offense at the idea that your preferred mode of operation might not be the perfect default for everyone. Nobody's talking about removing MTAs; the question is whether a desktop Linux distribution might want to optimize for the single-user desktop use case.
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:24 UTC (Mon) by cas (subscriber, #52554) [Link]
> I said a MUA, not a shell script.
you're making an arbitrary and false distinction. any script that sends mail is a (primitive) MUA - pretty graphics or even an ncurses interface are not required.
> There's an "xdg-email" command which opens a draft mail in the user's
xdg-* just defines the default MUA installed. it doesn't tell another app or script which MUA the user actually uses, and which one is actually configured.
nor does it tell a potential calling-app/script what command line options it has - i notice you completely ignored my point that /usr/sbin/sendmail provides standard and well-documented command-line options for other programs to use to send mail, whereas thunderbird (for example) does not...and (according to --help) doesn't even seem to be capable of doing that.
since not all MUAs actually provide that function, it's crazy to say "/usr/sbin/sendmail isn't needed, just use an MUA". "use something that *might* work if you're lucky" is not a solution, it's broken.
> I'd also point out that you seem to be taking personal offense at
no, i'm taking offence at short-sighted idiocy, lack of understanding of systems design, and the contempt for users that you are displaying ("they're too dumb to understand that"). users aren't as stupid or as incompetent as you claim.
Fedora keeps sendmail — for now Posted Aug 12, 2013 15:49 UTC (Mon) by josh (subscriber, #17465) [Link]
>> I said a MUA, not a shell script.
> you're making an arbitrary and false distinction. any script that sends mail is a (primitive) MUA - pretty graphics or even an ncurses interface are not required.
The difference is that the MUA is the program the *user* invokes when they want to send mail.
MTAs can work nicely for fully automated mail (when configured appropriately on a network that supports them). Not every user wants or needs fully automated mails sent on their behalf; in particular,
To put it bluntly: I don't *want* sendmail to work on my system, because then programs might go around thinking they get to send mail without my involvement. You're arguing as though every single system has a pile of programs with a legitimate reason to send mail, which might have been true on UNIX systems of yore, but is no longer true on a modern Linux system.
In any case, I'm not going to spend time arguing the merits of modern mail clients. MTAs have a target audience of mail server administrators. MUAs have a far broader target audience, and the authors of modern MUAs spend far more time on UX and ease of use. If you believe that both are equally easy to configure, I have no interest in trying to convincing you otherwise.
Fedora keeps sendmail — for now Posted Aug 9, 2013 15:15 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
The presence of /usr/bin/sendmail is not a guarantee that the system has a *configured* MTA, and as such it's an appalling API for applications to depend on. Meanwhile, mail applications still need to know how to speak various mail protocols because individual user requirements don't necessarily match the global system configuration - I don't want to have to code my work credentials into global configuration just so I can send work email.
Fedora keeps sendmail — for now Posted Aug 9, 2013 18:49 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
> I don't want to have to code my work credentials into global configuration just so I can send work email.
I think esmtp handles this fine with ~/.esmtprc (msmtp and ssmtp are similar IIRC), so it's not impossible to get this without reimplementing SMTP support in every client ever.
Fedora keeps sendmail — for now Posted Aug 9, 2013 19:30 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
But apps can't depend on esmtp being installed.
Fedora keeps sendmail — for now Posted Aug 9, 2013 19:37 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Well, they can. They can't depend on it being *configured* properly. I don't see a reason that, say KMail, couldn't require esmtp and store SMTP settings in ~/.esmtprc rather than its own configuration file somewhere else.
Fedora keeps sendmail — for now Posted Aug 9, 2013 19:43 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
And if the system has postfix installed as /usr/bin/sendmail?
Fedora keeps sendmail — for now Posted Aug 9, 2013 23:01 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
If you configure esmtp directly, call it directly as well?
Fedora keeps sendmail — for now Posted Aug 11, 2013 11:07 UTC (Sun) by cas (subscriber, #52554) [Link]
> The presence of /usr/bin/sendmail is not a guarantee that the system
> has a *configured* MTA
that's really not a compelling or even convincing argument.
the presence of your mail client is no guarantee that it's configured correctly. ditto for every other piece of software installed.
here's something for you to consider: if service foo is misconfigured or broken, where is the correct place to fix it? in service foo itself or in client bar?
> Meanwhile, mail applications still need to know how to speak
first you argue that the MTA might not be configured correctly, and then you say that it's OK for it to be misconfigured, just work around it in every app - each one of which can have it's own incomplete, conflicting, misconfigured and most likely half-arsed implementation of an MTA.
this is why programmers shouldn't make systems decisions.
do you even know what a unix system is? or why the small-tools approach has worked so well for decades?
> I don't want to have to code my work credentials into global
then don't. there's - slight exaggeration - a million ways for you to address your special needs that don't involve crippling distros by default.
Fedora keeps sendmail — for now Posted Aug 11, 2013 12:54 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> then don't. there's - slight exaggeration - a million ways for you to address your special needs that don't involve crippling distros by default.
"Special needs"???
I bet that at least 90% of users have to use some form of authenticated submission to send mail these days.
Fedora keeps sendmail — for now Posted Aug 11, 2013 13:11 UTC (Sun) by cas (subscriber, #52554) [Link]
yes, special need. his special need is that he wants to authenticate with his work server without, for some reason, involving an MTA.
as i said, there are many ways of achieving that.
Fedora keeps sendmail — for now Posted Aug 11, 2013 13:13 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> yes, special need. his special need is that he wants to authenticate with his work server without, for some reason, involving an MTA.
"Some reason" is "no world-readable passwords in plaintext".
I'd argue that anybody who keeps passwords on laptops unencrypted should have their head examined.
> as i said, there are many ways of achieving that.
Fedora keeps sendmail — for now Posted Aug 11, 2013 14:09 UTC (Sun) by cas (subscriber, #52554) [Link]
> "Some reason" is "no world-readable passwords in plaintext".
> I'd argue that anybody who keeps passwords on laptops unencrypted > should have their head examined.
right, because storing your credentials in your thunderbird or other MUA config or in ~/.muttrc or .fetchmailrc is so much more secure than storing them in a system config file readable only by root.
hint: they're all insecure if the laptop is lost or stolen. also, $user-readable credentials are slightly more insecure if someone has a few minutes access to the laptop.
you know what is (relatively) secure? using a local MTA and configuring it to use a certificate issued by your work to authenticate with your work server. even if your laptop is stolen, your login and password are not leaked and the certificate can be revoked.
even tunneling smtp to $work_server over ssh is more secure than storing your credentials on a laptop.
> > as i said, there are many ways of achieving that.
here, let me google that for you. answering trivial FAQs for you is my entire purpose in life. i'll get back to you with a complete report as soon as i have nothing more important to do.
Fedora keeps sendmail — for now Posted Aug 11, 2013 14:41 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> right, because storing your credentials in your thunderbird or other MUA config or in ~/.muttrc or .fetchmailrc is so much more secure than storing them in a system config file readable only by root.
Yes, they ARE more secure. Because they use a keychain which can be unlocked only by my password which I have to enter each time I resume my computer from sleep.
Besides, my /home/username directory is also encrypted by ecryptfs.
And neither of your solutions is actually implemented by the majority of mail relays out there.
Fedora keeps sendmail — for now Posted Aug 15, 2013 13:50 UTC (Thu) by nye (guest, #51576) [Link]
>here, let me google that for you. answering trivial FAQs for you is my entire purpose in life. i'll get back to you with a complete report as soon as i have nothing more important to do.
Except apparently ranting insanely about how your absurdly inconsequential use case should be the default inflicted upon millions of people, who would both need to spend the time reconfiguring their system to a semblance of sanity, assuming they somehow *know* that their system was configured by a selfish lunatic by default.
Christ, what an asshole.
Fedora keeps sendmail — for now Posted Aug 17, 2013 8:01 UTC (Sat) by cas (subscriber, #52554) [Link]
actually, it's you that's the arsehole.
and an ignorant fuckwit, too.
Enough Posted Aug 17, 2013 13:05 UTC (Sat) by corbet (editor, #1) [Link] Please... It's starting to feel like an elementary school playground here. Could I ask everyone to relax a bit and hold off on the personal attacks?
Enough Posted Aug 17, 2013 15:38 UTC (Sat) by cas (subscriber, #52554) [Link]
sure, but that's "attack" (singular) followed by retaliation - self defense is not an attack.
Fedora keeps sendmail — for now Posted Aug 11, 2013 17:09 UTC (Sun) by josh (subscriber, #17465) [Link]
> here's something for you to consider: if service foo is misconfigured or broken, where is the correct place to fix it? in service foo itself or in client bar?
A very reasonable point, but you've got it flipped around. If the user wants to run a mail client, the mail client is the thing to configure. And given the choice of configuring the mail client to talk to the user's mail server via SMTP, or configuring a local mail server to use the user's mail server and configuring the mail client to talk to that local mail server, the former ends up with far less configuration.
On top of that, with the former setup, when the user's mail client says a mail is sent, it's *actually sent*, rather than potentially sitting in a mail queue on the user's system where it might get lost without the user knowing. Not every user wants to be a mail server admin.
>> Meanwhile, mail applications still need to know how to speak
> first you argue that the MTA might not be configured correctly, and then you say that it's OK for it to be misconfigured
You've entirely missed the point of the statement you replied to. There may not be *any* valid system configuration for an MTA. The smarthost each user uses for their own mail is not necessarily suitable for use in the system configuration, either because the user may not want the system sending automated mail as them, or because the user doesn't want to store the credentials for their mail account systemwide. That's not a misconfigured MTA, that's a system where all the user's have their own mail server already and it doesn't live on the local system. If you want to argue that a user's *session* should include something similar to an MTA, that's an interesting idea, but that doesn't mean a systemwide MTA makes sense on systems that aren't the mail server for a given domain.
Fedora keeps sendmail — for now Posted Aug 11, 2013 18:47 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
"the presence of your mail client is no guarantee that it's configured correctly. ditto for every other piece of software installed."
What you're missing is that, even though Fedora currently installs sendmail by default, Fedora doesn't configure it by default. The same is true of many other Linux distributions. A client has no way to figure out whether sendmail will actually deliver remote mail or not, and nor does it have any way to report that to the user.
So sure, you can assert that /usr/bin/sendmail should always be configured in such a way that it will deliver mail to remote users. That doesn't make it true, and when writing software it makes more sense to conform to reality than to some platonic ideal.
(does the Debian installer even configure exim by default these days? My understanding was that it doesn't)
"do you even know what a unix system is? or why the small-tools approach has worked so well for decades?"
I've been a professional admin on Linux, Tru64 and (for my sins) Irix, and I've got an actual SVR4 box around here somewhere, so yeah, I've got some experience of that. But you seem to have misconstrued my argument. Would the world be a better place if all clients used a single implementation of SMTP? Yes, I think it would. Does that mean that the single implementation of SMTP should be a globally configured daemon? No. The argument that all mail should be sent via /usr/bin/sendmail is equivalent to arguing that all browsers should be hardcoded to talking to a machine-local proxy.
"then don't. there's - slight exaggeration - a million ways for you to address your special needs that don't involve crippling distros by default."
So, first, point me at a distribution that *by default* guarantees that /usr/bin/sendmail will be (a) present and (b) correctly configured. And then describe three of those ways.
Fedora keeps sendmail — for now Posted Aug 11, 2013 23:48 UTC (Sun) by cas (subscriber, #52554) [Link]
what you're missing is that it's not the MUAs job to figure out whether the local MTA is configured or not, same as it's not the MUAs job to figure out if the filesystem is corrupted or if the network is up or any one of a million other things that it should just rely on other parts of the system to do.
ditto for any other app or script that might need to send mail. it's not their job.
> I've been a professional admin on [...]
then you really should know better than to propose that system level services should be run out of a user's home directory...and definitely know better than to discard the modular, replaceable small-tools component model of unix for the MS jack-of-all-trades-master-of-none model.
Fedora keeps sendmail — for now Posted Aug 12, 2013 0:10 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Are you living is some impervious bubble?
System-level MTAs in default installations haven't been working AT ALL for at least 15 years.
So your choices are:
Fedora keeps sendmail — for now Posted Aug 12, 2013 0:43 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> System-level MTAs in default installations haven't been working AT ALL for at least 15 years.
we are living in different worlds.
Works for me.
Fedora keeps sendmail — for now Posted Aug 12, 2013 0:47 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Ok.
I'd gladly bet $100 that you can't use the default installation of Debian/Ubuntu to send a mail to alex.besogonov@gmail.com using the default MTA configuration, from within StarBucks network or any other random WiFi hotspot.
Fedora keeps sendmail — for now Posted Aug 12, 2013 1:51 UTC (Mon) by cas (subscriber, #52554) [Link]
1. sending mail from a public wifi is a special case that needs to be authenticated - nobody sane allows mail clients to connect and send from outside their network without authentication.
2. the reason why that can be tricky to implement is not because the configuration is difficult but because of 1. above - nobody sane lets external clients relay through them without authentication.
3. given that it's a special case that needs special configuration, the best place to configure it is *once* in the local system MTA and **NOT** multiple times in every app or script that needs to send mail.
4. as i mentioned in a previous post, the calibre application is an excellent example of exactly why sending and queuing mail should not be left to application developers who clearly do not understand how mail works. calibre's author is an expert in ebook formats - unfortunately, he thinks that makes him an expert in everything else (including smtp and security and GUI design, all of which he is atrocious at).
even more unfortunately, it's only one of many examples - and removal of a standard tool (/usr/sbin/sendmail) would only encourage proliferation of crappy, sub-standard, poorly-understood smtp implementations by people who have no idea what they're doing.
it's classic programmers NIH disease - rather than take the time to understand and make use of an existing system tool, they'll reinvent a half-arsed incomplete and shoddy implementation of it....and then refuse to see why it's a terrible idea for every other program to do the same.
Fedora keeps sendmail — for now Posted Aug 12, 2013 1:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> 1. sending mail from a public wifi is a special case that needs to be authenticated - nobody sane allows mail clients to connect and send from outside their network without authentication.
Whiskey Tango Foxtrot? This is NOT a special case! That's about as mundane use-case as it gets.
Ok, I get it. You don't even have an idea how people actually use their computers.
Fedora keeps sendmail — for now Posted Aug 12, 2013 2:10 UTC (Mon) by cas (subscriber, #52554) [Link]
no, it's just that i think - actually, *know* - that sending mail from a starbucks wifi connection is only a tiny subset of what people do with their computers.
optimising for that one special case is, to put it bluntly, FITH.
Fedora keeps sendmail — for now Posted Aug 12, 2013 2:22 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
I made a test on my home Internet connection. Same result.
Or do you argue that home users are just a filth that doesn't merit attention of developers? Maybe we should care only about 'serious' users?
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:10 UTC (Mon) by cas (subscriber, #52554) [Link]
mmmm yum. i love the taste of strawman
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:14 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
So care to answer?
A significant majority of home users simply can not send email using plain SMTP. What are you proposing to do?
Fedora keeps sendmail — for now Posted Aug 12, 2013 2:35 UTC (Mon) by josh (subscriber, #17465) [Link]
Systems privileged to act as mail servers, running on an IP that's not blacklisted, on a network that allows outbound unencrypted SMTP to random MXes, and maintained well enough to actually maintain reasonable deliverability metrics, are the vanishingly small special case compared to end-user client systems. Maintaining such a system requires non-trivial expertise. Congratulations, it sounds like you have it. Don't assume every random end-user does; it's far easier to tell your MUA "my mail server is over there".
Every single person I know who maintains a mail server on their personal system has had at least one incident where they either lost mail or had it delayed for days stuck in a mail queue somewhere. Life's too short. If you want to run your own mail server, please go right ahead; nobody is stopping you. However, many Linux distributions are trying to optimize for user-friendliness these days, not just flexibility and applicability to every possible use case. (See also http://islinuxaboutchoice.com/ .)
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:33 UTC (Mon) by cas (subscriber, #52554) [Link]
> it's far easier to tell your MUA "my mail server is over there".
it's nowhere near as difficult as you are pretending it is.
it's far easier to tell your MTA *once only* "my smarthost is there", than to have to configure the same information in every program that needs it - and then to re-configure them all when you change ISP or mail provider. or when you realise you need to handle work mail differently to personal mail.
> However, many Linux distributions are trying to optimize for
the mistake you and your ilk are maing is assuming that "user-friendly" equals "crippled and dumbed-down". it's the same mistake microsoft made in the 80s...that apple managed to avoid until the late 90s.
if you want a system like that, there are several available - you don't need to turn linux into a clone of mac or windows. OS X is actually a pretty good system.
really, if you hate unix or linux that much, why do you even try to use it? use something else that suits your needs better instead of trying to ruin the things about linux that make it good.
Fedora keeps sendmail — for now Posted Aug 12, 2013 14:05 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Perform a stock Debian install, performing no additional configuration steps. Connect this computer to a standard residential internet connection which blocks outgoing port 25 (as the vast majority do). Are you able to send email to arbitrary email addresses?
Fedora keeps sendmail — for now Posted Aug 12, 2013 20:55 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
If you set the Debian install to use your ISPs mail server as it's smarthost, then yes, you probably can send mail to arbitrary addresses on the Internet (at least, if you send them from an e-mail address your ISP assigned to you)
Fedora keeps sendmail — for now Posted Aug 12, 2013 20:59 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
That would be an additional configuration step, so it doesn't answer my question.
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:10 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
that configuration is done during the install, as others have pointed out.
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:25 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Having just performed a Debian install, I can assure you that it isn't.
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:45 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
since you are saying that this has to work without any configuration step, I'm surious as to what MUA you are using that works without any configuration.
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:48 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Sigh. No, that's not what I'm saying. What I'm saying is that you can't depend on there being a system-wide MTA that can deliver to the outside world, and as such any software that's expected to run on arbitrary machines cannot rely on the sendmail command doing anything useful.
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:48 UTC (Mon) by cas (subscriber, #52554) [Link]
if that's the case, it would only be because people like you have succeeded in having an MTA (the default used to be exim) excluded from the default install. and then to add insult to injury you triumphantly claim "look, it doesn't work, i told you so!".
if that's the case then i wouldn't have noticed because i always install postfix instead of exim. and i can assure you that when you do install an MTA in debian, it does indeed offer to create a basic configuration for you with about 4 or 5 options for you to choose from - one of which is "send all mail through a smarthost"
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:56 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Exim's still installed by default, it's just not configured to do remote delivery.
Fedora keeps sendmail — for now Posted Aug 13, 2013 8:48 UTC (Tue) by anselm (subscriber, #2796) [Link] But that still leaves you out in the cold if your ISP wants you to submit mail to port 587 with TLS and SMTP AUTH. You will need to configure that manually – in a manner that depends on your specific MTA – after the installation. The fact remains that ISP mail setups are diverse enough that any method of getting mail off the local machine – via a local MTA or an MUA – requires configuration. Instead of debating whether a system should come with a full-blown MTA like Sendmail by default, it would arguably be more productive to come up with a standardised scheme of representing ISP mail setups such that a user could be asked »What is your e-mail address (and possibly submission password)?« and the system could figure out automatically, for a reasonable majority of common ISPs, how to configure the local MTA or MUA of the user's choice to actually send mail using whatever access method that ISP supports, including goodies like encryption if it is available.
Fedora keeps sendmail — for now Posted Aug 13, 2013 10:02 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
i don't think that you would find anyone who is opposed to such a tool being created.
Just the work of identifying the different types of access, enumerating them, and maintaining a list of per-ISP configs would be of immense value.
then configuring MTA or MUA software from that data would be much easier.
and by the way, as long as the actual work of configuring the MTA/MUA was modular and scriptable, this would also fit into the "Unix way" quite nicely :-)
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:33 UTC (Mon) by cas (subscriber, #52554) [Link]
oh no! the sky is falling! an ISP that blocks smtp makes sending mail difficult. and it's all the MTA's fault.
this is even more contrived than the last example someone posted.
it's also a good example of why a local MTA is useful...you've got a lot more tricks up your sleeve to work around blockage with an MTA than you have with an MUA.
next up, "try to send mail from a laptop with a dead battery, during a power outage with no wifi or wired network available. you can't, see! and it's all the stupid MTA's fault".
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:40 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The vast majority of residential ISPs block outgoing port 25 traffic, and those that don't will probably still be unable to deliver mail because their IP blocks will be in SORBS. This isn't a contrived example. This is the common case.
Fedora keeps sendmail — for now Posted Aug 12, 2013 21:53 UTC (Mon) by cas (subscriber, #52554) [Link]
and the user will have just as much (or more) difficulty configuring an MUA to work around the block.
stop pretending that this is the MTA's fault.
Fedora keeps sendmail — for now Posted Aug 12, 2013 22:00 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
This discussion started with you claiming "the whole point of having /usr/sbin/sendmail on a system (whether that's provided by sendmail, exim, postfix, ssmtpd or anything else) is that other programs don't have to know how to route or deliver mail, they just pipe it to /usr/sbin/sendmail." Perhaps that's how it should be - there are clear benefits to things being configured in one place, and there are clear benefits to not reimplementing SMTP dozens of times. But, unfortunately, that's not how it is. If you want to send mail, you can't depend on the sendmail command.
Fedora keeps sendmail — for now Posted Aug 12, 2013 22:37 UTC (Mon) by cas (subscriber, #52554) [Link]
and as i said several times previously, you can't depend on the MUA being configured or working either.
just saying "it's too hard" and giving up is not a solution.
to configure either an MUA or an MTA there's a certain minimum amount of knowledge and understanding (or at least facts, like the smarthost name or IP address) required.
the same questions will be asked of the user, and a useful answer required - whether that's asked in a dialog/whiptail popup, a GUI dialog, or a plain tty style.
also, some here seem to think that only a GUI or ncurses app is an MUA. or that only automated scripts, cron job need to send mail via command-line interface.
/usr/sbin/sendmail *IS* an MUA. as is /usr/bin/mail. I can use them to send useful information to any email address....and I can do it reliably and conveniently, with consistent and documented command-line options.
grep foobar /var/log/something.log | sendmail me@somewhere.example.com
that's using an MUA. if i want to get fancy, i can use other command-line tools to compress the log extract and send it as a properly formatted mime-attachment.
Fedora keeps sendmail — for now Posted Aug 12, 2013 22:46 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
"and as i said several times previously, you can't depend on the MUA being configured or working either."
Yup. As a result, email's a poor default for reporting things, and so josh is trying to fix the fact that there are still things in Debian that default to logging via email. As you've demonstrated, it's easy to bridge from syslog to email if you know that your local configuration supports that.
Fedora keeps sendmail — for now Posted Aug 12, 2013 1:37 UTC (Mon) by cas (subscriber, #52554) [Link]
> System-level MTAs in default installations haven't been working
> AT ALL for at least 15 years.
extraordinary claims require extraordinary proof. or, in other words,
debian manages to configure an MTA (with about 4 or 5 simple options for the user at install time, two of which are "use a smarthost" and "i'll configure it myself"). debian's been doing that for well over 15 years, and manages to do it for at least exim (the default), postfix, and sendmail. if fedora can't do that, it's not the MTA that's at fault, it's fedora.
Fedora keeps sendmail — for now Posted Aug 12, 2013 1:42 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Simple.
1) Install a recent Debian/Ubuntu, make sure 'mailutils' package is installed. The default Postfix option is "Internet site", btw.
2) Do "mail -s 'test' blah@gmail.com'".
3) Observe that it doesn't work from 99% of networks.
I just did it, btw:
Fedora keeps sendmail — for now Posted Aug 12, 2013 2:16 UTC (Mon) by cas (subscriber, #52554) [Link]
> Simple.
not.
your one contrived example does not constitute extraordinary proof of an extraordinary claim.
you also seem to have some sort of comprehension problem where you ignore 99% of what has been said and focus on some trivial - or non-existant - point and then pretend that it's the smoking gun that proves your argument. this was mildly annoying at first but has now become tedious, which is unforgivable. bye.
Fedora keeps sendmail — for now Posted Aug 12, 2013 2:21 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> your one contrived example does not constitute extraordinary proof of an extraordinary claim.
WHAT IS FREAKING 'CONTRIVED' IN THIS EXAMPLE???
I got a Ubuntu 13.04 CD image, installed it in a VM and tried to send an email. I have a bog-standard home Internet connection and I haven't performed anything outstanding at all.
So you're proposing that we keep a _broken_ interface, that is impossible for normal users to configure and that hasn't worked for ages. All in the name of 'unixyness'.
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:10 UTC (Mon) by cas (subscriber, #52554) [Link]
> WHAT IS FREAKING 'CONTRIVED' IN THIS EXAMPLE???
I have no idea, because I have no idea what you actually did or didn't do. neither do i have any idea how dumb you're pretending to be to prove your point, or how dumb you actually are.
what i do know is that configuring an MTA to do a trivial task like sending an email from a desktop or laptop to an address @gmail.com is NOWHERE NEAR AS DIFFICULT AS YOU ARE PRETENDING IT IS. If it didn't work, it's because you deliberately broke it.
> So you're proposing that we keep a _broken_ interface, that is
it's nowhere near impossible. for simple stuff like you claim to have tried, it's trivial.
any user who finds answering a single question at install-time ("what's your smarthost?") too difficult is going to have *exactly* the same comprehension problem answering the same question for their pretty GUI MUA.
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> I have no idea, because I have no idea what you actually did or didn't do.
I described it - I took a stock Ubuntu image, installed it in a VM and tried to send a mail.
What exactly you don't understand?
>any user who finds answering a single question at install-time ("what's your smarthost?")
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:35 UTC (Mon) by cas (subscriber, #52554) [Link]
> What IS a smarthost?
what is a mail server? what is a mail relay? how many facetious questions can you ask in the name of pretending ignorance?
Fedora keeps sendmail — for now Posted Aug 12, 2013 11:47 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Actually, what is a mailserver? Most people simply don't care - they want their systems work reliably and with minimal setup.
You know, fanboys like you is a major factor that'd been limiting Linux desktop for many years.
Fedora keeps sendmail — for now Posted Aug 15, 2013 15:45 UTC (Thu) by smurf (subscriber, #17840) [Link]
Please think before replying.
The default email installation works by looking up an MX record and connecting to port 25 there.
The default firewall of almost every home OR corporate user explicitly blocks port 25 because too many viruses and worms install too many spambots on too many Windows systems with nonexistent or broken security.
Do you NOW understand why installing a standard Unix-style mailer no longer make sense?
Most home users no longer even have a smarthost they could use without SMTP authorization, so even if people knew what a smarthost is (which they typically don't) asking them about that at installation time will not be helpful.
Fedora keeps sendmail — for now Posted Aug 17, 2013 8:04 UTC (Sat) by cas (subscriber, #52554) [Link]
no, there's nothing to understand because you're still pretending that that is an issue that affects *ONLY* an MTA, that MUAs are somehow magically immune.
you are either mistaken or being deliberately deceptive. i'll give you the benefit of the doubt and assume you just haven't thought it through.
configuring an MTA to use a smarthost/relay/mail-server with authentication is NO MORE DIFFICULT than doing exactly the same thing in an MUA.
Fedora keeps sendmail — for now Posted Aug 17, 2013 11:43 UTC (Sat) by anselm (subscriber, #2796) [Link] configuring an MTA to use a smarthost/relay/mail-server with authentication is NO MORE DIFFICULT than doing exactly the same thing in an MUA. I'm not so sure. Kmail, for example, will probe a SMTP server for the best way to connect, including encryption and authentication. All the user needs to provide is the SMTP server's name and possibly their own user name and password for SMTP AUTH – and they get to put that into a reasonably obvious to find, convenient, and straightforward GUI dialog. It is also easy to maintain different »identities« with their own methods of sending mail to different submission servers, and to select between these when composing a message. Getting an MTA like Sendmail or Postfix to do the same usually involves figuring out which of a set of fairly obscure configuration files to edit, which parameters to tweak in which way, and so on. Normally you get to edit at least two different text files and may even have to remember to run a file through some command-line program in order to put it into the binary database format that the MTA will actually look at. With most MTAs, it is possible to assign different sender addresses their own smart hosts etc., but doing so for a given MTA – even a fairly straightforward one like Postfix – is way more than people will be happy to have to learn just to be able to send e-mail. In a distribution like Debian, the popular MTAs do come with a setup method that lets the installer pick one of a small number of alternatives (directly connected to the Internet/connected via a smart host/local mail only/…) but they fall far short of what is actually required in practice these days. There is ample scope for a user-facing mail configuration method that would collect mail submission information in a way that is not specific to any MUA/MTA, and would support package-specific »backends« that generated appropriate configuration settings for whichever software people are using on any given system.
|
|||||||||||||