Re: [nmh-workers] logging outgoing messages

[Ralph Corderoy]

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.