On 24.10.15 12:12, Brian May wrote:
Craig Sanders <cas@taz.net.au> writes: I think you might be confused, I wasn't talking about contacting the destination SMTP server directly, I was talking about contacting a remote authenticated queuing SMTP server directly.
Like it or not it is common practise to do this directly from the MUA. This offers advantages such as being able to enter the remote SMTP password when sending the email instead of saving it on disk (not that many people do this...)
That is not an advantage of trying to make an MUA into an MTA. I have always run an MTA (until recently, sendmail, now postfix.) on my single-user desktop _and_ I don't store any mail password on the machine. Here, it is fetchmail which issues the password, and rather than include it in .fetchmailrc, I enter it at the prompt. OK, if fetchmail has not been started beforehand, then the fetchmail prompt appears in the xterm where mutt is being started, but that's not mutt handling the password.
msmtp is interesting implementation of sendmail, because it lets individual users store their remote smtp servers in ~/.msmtprc.
mutt's SMTP capability is best used with a smart-host (either the localhost or elsewhere on the local network), not for direct delivery to the final destination host. ditto for any other MUA.
That is what I was talking about. Unfortunately, I have had this session to the smart host fail, and lost outgoing emails as a result.
I surmise that that is an artifact of using the MUA as an MTA, since I have never encountered that in more than two decades of using the ISP's mailhost as my smarthost via a local MTA. Erik