safety/permissions

safety/permissions

[Kurt Sys]

Hello all,

I have a quite serious problem (I guess) and I know, I can only blame myself.
Anyway, I want to solve it in a 'nice', non-drastic way.

I wanted to make my system somewhat safer, so I started, as it is recommended,
changing the permissions and groups. This seemed to work and I thought my system
was safe. But now, going online again, it seems as if I cannot mail... OK, this
is contraditionary, since I'm mailing, but now, I'm using webmail, but may
qmail-fetchmail won't work anymore.

So, I have installed qmail and fetchmail on a Debian system (Woody). Things were
ok before I changed (a lot of) permissions, since it is recommended here and
there to make nothing world-wide readable, and also writable and/or executable.
Initially, I had some problems other programs not working (due to wrong
permissions and/or groups), but most of them, I could solve, except this mailing
things.

If I run:
> echo "To: kurt.sys@rug.ac.be" | qmail-inject
I don't get an error or warning message. I can find all the messages I send
somewhere in /var/qmail/queue/mess/?? (?? to be replaced by a number), so they
are queued, but not sent.
> cat 155788 #This is a message I found in /var/qmail/queue/mess/9
Received: (qmail 18953 invoked by uid 1000); 17 Mar 2003 11:30:59 -0000
Date: 17 Mar 2003 11:30:59 -0000
Message-ID: <20030317113059.18953.qmail@ksys.rug.ac.be>
From: kurt@ksys.rug.ac.be
To: kurt.sys@rug.ac.be


I can't receive or send any mail. Anyone any idea how to solve this?

tnx a lot,
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Ray Olszewski]

Kurt -- Your problem is fundamental and based on bad advice (or a bad 
interpretation of good advice) about how to secure your system.

You write "it is recommended here and there to make nothing world-wide 
readable, and also writable and/or executable". This is simply nonsense.

Every standard program used by ordinary (non-root) users needs to be 
"world-wide ... executable".

Every script used by ordinary users also needs to be "workd-wide readable".

Some data files (typically in /etc) need to be "world-wide readable" to let 
user-level programs work proprely.

Some programs run by ordinary users (for example, MTAs such as qmail) need 
to run with some root-level permissions ("run suid" is the jargon for this; 
"man chmod" will probably explain that) to run properly.

I imagine there are even some files that need to be "world-wide ... 
writable" (the pseudo-files /dev/tty* are obvious examples, as is the /tmp 
directory; offhand. I can't think of a real file this morning).

A system that follows the advice you think you found "here and there" 
simply will not work, as you have been finding out.

As to your specific problem with mail ... if you changed permissions on 
unspecified things on your system, no doubt one of those changes introduced 
this problem. Did you make qmail not suid? DId you change permissions on 
the mail-spool directory in a way that causes problems? Did you do 
something to crond or anacron? Who knows? Trying to **guess** which of many 
undescribed changes ("I changed (a lot of) permissions")  is the culprit is 
all but impossible.

Now part of the behavior you see -- queueing the mail prior to sending it 
-- is (or can be, depending on undescribed details) normal MTA behavior. So 
your problem is most likely that qmail is unable to run the queue, not that 
the messages are being queued in the first place. The questions I posed 
above will tell you where to start looking for the specific change that 
introduced the problem, if you choose to go that route.

But the best way to solve this problem is to run a system that uses 
standard permissions. Debian Woody is pretty good in balancing security and 
functionality, and its setup scripts give you sensible (rather than 
wholesale) options about tweaking permissions in ways that tighten security 
without causing general problems (for example, not making users' home 
directories world-readable).

If you must run with tighter, non-standard permissions, then I suggest 
three courses of action.

