Hi Ken,
But do the users provide you the queue-id?
Very occasionally on first contact. Those that do clearly know their
onions. When roles are reversed, I do. :-) Those that don't get asked
to try and supply it if they're likely to return soon.
I'd keep the 250 as I expect we'd be doing this for 25x and its
value is significant. Also, there might be multiple lines of 25x.
Sigh. It's these sorts of things that make stuff spin off the rails.
I am aware that in theory any 2xx code can be returned by the DATA
command, but I think 99.9% of the time it will just be a 250.
Assuming you're right, that 0.1% is probably important.
And there's no way we should return a multiline response;
Where is the being returned to? What stops it being multi-line?
I think just the last output of the positive repsonse code (after the
2xx) is fine.
In the multi-line responses I've seen, it's the start that's specific
followed by a bit of an explanation.
I agree. Something specialising in queueing locally and then
forwarding on will do a better job and offer more options than
extending nmh to include those options over time. I see that nmh
has to talk TLS SMTP to submit an email locally, e.g. same host or
company, and that can be used to also submit across the Internet,
but that doesn't mean it's a good idea...
First ... what unreliable email providers do you guys use that go down
all of the time?
I never said the provider goes down all of the time. And kre suggested
when he was in an aeroplane. I mainly pointed out the advantages of
centralising MTA configuration in one place, the MTA, given many
programs like to send email on Unix.
But I can't recommend it to the average nmh user.
Thereby nobbling support for non-nmh email on their Unix system, and
that's a shame if they don't consider that as part of the decision.
--
Cheers, Ralph.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers