Hello again,
Yes, so do I. But if you'd 777 ~/.fetchmailrc, fetchmail will not run:
Sure. But that is not the issue. The issue is that murphy dictates that
this kind of error happens on a friday evening, leaving the file open for
every passer by to read till you get back on Monday and find the time to
discover the problem and fix it. And then if this password also is your
login password (in my case: on the NT machines) and everybody in the
organisation knows for sure that it has to be the same...
As an aside, what happens with a fetchmail daemon? Does it stop working
too? Does it even notice in case the file itself is not chaged?
But as I understand it, you don't trust your root's, correct? Well,
I haven't said that. I have implied that people in general might not
trust their root, and have said that, independenty of whether I do,
my password selection "algorithm" is private information that should
be "for my eyes only".
dunno, but you do know that even if fetchmail would store the password
encrytped, it would be rather easy to sniff the password, don't you?
I know. But sniffing requires more effort than simply reading a file
that has been accidently chmod-ed by a badly written shell script (or
some similar such).
Note that I already agreed that the unencrypted sending is the biggest
problem, since that's why fetchmail would need to cointain the decryption
code in the first place.
Regards,
MCE
--
========================================================================
M. Eyckmans (MCE) Code of the Geeks v3.1 mce-at-pi-dot-be
GCS d+ s+:- a36 C+++$ UHLUASO+++$ P+ L+++ E--- W++ N+++ !o K w--- !O M--
V-- PS+ PE+ Y+ PGP- t--- !5 !X R- tv- b+ DI++ D-- G++ e+++ h+(*) !r y?
========================================================================