1. Look in your logs to see what qmail (or maybe crond or anacron, 
depending on setup details you haven't reported here) is logging about 
attempts to run the queue.

2. Try running qmail in run-the-queue mode (probably "qmail -q" ... but 
check the man page, since I'm just guessing based on analogies to sendmail 
and exim) and see what happens.

3. Look "here and there" for a better explanation of the suggestions you 
are trying to implement, to see how those sources suggest handling the mail 
problem in the modified-permissions world they are steering you to. If you 
want help with that part, you need to refer us to the places where you are 
finding this advice, so we can see what they are really saying.

At 12:31 PM 3/17/2003 +0100, Kurt Sys wrote:
>Hello all,
>
>I have a quite serious problem (I guess) and I know, I can only blame myself.
>Anyway, I want to solve it in a 'nice', non-drastic way.
>
>I wanted to make my system somewhat safer, so I started, as it is recommended,
>changing the permissions and groups. This seemed to work and I thought my 
>system
>was safe. But now, going online again, it seems as if I cannot mail... OK, 
>this
>is contraditionary, since I'm mailing, but now, I'm using webmail, but may
>qmail-fetchmail won't work anymore.
>
>So, I have installed qmail and fetchmail on a Debian system (Woody). 
>Things were
>ok before I changed (a lot of) permissions, since it is recommended here and
>there to make nothing world-wide readable, and also writable and/or 
>executable.
>Initially, I had some problems other programs not working (due to wrong
>permissions and/or groups), but most of them, I could solve, except this 
>mailing
>things.
>
>If I run:
> > echo "To: kurt.sys@rug.ac.be" | qmail-inject
>I don't get an error or warning message. I can find all the messages I send
>somewhere in /var/qmail/queue/mess/?? (?? to be replaced by a number), so they
>are queued, but not sent.
> > cat 155788 #This is a message I found in /var/qmail/queue/mess/9
>Received: (qmail 18953 invoked by uid 1000); 17 Mar 2003 11:30:59 -0000
>Date: 17 Mar 2003 11:30:59 -0000
>Message-ID: <20030317113059.18953.qmail@ksys.rug.ac.be>
>From: kurt@ksys.rug.ac.be
>To: kurt.sys@rug.ac.be
>
>
>I can't receive or send any mail. Anyone any idea how to solve this?




-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Ray Olszewski]

Responses to an edited version of your message appear below. And you 
mistakenly (I assume) replied to me personally; I've added the linux-newbie 
list back in through a Cc: entry.

At 10:10 AM 3/18/2003 +0100, Kurt Sys wrote:
[...]
>Or are there any 'tests' I can run to see were the problem would be? (I found
>out that such an approach was always quite interesting to me, in that 
>sense that
>  I learned a lot from it how the system works.)

My prior response suggested a couple of things you might do to see why 
qmail is having trouble running the queue (which, from your fiest message, 
*appears* to be the location of the problem). I won't repeat them here, 
just suggest you re-read that reply.

The general lack of response here to your original inquiry suggests to me 
that few if any others run qmail (and I don't, using Debian's default MTA 
of exim instead). This will limit your ability to get help specific to that 
app.

>Oh yeah... I'm not really sure, but I think I can send messages not using
>webmail, but vm/emacs.

If you're not sure which app has the problem, how can we conceivably 
suggest solutions? Do your homework before posting, please.

>  Maybe it's the permissions of the /var/mail
>(/var/spool/mail)? They are set, for my mail-spool-file 'kurt':
>-rw-rw----   1 kurt mail         0 Feb 17 21:39

This is the standard mode for a user mail file so should not *itself* cause 
problems. (It might interact with some *other* change you made to cause a 
problem, though.) The directory that contains it (/var/mail) should be

drwxrwsr-x    2 root     mail         4096 Mar 18 07:47 mail

>So, of course, 0 bytes, and that's what is not changes when I run fetchmail
>(which 'serves' the mail from a mail-server so qmail-inject, as far is I
>understood it well).

This is incoherent. Please try more carefully. Quote complete, not 
fragmentary, results of commands, and use standard English grammar and 
syntax (from the rest of your message, we know you can).

This is also the first mention you have made of a problem with fetchmail, 
or incoming mail in general  ... your prior message discussed only failing 
to *send* mail with qmail, and then you indicated that qmail-inject did add 
the message to the queue ... so you might want to describe how you are 
using fetchmail and if your logs report any messages from fetchmail about 
problems getting mail.

>And euh... just to be sure: I shouldn't set e.g. all files in '/etc' to
>permission rwxr-x--- and change the group to users (so all users would be able
>to 'read' and 'execute' them, but not other people)? So I guess I should stick
>with the Debian Security-HOWTO?

