Re: Why use an email client AND sendmail/popa3d
On Wed 25 Nov 2020 at 09:30:41 (+1100), Keith Bainbridge wrote:
> On Sun, 22 Nov 2020 23:34:56 -0600 David Wright wrote:
> >>> On Mon 23 Nov 2020 at 14:27:36 (+1100), Keith Bainbridge wrote:
> >>> > So does htis get a new subject in the list?
>
> Interesting. I'll try it next time I want to use a comment from one
> thread as a separate topic. BUT I wrote a totally new subject line.
> Surely that is removing 'Re: '
Oops, sorry, my mistake. I was simultaneously replying to several
emails at too late an hour—your subject line was fine.
> I'd appreciate a good explanation if somebody is up to it.
Of why it starts a new thread? Because there are no References and no
In-reply-to, it doesn't get threaded onto an existing thread.
There's an exception where a client threads a message onto any other
one with a similar subject. I remember this often causing problems
20 years ago when someone would send "Lunch?" expecting an immediate
reply, and the recipient's client would thread it to a months-old
duplicate message.
> >>> It would appear so. [snipped the misleading sentence that was here]
> >>>
> >>> > I was interested to read that Flo, the OP, uses separate mail
> >>> > collection, sendmail and thunderbird. Some of the replies sound
> >>> > like this is a common practice.
> >>> >
> >>> > What are the advantages of this set of processes over letting
> >>> > tbird do it all? - or any other client for that matter?
> >>>
> >>> Disadvantages of using your email client to send might include:
> >>> . sending is relatively instant as the client is dispatching
> >>> it to the same machine, not the remote smarthost,
>
> So I wouldn't get the message saying the note is being sent by the
> client - because that bit is 'instantaneous' by being local.
I must have been half-asleep: that's poorly expressed.
Each bullet point is meant to be an advantage of using an MTA,
and a disadvantage of sending direct from client to smarthost.
So bullet point 1 ought to say:
. sending [via an MTA] is relatively instant as the client is dispatching
it [the email] to the [MTA, running on the] same machine, not the remote smarthost,
What you would observe in the two cases is (using mutt as an example):
With an MTA, the email is transferred almost immediately to the MTA
running on the same machine, and the client says "Mail sent".
With sending direct, some messages will flicker by as communication
is established with the smarthost; with large emails, there'll be a
pause while the file is transferred; then a couple more messages and
finally "Mail sent". On this computer, the mutt debug logs show that
sending a trivial email takes between 2 and 7 seconds, mostly
related to starting up the connection.
My transfer speeds (by cable) are very good nowadays. A decade ago
in the UK, with several miles to the exchange going over copper,
speeds were fairly dire (until FTTC arrived). Large attachments
could take a while to get out.
> >>> . exim will retry sending if your smarthost is busy/unavailable,
>
> OK. I have had instances of the 'sending' notice being there when I
> come back after lunch.
>
> >>> . it keeps logs,
>
> Fair enough
>
> >>> . it send emails on behalf of other processes, like cron jobs,
> >>> where your client is not involved.
>
> Is that why email from cron doesn't happen sometimes, then magically
> happens.
I would hesitate to guess without more information.
> >>> I don't collect emails in Flo's sense, as I use IMAP rather than
> >>> POP. So my INBOX is merely mutt's cache of individual emails,
> >>> rather than a live mailfile. The actual server is somewhere around
> >>> Manchester/Stockport.
>
> I prefer imap as I check mail on 3 devices, but it's become too slow to
> be workable, recently. I do check back occasionally to see if the
> connection to Germany is getting better. It is 20,000Km I suppose.
That beats my 7000km (over a very fat pipe).
IMAP is designed to be interactive, and fetch each email when you ask
for it. But you can cheat. One way with mutt is to use "search in
message bodies" for some "impossible" string (like a long random one),
and then go and make the coffee. The client is forced to fetch and
cache all the unread emails while searching for the string. When you
return, you'll be able to read new messages instantaneously because
they're already cached.
> I had this thought as I completed that last sentence: should I use my
> ISP as a collection point for my many addresses?
Personally, I prefer to keep my email hosting separate from my ISP.
It's one less complication when travelling, changing service provider,
or moving home or job.
> Thanks for a thought provoking response. I'll be contemplating this
> for a bit yet.
I hope I was a bit clearer.
Cheers,
David.
Reply to: