| |||||||||||||
Fedora keeps sendmail — for nowFedora keeps sendmail — for nowPosted Aug 11, 2013 10:52 UTC (Sun) by cas (subscriber, #52554)In reply to: Fedora keeps sendmail — for now by josh Parent article: Fedora keeps sendmail — for now
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.
(Log in to post comments)
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.
|
|||||||||||||