| |||||||||||||
Fedora keeps sendmail — for nowFedora keeps sendmail — for nowPosted Aug 12, 2013 2:27 UTC (Mon) by josh (subscriber, #17465)In reply to: Fedora keeps sendmail — for now by cas Parent article: Fedora keeps sendmail — for now
>> 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.
(Log in to post comments)
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.
|
|||||||||||||