I run a small network of 4 machines, it is not really a network, this connection being basicly a handy way of getting data between machines. Because of this there is no name server or mail server running on any machines For out going mail I have always ssh'ed to the machine with the internet connection and used pine, which has inbuilt support for outgoing mail. Unfortuantely this no longer works as I now do not have direct access to my ISP's mail server and access via the internet requires authentication and pine does not support that. How is outgoing mail set up done on a standard desktop system, a text based email client on the internet access machine is the only one that will be used. Hopefull something simple. Although I have been running linux now for well over twenty years, network connections between my machines has always just worked and I have always used pine, as a consequency I have learned little of this side of Linux configuration. Kernel and X server config are different stories though Lindsay
zlinw@mcmedia.com.au writes:
How is outgoing mail set up done on a standard desktop system, a text based email client on the internet access machine is the only one that will be used. Hopefull something simple.
I would suggest something like mutt or notmuch. Personally I am a fan of notmuch. There are a number of different clients that will access the same data. I am using the emacs client - I suspect this is the best supported. The best way of describing it I can think of: text based open source email client that tracks threads similar how Google does. There are also python bindings to access mail, something I haven't looked at yet. As well as CLI tools, although these are somewhat low level and probably better suited for shell scripts as opposed to casual reading of your email. http://notmuchmail.org/ Packages in Debian stable. Some customization may be required for maximum efficiency for both mutt and notmuch. By default both these use sendmail on the installed system, which must be configured and working - although they can be configured to use SMTP also. For notmuch you will need to setup something else (e.g. with getmail) for retrieving email - while notmuch supports imap, it probably is better to retrieve emails and store then in a local Maildir. It works somewhat differently to how imap works, and keeps its own index of messages outside imap. I have seen mutt hang indefinitely when the connection to the outgoing SMTP server dies (actually not sure what happened, possibly the server died), which in turn resulted in me loosing my outgoing email when I had to kill mutt. So maybe don't use SMTP with mutt unless you can trust the connection and server. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Fri, Oct 23, 2015 at 07:04:14PM +1100, Brian May wrote:
I have seen mutt hang indefinitely when the connection to the outgoing SMTP server dies (actually not sure what happened, possibly the server died), which in turn resulted in me loosing my outgoing email when I had to kill mutt. So maybe don't use SMTP with mutt unless you can trust the connection and server.
That's one of the reasons for running an MTA like postfix or exim. It's not mutt's job, or any MUA's job, to handle queueing and multiple delivery attempts for mail. An MUA should hand the mail to an MTA and forget about it. The MTA will queue the mail and attempt delivery as many times as it takes until it either succeeds or the delivery times out (in which case it will bounce it back to the sender with an "unable to deliver" message). the timeout is configurable, but defaults to around 5 days. 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. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
It's not mutt's job, or any MUA's job, to handle queueing and multiple delivery attempts for mail. An MUA should hand the mail to an MTA and forget about it. The MTA will queue the mail and attempt delivery as many times as it takes until it either succeeds or the delivery times out (in which case it will bounce it back to the sender with an "unable to deliver" message).
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...) 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. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Sat, 24 Oct 2015 12:12:34 PM Brian May wrote:
Craig Sanders <cas@taz.net.au> writes:
It's not mutt's job, or any MUA's job, to handle queueing and multiple delivery attempts for mail. An MUA should hand the mail to an MTA and forget about it. The MTA will queue the mail and attempt delivery as many times as it takes until it either succeeds or the delivery times out (in which case it will bounce it back to the sender with an "unable to deliver" message).
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.
Why not run a local queuing SMTP server?
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...)
Why would anyone want to do that? Anyone who can read the file on disk probably has access to exploit you in so many other ways that they are going to get the password anyway. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker <russell@coker.com.au> writes:
On Sat, 24 Oct 2015 12:12:34 PM Brian May wrote:
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.
Why not run a local queuing SMTP server?
On a laptop computer? Doesn't make a lot of sense. It won't keep retrying to send the message while the laptop is disconnected from the Internet or suspended.
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...)
Why would anyone want to do that? Anyone who can read the file on disk probably has access to exploit you in so many other ways that they are going to get the password anyway.
Say if your laptop computer was lost or stolen. If you don't have your SMTP/IMAP password stored on your filesystem, then there is no way they can access future emails or send emails via your MTA. Maybe they can't even access your old emails either, that depends on if the emails are downloaded or cached. (even worse if you use the same password for more then just email services - e.g. if it is a Google account) Of course, if your computer was stolen, *and* you get it back again, that is a different matter. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Sat, Oct 24, 2015 at 04:17:33PM +1100, Brian May wrote:
Russell Coker <russell@coker.com.au> writes:
Why not run a local queuing SMTP server?
On a laptop computer? Doesn't make a lot of sense. It won't keep retrying to send the message while the laptop is disconnected from the Internet or suspended.
it makes perfect sense. the mail is queued immediately by the local MTA, allowing mutt or whatever to immediately get on with ITS job of enabling you to interact with your mail. the local MTA then delivers the mail when it gets a chance to do so. BTW, it's not uncommon for, e.g., ppp or wlan or dhcp startup scripts to include something like 'sendmail -q' to flush the queue as soon as the network is up.
Say if your laptop computer was lost or stolen.
that's what encrypted filesystems are for.
(even worse if you use the same password for more then just email services - e.g. if it is a Google account)
don't do that. really. that's just brain-damaged. craig -- craig sanders <cas@taz.net.au>
On Sat, 24 Oct 2015 04:17:33 PM Brian May wrote:
Russell Coker <russell@coker.com.au> writes:
On Sat, 24 Oct 2015 12:12:34 PM Brian May wrote:
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.
Why not run a local queuing SMTP server?
On a laptop computer? Doesn't make a lot of sense. It won't keep retrying to send the message while the laptop is disconnected from the Internet or suspended.
Makes sense to me, I've been doing it for >10 years. NOTHING on a laptop will keep retrying when the laptop is disconnected. But if everything works as desired then Postfix on localhost will deliver to your ISP in a second or so.
Why would anyone want to do that? Anyone who can read the file on disk probably has access to exploit you in so many other ways that they are going to get the password anyway.
Say if your laptop computer was lost or stolen. If you don't have your SMTP/IMAP password stored on your filesystem, then there is no way they can access future emails or send emails via your MTA. Maybe they can't even access your old emails either, that depends on if the emails are downloaded or cached.
If you encrypt the filesystems then they can't do those things. Also standard procedure is to change passwords after a device is stolen. But if you want good performance for reading email over the Internet then offline IMAP is the way to go.
(even worse if you use the same password for more then just email services - e.g. if it is a Google account)
Just don't do that. Google has a mechanism for assigning different passwords for various purposes. If someone stole the system that I use for getting gmail.com mail then I would use the master password to revoke that password. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Brian May (brian@linuxpenguins.xyz):
msmtp is interesting implementation of sendmail, because it lets individual users store their remote smtp servers in ~/.msmtprc.
The category of maximally simple, stripped-down utilities to do outbound SMTP is collectively called 'nullmailers', after the name of the earliest best known example. I catalogue them here: 'Nullmailers' on http://linuxmafia.com/kb/Mail/ Note that some of them can do modern crypto extensions, most sadly not. Ordinarily, I strongly favour full-service MTAs = SMTP daemons (Exim4, Postfix, Courier-MTA), but there's one host where I opted for a nullmailer anyway: Silicon Valley Linux User Group's dedicated Web server www.svlug.org has no SMTP functionality running on it (those being on separate machine lists.svlug.org), but it's still desirable to send root's mail to someone offsystem so that an admin gets notified of anything serious in the logs, etc. So, nullmailer (does that job minimally, doesn't add much to the public attack surface).
On Sat, Oct 24, 2015 at 12:12:34PM +1100, Brian May wrote:
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...)
it also offers the disadvantage, as you discovered, of screwing up if the remote smarthost is unreachable for any reason. that's why i said that an MUAs job is to hand the mail to an MTA (prerably on localhost or at least on the local network) and forget about it. at that point, the MUA's job is done, finished. craig -- craig sanders <cas@taz.net.au>
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
Hi all, IMHO MTA's are not very flexible to - change smarthosts if you are changing the way your connected to the rest of the world - changing the smarthost for different accounts to satisfy SPF demands. "My" alpine at home has different .pinerc for different accounts (and delivers directly to the SMTP servers related to the accounts), while this is written in Chrome and Gmail's web interface.Pure laziness (and I do not do anything else in this browser or with this Google account) Regards Peter On Sat, Oct 24, 2015 at 7:27 PM, Erik Christiansen <dvalin@internode.on.net> wrote:
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 _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
participants (7)
-
Brian May -
Craig Sanders -
Erik Christiansen -
Peter Ross -
Rick Moen -
Russell Coker -
zlinw＠mcmedia.com.au