[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Vixie
Subject: Re: [Nmh-workers] More configuration stuff (acconfig.h)
Date: Thu, 05 Jan 2012 19:55:31 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]