SMTP Auth Does Not Work
mozafar rowshan
I have installed qmail (netqmail version) and patched it with Krzysztof Dabrowski SMTP Auth patch. But the mail server still operates as an open relay.
The patch was correctly installed:
$ telnet cp.main.org 25
Trying 192.168.4.15...
Connected to cp.main.org (192.168.4.15).
Escape character is '^]'.
220 cp.main.org ESMTP
EHLO cp
250-cp.main.org
250-AUTH LOGIN CRAM-MD5 PLAIN
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-PIPELINING
250 8BITMIME
...
My /service/qmail-smtp/run lines that call qmail-smtpd:
exec /usr/local/bin/softlimit -m 10000000 \
/usr/local/bin/tcpserver -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 25 /var/qmail/bin/qmail-smtpd \ cp.main.org /bin/cmd5checkpw /bin/true 2>&1
The cmd5checkpw binary is setuid and owned by "smau" user:
$ ls -l /bin/cmd5checkpw
-rwsr-sr-x 1 smau root 24650 Dec 8 09:47 /bin/cmd5checkpw
My /etc/poppasswd file:
$ ls -l /etc/poppasswd
- r- - - - - - - - 1 smau root 10 Dec 8 09:57 /etc/poppasswd
$ less /etc/poppasswd
someuser:somepass
Also, I loged in as qmaild user and checked cmd5checkpw utility directly and it worked properly!
I haven't any other idea about it. Thank you for help.
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
Kyle Wheeler
>I have installed qmail (netqmail version) and patched it with
>Krzysztof Dabrowski SMTP Auth patch. But the mail server still
>operates as an open relay.
How do you know?
I only ask because there are many ways of "testing" an email server
for being an open relay that are broken and give back false-positives
(i.e. the server is not an open relay, but the test says that it is).
Other than that, I'd suggest asking the author of the SMTP AUTH patch.
Another thing about what you said that bothers me: the mail server
"still" operates as an open relay. Did it operate as one before? Just
adding the SMTP-AUTH capability will not close an open relay; all it
does is allow people to authenticate before relaying. Think of it this
way: a mail server that is not an open relay is a mail server behind a
wall. SMTP-AUTH is a door in the wall. If your mail server was an open
relay to start with, there's no wall, so adding a door is pretty
pointless.
~Kyle
--
The surest way to corrupt a youth is to instruct him to hold in higher
regard those who think alike than those who think differently.
-- Nietzsche
mrowshan
--- James Craig Burley <ja...@jcb-sc.com> wrote:
> [OFF-LIST.]
>
> On Sat, 2007-12-08 at 00:34 -0800, mozafar rowshan
> wrote:
>
> > exec /usr/local/bin/softlimit -m 10000000 \
> > /usr/local/bin/tcpserver -v -R -l "$LOCAL" -x
> /etc/tcp.smtp.cdb -c
> > "$MAXSMTPD" \
> > -u "$QMAILDUID" -g "$NOFILESGID" 0 25
> /var/qmail/bin/qmail-smtpd
> > \ cp.main.org /bin/cmd5checkpw /bin/true 2>&1
>
>
> Looks like that third line was supposed to be broken
> into two lines,
> after the "\" that is instead quoting the space that
> follows as the
> first char in the hostname " cp.main.org".
OK, it was related to my mail client, don't mind it!
> Also, make sure the patch you're using wants a
> hostname as the first
> arg. Some SMTP AUTH patches do, some don't (they
> want just the
> checkpassword command followed by the args).
>
> That's an easy mistake to make if you are applying
> one patch but reading
> the documentation for another on how to configure
> it.
>
> Also, it wasn't clear from your post just what was
> wrong; I didn't see
> where you demonstrated your server was acting as an
> open relay.
OK, you're right. I've installed other Linux on vmware
and test mail client/server interactions; KMail as
client.
When sending a message with KMail (that is NOT
configured to know that "Server requires
authentication..."), the message passes through and
get arrived to the receiving user.
If I configure KMail to know that "Server requires
auth...", so I get some error about that "Server does
not support plain/cmd auth..." and some other error
that I do not remember now.
My test receiving users are the local mail server
users (local domain), So I have a question here:
is this correct that: if receiving user is local, SMTP
Auth will NOT occur??!! If yes, the rcpthosts file
checked BEFORE SMTP Auth??
My rcpthosts file only contains my local domain.
> Keep in mind SMTP AUTH usually only adds the ability
> to relay to the
> rest of the Internet after a user has successfully
> authenticated. An
> incorrect command line could lead to any user/pass
> combo being
> interpreted as legitimate, but won't always do so.
>
> So, unless someone authenticates "successfully" or
> you have some other,
> non-AUTH-related problem (such as a missing
> control/rcpthosts file or an
> incorrect /etc/tcp.smtp file), there shouldn't be
> any open relaying
> going on.
However, this is from my patch documentation:
======================================
take care to ensure your invocation of
qmail-smtpd uses the correct arguments. Otherwise,
your server may run as an open relay!
==================================================
My /etc/tcp.smtp file (allow relay for localhost):
127.:allow,RELAYCLIENT=""
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Kyle Wheeler
> When sending a message with KMail (that is NOT configured to know
> that "Server requires authentication..."), the message passes
> through and get arrived to the receiving user.
Is the user's domain in rcpthosts?
> If I configure KMail to know that "Server requires auth...", so I
> get some error about that "Server does not support plain/cmd
> auth..." and some other error that I do not remember now.
Probably because you haven't set up SMTP-AUTH properly...
> My test receiving users are the local mail server users (local
> domain), So I have a question here: is this correct that: if
> receiving user is local, SMTP Auth will NOT occur??!! If yes, the
> rcpthosts file checked BEFORE SMTP Auth??
The way it works is this: all domains listed in rcpthosts are domains
for which the server is considered "authoritative". For example, if
you were running the mail server for hotmail.com, you would put
hotmail.com into rcpthosts. This instructs qmail to accept any and all
email for hotmail.com NO MATTER WHO SENDS IT. Because it would be
silly to require people to have a hotmail.com email account in order
to send mail to hotmail.com users. So, in that sense, yes, rcpthosts
are checked before anything else.
SMTP-AUTH is a technology for allowing people to *RELAY* email; i.e.
to hand your server email that is destined for somewhere else, and
have your server take responsibility for getting it to the right
location. This would be, for example, if you were running a corporate
mail server, all the people in your company would set their clients to
send mail through your mail server.
But this is basic "how SMTP works" stuff; I think you should probably
read a good book on this (or at least the SMTP rfc) before going much
further.
>> So, unless someone authenticates "successfully" or you have some
>> other, non-AUTH-related problem (such as a missing
>> control/rcpthosts file or an incorrect /etc/tcp.smtp file), there
>> shouldn't be any open relaying going on.
>
> However, this is from my patch documentation:
> ======================================
> take care to ensure your invocation of
> qmail-smtpd uses the correct arguments. Otherwise,
> your server may run as an open relay!
> ==================================================
Indeed, he didn't list all the ways in which things could go wrong.
You found another! Be sure to follow your patch's directions correctly
and exactly!
> My /etc/tcp.smtp file (allow relay for localhost):
>
> 127.:allow,RELAYCLIENT=""
Which makes your server relay any and all email from connections that
originate from the machine itself. This is a common configuration, and
does not make your machine an open relay (in the usual sense of "open
relay").
~Kyle
--
He who joyfully marches in rank and file has already earned my
contempt. He has been given a large brain by mistake, since for him
the spinal cord would suffice.
-- Albert Einstein
mrowshan
OK, very thanks kyle, for these helpful info. But my
problem still has not been solved! I found a patch for
specially netqmail 1.05:
http://shupp.org/smtp-auth-tls/
then, I installed it exactly and my telnet output is
as follows:
$ telnet cp 25
Trying 192.168.4.15...
Connected to cp.main.org (192.168.4.15).
Escape character is '^]'.
220 cp.main.org ESMTP
EHLO cp
250-cp.main.org
250-STARTTLS
250-PIPELINING
250-8BITMIME
250-SIZE 0
250 AUTH LOGIN PLAIN CRAM-MD5
AUTH PLAIN
334
...
Before adding checkpassword /bin/true to smtpd
arguments, the response of my last command (AUTH
PLAIN) was this: "503 auth not available (#5.3.3)", So
this time, it is seemingly correct.
But when I want to connect to my mail server (by
CentOS/thunderbird within VMware):
(1) thunderbird does NOT know that server requires
authentication: if I want to send some message to an
external domain that does NOT exist in the rcpthosts
file, so its error is about rcpthosts file... it's
right. But:
(2) thunderbird DOES know that server requires
authentication: in this case, not only the
destined-for-external-domains messages fail, the mails
for my local domain (ie. included in rcpthosts) also
fail with the same error message:
"Sending of message failed. The message could not be
sent because connecting to SMTP Server cp.main.org
failed. The server may be unavailable or is refusing
SMTP connections..."
I did not find settings for determining the auth type
(plain/LOGIN...) in thunderbird.
thank you sssssssoooooooooo much again. I have really
confused, and have not any other idea about it.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Kyle Wheeler
> OK, very thanks kyle, for these helpful info. But my problem still
> has not been solved! I found a patch for specially netqmail 1.05:
> http://shupp.org/smtp-auth-tls/
> then, I installed it exactly and my telnet output is
> as follows:
>
> $ telnet cp 25
> Trying 192.168.4.15...
> Connected to cp.main.org (192.168.4.15).
> Escape character is '^]'.
> 220 cp.main.org ESMTP
> EHLO cp
> 250-cp.main.org
> 250-STARTTLS
> 250-PIPELINING
> 250-8BITMIME
> 250-SIZE 0
> 250 AUTH LOGIN PLAIN CRAM-MD5
> AUTH PLAIN
> 334
> ...
>
> Before adding checkpassword /bin/true to smtpd
> arguments, the response of my last command (AUTH
> PLAIN) was this: "503 auth not available (#5.3.3)", So
> this time, it is seemingly correct.
Okay...
> But when I want to connect to my mail server (by CentOS/thunderbird
> within VMware):
>
> (1) thunderbird does NOT know that server requires authentication:
> if I want to send some message to an external domain that does NOT
> exist in the rcpthosts file, so its error is about rcpthosts file...
> it's right. But:
Thunderbird CANNOT know whether a server *requires* authentication or
not. All it can know is whether a server *allows* authentication.
> (2) thunderbird DOES know that server requires authentication:
No, it really doesn't.
> in this case, not only the destined-for-external-domains messages
> fail, the mails for my local domain (ie. included in rcpthosts) also
> fail with the same error message:
>
> "Sending of message failed. The message could not be sent because
> connecting to SMTP Server cp.main.org failed. The server may be
> unavailable or is refusing SMTP connections..."
That means Thunderbird CANNOT CONTACT your server. This has nothing to
do with AUTH, and everything to do with whether your server is up,
running, and accepting connections, and whether your client is
configured properly. On my part, for example, cp.main.org is not a
resolvable name (I get an NXDOMAIN error when looking it up). Perhaps
Thunderbird is doing the same thing, and failing. Try configuring
Thunderbird to use the IP address of your server (192.168.4.15),
rather than "cp.main.org".
~Kyle
--
I think we ought always to entertain our opinions with some measure of
doubt. I shouldn't wish people dogmatically to believe any philosophy,
not even mine.
-- Bertrand Russell
Matt Simpson
>Thunderbird CANNOT know whether a server *requires* authentication
>or not. All it can know is whether a server *allows* authentication.
>
>
Hmmm. I've never used Thunderbird, but I once had a confusing
experience with Eudora which might be related.
In Eudora, there is a checkbox to indicate that the server requires
authentication. So, while Kyle is correct that the server itself
only advertises that it ALLOWS authentication, and does not advertise
that it requires it, it is possible for the users of some email
clients to tell the client that the server "requires" authentication.
And the part that really confused me was that when I checked "server
requires authentication", Eudora started using port 587 instead of
25. I guess that makes some sense. A server that "requires"
authentication, i.e. one that will not accept email from ANY client
that has not authenticated, is probably not an inbound MTA.
If Thunderbird makes the same assumption that Eudora does, that a
server that "requires" authentication (as indicated by the user), is
listening on port 587 instead of 25, this could explain mrowshan's
problem. If Thunderbird is trying to contact his server on port 587,
and the server is listening on port 25, that could cause an
"unavailable or refusing connections" error.
mrowshan
Hello everyone.
It was my fault! I was NOT appending my user-ID with
the domain-name when auhentication, in my mail-client.
Thank you all.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
--