smtp-auth + qmail-tls + forcetls patch for qmail

Changelog

  • 2016-09-19
    -qmail-tls patch updated to v. 20160918
      * bug: qmail-remote accepting any dNSName, without checking that is matches (E. Surovegin)
      * bug: documentation regarding RSA and DH keys (K. Peter, G. A. Bofill)
  • 2016-05-15 force-tls patch improved (a big thanks to Marcel Telka). Now qmail-smtpd avoid to write the auth verb if the STARTTLS command was not sent by the client
  • 2015-12-26 qmail-tls: updated to v. 20151215
    * typo in #if OPENSSL_VERSION_NUMBER for 2015-12-08 patch release (V. Smith)
    * add ECDH to qmail-smtpd
    * increase size of RSA and DH pregenerated keys to 2048 bits
    * qmail-smtpd sets RELAYCLIENT if relaying allowed by cert
  • 2015-10-05 qmail-authentication: updated to v. 0.8.3
  • 2015.08-24 fixed a bug on qmail-smtpd.c causing a double 250-STARTTLS, thanks to Andreas
  • 2015.08.08 fixed a bug on qmail-remote.c that was causing the sending of an additional ehlo greeting, thanks to Cristoph Grover

I have put into a package the latest version of the following patches for netqmail-1.06. You may be interested to the combined patch I have put together here.

qmail-authentication

Provides cram-md5, login, plain authentication support.
Fixed an issue on wrong capabilities in the ehlo message (thanks to Florian and genconc): removed the "-" sign before the AUTH verb

-  if (smtpauth == 1 || smtpauth == 11) out("250-AUTH LOGIN PLAIN\r\n");
-  if (smtpauth == 3 || smtpauth == 13) out("250-AUTH LOGIN PLAIN CRAM-MD5\r\n");
-  if (smtpauth == 2 || smtpauth == 12) out("250-AUTH CRAM-MD5\r\n");
+  if (smtpauth == 1 || smtpauth == 11) out("250 AUTH LOGIN PLAIN\r\n");
+  if (smtpauth == 3 || smtpauth == 13) out("250 AUTH LOGIN PLAIN CRAM-MD5\r\n");
+  if (smtpauth == 2 || smtpauth == 12) out("250 AUTH CRAM-MD5\r\n");

remember to restore the "-" sign if you are going to append a new line to the ehlo message.

qmail-tls

Implements TLS encrypted and authenticated SMTP between the MTAs and from MUA to MTA.

force-tls

Optionally gets qmail to require TLS before authentication to improve security.

Usage

wget http://notes.sagredo.eu/sites/notes.sagredo.eu/files/qmail/roberto-netqmail-1.06_auth_tls_force-tls.patch-latest
wget http://qmail.org/netqmail-1.06.tar.gz
tar xzf netqmail-1.06.tar.gz
cd netqmail-1.06
chown -R root.root .
patch < ../roberto-netqmail-1.06_auth_tls_force-tls.patch-latest
make
make setup check

Forcing STARTTLS

By default the authentication will be denied if the client does not provide the STARTTLS command. If you want to allow connections without TLS, just do

export FORCETLS=0

in your run file. Values different from 0 or no declaration at all will force the TLS before the auth.

Managing auth options

You may want to take a look to the README.auth file expecially if you are planning to enable CRAM-MD5 auth.

Be aware that you have to export SMTPAUTH in you run file.

Commenti

HI

I have question about forcetls patch:

telnet localhost 25
Trying 127.0.0.1...
Connected to box.
Escape character is '^]'.
220 domain.com ESMTP
ehlo box
250-domain.com
250-STARTTLS
250-PIPELINING
250-8BITMIME
250-SIZE 67108864
250 AUTH LOGIN PLAIN CRAM-MD5
auth login
538 auth not available without TLS (#5.3.3)
quit
221 domain.com
Connection closed by foreign host.

If forcetls is active, why not offer authentication server in an unencrypted connection?

swaks -t user@domain.com -f test@domain.com -s localhost -p25 -au test@domain.com -ap password
=== Trying localhost:25...
=== Connected to localhost.
<- 220 domain.com ESMTP
-> EHLO localhost.localdomain
<- 250-domain.com
<- 250-STARTTLS
<- 250-PIPELINING
<- 250-8BITMIME
<- 250-SIZE 67108864
<- 250 AUTH LOGIN PLAIN CRAM-MD5
-> AUTH CRAM-MD5
<** 538 auth not available without TLS (#5.3.3)
-> AUTH LOGIN
<** 538 auth not available without TLS (#5.3.3)
-> AUTH PLAIN AHRlc3RAZG9tYWluLmNvbQBwYXNzd29yZA==
<** 538 auth not available without TLS (#5.3.3)
*** No authentication type succeeded
-> QUIT
<- 221 wampir7.pl
=== Connection closed with remote host

Auth TLS not available without a password, and so it was sent in clear text, when you try to AUTH PLAIN authentication.
Is this a correct and meaningful?

The correct solution - gmail.com:

telnet smtp.gmail.com 25
Trying 74.125.79.108...
Connected to smtp.gmail.com.
Escape character is '^]'.
220 mx.google.com ESMTP a10sm4909715een.6
ehlo gmail.com
250-mx.google.com at your service, [83.230.14.219]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
auth login
530 5.7.0 Must issue a STARTTLS command first. a10sm4909715een.6
quit
221 2.0.0 closing connection a10sm4909715een.6
Connection closed by foreign host.

The server does not provide authorization for connection without encryption:

swaks -t user@domain.com -f test@gmail.com -s smtp.gmail.com -p25 -au test@gmail.com -ap password
=== Trying smtp.gmail.com:25...
=== Connected to smtp.gmail.com.
<- 220 mx.google.com ESMTP h3sm1449764eea.7
-> EHLO localhost.localdomain
<- 250-mx.google.com at your service, [83.230.14.219]
<- 250-SIZE 35882577
<- 250-8BITMIME
<- 250-STARTTLS
<- 250 ENHANCEDSTATUSCODES
*** Host did not advertise authentication
-> QUIT
<- 221 2.0.0 closing connection h3sm1449764eea.7
=== Connection closed with remote host.

No attempt was made AUTH PLAIN authentication, the password is safe.
Is such a solution is correct? Does it make sense?

In my opinion gmail has the correct solution to prevent sending an unencrypted password in the AUTH PLAIN.

Can you make a patch forcetls similar change in the future?

 

Cheers

Yes, I agree. This is a point where the patch deserves some improvement. I'll fix it when I have some time.

Thanks a lot for the contribution.

Hello, I used your installations and now my server is used to relay unauthenticated users from outlook or thunderbird to send mails through my server ... they creates accounts with wrong username/password in outlook per example, only the domain is good. What can i do to stop this?

If I understand well, they are using your MTA to send unauthenticated mail? In that case you have an open relay and I suggest to take a look again to the page where the "qmail configuration" is explained, in particular the submission service setup on port  587.

If they are sending messages through another relay, I suggest to setup SPF, DKIM and a DMARC policy

Hello,

They are using outlook or any other agent to send mail without be authenticated ... per example they take one from my hosted domains and use fake email, after this they set it in outlook, and they start sending spams. i don't use the port 587.

I just tested my self by connecting with a fake account into my server using outlook, and im able to send mails.

Do you have any suggestions ?

thank you

So you are not using my installation properly. Double check your tcp.smtp file to be sure that you are not allowing the internet to send mail with your server. 

Hello,

Here's my tcp.smtp file :

127.0.0.1:allow,RELAYCLIENT=""
:allow,SIMSCAN_DEBUG="2",QMAILQUEUE="/var/qmail/bin/simscan",CHKUSER_RCPTLIMIT="15",CHKUSER_WRONGRCPTLIMIT="3",CHKUSER_START="DOMAIN"

Any ideas ?

Thank you

your tcp.smtp is correct, but the behaviour of your server seems not to follow its setup. Are you absolutely sure that you are actually usinig this file, and that you have rebuilt your tcp.cdb file?

Hello,

Yes im using qmailctl cdb every time i change this file.

I don't know what im missing ?

can you show your rcpthosts? You should have only your local domains there

Yes i have only my hosted domains ... one per line

Hello,

Here's the logs of a current user who send mail from outlook :

@4000000057960ad937de0a44 CHKUSER relaying rcpt: from <Barnett.66811@domain.ltd|remoteinfo/auth:|chkuser-identify:> remote <helo:PcName|remotehostname:unknown|remotehostip:IP> rcpt <xxx@gmail.com> : client allowed to relay

@4000000057960ad937de77a4 policy_check: local Barnett.66811@domain.ltd -> remote xxx@gmail.com (UNAUTHENTICATED SENDER)
@4000000057960ad937dec5c4 policy_check: policy allows transmission
@4000000057960add2084e1ec mail recv: pid 11216 from <Barnett.66811@domain.ltd> qp 11217
@4000000057960add2084e5d4 qmail-smtpd: message accepted: Barnett.66811@domain.ltd from IP to xxx@gmail.com helo PcName
@4000000057960ae006d3083c tcpserver: end 11216 status 0
@4000000057960ae006d30c24 tcpserver: status: 0/30

Barnett.66811 is the fake user in domain.ltd (domaine exist)

can you contact me in a private message, so that we can investigate what's happening? (use the "contact" button above)

I have adjusted the force-tls patch accordingly. Now the program simply does an exit instead of a return if STARTTLS is not provided when required.

Hello,

first of all this patch needs to be updated so that SSLv3 is switched off. I did this by adding the following line of code in qmail-smtpd.c and qmail-remote.c:

  if (!myssl) { tls_err("unable to initialize ssl"); return; }

  /* disable SSLv3 */
  SSL_set_options(myssl, SSL_OP_NO_SSLv3);

Then, more severe, the parsing of the capabilities in the HELO message causes Gmail to choke and refuse mail delivery TO a patched server. The CORRECT lines should be:

+#endif
+  out("\r\n250-PIPELINING\r\n250-8BITMIME\r\n");
+  if (smtpauth == 1 || smtpauth == 11) out("250 AUTH LOGIN PLAIN\r\n");
+  if (smtpauth == 3 || smtpauth == 13) out("250 AUTH LOGIN PLAIN CRAM-MD5\r\n");
+  if (smtpauth == 2 || smtpauth == 12) out("250 AUTH CRAM-MD5\r\n");
   seenmail = 0; dohelo(arg);

NOTE the "-" sign at 8BITMIME and the REMOVED "-" sign at AUTH lines... this is necessary to not violate the ESMTP protocol!

BR Florian

thanks for the advise. Actually I was aware of the first issue, but didn't have time to fix it by myself. I'll do an update as soon as possibile

Concerning the second problem, I will write a note to the author of the qmail-auth patch and eventually I'll correct it as well

Florian, concerning the dash "-" question, as you know it must be omitted just in case it will be the last command in the list. In my big patch I have:

250-STARTTLS
250-PIPELINING
250-8BITMIME
250-AUTH LOGIN PLAIN
250 SIZE 25000000

and this is why the dash is present.

I'm not sure it's worth to modify the patch in this page, as it will certainly be the base for other patches that need to be added, which may (or not) add a command in the list. A good practice could be to add an innocent command like BYEBYE without dash at the end, but I think that problems could arise also in this case.

Hello,

this is strange. After your patch I do not see "SIZE" in the output. This could be the reason then. I will investigate

Thanks so far BR

The SIZE is due to the esmtp-size patch. I'm using this big patch http://notes.sagredo.eu/node/82#esmtp-size

Hello Roberto,

this explains it maybe: I did not use the big patch that you refer to in the link on the beginning, but only the smaller one from 11/2013. There is no size patch included, but the 250 headers are wrong. Maybe you should take this patch offline for reasons of clarity. I really overlooked that this is not the same file...

BR Florian

that patch reflects the modifications to qmail-smtpd.c of the qmail-auth patch. But I think that you are right, so I'm going to adjust it

I'm embarassed to say how many hours I lost before properly comprehending this exchange about florian's edits. In short I was operating under the assumption that

http://notes.sagredo.eu/sites/notes.sagredo.eu/files/qmail/patches/roberto-netqmail-1.06_auth_tls_force-tls.patch-latest

contained those edits. In the  hope of saving time for other careless readers like me, I have editted your auth_tls_force-tls patch to incorporate the "250-8BITMIME" fix and Vermeulen's more recent qmail-tls patch (20141216) which disables SSLv3.

You can get the updated patch here.

Hi gencoc, thanks for the contribution.

Concerning the "250-8BITMIME" fix, as said above, I'm not sure this is a fix. Anyway I'm going to write a clarification on the purpose as soon as possibile

I corrected the patch accordingly and upgraded the qmail-authentication to 0.8.2 as well

Hi there, great work on your combiled patch..

I've been working to try and disable auth on port 25 and require auth on 587. So far, it it's going well..

on 587, SMTPAUTH="!"

on 25, SMTPAUTH="-"

However, I've noticed on port 25 it would advertise 250-AUTH PLAIN LOGIN, however if I submit an AUTH request, it will honor it.

I was tempted to create a patch to enforce this, when smtpauth=0 in qmail-smtpd, however that changes the way the patch works. Instead I was thinking of creating a new mode: SMTPAUTH="^" which disables auth altogether.

--- netqmail-1.06/qmail-smtpd.c 2015-01-21 02:20:52.947328493 +0000
+++ netqmail-1.06-cp/qmail-smtpd.c      2015-01-21 02:26:36.179831239 +0000
@@ -178,6 +178,7 @@
 }
 
 int smtpauth = 0;
+int smtpauthdisable = 0;
 int liphostok = 0;
 stralloc liphost = {0};
 int bmfok = 0;
@@ -249,7 +250,9 @@
   auth = env_get("SMTPAUTH");
   if (auth) {
     smtpauth = 1;
+    smtpauthdisable = 0;
     case_lowers(auth);
+    if (!case_diffs(auth,"^")) { smtpauth = 0 ; smtpauthdisable = 1 ; }
     if (!case_diffs(auth,"-")) smtpauth = 0;
     if (!case_diffs(auth,"!")) smtpauth = 11;
     if (case_starts(auth,"cram")) smtpauth = 2;
@@ -1055,6 +1058,9 @@
 void smtp_auth(arg)
 char *arg;
 {
+/* Really disable auth */
+  if (smtpauthdisable) { out("503 auth not available (#5.3.3)\r\n"); return; }
+
 
 /* forcetls patch */
 #ifdef TLS

 

First of all, to disable auth on port 25, why don't you simply avoid to call vchkpw in your run file? In that way there's no need to declare SMTPAUTH anymore.

Concerning your suggestion, what the RFCs say? I don't have the time to check, but are you sure that you *can* declare the AUTH verb even if the auth is forbidden?

In any case I think it's better to stick with the original eh auth patch, just to simplify the future upgrades...

Thanks for the contribution :)

First of all, to disable auth on port 25, why don't you simply avoid to call vchkpw in your run file? In that way there's no need to declare SMTPAUTH anymore.

I can't make that change since it would be global. I actually need to be able to disable SMTP auth for some systems, not all so using environment variables and tcpserver is the way to do this rather than a global change to vchkpw

Concerning your suggestion, what the RFCs say? I don't have the time to check, but are you sure that you *can* declare the AUTH verb even if the auth is forbidden?

You're describing what I think is a bug. With your patch the server postively responds to AUTH even if AUTH is not advertised (and should be disabled SMTPAUTH="-" or SMTPAUTH unset)  Here's a walk through of the problem and how my patch works around it:


$ telnet localhost 25 # With SMTPAUTH unset or SMTPAUTH set to "-"
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 caretaker.intrepid.co.uk ESMTP
EHLO localhost
250-caretaker.intrepid.co.uk
250-STARTTLS
250-PIPELINING
250-8BITMIME   
250 SIZE 0

Ok, so far it hasn’t offered 250-AUTH

AUTH PLAIN
538 auth not available without TLS (#5.3.3)

That’s not right, it should say auth is unavailable fullstop!

Let’s try with openssl to support STARTTLS
$ openssl s_client -connect localhost:25 -starttls smtp
...
250 SIZE 0
AUTH PLAIN
334
mybase64creds
235 ok, go ahead (#2.0.0)

Even though AUTH was not advertised, and we explictly asked for it to
be disabled (SMTPAUTH="-") it still accepted the AUTH username and password

With my patch (SMTPAUTH="^") AUTH really is disabled:

$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 caretaker.intrepid.co.uk ESMTP
EHLO localhost
250-caretaker.intrepid.co.uk
250-STARTTLS
250-PIPELINING
250-8BITMIME
250 SIZE 0

AUTH PLAIN
503 auth not available (#5.3.3)

I'm not sure my patch is the best way to solve this bug. It adds another feature (SMTPAUTH="^") which means it won't change existing behaviour (for people who rely on the hidden but available AUTH) However, if it were to follow the RFC, I believe that if AUTH is not advertised, AUTH requests should always be met with a 503

I can't make that change since it would be global. I actually need to be able to disable SMTP auth for some systems, not all so using environment variables and tcpserver is the way to do this rather than a global change to vchkpw

Why not assigning to those systems the RELAYCLIENT variable?

Concerning the main purpose of your message, I understand now. In normal conection (not encrypted) it should not advertise the AUTH if it is not allowed. This should be fixed.

But I can't get the bug you showd in the encrypted connection. I have

AUTH PLAIN
503 auth not available (#5.3.3)

are you using my latest combined patch, with no modifications?

Edit: uh.. this is because I don't have vchkpkw.. So I think you are right. I will apply your patch. Thank you :)

I'm thinking again about it... actually this is not a bug but an intentional behaviour of the auth patch. Infact it allows the auth if SMTPAUTH is not declared at all.

Please let me know if you can solve assigning the RELAYCLIENT to those IP and disabling vchkpw on the run file

Hi,

I had added  export FORCETLS=0 to my run file and still it requires TLS auth.

<-  250-STARTTLS
<-  250-PIPELINING
<-  250-8BITMIME
<-  250-AUTH LOGIN PLAIN CRAM-MD5
<-  250 SIZE 0
 -> AUTH LOGIN
<** 503 auth not available (#5.3.3)
*** No authentication type succeeded
 -> QUIT

What did i done wrong?

regards

nic

Hi Nic,

it's not complaining about a missing TLS connection, it's complaining about a missing AUTH. Are you sure that you are calling vchkpwd in your run file?

Thanks Roberto. You spotted it correctly.

cheers!

Hi Roberto,

Please, you can update the combined patch with the last patch, combine patch version is 2015.04.11 right now.

Thank for you work!!

Hi, the big patch 2015.04.11 already contains the latest auth-0.8.2 and tls-20141216 :-)

Thank you for gathering all these useful informations, patches and stuff regarding netqmail. I have found however a situation which might not be supported by these patches. I have set FORCTLS=1 for all clients coming from the outside (not our DMZ or LAN), because I want them to use encryption. On the other side a CRAM-MD5 authentication does offer a certain amount of safety (IMO). So i should allow the users to use this. but not LOGIN or PLAIN. But this is not possible? Am I right? Thank you.

to allow *only* CRAM-MD5 just use (README.auth for more info)

SMTPAUTH="!cram"

but IMHO a TLS connection is already secure with TLS v.1.2 (POODLE vulnerability was fixed in the latest patch version) and I think there's no need to force also CRAM-MD5, which turns to be useful just when you cannot force tls (on port 25 for instance) 

Hello Roberto,

I have a question about the combined smtp-auth + qmail-tls (starttls) + forcetls patch. We have a problem with one server which refuses to accept messages send by our MTA. While tracking down with network debugging tools I found that qmail sends the EHLO three times. These are refused by the remote mailserver and qmail finally gives up. If I understand the combined patch correctly there are actually 3 EHLOs sent. On if it's via SMTPS, then after tls_init once again. And a third time unconditinally. Is this correct? Well, normally there are no problems, but one mailserver doesn't accept our mails anymore.

+ if (code >= 500) quit("DConnected to "," but greeting failed");
+ if (code != 220) quit("ZConnected to "," but greeting failed");
+
+#ifdef EHLO
+# ifdef TLS
+ if (!smtps)
+# endif
+ code = ehlo();
+
+# ifdef TLS
+ if (tls_init())
+ /* RFC2487 says we should issue EHLO (even if we might not need
+  * extensions); at the same time, it does not prohibit a server
+  * to reject the EHLO and make us fallback to HELO */
+ code = ehlo();
+# endif
+
+ code = ehlo();
+
+ if (code == 250) {
+ /* add EHLO response checks here */
+
+ /* and if EHLO failed, use HELO */
+ } else {
+#endif
+
+ substdio_puts(&smtpto,"EHLO "); substdio_put(&smtpto,helohost.s,helohost.len); substdio_puts(&smtpto,"\r\n"); substdio_flush(&smtpto); - if (smtpcode() != 250) quit("ZConnected to "," but my name was rejected");

Hi Christoph,

in my telnet tests I always get only two EHLO. The portion of code that you report is actually suspect, but I have to admit that it's not clear to me what all those "if" imply. Anyway that portion of code is exactly the code of the tls Vermulen patch, as there were no modifications/customizations by me in qmail-remote.c

Let me know if you manage to solve

Yes, they are the same. So I should perhaps ask Vermeulen himself about it? I have a recording of a network session, where there are actually three EHLOs sent, and after that a HELO. The remote server doesn't understand this and starts to refuse the 2nd, 3rd EHLO and the final HELO. I will tell you what I found out. Greetings

Hi Roberto, Sorry. I lost oversight a little. I think the Vermeulen patch with POODLE attack changes is not exactly the same as part of your compiled patch. There a at least a few double lines in the combined patch. I think there's at least one line of 'code = ehlo()' too much. This gets too complicated via this blog - perhaps we should go on via mail? you have my address.

Sorry, I'm nearly spamming you ... ;-)

I've been able to create a patch. I finally understood what is there too mich in the combined patch, and this is the patch for qmail-remote.c We should perhaps really discuss this further via mail - you have my address.

root@flip-vm netqmail-1.06]# diff -u qmail-remote.c.pre.patch qmail-remote.c 

--- qmail-remote.c.pre.patch 2015-08-05 17:24:19.277513324 +0200 
+++ qmail-remote.c 2015-08-06 01:05:19.583864641 +0200

@@ -544,34 +544,23 @@
code = ehlo();
# endif 
- code = ehlo();
+ if (code == 250)
+ {
+ /* add EHLO response checks here */
- if (code == 250) {
- /* add EHLO response checks here */
- 
- /* and if EHLO failed, use HELO */
- } else {
+ /* and if EHLO failed, use HELO */
+ } else { 
#endif
-
-
- substdio_puts(&smtpto,"EHLO ");
- substdio_put(&smtpto,helohost.s,helohost.len);
- substdio_puts(&smtpto,"\r\n");
- substdio_flush(&smtpto);
-
- if (smtpcode() != 250) {
- substdio_puts(&smtpto,"HELO ");
- substdio_put(&smtpto,helohost.s,helohost.len);
- substdio_puts(&smtpto,"\r\n");
- substdio_flush(&smtpto); 
- code = smtpcode();
- // CGi
- // if (code >= 500) quit("DConnected to "," but my name was rejected");
- // if (code != 250) quit("ZConnected to "," but my name was rejected");
- }
+ substdio_puts(&smtpto,"HELO ");
+ substdio_put(&smtpto,helohost.s,helohost.len);
+ substdio_puts(&smtpto,"\r\n");
+ substdio_flush(&smtpto);
+ code = smtpcode();
+ if (code >= 500) quit("DConnected to "," but my name was rejected");
+ if (code != 250) quit("ZConnected to "," but my name was rejected");
#ifdef EHLO
- }
+ } 
#endif 
if (user.len && pass.len)

Roberto,

your combined patch also has another small issue with the SMTP server sending the "250-STARTTLS" capability back twice in response to an EHLO query.

The problem is in qmail-smtp.c. Your combined patch includes (in the smtp_ehlo() routine):

+#ifdef TLS
+ if (!ssl) out("\r\n250-STARTTLS");
+ if (!ssl && (stat("control/servercert.pem",&st) == 0))
+   out("\r\n250-STARTTLS");
+#endif

but this should be:

+#ifdef TLS
+ if (!ssl && (stat("control/servercert.pem",&st) == 0))
+ out("\r\n250-STARTTLS");
+#endif

I.e. there is one STARTTLS response too many.

This seems to be an issue with the qmail-tls patch (netqmail-1.06-tls-20141216.patch) not having been applied properly. (That patch is a bit weird, it patches qmail-smtp.c twice, first to add the line in question, then later to remove it again.)

Thanks for putting all of this together!

Andreas

 

thank you. I'll fix it asap

Edit: this bug has been fixed

Hello,

I have the some issue :

220 xxxxa ESMTP
4000000055f84b69318515fc 30706 < EHLO xxxxx
4000000055f84b693186082c 30706 > 250-xxxx
4000000055f84b6931860c14 30706 > 250-STARTTLS
4000000055f84b6931860ffc 30706 > 250-PIPELINING
4000000055f84b6931860ffc 30706 > 250-8BITMIME
4000000055f84b6931862f3c 30706 > 250-AUTH LOGIN PLAIN
4000000055f84b6931863324 30706 > 250 SIZE 0
4000000055f84b69358ac3a4 30706 < AUTH LOGIN
4000000055f84b69358b2d1c 30706 > 503 auth not available (#5.3.3)

Im calling vchkpw from run file ... but still i can't authenticat ... would you please tell me how you solved this issue ?

Thank you

Hi, can you post your run file?

Hello,

Here's is my run file 

#!/bin/sh

QMAILQUEUE="/var/qmail/bin/simscan" ; export QMAILQUEUE
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`*

export SMTPAUTH=''
export AUTH=1
export FORCETLS=0
LOCAL=`head -1 /var/qmail/control/me`
if [ -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z "$LOCAL" ]; then
echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
echo /var/qmail/supervise/qmail-smtpd/run
exit 1
fi
if [ ! -f /var/qmail/control/rcpthosts ]; then
echo "No /var/qmail/control/rcpthosts!"
echo "Refusing to start SMTP listener because it'll create an open relay"
exit 1
fi
exec /usr/local/bin/softl

but you are not calling vchkpw as you said.. I'm not familiar with checkvpw.. I guess that the problem is there..

Yes, even if i replace the run file with /home/vpopmail/bin/vchkpw ... i always can't authenticate

ls -l /home/vpopmail/bin/vchkpw
-rwx--x--x 1 vpopmail vchkpw 123968 sept. 15 10:40 /home/vpopmail/bin/vchkpw

are you using my combined patch?

Yes, i used netqmail 1.06 with your combined patch ...

for information i had already vpopmail installed from the qmail 1.03 ... now i upgrated to netqmail with your scripts ...

But im still facing that problem ... i don't see what im doing wrong ... do you think this is a problem with the vchkpw already installed with vpopmail ?

thank you

did you recompiled vpopmail against the netqmail patched with my combined patch? If yes, what the smtp log says?

Hello,

No i didn't recompiled vpopmail after make setup check for your netqmail patch comibined ... do i have to do it ?

Thank you

Hello,

I just recompiled vpopmail and then re-patch your netqmail with your comibned patch ... but the problem is still present ...

Any ideas ?

Thank you

Sorry, I didn't explain myself very well. Actually you have to recompile netqmail once you have installed vpopmail. If this is what you did you are ok. In the case feel free to post the smtp log

Hello,

I fixed the problem ... it was in my run file ...

this :

exec /usr/local/bin/softlimit -m 30000000 \
/usr/local/bin/tcpserver -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" XXX 2525 \
/usr/local/bin/recordio sh -c '/var/qmail/bin/qmail-smtpd' XXX \
/home/vpopmail/bin/vchkpw /usr/bin/true 2>&1

Should be like this :

exec /usr/local/bin/softlimit -m "30000000" \
    /usr/local/bin/tcpserver -v -H -R -l  "$LOCAL" \
    -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
    -u "$QMAILDUID" -g "$NOFILESGID" XXX 2525 \
    /var/qmail/bin/qmail-smtpd \
    /home/vpopmail/bin/vchkpw /bin/true 2>&1

Thank you

It looks like there is a bug in the qmail-auth patch. I have an Android client connecting to the server (using TLS), and the client is issuing a RSET command after successfully authenticating but before sending the actual email (for whatever reasons that I don't understand). This results in the actual sending of the message failing with an "Authentication required" message (I have SMTPAUTH='!') set). The issue seems to be that, according to the SMTP RFCs, a RSET must retain authentication, yet the patch resets it (in smtp_rset()):

void smtp_rset(arg) char *arg;
{
-  seenmail = 0;
+  seenmail = 0; seenauth = 0;
+  mailfrom.len = 0; rcptto.len = 0;
   out("250 flushed\r\n");
}

I have fixed this to comment the resetting of 'seenauth':

void smtp_rset(arg) char *arg;
{
-  seenmail = 0;
+  seenmail = 0; /* seenauth = 0; */
+  mailfrom.len = 0; rcptto.len = 0;
   out("250 flushed\r\n");
}

With this, the Android client is able to connect and send email successfully.

I will also forward that to the upstream maintainer of the qmail-authentication patch, but you may also want to fix that locally for the time being.

Andreas

 

thank you Andreas, I'll check this issue as soon as possible. 

Andreas, I have noticed that the e.h. has updated his s/qmail but he hasn't updated the qmail patch yet.. do you know if the modification he did was the same as you suggest here in your comment?

I discussed this with him and he had said that we would update his patch and include this modification. He may just want to wait until the next release for qmail-authentication patches. I looked at his most recent s/qmail code, and it looks like he did the same that I showed above in there.

yes, he mentioned your hint in the s/qmail m/l

Hi,  where should I store the certificate? Clientca.pem, clientcrl.pem or servercert.pem? Will the TLS working with a self signed certificate?

I get this error :

454 TLS connection failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol (#4.3.0) after the auth login command.

What does it mean?

Reagrds. Marc

Hi Marc,

I forgot to mention here how to create the certificate. Please take a look to the "Creating an SSL key file" section of the big patch page here http://notes.sagredo.eu/node/82

The certificate is stored in /var/qmail/control/servercert.pem, and in my configuration must be owned by vpopmail. And yes, self signed certs work

Thanks.  I've now generated a new self signed certificate and saved in the right file but I still get the same error message after the starttls command.

220 gj3.grisjaune.com ESMTP
ehlo
250-gj3.grisjaune.com
250-STARTTLS
250-PIPELINING
250-8BITMIME
250-AUTH LOGIN PLAIN
250 SIZE 0
starttls
220 ready for tls
auth login
454 TLS connection failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol (#4.3.0)

For information: I don't use vpopmail. I work with Zarafa (which give POP and IMAP but no SMTP AUTH) on debian. To apply your patch, I started with the netqmail-1.06 from Debian (and the debian patches). So it was necessary to adjust your patch. This is probably the cause of my non fonctional system. Even if I disable the forcetls (in the code), the authentification doesn't work...

Is there a way to get more log? I don't have anything in the qmail logs nor in syslog.

Thanks for help.

Regards, Marc

so which port are you using to do the auth? 

The tls patch embedded in my combined patch does not allow the SSL_23, because of the poodle vulnerability. You must connect using TLS