"users" is just another group name in /etc/groups. It isn't a magic wand to 
solve problems. If you add all the userids for non-root accounts to that 
group, I don't know who is left as "other people" ... unless you mean the 
"system" accounts like daemon, mail, and operator ... but some of those 
system accounts also need to be able to run some apps, so you will still 
have problems with that interpretation of what you ask about.

Even as an experienced user, I stick with the Debian standards for 
permissions except in rare cases (and those I deal with on a case-by-case 
basis, never changing things wholesale, as you aparently did). I haven't 
read the Debian Security-HOWTO so cannot comment on its value.

>tnx,
>Kurt
[old stuff deleted]



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Kurt Sys]

Eello again,

I tried to make my homework as good as possible. I reinstalled 'everything', so
all permissions are now default values, except the ones in my homedir. I was
able to solve some (other) problems with qmail. Now, I can send mail using
qmail. I can receive mail whenever I send a message from my machine to my
machine (so local mail delivery is ok).
I can not send a message from 'outside' (so I send from my webmail to my 'local'
mailbox kurt@ksys.rug.ac.be) nor can I receive any messages present on a
mail-server (allserv.rug.ac.be, which is not mine). 
If I send a message from my webmail (I consider this as 'mailing from another
machine) to my local address, it's not delivered and I do not get an error
message (yet, i.e. after a few hours). So, apparently, it tries to write to
'somewhere', but it doesn't work. I can't find anything in my log-files.
If I 'fetchmail' my mail from the webserver (so, the 'allerv.rug.ac.be'), it
fetches that mail, but it doesn't deliver the mail. I know it fetches the mail
since it is removed from the server if I don't set the 'keep'-value (which keeps
the mail on the server).

So, my mail cannot be delivered if it comes from 'outside'. Permissions are all
'default' values, except the ones in my homedir. Now, I see nothing special
about these (and very 'open'):
755 for /home/kurt 
755 for /home/kurt/.mydata (where mail-files and 'inbox' is, after it is taken
from /var/mail/kurt)
755 for /home/kurt/.mydata/inbox (file with my mail)
600 for /home/kurt/.fetchmailrc

Kurt



Quoting Ray Olszewski <ray@comarre.com>:

[...]
> >  Maybe it's the permissions of the /var/mail
> >(/var/spool/mail)? They are set, for my mail-spool-file 'kurt':
> >-rw-rw----   1 kurt mail         0 Feb 17 21:39
> 
> This is the standard mode for a user mail file so should not *itself* cause 
> problems. (It might interact with some *other* change you made to cause a 
> problem, though.) The directory that contains it (/var/mail) should be
> 
> drwxrwsr-x    2 root     mail         4096 Mar 18 07:47 mail
>
> This is also the first mention you have made of a problem with fetchmail, 
> or incoming mail in general  ... your prior message discussed only failing 
> to *send* mail with qmail, and then you indicated that qmail-inject did add 
> the message to the queue ... so you might want to describe how you are 
> using fetchmail and if your logs report any messages from fetchmail about 
> problems getting mail.
> 
[...]
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Ray Olszewski]

OK, Kurt. To get help with these problems, you're going to need to describe 
them in a bit more detail.

First, *where* is "outside"? Is this system connected to the Internet, and 
you are trying to send mail to it from a place that is truly off-site? Or 
is "outside" another machine on the same LAN? Or something else? (You refer 
to your "Webmail" but do not say where that is coming from.)

