Re: [nmh-workers] logging outgoing messages

[Ralph Corderoy]

Hi kre,

> The need is less common today, than it once was, since more and more
> e-mail is direct from sender's MTA to recipient's - but back when more
> mail relaying was done (when there was more than just "the internet")
> the queue-id along with the transfer timestamp

I grovel around MTA logs on a machine hosting Mailman for all the UK LUG
lists and the queue ID is the key thing.  It's the first thing I have to
work out if it's not provided.

The Message-ID field isn't necessarily a one-to-one mapping to QID, as
the same email with the same Message-ID can arrive and be queued more
than once.

> Any rational (MTA) client does.   MUA's typically don't, but those
> should not really ever be talking to anything but their local MTA.

Here, here.

> the only rational solution is to log all of the 250 response (after
> the 250 itself).

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.

Is it just 25x that should trigger this hook, or 4xx, etc., too?

> Personally, I'd just suggest keeping the local MTA, having post
> deliver to that, and let it do the logging - it will also do queueing
> in case your local ISP link is down (like you want to send e-mail
> while in an airplane...).  That is, I wouldn't bother with this at all
> - there is an alternative (and better) solution already available.

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...

I run a local Postfix so it has all the configuration about the next
smarthost based on the hat I'm wearing, not nmh which, IMO, is the wrong
place.  Thus mail(1) benefits too.  And I'm aware of mhmail(1), but it's
not the same.  crontab(5)'s MAILTO, at(1)'s LOGNAME, ~/.forward files,
... all benefit from central configuration rather than inside nmh.

Ditto fetching email.  I don't fetch large emails by default because
they're typically spam; the features of the specialist program for
fetching emails already provide for that, and lots more; no patching of
inc(1) required.  :-)

-- 
Cheers, Ralph.