23 Oct
2015
23 Oct
'15
6:36 p.m.
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
23 Oct
23 Oct
7:04 p.m.
zlinw(a)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(a)linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
24 Oct
24 Oct
11:32 a.m.
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(a)taz.net.au>
12:12 p.m.
Craig Sanders <cas(a)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(a)linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
2:06 p.m.
On Sat, 24 Oct 2015 12:12:34 PM Brian May wrote:
Craig Sanders <cas(a)taz.net.au> writes:
Why not run a local queuing SMTP server?
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...)
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/
4:17 p.m.
Russell Coker <russell(a)coker.com.au> writes:
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(a)linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
On Sat, 24 Oct 2015 12:12:34 PM Brian May wrote:
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.
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.
6:27 p.m.
On Sat, Oct 24, 2015 at 04:17:33PM +1100, Brian May wrote:
Russell Coker <russell(a)coker.com.au> writes:
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.
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. 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(a)taz.net.au>
7:58 p.m.
On Sat, 24 Oct 2015 04:17:33 PM Brian May wrote:
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.
Russell Coker <russell(a)coker.com.au> writes:
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.
On Sat, 24 Oct 2015 12:12:34 PM Brian May wrote:
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. 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? 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)
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/
4:25 p.m.
Quoting Brian May (brian(a)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).
6:20 p.m.
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(a)taz.net.au>
7:27 p.m.
On 24.10.15 12:12, Brian May wrote:
Craig Sanders <cas(a)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.
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
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. 
27 Oct
27 Oct
5:37 p.m.
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(a)internode.on.net>
wrote:
On 24.10.15 12:12, Brian May wrote:
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(a)luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main
Craig Sanders <cas(a)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.
2712
days inactive
2716
days old
11 comments
7 participants
participants (7)
-
Brian May -
Craig Sanders -
Erik Christiansen -
Peter Ross -
Rick Moen -
Russell Coker -
zlinw＠mcmedia.com.au