Second, do you have qmail running in daemon mode? That is, is it (or is 
anything) listening on port 25? You can check this with "netstat -ln". You 
can also just check the process list to see if the daemon is running ("ps 
ax |grep qmail", assuming the daemon is either qmail or qmaild). OR you can 
try to telnet to port 25 on the host ansd see if you get a response 
("telnet [hostname] 25"). If nothing is listening on port 25, the mail 
cannot be delivered (and it might be queued for sending for as long as a 
week, depending on the practice at your Webmail site, so you might not know 
that this is the cause for quite some time).

Third, how is your Linux host connected to the Internet? Does it have a 
"real" (routable) IP address or a "private" (non-routable) one? If the 
latter, is whatever you are using to NAT the LAN allowing incoming SMTP 
traffic to reach the Linux server (different "whatevers" do this in 
different ways, but the generic concept is port forwarding)?

I don't ue fetchmail myself, so I can't really offer suggestions about 
where to begin looking into that particular problem. I don't even havet the 
man page installed locally, so I can't readily check if it needs a running 
SMTP daemon (anyone?) or if it starts up its own copy of your MTA.

At 05:51 PM 3/20/2003 +0100, Kurt Sys wrote:
>Eello again,
>
>I tried to make my homework as good as possible. I reinstalled 
>'everything', so
>all permissions are now default values, except the ones in my homedir. I was
>able to solve some (other) problems with qmail. Now, I can send mail using
>qmail. I can receive mail whenever I send a message from my machine to my
>machine (so local mail delivery is ok).
>I can not send a message from 'outside' (so I send from my webmail to my 
>'local'
>mailbox kurt@ksys.rug.ac.be) nor can I receive any messages present on a
>mail-server (allserv.rug.ac.be, which is not mine).
>If I send a message from my webmail (I consider this as 'mailing from another
>machine) to my local address, it's not delivered and I do not get an error
>message (yet, i.e. after a few hours). So, apparently, it tries to write to
>'somewhere', but it doesn't work. I can't find anything in my log-files.
>If I 'fetchmail' my mail from the webserver (so, the 'allerv.rug.ac.be'), it
>fetches that mail, but it doesn't deliver the mail. I know it fetches the mail
>since it is removed from the server if I don't set the 'keep'-value (which 
>keeps
>the mail on the server).
>
>So, my mail cannot be delivered if it comes from 'outside'. Permissions 
>are all
>'default' values, except the ones in my homedir. Now, I see nothing special
>about these (and very 'open'):
>755 for /home/kurt
>755 for /home/kurt/.mydata (where mail-files and 'inbox' is, after it is taken
>from /var/mail/kurt)
>755 for /home/kurt/.mydata/inbox (file with my mail)
>600 for /home/kurt/.fetchmailrc
[old stuff deleted]



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Kurt Sys]

Hello again,

OK, I tried to make my 'receiving mail from outside' to work, and I
lost all my mail that was still on 'the mailserver', due to bad
fetchmail configuration file. That's way the previous message(s)
is/are not included in this one. But it's important to mention: telnet
does work! There was an error in my inetd.conf-file. I restored it,
and the 'normal telnet-procedure' works:

----
kurt@kurtpjoeter:~$ telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 ksys.rug.ac.be ESMTP
helo dude
250 ksys.rug.ac.be
mail <kurt@ksys.rug.ac.be>
250 ok
mail <kurt@ksys.rug.ac.be>
250 ok
data
503 RCPT first (#5.5.1)
rcpt <kurt@ksys.rug.ac.be>
250 ok
data
354 go ahead
Subject: Just a test

I'm testing...
.
250 ok 1048261497 qp 18709
quit
221 ksys.rug.ac.be
Connection closed by foreign host.

kurt@kurtpjoeter:~$ telnet 157.193.192.167 25
Trying 157.193.192.167...
Connected to 157.193.192.167.
Escape character is '^]'.
220 ksys.rug.ac.be ESMTP
helo dude
250 ksys.rug.ac.be
mail <kurt@ksys.rug.ac.be>
250 ok
rcpt <kurt@ksys.rug.ac.be>
250 ok
data
354 go ahead
Subject: Test2

Testing again
.
250 ok 1048261594 qp 1625
quit
221 ksys.rug.ac.be
Connection closed by foreign host.
kurt@kurtpjoeter:~$

----

I received both messages (on my local machine).


Kurt.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Kurt Sys]

Hello...


I'm really sorry to bother you again. I'm still trying to make my mail
working... and I found something else working:
I can send emails to kurt@ksys.rug.ac.be using webmail (on my
computer, but I consider this as 'outside'). So, the only thing that
doesn't work right now is getting my mail from a (non-local)
mailserver and send them to my local MTA (and I use fetchmail for
this). I do not know whether the problem is fetchmail or qmail or
both, but I would like to know how I can test these things.
I don't know if this was really the problem, but on a Spanish forum (I
guess it was Spanish) I could 'extract' information about qmail and
xinetd, so I installed the latter (apparently it wasn't installed) and
so, I was able to send mail to 'kurt@ksys.rug.ac.be'. So now, there's,
I hope, only one problem left...


Thanks a lot (especially to Ray),
Kurt.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Ray Olszewski]

