[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] bug #23168: post -sasl doesn't honour username in .net
From: |
David Levine |
Subject: |
Re: [Nmh-workers] bug #23168: post -sasl doesn't honour username in .netrc |
Date: |
Sat, 06 Apr 2013 13:53:40 -0400 |
Lyndon wrote:
> .netrc isn't the right mechanism. Its long-standing use is for
> mapping "system" login credentials for things like telnet and ftp.
> If, as you state, pop account names are becoming divorced from login
> names, then it would be impossible to use .netrc for both pop and
> ftp account mapping to the same destination host. (If .netrc had a
> "service name" identifier, it would work.)
I don't see one.
MH/nmh has used .netrc for at least 16 years. I haven't run
into a problem with it, other than wishing that nmh didn't
see my "default" entry.
> A private-to-nmh file would be a better choice. Maybe
> there's a way to keep this info in the user's profile?
I don't think we want to start enforcing profiles to be
read-only to the user. Maybe encrypt/decrypt with some
private key? But that's not something I want to sign up
for now.
In any case, it seems like we might want to support various
schemes. How about adding a "credentials" profile entry
with support for these:
credentials: legacy
which would be what we have now (~/.netrc except uses login
for username unless overridden by -user, and defaults to login
for password with -sasl, and prompts user with -nosasl). And
would be the default.
credentials: file:.netrc
would get both username and password from the file. If
either is not found, the user would be prompted, as they now
are. Any valid filename could appear in place of .netrc,
either absolute or relative to Path or $HOME.
David