Re: [Nmh-workers] More configuration stuff (acconfig.h)

[Paul Vixie]

On 1/5/2012 7:41 PM, Lyndon Nerenberg wrote:
>> REALLYDUMB    - What this does is prevent adrsprintf() from appending a
>>           local hostname if a username doesn't have one.  You know,
>>           I really think this should be a run-time option instead.
>>           Anyone care if I make it so it is?  (The default can
>>           be off to match current behavior).
>
> Shouldn't this be the decision of the message submission agent? For
> instance, the MSA has a much better idea of what the domain part of
> the address should look like.  I'd argue for ripping it out altogether.

appending a local host name is almost always the wrong thing to do. let
the MTA fully qualify stuff if the next-hop isn't another local mailbox
(or even if it is). this is policy, and does not belong in the user agent.

>> RPATHS        - Construct Return-Path headers from "From " lines.
>>           I say keep it, since it's been around forever (a fair
>>           amount of code, actually).
>
> I'm going to argue for the removal of this code, as well.  The
> Return-Path header should be inserted by the delivering MTA, and I
> can't think of any modern MTA that doesn't.

i have to agree. multiple From_ lines was a uucp-ism and predates
Sendmail. the systems that still work this way are pre-ANSI C and
pre-POSIX and won't be able to compile NMH in any case.

>> BUILTIN_FTP    - This was the only code I didn't add IPv6 code to.  It's
>>           turned on right now, but I have to question how useful it
>>           is (it's built-in ftp support for mhn).  I haven't seen
>>           MIME messages with external-body parts in forever, and
>>           even if we did get any I think this work should be forked
>>           off to an external ftp program or something like curl.
>>           Thoughts?  Actually, I wonder how many MUAs support
>>           MIME external-body anyway (okay, a quick Google shows
>>           that it's non-zero, but I suspect that a lot of it is
>>           done via http rather than ftp anyway).
>
> I still receive (and send) the occasional message with externals.  But
> the internal FTP support should be nuked.  It doesn't handle any of
> the modern FTP extensions (authentication, UTF8, modern file listing).

strong +1 here. link against a library to get this; don't reimplement
FTP locally.