Kurt -- Not to sound like a dullard here, but ... what is your question? I 
only have an imprecise memory of your earlier messages, not actual copies, 
but you were having some sort of problems with your MTA. From this message, 
we know that

A. Your MTA itself is running in daemon mode (since you can send mail 
successfully by telnet'ing to port 25).

B. Your fetchmail configuration is wrong in some unspecified way that, 
presumably, you are aware of.

Things we still don't know are:

A. How are you connected to the Internet? While you can telnet *locally* to 
port 25, can someone from outside do so? I cannot do so from here, though I 
can traceroute to it. This may mean that you are, or your ISP is, blocking 
access to port 25 from offsite (the attempt just hangs; no response, not 
even "Connection refused", hinting at firewalling as the cause.). You need 
to investigate why this is happening before you will be able to receive 
mail directly.

B. If you are still seeing offsite mail sitting in the queue. In this case, 
you should investigate if you can connect *to* port 25 on other hosts 
directly from your system. If your ISP is blocking incoming port-25 
traffic, it **may** also be blocking outgoing port-25 traffic to anyplace 
but its own SMTP relay servers.

C. If your system is already setup to use your ISP's SMTP relay. If so, and 
you are having the problem I described in B, you might investigate whether 
your ISP has any authentication requirements you are not fulfilling. Some 
ISPs use pop-before-smtp authentication, for example. Linux apps can handle 
that, though I forget exactly how ... if that's what you need, post a 
followup saying so, and someone here will help you out with the details.

Depending on where you have been trying to send offsite mail to, it is 
possible that you are running into some other authentication problem. It's 
hard to do more than guess here ... but it is not all that likely, just a 
remote possibility. But one way to test it is to try sending a message 
directly to me. I run my own MTA, and it has no restrictions on it for 
accepting mail to valid addresses **in my domain** (it's not an open relay, 
so please don't misread this message as saying it is one). If you cannot 
send an e-mail directly to me, then you probably have port-25 problems 
(rather than, say, auth/ident proboems).

If your remaining problems are caused by your ISP, then Linux 
troubleshooters won't be able to help you. Your only options are (a) find 
out how your ISP want you to send mail and obey its rules; (b) persuade 
your ISP to change its rules better to match your technical needs; or (c) 
find a new ISP.

At 04:56 PM 3/21/2003 +0100, Kurt Sys wrote:
>Hello again,
>
>OK, I tried to make my 'receiving mail from outside' to work, and I
>lost all my mail that was still on 'the mailserver', due to bad
>fetchmail configuration file. That's way the previous message(s)
>is/are not included in this one. But it's important to mention: telnet
>does work! There was an error in my inetd.conf-file. I restored it,
>and the 'normal telnet-procedure' works:
>
>----
>kurt@kurtpjoeter:~$ telnet 127.0.0.1 25
>Trying 127.0.0.1...
>Connected to 127.0.0.1.
>Escape character is '^]'.
>220 ksys.rug.ac.be ESMTP
>helo dude
>250 ksys.rug.ac.be
>mail <kurt@ksys.rug.ac.be>
>250 ok
>mail <kurt@ksys.rug.ac.be>
>250 ok
>data
>503 RCPT first (#5.5.1)
>rcpt <kurt@ksys.rug.ac.be>
>250 ok
>data
>354 go ahead
>Subject: Just a test
>
>I'm testing...
>.
>250 ok 1048261497 qp 18709
>quit
>221 ksys.rug.ac.be
>Connection closed by foreign host.
>
>kurt@kurtpjoeter:~$ telnet 157.193.192.167 25
>Trying 157.193.192.167...
>Connected to 157.193.192.167.
>Escape character is '^]'.
>220 ksys.rug.ac.be ESMTP
>helo dude
>250 ksys.rug.ac.be
>mail <kurt@ksys.rug.ac.be>
>250 ok
>rcpt <kurt@ksys.rug.ac.be>
>250 ok
>data
>354 go ahead
>Subject: Test2
>
>Testing again
>.
>250 ok 1048261594 qp 1625
>quit
>221 ksys.rug.ac.be
>Connection closed by foreign host.
>kurt@kurtpjoeter:~$
>
>----
>
>I received both messages (on my local machine).



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Heimo Claasen]

Sheer horror:
> OK, I tried to make my 'receiving mail from outside' to work, and I
> lost all my mail that was still on 'the mailserver', due to bad
> fetchmail configuration file.

If it's that easy to destroy one's mail with some unperceived error I'm
only confirmed in not migrating my mailing from the reliable, fully
transparent DOS environment to the Linux box.

And sorry, Ray, your best efforts to solve the riddle does not help if
the user doesn't get a clue about how "listening to port 25" is related
to the "mail queue" - it's deficiencies of the most fundamental
contextual explanations that put newbies off time and again. (And what
I call "specialised blindness" - try to find out from the "standard"
beginner's bibles like "Running Linux" or "Linux in a Nutshell" what
the "meta key" is, or what is meant with "filetype", <bg>).

// Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-03-21
The WebPlace of ReRead - and much to read  ==>  http://www.revobild.net

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

safety/permissions

[Kurt Sys]

Hello all,

I don't know if there were (a lot) of responses to my last mail(s),
since I again did some 'uncareful' things and I lost now and then some
mail. Anyway, for the people who want to know, the problem is solved
now completely. It was something with my fetchmail configuration. I
don't fully understand why it used to work but it didn't work when I
reinstalled Linux Debian, but ok... Here's the solution:

My .fetchmailrc-file looks now like this:
-----
set postmaster "kurt"
set bouncemail
set spambounce
set properties ""
set daemon 500
poll allserv.rug.ac.be with proto IMAP
       user 'ksys' there with password 'xxxx' is 'kurt' here 
       options smtphost 'ksys.rug.ac.be' forcecr ssl fetchall
-----

I had to add the option:
smtphost 'ksys.rug.ac.be'

I guess another config-file, somewhere is /etc is wrong and fetchmail
reads that file if it doesn't find the 'smtphost'-option. Could this
be right?


Anyway,
thanks for your help,
Kurt.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[whitnl73]

On Mon, 24 Mar 2003, Kurt Sys wrote:

> Hello all,
>
> I don't know if there were (a lot) of responses to my last mail(s),
> since I again did some 'uncareful' things and I lost now and then some
> mail. Anyway, for the people who want to know, the problem is solved
> now completely. It was something with my fetchmail configuration. I
> don't fully understand why it used to work but it didn't work when I
> reinstalled Linux Debian, but ok... Here's the solution:
>
> My .fetchmailrc-file looks now like this:
> -----
> set postmaster "kurt"
> set bouncemail
> set spambounce
> set properties ""
> set daemon 500
> poll allserv.rug.ac.be with proto IMAP
>        user 'ksys' there with password 'xxxx' is 'kurt' here
>        options smtphost 'ksys.rug.ac.be' forcecr ssl fetchall
> -----
>
> I had to add the option:
> smtphost 'ksys.rug.ac.be'
>
> I guess another config-file, somewhere is /etc is wrong and fetchmail
> reads that file if it doesn't find the 'smtphost'-option. Could this
> be right?
>
Not exactly.  smtphost defaults to 'localhost'.
>
> Anyway,
> thanks for your help,
> Kurt.

Lawson
--
---oops---



________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: safety/permissions

[Kurt Sys]

Mail from whitnl73@juno.com
sent on Monday March 24 2003 at 16:50 (GMT-0500):

> On Mon, 24 Mar 2003, Kurt Sys wrote:
> 
> [...]
> >
> > I guess another config-file, somewhere is /etc is wrong and
> > fetchmail reads that file if it doesn't find the
> > 'smtphost'-option. Could this be right?
> >
> Not exactly.  smtphost defaults to 'localhost'.
> [...]


OK... I get it. True: I can't send mail to myself using a simple
command like:

$ echo "To: kurt@localhost" | qmail-inject

Possible reason (just for my understanding of this machine, this is
absolutely nothing I worry about)?

tnx,
Kurt.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs