| |||||||||||||
Fedora keeps sendmail — for nowFedora keeps sendmail — for nowPosted Aug 15, 2013 15:45 UTC (Thu) by smurf (subscriber, #17840)In reply to: Fedora keeps sendmail — for now by cas Parent article: Fedora keeps sendmail — for now
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.
(Log in to post comments)
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.
|
|||||||||||||