headers
Dermot Paikkos | 20 Sep 2004 15:52

Recommanded config

Hi,

SYSTEM: Exim 4.42 MTA Qpopper 4.0.5 on Tru64 UNIX

I am planning to move our email from a v. old server and popd to a 
fresh one. In the old configuration all the pop user where kept in a 
Plain text file 'POP' that was in a GECOS format. 

I was wondering if it is possible to maintain a similar 
configuration. I have reservations about added all pop users to the 
/etc/passwd's file as some pop users will have also have a login 
account. If all the pop users are in the passwd's file, if someone 
snoops my plain-text password during a pop session, that would be 
stealing my login password as well. 

I want to keep the client configuration as simple as possible so APOP 
seems like it might be cause the users some confusion. One aim is to 
make the transformation as transparent as possible so I don't want 
the client's to have to do no more that perhaps change the pop3 host 
or maybe I would do something with the DNS to resolve the hosts 
correctly.

Does anyone know if the above configuration is possible or have any 
strong feeling about what I am trying to do?

Thanx.
Dp.

~~
Dermot Paikkos * dermot <at> sciencephoto.com
(Continue reading)

Permalink | Reply |
headers
Daniel Senie | 20 Sep 2004 16:18

Re: Recommanded config

At 09:52 AM 9/20/2004, Dermot Paikkos wrote:
>Hi,
>
>SYSTEM: Exim 4.42 MTA Qpopper 4.0.5 on Tru64 UNIX
>
>I am planning to move our email from a v. old server and popd to a
>fresh one. In the old configuration all the pop user where kept in a
>Plain text file 'POP' that was in a GECOS format.
>
>I was wondering if it is possible to maintain a similar
>configuration. I have reservations about added all pop users to the
>/etc/passwd's file as some pop users will have also have a login
>account. If all the pop users are in the passwd's file, if someone
>snoops my plain-text password during a pop session, that would be
>stealing my login password as well.

First off, you can have accounts in /etc/passwd which do not have the 
ability to log in. Make the shell /bin/nologin or /bin/false or something 
like that. The users will be able to POP, but not get a shell and log in.

Second, don't leave telnet, ssh or FTP or other things open. Then they 
can't log in.

Third, you should be using shadow password setups.

Fourth, implement TLS, and your passwords will be encrypted. Or use APOP. 
Or both.

>I want to keep the client configuration as simple as possible so APOP
>seems like it might be cause the users some confusion. One aim is to
(Continue reading)

Permalink | Reply |
headers
Hugh Sasse Staff Elec Eng | 20 Sep 2004 18:48
Picon
Picon

Re: Recommanded config

On Mon, 20 Sep 2004, Daniel Senie wrote:

> At 09:52 AM 9/20/2004, Dermot Paikkos wrote:

>> I want to keep the client configuration as simple as possible so APOP
>> seems like it might be cause the users some confusion. One aim is to
         [...]
> TLS is pretty simple to have users make use of. It's well supported by client 
> software. Don't expect a majority of your users to use it though.

Is there well known documentation on how to do this?  With a variety
of mail clients (Outlook, Outlook Express, Eudora) to handle this
needs to be fairly painless.  Most Microsoft mail clients seem to
have a facility that says something like (its a while since I
looked) secure connection, and doesn't tell you whether it should be
usng TLS, SSL, PAM, or whatever.  I have the suspicion that one will
get what one is given, and it will be hard to determine what that
is. :-)  If it goes wrong, I also suspect that anyone looking at
this will be told to see the system administrator.... Pointers would
be useful.

         Thank you
         Hugh
Permalink | Reply |
headers
Dermot Paikkos | 20 Sep 2004 16:34

Re: Recommanded config

Daniel,

1) yes I have that:
popuser:x:36:15:Pop user:/var/spool/mail/popuser:/bin/false

which is fine for non-shell accounts. But as said, if someone snoops 
my pop session they will also have my login password. And yes, they 
could do the same with telnet.

2) This server does more than just pop so other services have to be 
on. 

3) I have shadows but the pop users send details in plain-text, 
that's where the vulnerable is, not in the /etc/passwd file.

4) I am trying to avoid having to make the clients make any changes 
to their e-mail client, otherwise I would probably go with APOP which 
would give me the separation of pop-user and shell accounts I am 
trying to achieve.

Dp.

On 20 Sep 2004 at 10:18, Daniel Senie wrote:

> At 09:52 AM 9/20/2004, Dermot Paikkos wrote:
> >Hi,
> >
> >SYSTEM: Exim 4.42 MTA Qpopper 4.0.5 on Tru64 UNIX
> >
> >I am planning to move our email from a v. old server and popd to a
(Continue reading)

Permalink | Reply |
headers
Christian Schmidt | 22 Sep 2004 00:55
Picon

Re: Recommanded config

Hello Dermot,

Dermot Paikkos, 20.09.2004 (d.m.y):

> 1) yes I have that:
> popuser:x:36:15:Pop user:/var/spool/mail/popuser:/bin/false
> 
> which is fine for non-shell accounts. But as said, if someone snoops 
> my pop session they will also have my login password.

But if the user's shell is /bin/false, they won't be able to login to
gain shell access.

> And yes, they could do the same with telnet.

This can be done using every protocol that is not secured by means of
encryption. ;-)

Regards,
Christian
--

-- 
Der Geist wird reich durch das, was er empfängt, das Herz durch das,
was es gibt.
		-- Victor Marie Hugo
Permalink | Reply |
headers
Christian Schmidt | 20 Sep 2004 18:32
Picon

Re: Recommanded config

Hello Dermot,

Dermot Paikkos, 20.09.2004 (d.m.y):

> 1) yes I have that:
> popuser:x:36:15:Pop user:/var/spool/mail/popuser:/bin/false
> 
> which is fine for non-shell accounts. But as said, if someone snoops 
> my pop session they will also have my login password.

What about switching to POP3s?

Regards,
Christian
--

-- 
Auf die bösen Menschen ist Verlaß. Sie ändern sich nicht.
		-- William Faulkner
Permalink | Reply |

Gmane