[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug or bad configuration??
On Thu, May 31, 2001 at 10:34:54AM +0200, Rocio Alfonso Pita wrote:
> I'm sorry but I don't understand well you. I'm Spanish, my english is
> poor and I don't understand why an user is authenticated and other no.
> can you explain me how I can deny ALL if is not an IP mine?
Simple, don't support user authentication at SMTP.
Other system had at its smtpserver.conf following entries
ACTIVATED (without preceding '#' character):
#PARAM smtp-auth # Enable, if you want to allow SMTP to autenticate
# # with the default code against system /etc/passwd
# # (or whatever source getpwnam() uses for it..)
# # This is intended to be used WITH the TLS network
# # encryption support!
#PARAM SMTP-auth-pipe /path/to/program
# # External authentication program. The
# # authenticator should read a username from
# # command line and a password from standard input.
# # Exit status 0 means successful authentication.
# # Enable, if the "AUTH LOGIN" must be allowed to
# # be used without running under TLS security
# # envelope. ENABLING THIS IS A SECURITY THREAT!
Especially this THIRD PARAM is important -- it allows you, the
system administrator, to endanger your user's passwords security..
(I just changed the wording slightly to emphasis the security issues.)
If you compare the examples, system without AUTH LOGIN
support didn't allow relaying, while the one which did
support it, and at which the user logged in successfully,
that one allowed relaying just fine.
In the policy control codes, "fulltrustnet +" flag, and
having acquired authenticated username are equivalents.
HOWEVER, you can define an "rejectnet +" flag for IP addresses
which overrides even SMTP authentication, but you better
not to use it anywhere except when blacklisting explicitely
some addresses/networks. Specifically: DON'T use it at
the default address tag of: '[0.0.0.0]/0' !
The idea for SMTP authentication is, after all, to verify that
sender is one of local peons, perhaps traveling far away, and
THEN to allow them to send thru the local server.
Security issues step in: NO PLAINTEXT PASSWORDS OVER THE NETWORK
WITHOUT ENCRYPTION ! E.g. do it only under "STARTTLS" encryption
Supply each user with their individual usernames/passwords.
Having the user to *always* needing to authenticate for sending
is a good thing. Doing it only under encryption will make password
stealing that much more difficult.
Doing email retrieval (POP3/IMAP) only under encryption (SSL) is
also an important thing.
> Matti Aarnio wrote:
> > This user has authenticated to the system -- "usuario" is,
> > I think "user" in some latin family language ?
> > My default setup is such that the plaintext password login
> > (the only thing that there is) can only happen underneath the
> > secrecy cloak of SSL. BASE64 encoding is *not* encryption!
> "Passswords are like underwear.
> You donīt share them, you donīt hang them on your monitor,
> or under your keyboard, you donīt email them, or put them on
> a web site, and you must change them very often."
/Matti Aarnio <email@example.com>