nmh-workers
[Top] [All Lists]

Re: [nmh-workers] logging outgoing messages

2019-07-10 10:04:04
Any rational (MTA) client does.

No argument there.

MUA's typically don't, but those should
not really ever be talking to anything but their local MTA.

Right, and since nmh is a MUA ...

What is
different now than what used to be true, is what people regard as their
local MTA, which in the past would normally have been either on the same
host, or at absolute worst, in the same organisation as the sender (and
usually same department of the organisation when it is big enough to have
such things).   (Organisation can mean household for personal e-mail).
Way too many people today are relying upon "free" giant e-mail providers
to do everything for them.

Well, out of the three email providers I deal with on a semi-regular
basis, all of which I have a financial relationship with, exactly zero
would let me perform final delivery from a MTA that I ran myself (this
is enforced via firewall rules and other things like SPF and DKIM records;
I suppose in the case of SPF and DKIM it would more mean that the odds
are high that if I tried to perform final delivery from my own machines
the email would be rejected as spam).  So I think it is very very common
in the modern Internet that you cannot perform final delivery yourself
but need to submit it to a MTA you don't control and have it do it for you.

Now, exactly how you DO this is, of course, up to you.  All of the
email providers I deal with require authentication if you're submitting
messages across the global Internet.  Having a client MTA perform the
necessary authentication requiries extra configuration.  And ... well ...
configuring an MTA is hard.  The nmh mailing list is FULL of people who
have problems configuring their MTA.  Two people ON THIS THREAD have
long delays when they submit email to their local MTA.  I don't notice
these things because I let someone else deal with it, and it turns out
they deal with it just fine (because they get tons of complaints if
it doesn't work).

So, yes, lots of people DO rely on giant email providers.  Why would they
not?  For most purposes they work just fine, and you don't have to spend
your time figuring out why submitting email takes so long.  I can type
"send" at the What Now? prompt, email gets submitted in less than a second,
I get email showing up in my mailbox, and I don't have to think about
my postfix configuration at all.  This seems like a perfectly reasonable
set of affairs.

So that's why when people are having problems with the MTA THAT THEY
CONTROL, I always advise that they configure nmh to submit directly to
their email provider's MTA.  Number one, that's something we can provide
support for if they run into problems.  Number two, it's the way the
vast majority of email users are configured so you'll be working with
a setup that is the common case and will likely receiver much better
support from your email provider.

Now, I must be honest and say one downside to this configuration is that
you don't get automatic queuing if your email provider is down.  But when
I think about it, I realize I cannot remember the last time this has
happened to me.  It turns out email providers have spent a lot of time
and money creating redundancy, to the point where if GMail is down it
makes the news.  So if being able to automatically queue email is a hard
requirement for you, then yes, you SHOULD configure a local MTA.  But
I would humbly suggest that for most people that this is optimizing for
the extremely uncommon case.

Now in nmh we're going to continue support submitting to your own MTA,
be it via SMTP, sendmail/SMTP, or the hated sendmail/pipe interface.  So
configure your own MTA if you want; we will continue to make that work.
But it's clear to me that MOST PEOPLE should not be doing that.  A good
test would be: if you have to send email to nmh-workers about problems
with your MTA configuration, you shouldn't be running one.

--Ken

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>