>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