Upgrading qmail

I am getting  the following error when connecting to my other server (much older) at mail.sorehands.com when sending from mail2.sorehands.com:

delivery 10: deferral: TLS_connect_failed:_error:0A00018A:SSL_routines::dh_key_too_smallZConnected_to_23.237.50.67_but_connection_died._(#4.4.2)/

I don’t get this error when sending/connecting with gmail's or yahoo's mail servers. 

Try like this

echo 'HIGH:MEDIUM:!MD5:!RC4:!3DES:!LOW:!SSLv2:!SSLv3' > /var/qmail/control/tlsserverciphers

I tried your suggestion, but I still have an issue when sending an issue. 

I tried both 

On mail2.sorehands.com (the new server) I used

HIGH:MEDIUM:!MD5:!RC4:!3DES:!LOW:!SSLv2:!SSLv3

and

DEFAULT

And it had the same problem. But, when changed the old server mail.sorehands.com and used

HIGH:MEDIUM:!MD5:!RC4:!3DES:!LOW:!SSLv2:!SSLv3:!DH

it was happy.

For some reason, it thinks the DH key was too small. Noone else did on either the old or new.

Great. So it appears that the solution is to add

!DH

Hi Roberto,

  I've been experiencing many issues lately with GMail, as they are now rejecting messages due to the lack of Message-ID header. The problem arises when you send autorespond messages (the "blah" part of the Message-ID header added by "autorespond" seems not to be "ok" for Google, so I had to modify the autorespond.c program to add a more apropriate value), valid bounces or any other email sent by any client that doesn't create and add the Message-ID header before sending it using qmail-smtpd. As QMail doesn't add that header when coming from the network, this issue is getting quite problematic for us, QMail users. I've written a small quick'n dirty shell script that removes the original Message-ID if exitst and adds a proper header again, but clients are hanging while using it (I've put it into QMAILQUEUE variable and then invoking the next queue processor after it), so I think I have to research more on the matter... 

  Anyway, I think it's time to add that functionality somewhere in qmail-smtpd.c (checking if Message-ID is already present, or add it if is not), but I wanted to check first if you have seen any patch or add-on, as I wasn't able to find one yet. 

  Thank you in advance. 

Gustavo Castro. 

Hi Gustavo,

thanks for the notice. I can do tests next week.

Can you share your modifications at autorespond.c? Can you mention at least one client that doesn't add a proper message-id, so that I can do tests with it?

PS What is the error message returned by google?

Hello, I’m trying to create a plugin (qmail-spp) to apply in the [data] section, and I can’t manage to get the email itself in order to process it. I do get the environment variables such as SMTPRCPTTO, SMTPMAILFROM, etc.
Do you know if qmail-spp passes the email through stdin or by some other method or variable? or do you have any example?

Regards

Sorry, I'm not sure I understood what you mean here... can you explain what you want to do more in detail?

I want to pass the entire email (header/body/attachments) to a Python or Bash script that will be processed by qmail-spp. From what I understand, in the [data] section I should be able to access the email, but I can’t manage to do it and I’m not sure if it can actually be done there.

Thanks

spp cannot access the email as a whole, e.g. its body content, but only the variables of that email. If you look at the code of smtp_data(), where spp comes into action

if (!spp_data()) return;
seenmail = 0;
if (databytes) bytestooverflow = databytes + 1;
if (qmail_open(&qqt) == -1) { err_qqt(); return; }
qp = qmail_qp(&qqt);
strnumqp[fmt_ulong(strnumqp,qp)] = 0; /* qp for qlog */
out("354 go ahead\r\n");

the spp_data() function is called before the data are sent by the client, as the "354 go ahead" verb still has to come

Hi

I'm constantly following you and thanks for your effort to make qmail still alive. May be you'll remember me, I informed you about simscan's message dropping issue. I see you've given credit about it to your page in "Installing and configuring simscan" section's Changelog:
"unreleased
- message with found viri is now put in quarantine (tx Shah Imran)"

My question is, is qmail capable to sign ARC seal? Is it possible to integrate it? Now days I'm trying to integrate ARC seal in my qmail servers. Hope you can show me some light about it.

Thanks

BR

Shah Imran

Hi,

ARC is not available in my qmail and I'm not aware of any available program to use in order to integrate into my package. If you find anything interesting let me know

Hi Roberto , 

    While trying to download the latest version for upgrading qmail its giving a 404 error.

QMAIL_VERSION=2025.07.10
Location: https://codeload.github.com/sagredo-dev/qmail/tar.gz/refs/tags/v2025.07.10 [following]
--2025-07-13 20:41:37-- https://codeload.github.com/sagredo-dev/qmail/tar.gz/refs/tags/v2025.07.10
Resolving codeload.github.com (codeload.github.com)... 20.207.73.88
Connecting to codeload.github.com (codeload.github.com)|20.207.73.88|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2025-07-13 20:41:37 ERROR 404: Not Found.

corrected

Sorry, you have to wait the Sinner final ending... :-) download from gihub for the time being

Hi Roberto,

I have another small-ish patch. Initially, I just wanted to extend SPP to enable support for conditional greylisting (that will have to come later), but in the process I noticed a few issues with the SPP integration with the rest of the patches. So in the end, my patch now includes multiple things:

1) Fixes for SPP handling. In particular, SPP plugins are supposed to be able to tell qmail-smtp to bypass any of its internal checks ('O' response). Internally, that is when the spp_xxx() functions return 2 instead of 1. But that logic was not always there and in some cases actually reversed (qmail-smtpd would do qregex checks even though spp_mail() returned 2, i.e. told it not to). I fixed that and also added logic to bypass other checks in smtp_helo, smtp_mail and smtp_rcpt if the plugin says so. I decided not to bypass checks that are not directly about RCPT checking, such as RBL checks, as well as calls external tools such as rcptcheck. Also, this integrates with my Debian version of user checking, so needs to be adapted for the chkuser setup (I bypass that by requiring (spp_val == 1) in my case). 

2) Added support for additional "[pass]" SPP plugins that get called *after* all the RCPT checks are done and the recipient is accepted. 

3) Added support for qmail-smtpd setting an RBLRESULT environment variable (akin to SPFRESULT) together with the option for RBL checks to be ignored (by starting the corresponding line with '=' in control/dnsbllist). Such that checks can be used to only set the variable (and output logs). 

Combined patch is here. 

I have, however, not tested this extensively. I don't do any of the extra checking options that the various patches enable. Do you have a way to test esp. the SPP handling changes with things like qregex, realbadrcpt, validrcptto, etc.? To make sure I at least didn't break anything? Likewise for RBL. 

Once this proves stable, my plan is to look into conditional greylisting with the idea of using it as a [pass] plugin that only greylists e.g. if SPF or RBL checks (set to ignore in qmail-smtpd) fail (via SPFRESULT and RBLRESULT variables). In my setup, I don't outright block all RBLs, but let spamassassin handle some. 

Sorry for the late responce to this, but I was engaged in other jobs...

1) Basically I would never bypass [helo] [mail] and [rcpt] plugins, but only [data] plugins. What is the reason to do differently? Is it only in case it passed greylisting or auth? Can it be set in some way?

Please let me know if the patch you linked above is still your latest version, so that I can proceed with some tests

Thanks so much for sharing

The SPP patch linked above should still be the same, I didn't make any more changes.

I am basically just trying to implement the behavior as documented here: https://qmail-spp.sourceforge.net/doc/index.html - if the plugin returns 'O', qmail-smtpd is supposed to bypass other checks.

This was there for MAIL and RCPT, but in some cases the logic was simply wrong (from all I understood), e.g. reversed. So I tried to fix that.

In addition, I extended this also to apply to HELO plugins, i.e. they can now also return 'O' to bypass checks. When SPP was written, there were no checks performed in the HELO phase, so this simply didn't apply then. But the qregex patch adds some checks there, so it made sense to me to extend that functionality to that (in the same way how it applies to qregex checks in MAIL/RCPT). Note that this is optional - it will only apply if the plugin returns 'O', i.e. only in cases where the plugin has been explicitly written to return such a bypass condition (my assumption is that normal HELO plugins won't). In other words, it's set by the plugin.

Finally, note that DATA plugins never had the option to bypass checks (there are no checks during the DATA phase). That remains unchanged.

Thank you. I'll do some tests and get back to you

Hi Roberto,

I created a patch to add "Authentication-Results:" header support for compliance with RFC 7601.I also made the "Received-SPF:" headers a bit more compliant with the relevant RFC 7208 spec. 

I implemented this by letting qmail-smtpd and qmail-dkim pass authentication information to qmail-queue via a QMAILAUTHENTICATED environment variable, where each of them can add relevant info to the header by appending them as semi-colon separated entries to this variable. 

qmail-queue then inserts the actual header if QMAILAUTHENTICATED is defined. If QMAILAUTHENTICATED is defined but empty, it will insert a 'none' header entry. The service/server ID for the header can be defined via an optional 'control/authservid' file (defaults to 'control/me').  

The patch is available here (add '.diff' to the end ot get an actual patch file).  

Thank you, Andreas. I'll check it out

Actually, I fixed a few bugs and improved RFC compliance a bit more. Also, while the "DKIM-Status:" header is not in any RFC (the standard way to communicate DKIM results is the "Authentication-Results:" header it seems), I reverted to mirroring the way the historic RFC sets the "DomainKeys-Status:" header when setting "DKIM-Status:" (e.g. using "good" instead of "pass" the way it was before - also to not break things that may depend on that). 

Patch on top of the other patch is here, i.e. please apply both (this after the other).  

Alternatively, here is the full patch that includes both (as well as a Makefile fix and a README.md change for my repo fork, i.e. the latter you can ignore).

Is the patch for your divergent fork or for my original branch? In latter case a PR would be great 

It's on my forked branch. Probably easier to just apply tihs patch - it should apply to your original branch I would think. Just revert/don't apply the README.md change that is in there. 

It works nicely here!

Authentication-Results: smtp.sagredo.eu;
	spf=pass (smtp.sagredo.eu: SPF record at _netblocks.google.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=sender@gmail.com;
	dkim=pass header.d=gmail.com.20230601.gappssmtp.com header.i=@gmail.com.20230601.gappssmtp.com header.s=20230601

The code for qmail-smtpd.c in the latest Github repo has a bug when using GREETDELAY without DROP_PRE_GREET. Basically, the greetdelay integer value is passed to the logging function where a char* is expected, leading to a segfault. 

I created a patch to fix this (while also making logging more consistent) here.

Thank you. I can't believe no one ever noticed this problem

Let me test some more days the CRLF fix and I'll pull both your fixes on my github

I can't believe no one ever noticed this problem

Yes, it's a quite obvious bug, so not sure how it ended up there. The original GREETDELAY patch did not have this line of code for logging, so not sure when and where it was added. I would have also expected the compiler to catch this and at least throw a warning. Makes you wonder... 

Hi Roberto , 

     I have recently upgraded my server as per the guide mentioned here on your site .  The server is up and running and i have migrated the users to the new server . But few of the users are facing issue as below 

SSL Error when configuring ports 465 smtpsd as outgoing server on Microsoft Outlook

2025-03-25 16:09:41.556666409 sslserver: ok 353235 abc.com:0.0.0.0:465 192.168.55.11::51082
2025-03-25 16:09:41.557265905 sslserver: fatal: (111) unable to accept TLS from: 192.168.55.11 for pid: 353235 unsupported protocol

TLS Error when configuring port 587 submission as outgoing server on Microsoft Outlook

2025-03-25 14:47:23.581863089 tcpserver: ok 328388 103.252.55.4:587 192.168.55.11::50786
2025-03-25 14:47:23.602716462 qmail-smtpd: read failed (tls connection failed): (null) from 192.168.55.11to (null) helo SAIPC

Also User cannot connect to Dovecot on imaps 993 port until I had to change the following setting in dovecot 10-ssl.conf

#ssl_min_protocol = TLSv1.1  if this is enabled user cannot connect from Microsoft Outlook 15 
ssl_min_protocol = TLSv1    Once changed to this user was able to connect from Microsoft Outlook 15 

Any pointers that you can guide me towards so that I can resolve these issues

Regards

I think that you have to allow SSLv3 in /var/qmail/control/tlsserverciphers, but you know that is an unsecure protocol, so do it at your own risk.

!SSLv3 should be deleted from that configuration file if you want to allow SSLv3. So /var/qmail/control/tlsservercipher will be

HIGH:MEDIUM:!MD5:!RC4:!3DES:!LOW:!SSLv2

Another method to allow *only* a particular domain is to touch control/notlshosts/FQDN where FQDN is the domain to allow. In this case all other domains advertising SSLv3 will be banned while microsoft will be allowed. But the important thing to know is that the TLS connection is skipped, so I don't know if it's what you want.

If you declare control/notlshosts_auto containing any number greater than 0 the TLS connection for remote servers with an obsolete TLS version is skipped, i.e. the control/notlshosts/FQDN is dinamically created for you and the next time it connects it will be allowed.

Its not about FQDN , has to do with the Email Client being used as these users are belonging to the same mydomain.tld.  The incoming mail is not a issue at all.  Its just the dovecot imaps 993 and the 465  smtpsd and 587 submission which is not functioning as it should with the old email client being used for this upgraded new version of the mail server. 

I had to change the setting for dovecot 993 port in 10-ssl.conf to allow min 

ssl_min_protocol = TLSv1 instead of the default ssl_min_protocol = TLSv1.1 

Only this way the Email Client Microsoft Outlook was able to connect to the  Imaps port .

I guess this has to do with the email client  Microsoft Outlook version 15  etc .  I will try with Mozilla ThunderBird which I personally use for my gmail account and has been working well for years now . 

Also all these users are from the same domain mydomain.tld and are on a fixed subnet , any tweaking that can be done to facilitate these users without compromising the actual intended functionality of all the upgrades done . 

So the client is using an obsolete protocol that your qmail is refusing. Try the first option in my message above

I would also make tests to find out if TLS 1.0 is sufficient or you have to open to SSLv3 as well

Hi Roberto,

Wanted to check if is correct, I had to change the supervise/qmail-smtpsd/run script to avoid above errors, I'm not getting errors while using SSL with Outlok client on port 465:

Uncomented from the run script:

export FORCETLS=0
export DISABLETLS=1

also commented out:

# qmail-spp plugins
#export HELO_DNS_CHECK=GNLR
#if [ ! -f $QMAILDIR/control/smtpplugins ] || [ ! -d $QMAILDIR/plugins ]; then
export ENABLE_SPP=0
#else
# export ENABLE_SPP=1
#fi

My control/tlsserverciphers:

HIGH:MEDIUM:!MD5:!RC4:!3DES:!LOW:!SSLv2:!SSLv3

I have TLS on port 587 and SSL on port 465 working OK using a Microsoft Outlook client.

Your supervise/qmail-submission/run script is working unchanged on port 587 using TLS on my system..

Yes it seems to be ok. TLS has to be disabled on port 465, while tlsciphers are useful on ports where tls is enabled, i.e. 25 and 587. I would leave on the helo dns check plugin also on 465 service 

Thanks for your reply,

When HELO_DNS_CHECK is turned on with:

export HELO_DNS_CHECK=GNLR

, then I get the error:

2025-06-09 17:20:23.396401419 sslserver: tls 216997 accept TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384
2025-06-09 17:20:43.428969597 helo-dns-check: malformed HELO/EHLO [LUIS11] from [x.x.x.x]
2025-06-09 17:20:43.429043008 helo-dns-check: blocked with: malformed HELO/EHLO

and in Outlook displays:

The connection to the server was interrupted.

Maybe needs different options.

You are right. The helo dns check must disabled on 465 and 587 ports. I have to correct my example run scripts

Thanks Roberto, it is working with the new options now.

The new supervise/qmail-smtpsd/run script you posted is missong the &1 at the end of the last line.

Thank you for your support.

Hi  roberto puzzanghera 

I have installed new version  2024.12.01 but got some error below.

How can I fix it?

Connected_to_27.86.106.68_but_server_does_not_support_unicode_in_email_addresses./Remote_host_said:_250-msmx.au.com/250-PIPELINING/250-SIZE_3145728/250-ETRN/250_8BITMIME/Connected_to_202.93.78.241_but_server_does_not_support_unicode_in_email_addresses./Remote_host_said:_250-mtagw0033.mail.otm.ynwp.yahoo.co.jp/250-PIPELINING/250-8BITMIME/250_SIZE_41943040/

I have evaluated this problem more carefully and checked the code again. The error that you reported

Connected_to_27.86.106.68_but_server_does_not_support_unicode_in_email_addresses./Remote_host_said:_250-msmx.au.com/250-PIPELINING/250-SIZE_3145728/250-ETRN/250_8BITMIME/Connected_to_202.93.78.241_but_server_does_not_support_unicode_in_email_addresses./Remote_host_said:_250-mtagw0033.mail.otm.ynwp.yahoo.co.jp/250-PIPELINING/250-8BITMIME/250_SIZE_41943040/

is triggered by qmail-remote when **sending** UTF8 characters. You don't have any Received header in your sent mail, therefore you don't have to worry about the Received header check. The connection is closed by your server because the outgoing message has UTF8 characters but the remote server does not advertise the SMTPUTF8 capability after the greeting, as can be seen in the above log line.

As you know, if a server can handle EAI, this is how the conversation must begin

# telnet 0 25 
Trying 0.0.0.0... 
Connected to 0. 
Escape character is '^]'. 
220 smtp.sagredo.eu ESMTP 
ehlo test 
250-smtp.sagredo.eu 
250-STARTTLS 
250-PIPELINING 
250-SMTPUTF8 
250-8BITMIME 
250 SIZE 10000000

Hi Jacky,

it is related to the new EAI feature. It means that you are receiving a message with UTF8 characters, but the remote server is violating the RFC protocol, as it's not advertising the SMTPUTF8 verb after the MAIL FROM. So the connection is closed by your server just like if it was garbage.

You could enable recordio in your qmail-smtpd and check if this is the case. The MAIL FROM field in the smtp conversation should look like this if one of the addresses brings special characters:

MAIL FROM:<òòòò@remoteserver.tld> SMTPUTF8
RCPT TO:<mimì@yourserver.tld>

you can test yourself your server telnetting in that way.

Possibly you have addresses with special characters that you can allow. Be aware that things are changed a bit in this new release.

Sorry, the error appears at qmail-remote level, so it's because you are sending special characters in the from and/or rcpt address, but the remote server is not advertising the SMTPUTF8 after the greeting, so the conversation is closed by you.

PS: if you want to add additional special characters to the alphanumeric set, look for the CHKUSER_ALLOWED_CHARS variable at the bottom of chkuser_settings.h in the source. Then recompile and restart qmail

Hi roberto puzzanghera 

Thank you for your advice.

I have also checked checkutf8message() functions in eai.c file.

it not only check characters in the from and/or rcpt address but also check Received: header has [UFT8] character

Received: header with UTF8

Received: from xxx (xxxx)
  by mail4 with UTF8SMTPS (TLS_AES_128_GCM_SHA256 encrypted); 13 Dec 2024 14:55:01 +0900

Received: header without UTF8

Received: from xxx (xxx)
  by mail4. with SMTP; 13 Dec 2024 10:07:55 +0900

Should we check Received: header? 

According to the RFC5336 https://datatracker.ietf.org/doc/html/rfc5336#section-3.2

An SMTP server that announces this extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 2821 specifies that a mailbox can appear.

so yes... let me understand why it can be a problem for you.

Hi Roberto Puzzanghera 

I don’t doubt RFC5336, but after checking all the headers in the email, there were no UTF-8 characters.

However, just because there was a UTF8SMTP string in the Received header, the email couldn’t be sent externally, which seems a bit strange. I’m considering removing the check for the Received header or using an older version.

And this is always happening or just for a specific mail? How can I reproduce it? Send me more details please

Hi roberto puzzanghera 

That just happened with  3 marketing emails.

I am currently testing version 2024-12-01 and debugging it on  one server.

If this issue keeps happening, I will contact you.

Hi Roberto Puzzanghera 

After debugging for a week, everything is stable, and no errors have occurred with this patch.

Thank you for your advice.

Thanks to you for the feedback!

Hi Roberto, thanks for your awesome work and support.

I tried to patch QMAIL_VERSION=2024.10.26 with qmail-remove_chkuser_vpopmail.patch, but failed at hier.c, I think because of this line which is not in the context lines of the relevant portion of the patch:

d(auto_qmail,"control/notlshosts",auto_uidr,auto_gidq,0755);

It also refused to delete chkuser_settings.h.

Regards!

Unfortunately I don't have the time to upgrade that patch. But you can use the specific github branch where chkuser has been dropped

The top of this document says that the latest stable version is v2024.10.26.  But since that version does not even compile I would hardly call it stable.

root@mail:~/qmail# git branch
* (HEAD detached at v2024.10.26)
main
netqmail-1.06
root@mail:~/qmail# make setup check
./compile chkuser.c
chkuser.c:39:10: fatal error: vpopmail.h: No such file or directory
39 | #include "vpopmail.h"
| ^~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:333: chkuser.o] Error 1

The only branch I have seen that compiles without error so far is netqmail-1.06.  The remaining branches fail to complete the make process 

It compiles for those who read the docs. You didn't install vpopmail. I would pay more respect  when approaching a free product, expecially when not giving any kind of contribution to it, or switch to commercial software

I am following the setup instructions here on a debian host (Ubuntu).  They are pretty straightforward.  I followed the instructions to the point where it got to t

• Download and compile

make
make setup check

Make ran the first time but then running make setup check yields the following output:

root@mail:~/qmail# make setup check
( ./auto-uid auto_uida `head -1 conf-users` \
&&./auto-uid auto_uidd `head -2 conf-users | tail -1` \
&&./auto-uid auto_uidl `head -3 conf-users | tail -1` \
&&./auto-uid auto_uido `head -4 conf-users | tail -1` \
&&./auto-uid auto_uidp `head -5 conf-users | tail -1` \
&&./auto-uid auto_uidq `head -6 conf-users | tail -1` \
&&./auto-uid auto_uidr `head -7 conf-users | tail -1` \
&&./auto-uid auto_uids `head -8 conf-users | tail -1` \
&&./auto-uid auto_uidv `head -9 conf-users | tail -1` \
&&./auto-gid auto_gidq `head -1 conf-groups` \
&&./auto-gid auto_gidn `head -2 conf-groups | tail -1` \
&&./auto-gid auto_gidv `head -3 conf-groups | tail -1` \
) > auto_uids.c.tmp && mv auto_uids.c.tmp auto_uids.c
fatal: unable to find user alias
make: *** [Makefile:121: auto_uids.c] Error 111

IT may be entirely possible that maike failed the first time as well, I can't scroll back that far to see.  At any rate running make now yields the same result as make setup check.  It seems like there needs to be certain user preconditions met or something but nothing in the documentation mentions this.

I guess you forgot to create the qmail users

Hi Roberto, 

I am getting the following error while recompiling qmail below are the details 

QMAIL_VERSION=2024.06.08

Openssl Version
OpenSSL 1.0.1e-fips 11 Feb 2013

./compile qmail-remote.c
qmail-remote.c: In function âtls_initâ:
qmail-remote.c:437: error: âOPENSSL_INIT_LOAD_SSL_STRINGSâ undeclared (first use in this function)
qmail-remote.c:437: error: (Each undeclared identifier is reported only once
qmail-remote.c:437: error: for each function it appears in.)
qmail-remote.c:438: warning: passing argument 1 of âSSL_CTX_newâ makes pointer from integer without a cast
/usr/include/openssl/ssl.h:1630: note: expected âconst struct SSL_METHOD *â but argument is of type âintâ
make: *** [qmail-remote.o] Error 1

Regards

Shailendra

Hi Shailendra, this is because of your old openssl version. You have to choose between one of the following options

- upgrade your openssl (I woudn't do it if I don't know which other package must be recompiled (openssh?))

- use an old qmail patch of mine, downloading it from the archive https://notes.sagredo.eu/files/qmail/patches/roberto-netqmail-1.06/. Just pick up the one with the date around your OS release and try. I think at least 10/12 years ago for openssl v. 1.0

- download my latest qmail, manually remove the qmail-tls patch from f.v., then add an old version of the same patch. You can find all qmail-tls patches here https://notes.sagredo.eu/files/qmail/patches/tls/. Just look for the one where the string OPENSSL_INIT_LOAD_SSL_STRINGS is not matched by grep

It appears that the tls patch released in 2020 compiles successfully against openssl v. 1.0

Hello everyone,

I found an error with the delivery of some emails involving TLS.

When using a server with a newer version of OpenSSL, TLS 1.0 and 1.1 were left out, leaving only 1.2 and 1.3. However, because of this, qmail-remote, when delivering emails to older servers, generates a TLS/SSL error and the email returns to the queue.

Error example: delivery 50838: deferral: TLS_connect_failed:_error:0A00018A:SSL_routines::dh_key_too_small;_connected_to_187.8.50.70. (but there are other types).

However, qmail will NEVER attempt to send without TLS to these servers since they report that they support STARTTLS in the connection. Perhaps some adjustment in qmail-remote could be made so that when a TLS/SSL error occurs, it adds the domain's MX FQDN to /var/qmail/control/notlshosts/, so that on the next delivery attempt, it sends without using STARTTLS.

I even found government servers with outdated TLS, which would not receive emails until I added their FQDN to /var/qmail/control/notlshosts for qmail to send without using TLS.

Best regards,

fixed in version 2024.10.26

Hi,

I'm also getting "dh_key_too_small" error while delivering mail to some host. Following are some example host where I get dh_key_too_small error.

itokin.com.hk
mail1.tfzipper.com
mail4.optimaxbd.net
mailgw1e.hk2china.com
mail.mekodenim.com.pk
mail.pot-bd.com

There are many hosts that does not accept mail until I add to /var/qmail/control/notlshosts/. I think there should be an automated script that will add file to /var/qmail/control/notlshosts/ location.

I'm running Debian Bookworm, OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)

Thanks.

I still have to reproduce this issue, I'll try again.

For me, we can add Alexandre's patch but I would require that the user enables the functionality by means of a control file, say control/enablenotlshosts, where to put 1 inside, just to avoid unwanted surprises for those who don't want to allow clients with obsolete tls

Alexandre, do you have upgrades for your patch?

I'm using the patch I made above in production, and it has been working... since that day until today, I have 97 hosts that only support TLS 1.0 or 1.1, and since I don't have support for that, it results in an error. Then it adds the host to notlshosts, and on the next attempt, it sends without using any TLS

Can you guys give this patch a try?

git clone -b fix-dh_key_too_small https://github.com/sagredo-dev/qmail.git

you need to enable the feature defining control/notlshosts_auto with a value greater than 0

I cannot reproduce this issue. I'm sending to a remote server (openssl 0.9.8 with TLS 1.1 not available) and my remote messages have been sent by qmail-remote with no errors.

It would be great if you can mention a public server with an old openssl, to use for a quick test

which version of my qmail package or TLS patch are you using? According to my logs, I haven't had a TLS_connect_failed error for the past 6 years now.

I'm using the latest version, qmail-2024.06.08, compiled on Debian 12.

Testing the remote hosts that showed an error with 'openssl s_client -connect XXXX:25 -starttls,' I see that they still support TLS 1.0 or 1.1, while the version compiled on Debian 12 supports only 1.2 or 1.3.

which version of openssl is installed in debian 12? I'll try to reproduce the issue in the following days, but I think that this is something to submit to f.vermeulen attention

OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)

I made a temporary (ugly?) solution here that worked... when a TLS error is generated, it adds the FQDN to notlshosts.

In qmail-remote.c, in the function void tls_quit(const char *s1, const char *s2),

I changed from:

void tls_quit(const char *s1, const char *s2)
{
  out((char *)s1); if (s2) { out(": "); out((char *)s2); } TLS_QUIT;
}

to:

void tls_quit(const char *s1, const char *s2)
{
  FILE *fp; // ACF
  char acfcommand[1200]; // ACF
  sprintf(acfcommand, "/bin/touch /var/qmail/control/notlshosts/'%s'", partner_fqdn);
  fp = popen(acfcommand, "r");
  if (fp == NULL) {
    printf("Failed to run command\n" );
    exit(1);
  }
  pclose(fp);
  out((char *)s1); if (s2) { out(": "); out((char *)s2); } TLS_QUIT;
}

Note that /var/qmail/control/notlshosts needs to have ownership qmailr:qmail so that it can write to it!

I’m currently using this on a test server to see if I don’t accidentally cause another issue... before moving it to production.

Just to advise anyone still using the above code that it introduces a vulnerability. Fixed here https://github.com/sagredo-dev/qmail/pull/42 

Great! Let us know if it works

Greetings,

Short question: can I compile netqmail with your unified patch, and then just ignore the vpopmail piece?

Long question: I have a very old qmail installation that I've been carrying along from CentOS to CentOS version. It's currently on CentOS 7 and built from Bruce Guenter's old RPMs, but it's time to modernize and I'm looking at building from scratch+patch. However, we do not use vpopmail (and will not be using it), but rather use a different virtual mail manager.

Is it possible to use this unified patch, but effectively ignore vpopmail after install? I'm perfectly capable of changing permissions, ownership, run scripts, and the like, but without having built this before, it's unclear whether vpopmail is so heavily integrated into this package as to render the package unusable if vpopmail is unused.

Thanks in advance!
Peter

you can use without it but it won't compile.  So install vpopmail and then forget about. Also disable chkuser.

Or you can try to remove chkuser and the call to vpopmail from the Makefile. It's not difficult to do.

you have here a patch to remove chkuser and vpopmail from the sources https://github.com/sagredo-dev/qmail/blob/main/other-patches/qmail-remove_chkuser_vpopmail.patch

If you prefer to do it manually, be aware that the "control/cache" dir and the control/*.pem files have to be owned by the user who runs qmail-smtpd, so you should adjust the update_tmprsadh.sh file

Hi Roberto

When I try to download https://github.com/sagredo-dev/qmail/archive/refs/tags/v2024.06.08.tar.gz, the file is indicated like not found (404) 

Could you verify ?

Thanks

Hi, try again now

It's OK, thank you. 

Hello Roberto,

Thanks a lot for all your work. I would not be able to have my own server if wouldn´t be because of your patch.

I am running a qmail patched with netqmail-1.06 in my mail server. The server is 100% configured and operational.

I need to add DKIM support.

I downloaded your version from the github and compiled without any issue.

From your notes, I understand that the installation would simply consist on executing:

qmailctl stop

rm -r /var/qmail/queue

make setup

qmailctl start

My question is simple ... would this keep my old configuraiton and add qmail-dkim ?

If the answer is positive, i believe that I should just upgrade, wait to ensure compatibility and configure dkim after some days.

Am I correct ?

Thanks for your support !

i$

Hi, probably your current DKIM configuration won't work as it was revised recently. After the upgrade you should refer to the dkim documentation 

Hello Roberto,

Apologies, I was not clear enough.

Let me try again:

 - My current netqmail-1.06 does not have DKIM configured nor enabled

 - I noticed the new way to configure DKIM, this is why ...

  - ... I have compiled a new qmail GITHUB_based version without any problem.

If I install the upgraded qmail (github_based) using the following procedure:

qmailctl stop

rm -r /var/qmail/queue

make setup

qmailctl start

Will my old configuration remain and work ?

In case of a positive answer, I will upgrade first to then configure DKIM following the new procedure.

Many thanks !

Regards

Yes, your old configuration will work

Thanks a lot Roberto,

I has worked perfectly.

Thanks !

May I ask if your qmail package (included patches) can be installed in CentOS 5.3?

When I run "make setup check", it stops with a number of errors.

srs.c:3:37: error: /usr/local/include/srs2.h: No such file or directory
srs.c: In function ‘srsforward’:
srs.c:86: error: ‘srs_t’ undeclared (first use in this function)

........

srs.c:144: error: ‘SRS_SUCCESS’ undeclared (first use in this function)
make: *** [srs.o] Error 1

If I download netqmail-1.06.tar.gz and patch dkim-netqmail-1.06.patch-1.46 , it compile successfully. However, there is a lot of error if I add other patches. It cannot send email at all.

Please advise how I can install the qmail-dkim into our qmail installed in CentOS 5.3. Thanks a lot!

Hi, my qmail requires the libsrs2 library. Read the docs above.

Concerning the other problem, building a composite patch is a bit complicated and for me mantaining my one is enough. It would be impossible to teach how to do that in this reply, also because it is beyond the scope of this guide, sorry

Hi

I'm a little old :D, and I really don't like github :D
Ajajajajaja
I was from the very old school, ftp, download links, and everyone working on its own :D
Aajajaja

Hi Pablo :-), I'm old school too but there's no github knowledge required... just take the time to read the new instructions and you'll find the link :-)

Hi again ! :D

I can't find the old format (1 file patch), I only see the qmail source allready patched :D

What I'm missing ?

Pablo, there's no patch anymore. You have to download the patched sources, then unpack. It's explained at the top of this page. Just cut and paste the code. No need to use git

ok, thanks

As I was talking with some friends, programming now is for lazy people, now, nobody knows what are using, nobody know what is a patch, nobody ever read a source file !
Neither patches, now, I want the file alredy patched
Ajajajja

The way we did software is dead !
A guy who works with phyton told me that he use chat gtp to wrote code !

We are going to become extinct in a few years
ajajajajj

and nobody ever read the docs! :-)

Hi roberto puzzanghera 

I am not sure but I think qmail-liberal-lf patch  in our patch is affeted with CVE-2023-51765

Is that correct?

I released an update which denies bare LF by default. Now bare LF can be allowed by defining ALLOW_BARELF in tcprules or in the run file

I did the tests here and found out that my package is vulnerable to smuggling. Removing the liberal-lf solves.

I uploaded my changes here in a testing branch. I'll relase a new package in the following days if further tests without that patch are ok. If you want to try it you are welcome.

Thanks for the advice!

PS this is the reject logline of my server once I repaired it

2024-01-18 20:45:15.679975634 qlogenvelope: result=rejected code=451 reason=bad_newlines detail= helo=check.smtpsmuggling.com mailfrom=test@check.smtpsmuggling.com rcptto= relay=yes rcpthosts= size=268 authuser= authtype= encrypted= sslverified=no localip=10.0.0.4 localport=25 remoteip=10.0.0.4 remoteport=43466 remotehost=smtp.sagredo.eu qp=31931 pid=31923

Honestly I didn't have the time to dig into it, just read discussions in qmail lists

PS if anyone can play with these test tools concerning the alleged smuggling security issue it would be welcome https://github.com/The-Login/SMTP-Smuggling-Tools 

Hi,

When I enable chkuser with the 2024.01.15 version, I get a compilation error:

chkuser.c:953:45: warning: implicit declaration of function ‘vmaildir_readquota’ [-Wimplicit-function-declaration]
953 | if (vmaildir_readquota(tmp_path.s,format_maildirquota(user_passwd->pw_shell))
| ^~~~~~~~~~~~~~~~~~
make: *** [Makefile:333: chkuser.o] Error 1

However, with the 2024.01.05 version, I don't get this error...

Thanks.

weird... this part wasn't touched during latest upgrade. It's not recognizing your vpopmail installation directory.

can you do this from the qmail source directory?

/bin/sh vpopmail-dir.sh

it should output your vpopmail installation directory

Hi Gabriel, which Linux distribution and which gcc version?

Hi Roberto,

Thanks for trying to help me.

I tried to compile the 2024.01.05 version again with chkuser enabled, and the same error is now showing up. So I must correct what I said before. The error is showing up regardless of the version now. If I disable chkuser in chkuser_settings.h, the error doesn't show up.

Answering your questions:

Running /bin/sh vpopmail-dir.sh replies /home/vpopmail, which is the correct path.

Here we use Debian 12.4 and gcc (Debian 12.2.0-14) 12.2.0.

Thank you in advance.

Gabriel.

got it! The actual error was before the line you reported

chkuser.c:124:2: error: #error "chkuser setting error: CHKUSER_ALWAYS_ON and CHKUSER_STARTING_VARIABLE are mutually esclusive. Edit your chkuser_settings.h and disable one of them" 
 124 | #error  "chkuser setting error: CHKUSER_ALWAYS_ON and CHKUSER_STARTING_VARIABLE are mutually esclusive. Edit your chkuser_settings.h and disable one of them" 
     |  ^~~~~

so you have enabled chkuser by removing the comment on the variable CHKUSER_ALWAYS_ON, which is commented by default. In this case, as reported in the error message, you have to comment CHKUSER_STARTING_VARIABLE.

Be aware that enabling chkuser in this way prevents the possibility of disabling it in the run file.

Hi Gabriel, it compiles with no errors here on Debian 12... 

can you verify that the file /home/vpopmail/etc/lib_deps exists and that the libriaries listed in that file are linked?

ldd /home/vpopmail/bin/vadddomain

Hi Roberto,

Actually the whole thing was my mistake. I followed your guide, at Configuring chkuser, you say to uncomment the #define lines, and I edited the chkuser_settings.sh and removed the starting # from those lines thinking that # meant "comment". I am not well versed in the C language. Only after you last message I understood that commenting is done with /* and */ and I shouldn't have touched the #define lines, because they were already uncommented in the chkuser_settings.sh inside the .tar.gz file you provide, I belive the whole "Configuring chkuser" section listing each #define line is completely unecessary and should be removed, so other people don't do the same mistake as I did.

Or at least the wording should be changed to say that the reader must COMMENT those lines if he wants to disable each one of the features -- since they are already enabled. If you read carfuly, you say that those lines must be "uncommented", but they are already uncommented...

Cheers,

Gabriel.

Ok...  I'll try to improve that section. Unfortunately I don't think I have chances to do the same with my english :-)

Hi, the qmail-tls patch has been updated by its author to support OpenSSL v3. (Until now, OpenSSL 1.1 support was required, which some linuxes have been dropping i.e. debian!)

New patch is: http://inoa.net/qmail-tls/notqmail-1.08-tls-20231230.patch

I am going to try to manually figure out how to apply this to my build (at the moment based on roberto 2020.12.04) , but meanwhile I wanted to let you know so you could update the new distribution. Some day soon I would like to update mine to a use a more recent sagredo distribution :)

I merged your changes to my tree on github. In my Slackware I still have the old openssl-1.1 version. Did you test everything on Debian/openssl-3?

Yes I am running "my" version as of yesterday night and it is alive and fine.  ldd command on qmail-remote and qmail-smtpd indicate they are linked with libssl 3 :)

Thanks for the advice. I'll upgrade my patch 

wget https://github.com/sagredo-dev/qmail/archive/refs/tags/v${QMAIL_VERSION}.tar.gz
--2024-01-04 11:53:59-- https://github.com/sagredo-dev/qmail/archive/refs/tags/v2024.01.04.tar.gz
Resolving github.com (github.com)... 140.82.112.4
Connecting to github.com (github.com)|140.82.112.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/sagredo-dev/qmail/tar.gz/refs/tags/v2024.01.04 [following]
--2024-01-04 11:54:00-- https://codeload.github.com/sagredo-dev/qmail/tar.gz/refs/tags/v2024.01.04
Resolving codeload.github.com (codeload.github.com)... 140.82.114.9
Connecting to codeload.github.com (codeload.github.com)|140.82.114.9|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2024-01-04 11:54:00 ERROR 404: Not Found.

2023.01.04 was removed. Use 2023.01.05

Hi, 

Im looking if its possible to have some control file for qmail or mechanism for dropping auth attemp for certain emails ?

like: qmail-smtpd[2706450]: auth: auth-failed type=login user=<mailer-daemon@com.com> 

qmail-smtpd: read failed (connection closed by the client before the quit cmd): (null) from 195.190.115.42 to (null) helo mxv.trucksparts.ru

its piling up and fail2ban dont really help, as each auth is from different IPs once.

im looking if there is way to have /control/blockauth kind of file , where i put for example mailer-daemon@com.com and qmail-smtp or sslserver will just close conenction imediately 

similar way as badrcptto is working.

thank you

There's no options like this, but you can use control/authsenders to redirect the Auth of certain users to a different (unexistent) port. Look at the man for more info

Hi,

thnx for hint, but authsender are for ourtgoing smtp . im looking for incoming auth conenction / where bots are trying to login with some crendentials of non existen accounts

i want qmail to drop connection once a certain login name is used /dotn wait for auth, drop it/

seems no way round this

anyway, thnx

miki

Hi, Please add "senderip" patch so that specific domain can use specific IP for outgoing mail. JMS has this patch at: https://qmail.jms1.net/patches/combined-details.shtml#:~:text=domain:1.2.3.4

Hi, I cannot find the patch source at the link you provided

hi,

Thanks for your reply. I also searched in the web, but did not find any patch. As I'm not a programmer, so it's really difficult for me to identify what's inside the code. But original qmail-1.03 holds following codes in timeoutconn.c file. Hope this can enlighten expert like you:

timeoutconn.c: struct constmap senderip ;
timeoutconn.c: switch ( control_readfile ( &stext , "control/senderip" , 0 ) )
timeoutconn.c: if ( ! constmap_init ( &senderip , stext.s , stext.len , 1 ) )
timeoutconn.c: chosenip = constmap ( &senderip , domain.s , domain.len ) ;

below are the difference after applying the patch:

timeoutconn.c: struct constmap senderip ;
timeoutconn.c: switch ( control_readfile ( &stext , "control/senderip" , 0 ) )
timeoutconn.c: if ( ! constmap_init ( &senderip , stext.s , stext.len , 1 ) )
timeoutconn.c: chosenip = constmap ( &senderip , domain.s , domain.len ) ;
timeoutconn.c.orig: struct constmap senderip ;
timeoutconn.c.orig: switch ( control_readfile ( &stext , "control/senderip" , 0 ) )
timeoutconn.c.orig: if ( ! constmap_init ( &senderip , stext.s , stext.len , 1 ) )
timeoutconn.c.orig: chosenip = constmap ( &senderip , domain.s , domain.len ) ;
Binary file timeoutconn.o matches

Hope this can give you some clue.

thanks.

Hi, it's not an easy task. Please understand that I'm not in the position to fullfill personal requests for free...

OK, I'll try to figure it out. If I succeed, I'll post here so that everybody can get benefited.

thanks.

Hi,

I've found that patch. Below is the patch. Requesting you to add it in your combined patch.

Patch link: https://qmail.jms1.net/patches/newbind.patch 

BR

You can always add the patch yourself.  

However, it won't link unless you add an extern prior to the reference in tcp-env.c. 

I have not fully tested it yet, but will.  I am not sure what will happen if you use the outgoingip and senderip file at the same time.

Hi, I think I already replied to your request above

Hi,

I'm trying to compile qmail in Debian 12 that come with OpenSSL 3.0.9 and I'm getting some errors. Is there any way to compile with OpenSSL 3.0.9?

Thanks

Joao

Hi, libdomainkeys is no longer a prerequisite of my patch. Qmail compiles with no errors here.

Hello, Roberto, thank you for replying.

I'm using your patch but my vpopmail authentication is cdb. Do I need libdomainkeys?

Thanks
Joao

No. It was a prerequisite of the dkim program inside qmail, to sign messages with the old domainkeys signature. Now that part has been dropped, so we can forget about libdomainkeys

Hello Roberto

Sometimes the email recipients make a redirection to their Gmail box. Then the DKIM and SPF systems no longer work and emails are considered to be spam.

I read that it was possible to add an ARC signature (Authenticated Received Chain).

Do you know and what do you think of this system. Would this system suit the problem of redirects? Do you know if a patch exists to add this signature?

Thanks

Hi, is the forward performed by qmail or via sieve rules? In the first case SRS can be the solution, as you know.

I haven't played with ARC yet. But I think that in case of a sieve rule qmail can't do much, because the decision of forwarding the message is up to the LDA and it should be the LDA (dovecot) to change the header and add the ARC certification... in this case I would look for a dovecot plugin.

On the qmail side, did you have a look at https://github.com/mbirth/mail-arc?

Let me know if you find something interesting

PS an idea can be to modify that python and prepend it in the .qmail so that it can do the ARC stuff before passing the message to dovecot

Roberto, redirection is not done from my server. My problem is when I send an external email to abc@domain.com and that abc@domain.com makes a redirection to a Gmail account. The email goes to spam at Gmail because the SPF and DMARC are no longer good.
I find so little information on arc certification that I do not know if this certification must be added before I send the email by my Qmail server or if it is the external server when it makes the transfer. .. I continue to seek;)

So it's not your server responsibility to certify with ARC those forwards for you. That remote server can use ARC or better SRS. Your server is already providing its credentials when it uses SPF and/or DKIM correctly

Well, I have a job less ;) Thanks

You will have when you forward via sieve :-)

For the moment, I have not installed Dovecot/Sieve as it is not tempted to look at how it works ...

Heia,

Thanks for all the continued effort on the qmail patch!

Tried to update to the latest today, but it broke on not finding vpopmail.h

(note that I'm building from a clean alpine docker by adding prerequisites first, this has always worked so far)

Some digging later I noticed your new script to detect the include dir, with empty output:

bash -x ./vpopmail-dir.sh
+ PASSWD=/etc/passwd
+ '[' '!' -f /etc/passwd ']'
++ head -9 conf-users
++ tail -1
+ VUSR=vpopmail
+ SED=
+ for f in /usr/bin/sed /bin/sed /usr/sbin/sed /sbin/sed /usr/local/bin/sed /usr/local/sbin/sed
+ test -x /usr/bin/sed
+ for f in /usr/bin/sed /bin/sed /usr/sbin/sed /sbin/sed /usr/local/bin/sed /usr/local/sbin/sed
+ test -x /bin/sed
+ SED=/bin/sed
+ break
+ '[' /bin/sed = '' ']'
++ /bin/sed -n '/#/! s/^vpopmail:.*:.*:.*::\(.*\):.*/\1/p' /etc/passwd
+ echo

Compare this against the added user in /etc/passwd:

grep vpopmail /etc/passwd
vpopmail:x:89:89:Linux User,,,:/home/vpopmail:/sbin/nologin

Maybe use getent instead? E.g.

getent passwd vpopmail | cut -d: -f6
/home/vpopmail

I uploaded a new combined patch with your suggestion based on getent

Hi,

getent would be ok, but I would like to understand what's wrong in my approach based on sed. Do you have any idea?

I downloaded a very minimal alpine LXC image and it works as is in finding the vpopmail dir, even before I install anything.

PS /etc/passwd in the alpine installation already had the vpopmail user :-) are you the maintainer of that LXC image?

The vpopmail-dir.sh should look for 'sed' in '/bin' as well - which is how it is on Ubuntu 20 LTS at least. 

Thanks for letting me know. That's easy to correct. I'll do it as soon as possible

np! Took me a bit to figure out a weird error I was getting until I realized it couldn't find sed 😂

Hi roberto puzzanghera 

Today I faced this error below in smtpd log.

Do you know anything about this error? .This is qmail error or my resolve DNS .

2023-06-28 01:06:57.006281500 DNS query timeout for ***.com
2023-06-28 09:26:16.487948500 DNS query timeout for ***.com
2023-06-28 10:37:49.557948500 DNS query timeout for ***.jp

I can't say much more than what it already says... did you try to query that DNS from the command line?

 Hi roberto puzzanghera 

Thank you for your advice. 

I checked all DNS resolver server. Everything is good.

Receiving and sending email is not affected by this log message. I think it is not qmail 's problem.

Hi

I may have missed a trick, but is there a possibility for the date to be readable directly in the qmail log files ?
For the moment I am forced each time to use tai64nlocal

Thanks

Hi, I've just added a patch for daemontools which provides a readable datetime format like this

2023-06-28 16:17:26.501272173 tcpserver: status: 0/200/0

This will be compatible with the convert-multilog and qlog archive programs, while the patch that I suggested below will break them.

Look at the daemontools page for details

You have to patch daemontools with this patch. But in this case the archive_qmail_qlog functionality will not work, so you have to choose which one you want.

Edit: also the JMS multilog backup will not work with this

It works. Great.

Thanks

Hi brother, first of all, thanks for your excellent work here with this huge patch. I used to have one myself long time ago, but gave up with no time for maintaining. Your patch is outstanding. I have a small suggestion if you allow me to:

the reject code 451 is listed in several distinct errors on qmail-smtpd.c

the error:

@40000000648b1bd90cba9d14 qlogreceived: result=rejected code=451 reason=queuedelay detail=qq_internal_bug_(#4.3.0) helo=ams1b-admin-mta-01.mta.blizzard.com mailfrom=noreply@battle.net rcptto=RODRIGO@DELPHUS.ORG relay=no rcpthosts= size=59959 authuser= authtype= encrypted=tls sslverified=no localip=177.67.83.195 localport=25 remoteip=185.60.113.118 remoteport=50444 remotehost=ams1b-admin-mta-07.mta.blizzard.com qp=15137 pid=15132

the code:

void die_alarm() { qlogenvelope("rejected","alarmtimeout","","451"); logit("timeout"); out("451 timeout (#4.4.2)\r\n"); flush(); _exit(1); }
void straynewline() { qlogenvelope("rejected","badnewlines","","451"); logit("bad newlines"); out("451 See http://pobox.com/~djb/docs/smtplf.html.\r\n"); flush(); _exit(1); }
void err_qqt() { qlogenvelope("rejected","qqtfailure","","451"); out("451 qqt failure (#4.3.0)\r\n"); }

and there is another one in RBL, SPF  and CHKUSER code as well. Is that related to temp problems ? my qq problem is quite persistent

I am sure I am getting the last one, the qqfailure, but I don't know why. message goes  to the last qqx loop at qmail-smtpd.c

[pid 16171] read(0, "\27\3\3\26\261", 5) = 5
[pid 16171] read(0, " /\10\203z\340~\217\361b\331\21J\365B\247`\227X\270\324\261+\267\244 \215\322\232\340\35\305"..., 5809) = 5809
[pid 16171] read(0, "\27\3\3\26\261", 5) = 5
[pid 16171] read(0, "6\3\3708Y\f\302\345\221\352\233\227Pd\233\254\350\300hq\345\267d\357\216a\36\274}\370\306\26"..., 5809) = 5809
[pid 16171] read(0, "\27\3\3\26\261", 5) = 5
[pid 16171] read(0, "%RN\327\312\rJ\10\355#,\317\234e xHF\30646q\26\350\3117\377Vk2\346\333"..., 5809) = 5809
[pid 16171] read(0, "\27\3\3\26\261", 5) = 5
[pid 16171] read(0, "\221{\327S\265\213\232\304b\376\317qe\251o\10\340m\0256Q\223\350\4\0260k\277\215r\7Q"..., 5809) = 4207
[pid 16171] read(0, 0x55e5f9d4d6b7, 1602) = -1 EAGAIN (Resource temporarily unavailable)
[pid 16171] select(1, [0], NULL, NULL, {tv_sec=1200, tv_usec=0}) = 1 (in [0], left {tv_sec=1199, tv_usec=790431})
[pid 16171] read(0, "\253ez\4\332|\351\245/\25147\7so\27!\343\356\271F\341{\212{\3\377]\220\354\7\377"..., 1602) = 1602
[pid 16171] read(0, "\27\3\3\26\261", 5) = 5
[pid 16171] read(0, "d\351\245\335\236\221\365pQ\223CO\334\t4\2637\vnN\275d\7\307\277\230|\207\r\365\0F"..., 5809) = 5809
[pid 16171] read(0, "\27\3\3\26\261", 5) = 5
[pid 16171] read(0, "7\321qC\221\22\f\320\317^s\235\313\364\346G\237\312Q\233R4\24\6\17\33E\377\343yc,"..., 5809) = 5809
[pid 16171] read(0, "\27\3\3\26\261", 5) = 5
[pid 16171] read(0, "\232H\301D\372\2=\2358\22/\265!\312\21t\366\370\0\367)\272\311Qot\"[\344\345\7\4"..., 5809) = 5809
[pid 16171] read(0, "\27\3\3\16E", 5) = 5
[pid 16171] read(0, "2D\10\210\16H\364~t\237\263\t\204]\16s\212\217\211\332v\261/z2QQ%/\201\2277"..., 3653) = 3653
[pid 16171] close(4) = 0
[pid 16171] close(6) = 0
[pid 16171] read(7, "", 1024) = 0
[pid 16171] close(7) = 0
[pid 16171] wait4(16172, [{WIFEXITED(s) && WEXITSTATUS(s) == 81}], 0, NULL) = 16172
[pid 16171] select(3, NULL, [2], NULL, {tv_sec=1200, tv_usec=0}) = 1 (out [2], left {tv_sec=1199, tv_usec=999996})
[pid 16171] write(2, "qlogreceived: result=rejected co"..., 406) = 406
[pid 16171] select(3, NULL, [2], NULL, {tv_sec=1200, tv_usec=0}) = 1 (out [2], left {tv_sec=1199, tv_usec=999998})
[pid 16171] write(2, "\n", 1) = 1
[pid 16171] select(3, NULL, [2], NULL, {tv_sec=1200, tv_usec=0}) = 1 (out [2], left {tv_sec=1199, tv_usec=999998})
[pid 16171] write(2, "qmail-smtpd: message delayed (qq"..., 160) = 160
[pid 16171] write(1, "\27\3\3\0/\7C\320\30])%U\21\264\231\301\211\256*\\w\254[?%y\334HB!\10"..., 52) = 52
[pid 16171] write(1, "\27\3\3\0'\237\324\5\332\217C\0M5\37$\1.\311\267\362\250{\353\32\232[\362\266\244+\37"..., 44) = 44
[pid 16171] write(1, "\27\3\3\0\23f\213P?*\223\337\360.$p\346\252\374^\351)\337\f", 24) = 24
[pid 16171] exit_group(0) = ?
[pid 16171] +++ exited with 0 +++

I have even tried to "fix" qmail-queue with that perl recomended here, I have removed queue and installed a new one from qmail check setup, none makes any difference.

I'm quite  lost atm, but I am sure I have more than one host with such problems.

any comments appreciated

thanks, Rodrigo

are you using my latest patch?

have also a look at this thread https://notes.sagredo.eu/en/qmail-notes-185/testing-qmail-smtp-and-auth-22.html#comment2960  

Fantastic.

Well I am not sure what's wrong with qmail-dkim, but since it's not my submission, I've switched from qmail-dkim to qmail-queue and it worked like a charm. I see in the strace that somehow dkim is not quite able to lookup hosts, tho my /etc/resolv.conf points to 127.0.0.1 which is dnscache and it works like a charm. I will investigate it further, as qmail-dkim works perfectly when called from my submission, well it signs just fine.

Thanks Brother.

Rodrigo

Sure that you are not affected by the same bug, which was cured on March 18? According to the code lines that you posted above you are not using the latest patch...

Oh I see. It is possible indeed. I have patched with latest today. I will try dkim once again and let you know about it. 
thanks 

Hi brother, 

can you show the entire qmail-smtpd log line? It is not shown completely in your strace...

Edit: I see now your qlog error line, sorry for asking

Hello 

Please modify the 

gunzip -c ../roberto-netqmail-1.06.patch-latest.gz | patch

with 

gunzip -c ../roberto-netqmail-1.06.patch-2023.03.01.gz |patch 

Or save wget with latest . 

Corrected. Thank you

Hi roberto puzzanghera 

After applied the latest patch. I could not send email account with domain s--and--s.net

The error is "553 5.1.3 sorry, mailbox syntax not allowed ". I think 「--」 is not accepted. 

Before updated the latest patch. I used 2022.05.22 patch.

$ telnet 172.24.4.23 25
Trying 172.24.4.23...
Connected to 172.24.4.23.
Escape character is '^]'.
220 mail.local Welcome to SMTP server ESMTP
AUTH LOGIN
334 VXNlcm5hbWU6
xxxxx
334 UGFzc3dvcmQ6
xxxxx
235 ok, go ahead (#2.0.0)
mail from:test@mail.local
250 ok
rcpt to:test@s--and--s.net
553 5.1.3 sorry, mailbox syntax not allowed 
quit
221 mail.local Welcome to SMTP server
Connection closed by foreign host.

I cannot reproduce the issue. And I remember that we cured it here...

can you double check that you are actually applying the latest patch?

hi roberto puzzanghera 

Yes, I tried to compile again with the lastest patch. but the same is displayed.

In chkuser_settings.h , i uncommented 383 line and recomplied again everything is going well

#define CHKUSER_DISABLE_VARIABLE "RELAYCLIENT"

Do you have CHKUSER_SENDER_NOCHECK_VARIABLE defined as RELAYCLIENT?

Yes ,I have #define CHKUSER_SENDER_NOCHECK_VARIABLE "RELAYCLIENT" in chkuser_settings.h too.

Weird... This option would be sufficient to let RELAYCLIENT send even garbage in the domain syntax. 

My tests work as expected. And if I disable RELAYCLIENT from tcprules mails with the double hyphen are sent anyway

Thank you roberto puzzanghera

Now I can not figure out the problem. So I will run qmail with this setting. 

#define CHKUSER_DISABLE_VARIABLE "RELAYCLIENT"

Hi Jacky

Unfortunately you are playing with the wrong knobs. Please undo what you did.

The patch Roberto mentioned previously corrected "check_sender_address_format()" function.

But you are bitten by "check_rcpt_address_format()" function.

Please search this function after patching, and comment out the lines below as follows:

/*
 } else {
if (strstr (domain->s, "--") != NULL)
return 0;
*/

Thanks Ali. Patch updated

Hi roberto puzzanghera and Ali Erturk TURKER 

Thank you very much!

I applied the latest patch. Everything is going well.

Appreciated

Hi Roberto,

As you will see here the qmail-auth patch sets the protocol string as "ESMTPA", even though the user is authenticated via starttls/smtps. We need a patch like this to correct the headers generated by qmail-smtpd (which should cleanly apply on your combined patch). After the patch, the mail headers will change from "ESMTPA" to "ESMTPSA" and the

ssl_cipher used will be provided as follows:

Before patch:

Received: from unknown (HELO ?172.16.10.2?) (turkerali@xxxxxx.xxx@172.16.10.2)
    by xxx.xxxxxx.com with ESMTPA; 10 Mar 2023 20:33:57 -0000

After patch:

Received: from unknown (HELO ?172.16.10.2?) (turkerali@xxxxxx.xxx@172.16.10.2)
    by xxx.xxxxxx.com with ESMTPSA (TLS_AES_128_GCM_SHA256 encrypted, authenticated); 12 Mar 2023 12:32:03 -0000

Feel free to test and share on your website.

Regards,

AET

Thank you, Ali. Added

Hi Roberto,

Bruce Guenter (a qmail guru) has written a patch which offers the exact same functionality of your qmail-remote CRLF patch, while providing 10x less CPU usage for qmail-remote. He accomplishes this by reading the message in 4K chunks (instead of byte-by-byte) while substituting the control characters, and pushing the mail to the remote mail server.

That makes perfect sense, as almost all major filesystems in use today (ext4, btrfs, xfs) default to 4K blocksize.

I modified his patch so that it applies cleanly on your combined patch. Feel free to download from this link, test and share on your website.

Hi Ali, thanks for the advise. Patch added

Roberto and Ali, 

the old patch from Bruce is actually not doing the same as the CRLF patch. It addresses a different concern (performance), but does not fix the CRLF issue. Not sure the performance problem is still valid on modern systems (the OS should really do the buffering/caching internally), but if you want to keep Bruce's performance mod, a patch to incorporate the CRLF fix into it is attached (that I hacked together, i.e. no guarantees). I can't get the attachment to paste correctly, but the diff is also here (ignore the qmail-smtpd.c patch that is part of it):

https://github.com/agerstla/qmail/commit/c215bb0c03568dc69dd4d438ba99b9380f907762.diff

Andreas

diff --git a/qmail-remote.c b/qmail-remote.c
index 3d52b69..3531636 100644
--- a/qmail-remote.c
+++ b/qmail-remote.c
@@ -344,10 +344,11 @@ void blast()
char in[4096];
char out[4096*2+1];
int sol;
+ int cr;

substdio_put(&smtpto,firstpart.s,firstpart.len);

- for (sol = 1;;) {
+ for (sol = 1, cr = 0;;) {
r = substdio_get(&ssin,in,sizeof in);
if (r == 0) break;
if (r == -1) temp_read();
@@ -360,18 +361,32 @@ void blast()
while (i < r) {
if (in[i] == '\n') {
sol = 1;
+ cr = 0;
++i;
out[o++] = '\r';
out[o++] = '\n';
break;
}
+ if (cr) {
+ sol = 1;
+ cr = 0;
+ out[o++] = '\r';
+ out[o++] = '\n';
+ break;
+ }
+ if (in[i] == '\r') {
+ ++i;
+ cr = 1;
+ continue;
+ }
out[o++] = in[i++];
}
}
substdio_put(&smtpto,out,o);
}
- 
- if (!sol) perm_partialline();
+
+ if (cr) substdio_put(&smtpto,"\r\n",2);
+ else if (!sol) perm_partialline();
flagcritical = 1;
substdio_put(&smtpto,".\r\n",3);
substdio_flush(&smtpto);

Thanks for the contribution, I'll check it out

Hi Roberto,

Thank you for putting together the combined patch that adds so many useful feature to netqmail-1.06.

Will the combine patch work without vpopmail? I would like to use it on servers where I do not have mysql and vpopmail installed.

No, it has vpopmail as a prerequisite 

Hi Robert

As you will see here, if the remote port is given as "465" in control/smtproutes file, qmail-remote automatically switches to implicit TLS ("SMTP over TLS" or "smtps"). I believe qmail-rfc2821 patch appeared before the qmail-tls support, therefore it does not cover implicit TLS (SMTPS) connections. Since I am a fan of implicit TLS connections myself, (due to STARTTLS MitM attacks), I created this patch. Feel free to test and share on your website.

Do you think that it shoukd be like this?

# ifdef TLS 
- if (tls_init())
+ if (tls_init()) { 
   if (smtps) { 
       code = smtpcode(); 
       if (code >= 500 && code < 600) quit("DTLS Connected to "," but greeting failed"); 
       if (code >= 400 && code < 500) return; /* try next MX, see RFC-2821 */ 
       if (code != 220) quit("ZTLS Connected to "," but greeting failed"); 
   } 
 /* 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

Hi Roberto,

I also removed 2 lines from tls_init() to move the connection checks to smtp() function,

to make the code consistent with the previous qmail-rfc2821 patch. Please check my patch again.

It should apply cleanly on your combined patch.

AET

Yes, I see those other two lines removed.

But I don't understand why in your patched file this line

code = ehlo();

is no longer inside the if (tls_init())

Hi Roberto,

Probably there is a misunderstanding. My patch does not replace the qmail-rfc2821 patch.

My patch should be applied on top of your latest combined patch (netqmail-1.06 v. 2023.02.24).

After patching, qmail-remote.c should look like this. Please check and let me know if you have any questions.

Regards

AET

Exactly. What I don't understand is why that last

code = ehlo();

before your patch is inside the if (tls_init()) block

  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();

while after your patch it is outside the same block

if (tls_init())
if (smtps) {
code = smtpcode();
if (code >= 500 && code < 600) quit("DTLS Connected to "," but greeting failed");
if (code >= 400 && code < 500) return; /* try next MX, see RFC-2821 */
if (code != 220) quit("ZTLS Connected to "," but greeting failed");
}
/* 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();

Hi Roberto

You are %1000000000000 right.

First I created the patch on my win10 machine and it's exactly how you suggested.

Then I manually created it again on my linux vm to rebase it on your combined patch, and screwed up.

I revised the patch , should be OK now.

Impossible not to have at least a bug when you develop on Windows :-)

Patch updated

Hi Roberto

At some point in time, Luca Franceschini had renamed control/badmailto and control/badmailtonorelay files to control/badrcptto and control/badrcpttonorelay files in:

qmail-smtpd.8
qmail-smtpd.c

Unfortunately this patch overlooked these files, which still contain the old naming scheme.

README.qregex
qmail-control.9
qmail-smtpd.8
qmail-showctl.c

The above files should also be updated accordingly.

Regards,

Ali Erturk TURKER

corrected. Thank you

Hi roberto puzzanghera 

Today, I got many error in SMTP log. 

Can you tell me the meaning of「reason=alarmtimeout 」 . And how can I tunning any qmail 's parameter to fix it ?

2022-11-14 19:40:42.017547500 mail1 qlogenvelope: result=rejected code=451 reason=alarmtimeout detail= helo=xxx mailfrom=xxx@163.com rcptto= relay=no rcpthosts= size=148766 authuser= authtype= encrypted= sslverified=no localip=xxxx localport=25 remoteip=xxxxx remoteport=16847 remotehost=m12-15.163.com qp=3063 pid=2630

Hi Jacky,

it is an error belonging to the timeoutread function of qmail-smtpd, which doesn't have any comment inside. It is triggered when the client does not provide some of the mandatory commands in time, such as helo, mailfrom, rcptto etc. When I have this error I can always see a missing helo, or a missing mailfrom or rcptto just like when the client didn't provide them in time. You can see that rcptto is empty also in your example.

I don't think that this is your server's renponsibility. Anyway you can try to increase the "timeoutsmtpd" time in your control/timeoutsmtpd if you have set it to a very short time interval. It defaults to 1200s (20 minutes), which is a very long time.

You can reproduce that logline by connecting to your server, not providing the helo or mailfrom or rcptto commands and letting the remote server close the connection after the timeout (of course it's better to shorten it modifying your control/timeoutsmtpd file).

I  increased timoutsmtpd to 600 second. Until now I did not get any alarmtimeout log anymore. 

Thank you roberto puzzanghera

Hi roberto puzzanghera 

I am trying to write a qmail-spp plugin to deny the message that over size limit of our partner mail server.

So can I get size of message via environment variable like TCPREMOTEHOST ?

Hi,

I'm not sure that the environment variables visible for qmail-smtpd will be directly visible inside a qmail-spp program. You can see which variables you have in the readme file at point 5 https://notes.sagredo.eu/files/qmail/patches/qmail-spp/README. I don't recall if/where the size of the incoming message is stored, but you can easily print those variables to find out where it is.

Hi roberto puzzanghera 

I will try to set enviroment MAILSIZE in qmail-smtpd.c

I have one more question. Is there limit maximum of allowed recipients(To,Cc or Bcc). I try to send 1000 recipients

but it does not work well

I dont set CHKUSER_RCPTLIMIT variable. 

yes, look at the concurrencylocal and concurrencyremote config files (http://www.lifewithqmail.org/lwq.html#configuration)

edit: be sure not to have set limits here for that particular account https://notes.sagredo.eu/en/qmail-notes-185/limiting-the-number-of-emails-sent-by-a-given-auth-userdomainip-231.html

 Hi Roberto and all,

Recently one of my domains keep getting 550_5.5.3_sorry,_reached_maximum_number_of_recipients_allowed_in_one_session_(chkuser) when someone sent more than 20 recipients to them. How and where do i increase this limit?

Thank you

Hi, just edit control/concurrencyincoming and restart qmail

Hi Roberto,

I see a lot of messages like this from time to time in the smptd log. I don't know if this is something we should worry about or it is normal and safe to ignore.

Thank you in advance!

 qmail-smtpd: read failed (hang up before quit cmd)

I recorded a qmail-smtpd session just to be sure what that messages means:

2022-05-22 20:13:44.267014500 tcpserver: pid 27286 from 199.249.230.87 
2022-05-22 20:13:44.357670500 tcpserver: ok 27286 smtp.sagredo.eu:10.0.0.4:25 tor38.quintex.com:199.249.230.87::37602 
2022-05-22 20:14:04.363400500 27286 > 220 smtp.sagredo.eu ESMTP^M 
2022-05-22 20:14:06.787104500 27286 < [EOF] 
2022-05-22 20:14:06.787172500 qmail-smtpd: read failed (hang up before quit cmd): (null) from 199.249.230.87 to (null) helo > 
2022-05-22 20:14:06.787488500 27286 > [EOF] 
2022-05-22 20:14:06.787591500 tcpserver: end 27286 status 256

It is an issue due to the fact that the client closed the connection unexpectedly without sending the quit command. Tecnically it is something that should not happen, so the read error.

PS often this happens after the client received a reject message from our qmail. I've just modified the error messages in the patch of may 22 from "hang up before quit cmd" to "client closed the connection before the quit command"

Hello,

After apply the patch roberto-netqmail-1.06.patch-2022.02.13, i got this error:

compilation terminated.
make: *** [: srs.o] Erro 1

Did you install libsrs2 first?

If yes please post the entire error string

Thanks, I installed libsrs2 and the process advanced a little further, changing the error message:

make: *** [Makefile:1674: qmail-remote.o] Erro 1

Can you provide the entire error string, please?

This is the complete output after I run the command 'make setup check'

Makefile:156: aviso: sobrescrevendo os comandos para o alvo 'base64.o'
Makefile:152: aviso: ignorando comandos antigos para o alvo 'base64.o' 
Makefile:239: aviso: sobrescrevendo os comandos para o alvo 'byte_cspn.o'
Makefile:235: aviso: ignorando comandos antigos para o alvo 'byte_cspn.o' 
Makefile:255: aviso: sobrescrevendo os comandos para o alvo 'byte_rcspn.o'
Makefile:251: aviso: ignorando comandos antigos para o alvo 'byte_rcspn.o' 
Makefile:1845: aviso: sobrescrevendo os comandos para o alvo 'qmail-todo'
Makefile:1831: aviso: ignorando comandos antigos para o alvo 'qmail-todo' 
Makefile:1853: aviso: sobrescrevendo os comandos para o alvo 'qmail-todo.o'
Makefile:1839: aviso: ignorando comandos antigos para o alvo 'qmail-todo.o' 
Makefile:2172: aviso: sobrescrevendo os comandos para o alvo 'spf.o'
Makefile:2154: aviso: ignorando comandos antigos para o alvo 'spf.o' 
Makefile:2177: aviso: sobrescrevendo os comandos para o alvo 'spfquery'
Makefile:2160: aviso: ignorando comandos antigos para o alvo 'spfquery' 
Makefile:2184: aviso: sobrescrevendo os comandos para o alvo 'spfquery.o'
Makefile:2167: aviso: ignorando comandos antigos para o alvo 'spfquery.o' 
Makefile:2222: aviso: sobrescrevendo os comandos para o alvo 'str_cpyb.o'
Makefile:2218: aviso: ignorando comandos antigos para o alvo 'str_cpyb.o' 
Makefile:2311: aviso: sobrescrevendo os comandos para o alvo 'strsalloc.o'
Makefile:2306: aviso: ignorando comandos antigos para o alvo 'strsalloc.o' 
./compile qmail-remote.c
qmail-remote.c: In function ‘dropped’:
qmail-remote.c:128:7: error: ‘ssl_err_str’ undeclared (first use in this function)
128 | if (ssl_err_str) { out((char *)ssl_err_str); out(" "); }
| ^~~~~~~~~~~
qmail-remote.c:128:7: note: each undeclared identifier is reported only once for each function it appears in
qmail-remote.c: In function ‘ssl_timeoutread’:
qmail-remote.c:158:10: warning: implicit declaration of function ‘ERR_error_string’ [-Wimplicit-function-declaration]
158 | out(ERR_error_string(ERR_get_error(), buf)); out("\n");
| ^~~~~~~~~~~~~~~~
qmail-remote.c:158:27: warning: implicit declaration of function ‘ERR_get_error’; did you mean ‘SSL_get_error’? [-Wimplicit-function-declaration]
158 | out(ERR_error_string(ERR_get_error(), buf)); out("\n");
| ^~~~~~~~~~~~~
| SSL_get_error
In file included from qmail-remote.c:7:
qmail-remote.c: At top level:
substdio.h:12:64: warning: initialization of ‘int (*)()’ from incompatible pointer type ‘ssize_t (*)(int, void *, size_t)’ {aka ‘long int (*)(int, void *, long unsigned int)’} [-Wincompatible-pointer-types]
12 | #define SUBSTDIO_FDBUF(op,fd,buf,len) { (buf), 0, (len), (fd), (op) }
| ^
qmail-remote.c:231:17: note: in expansion of macro ‘SUBSTDIO_FDBUF’
231 | substdio ssin = SUBSTDIO_FDBUF(read,0,inbuf,sizeof inbuf);
| ^~~~~~~~~~~~~~
substdio.h:12:64: note: (near initialization for ‘ssin.op’)
12 | #define SUBSTDIO_FDBUF(op,fd,buf,len) { (buf), 0, (len), (fd), (op) }
| ^
qmail-remote.c:231:17: note: in expansion of macro ‘SUBSTDIO_FDBUF’
231 | substdio ssin = SUBSTDIO_FDBUF(read,0,inbuf,sizeof inbuf);
| ^~~~~~~~~~~~~~
qmail-remote.c: In function ‘quit’:
qmail-remote.c:350:30: error: ‘smtps’ undeclared (first use in this function); did you mean ‘smtpto’?
350 | if (state & TLS_ST_OK || (!smtps && state & TLS_ST_BEFORE))
| ^~~~~
| smtpto
qmail-remote.c: In function ‘smtp’:
qmail-remote.c:585:13: warning: implicit declaration of function ‘strcasecmp’ [-Wimplicit-function-declaration]
585 | if (strcasecmp(fqdn,commonName)){
| ^~~~~~~~~~
qmail-remote.c:622:9: warning: implicit declaration of function ‘b64encode’ [-Wimplicit-function-declaration]
622 | if (b64encode(&auth_smtp_plain,&slop)) temp_nomem();
| ^~~~~~~~~
make: *** [Makefile:1674: qmail-remote.o] Erro 1

did you installed openssl? which version?

can you post which version of gcc and which os you have?

OpenSSL Version:

OpenSSL 1.1.1n  15 Mar 2022

In 'gcc -v' the result is this:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)

And my OS is Debian 11.3

ssl_err_str was defined around line 72 of qmail-remote.c, isn't it?

did you get any error during the patch process?

Hi roberto puzzanghera 

In this qmail patch can I apply reject null senders only for special port (465 or 587) with environment variable  ?

try this patch defining REJECTNULLSENDERS in your run file https://notes.sagredo.eu/files/qmail/patches/roberto-netqmail-1.06/roberto-netqmail-1.06.patch-2022.02.25.gz

let me know

Hi roberto puzzanghera 

Thank your patch.
After apply new patch I got this error below.

# telnet 127.0.0.1 587
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
421 unable to read controls (#4.3.0)
Connection closed by foreign host.

# openssl s_client -connect localhost:587 -starttls smtp
CONNECTED(00000003)
didn't found starttls in server response, try anyway...
write:errno=32
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 38 bytes and written 25 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1645801919
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

try downloading again now

Hi roberto puzzanghera 

Everything is fine. Thank you very much.

P/s: I think if add ipv6 support this patch is the best patch for qmail.

Yes, I think because this is the only maintained patch published on the internet!

Ipv6 would be great! Which patch are you testing?

I tested this patch roberto-netqmail-1.06.patch-2022.02.25.gz 

and implemented to one production server for workload test.

I'm not sure that ipv6 can work without patching the core of qmail...

Exactly,

I just applied tcpserver for ipv6 only . incomming email is fine(RBL is not working well) ,

but outgoing does not work.

I guess that the rblsmtpd program by eh embedded in ucspi-tcp6 will work

I think that also at least spf and moreipme have to patched.

If you want to help, can you test the Manvendra's ipv6 patch here https://sourceforge.net/projects/indimail/files/netqmail-addons/qmail-dkim-1.0/ against Saout's spf?

this patch with name dkim+spf+ipv6.patch-1.14.gz right?

If you need one machine with ipv6 let me know.

yes, this one. At a certain point Manvendra added ipv6 to the original dkim patch, but I've never found the time to add it to my patch.

I would install it on a vanilla qmail and test it as is. Then I would install the spf patch (https://notes.https://notes.sagredo.eu/files/qmail/patches/qmail-spf-rc5.patchsagredo.eu/files/qmail/patches/qmail-spf-rc5.patch) on top of it and test spf.

Thanks for the collaboration and for the possibility to use a machine of yours. This month I don't have free time because I have to migrate this server.

We can continue this discussion on ipv6 in private via mail if you like (contact button on the top of this page).

Hey Robert,

Long time reader, first time caller.  Recently came across the not-qmail project (GH/not-qmail/not-qmail), from some former qmail users who went over to postfix and came back.  Was wondering if you'd taken a look at their work, or if you think net-qmail is still the best base for qmail?

Hi Ryan, certainly a combined patch based on the qmail legacy like mine can't represent the future of qmail and one day we'll have to look at some of those qmail successors like not-qmail. I've never played with not-qmail but I have a big respect for such an ambitious project, and the fact that it comes from qmail gurus like Manvendra Bhangui and the others sounds like a garantee for me. But, as their wishlist says, most common features still have to be implemented, so let's give them their time.

Nowadays, if I'd have to use in production a qmail successor, I'd rather consider Manvendra's indimail (it has everything) and Erwin Hoffmann's s/qmail (very active and complete)

Hi roberto puzzanghera 

I tried to apply newest patch combined patch for netqmail-1.06 v. 2022.02.10

but got some error below. Can you check it for me. is it displayed only on my server?

./compile qmail-smtpd.c
In file included from tls.h:4:0,
from qmail-smtpd.c:36:
qmail-smtpd.c: In function ‘tls_init’:
qmail-smtpd.c:2351:28: error: ‘SSL_OP_NO_RENEGOTIATION’ undeclared (first use in this function)
SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION);
^
qmail-smtpd.c:2351:28: note: each undeclared identifier is reported only once for each function it appears in
make: *** [qmail-smtpd.o] Error 1

can you try with this one please? https://notes.sagredo.eu/files/qmail/patches/roberto-netqmail-1.06/roberto-netqmail-1.06.patch-2022.02.13.gz

Hi, which version of openssl do you have?

Hi,

I am using openssl version below. Is it old?

OpenSSL 1.0.2k-fips  26 Jan 2017

openssl is now at v. 1.1.

The patch that I linked above should solve your problem. Let me know.

Hi roberto puzzanghera

When i tried to apply the link you gave to me. I got some text below.

what should i do? Just enter to countinue?

# gunzip -c ../roberto-netqmail-1.06.patch-2022.02.13.gz |patch
The next patch would delete the file CHANNELS, which does not exist!  Assume -R? [n]

Sorry, the patch that I uploaded yesterday is corrupted. Please download it again and retry

Hi Roberto Puzzanghera 

Thank you very much .

I applied new patch successfully.

Until now everything is good.

Hi roberto puzzanghera 

Yesterday, I updated the latest this patch. After that i faced the problem with qmail-smtpd process.

It made my CPU to 100% . Did you have the same issue? Do you have any advice for me to check my server?

Send and receive e-mail is ok.

Tasks: 717 total,   2 running, 581 sleeping,   0 stopped,   0 zombie

%Cpu(s):  6.5 us,  0.2 sy,  0.0 ni, 93.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

KiB Mem : 65429236 total, 24054772 free,  2695836 used, 38678628 buff/cache

KiB Swap:  8388604 total,  8344368 free,    44236 used. 58790728 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                      

17142 vpopmail  20   0   43068   4764   4176 R 100.0  0.0   8:28.19 qmail-smtpd                                                                                                  

21070 root      20   0  164140   5152   3804 R   0.7  0.0   0:00.06 top 

Hi Jacky, no I don't have the same problem.

What do you have in the tcpserver: status line?

2022-01-23 16:16:37.153586500 tcpserver: status: 1/200

PS If I understand well, you are one of the most ancient commentators of this place :-) 

Hi roberto puzzanghera 

Thank you for your reply ! It is my qmail-smtpd in status line.

2022-01-24 01:17:40.458419500 tcpserver: ok 26702 mail1.xxx.com:172.24.xxx.xxx:25 service.axxx.xxx:209.141.xxx.xxx::45762
2022-01-24 01:17:41.066480500 tcpserver: end 26549 status 2562022-01-24 01:17:41.066481500 tcpserver: status: 15/600
2022-01-24 01:17:41.722767500 tcpserver: end 26593 status 256
2022-01-24 01:17:41.722767500 tcpserver: status: 14/600
2022-01-24 01:17:41.841063500 tcpserver: status: 15/600
2022-01-24 01:17:41.841284500 tcpserver: pid 26723 from 107.16xxx.xxx
2022-01-24 01:17:42.313190500 tcpserver: end 26588 status 256
2022-01-24 01:17:42.313191500 tcpserver: status: 14/600
2022-01-24 01:17:42.854308500 tcpserver: status: 15/600
2022-01-24 01:17:42.854440500 tcpserver: pid 26726 from 134.73.xxx.xxx
2022-01-24 01:17:42.854926500 tcpserver: ok 26726 mail1.xxx.com:172.24.xxx.xxx:25 :134.73.xxx.xxx::61096
2022-01-24 01:17:43.897306500 tcpserver: status: 16/600
2022-01-24 01:17:43.897474500 tcpserver: pid 26727 from 151.52.xxx.xxx
2022-01-24 01:17:43.990919500 tcpserver: ok 26652 mail1.xxx.com:172.24.xxx.xxx:25 :107.16xxx.xxx::54474

Are the servers' date and time correct? 

Secondly, I would try to see what smtpd is doing with strace

Hi roberto puzzanghera 

This is my strace qmail-smtpd. I used "strace -fp 24210" command. i

strace: Process 24210 attached
brk(NULL) = 0x840000
brk(NULL) = 0x840000brk(0x83c000) = 0x83c000
brk(NULL) = 0x83c000
write(1, "\26\3\1\0001\2\0\0-\3\1\223\310\"\312Q\0\202\321\223\303.b;}\245I'\276\225\313\344"..., 4095) = 4095
read(0, 0x810c43, 5) = -1 EAGAIN (Resource temporarily unavailable)fcntl(0, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(0, F_SETFL, O_RDWR) = 0fcntl(1, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(1, F_SETFL, O_RDWR) = 0select(2, NULL, [1], NULL, {tv_sec=60, tv_usec=0}) = 1 (out [1], left {tv_sec=59, tv_usec=999997})
write(1, "454 TLS connection failed: timed"..., 47) = 47
brk(NULL) = 0x83c000brk(NULL) = 0x83c000
brk(0x83a000) = 0x83a000brk(NULL) = 0x83a000
brk(NULL) = 0x83a000brk(NULL) = 0x83a000
brk(0x836000) = 0x836000brk(NULL) = 0x836000
brk(NULL) = 0x836000brk(NULL) = 0x836000brk(0x82b000) = 0x82b000
brk(NULL) = 0x82b000select(3, NULL, [2], NULL, {tv_sec=60, tv_usec=0}) = 1 (out [2], left {tv_sec=59, tv_usec=999996})
write(2, "qmail-smtpd: read failed (tls co"..., 114) = 114
exit_group(1) = ?+++ exited with 1 +++

you have a TLS connection failure, I guess in your submission service. Can you check your TLS certificate state in this way

openssl s_client -starttls smtp -crlf -connect localhost:587 -cert /var/qmail/control/servercert.pem -key /var/qmail/control/servercert.pem -state

Hi roberto puzzanghera 

Sorry for late reply . 

I added recordio command before qmail-smtpd in config file to get more detail log. but no TLS error log .

I changed qmail-smtpd/run config [/usr/local/bin/softlimit -m 10000000]->][/usr/local/bin/softlimit -m 200000].

So after 2 days everything is ok. and my server 's cpu is sage now. I think softlimit is over-spec . Thank you for your kindly support.

I am still trying to get qmail using IPv6 . Have a nice day.

Here is command 's result on my server. I am using "SMTPD_GREETDELAY" for greeting delay too.

Maybe this make server resouce is higher than normal? I will remove SMTPD_GREETDELAY option.

openssl s_client -starttls smtp -crlf -connect localhost:587 -cert /var/qmail/control/servercert.pem -key /var/qmail/control/servercert.pem -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify return:1
depth=0 CN = *.no1-serxxx.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/CN=*.no1-serxxx.com
i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGRzCCBS+gAwIBAgIMTy0J+wRHU1/6EtfPMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTIxMDYxMTA4MDQwOFoXDTIyMDcx
MzA4MDQwOFowHTEbMBkGA1UEAwwSKi5ubzEtc2VydmVyMjguY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqTXFrhHBizsjq4CCBeTADUN/7bl1F2yc
xHfWiptQzGTnY3ohDCbnsY4/pYqh3AX6/e5ay5++XHHsDlnh9hKFHwEDoBV8f2Jx
NGVChH1JLwGTXEzseeEse76JkqZQj4K6ImxrUvieS4OisN0BTxtkFQ1cazAwHCL1
CjtIoULJK6keoIdZ24H6bNjKX/stmqb6sUp2ttHQOnzTojbZ4dmqqtI/fhfN0dLn
SQrq1aV0owfkgplMS48whjRjfRvuCLGDYy1vl4hpbhBTEQgv4TKxR/cEozAMwDJD
Rhqj2Gujn7CRnlN37ywptBSKStQD9Jsjx2WsNnkSlZMPIaj4dhe1oQIDAQABo4ID
VjCCA1IwDgYDVR0PAQH/BAQDAgWgMIGJBggrBgEFBQcBAQR9MHswQgYIKwYBBQUH
MAKGNmh0dHA6Ly9zZWN1cmUyLmFscGhhc3NsLmNvbS9jYWNlcnQvZ3NhbHBoYXNo
YTJnMnIxLmNydDA1BggrBgEFBQcwAYYpaHR0cDovL29jc3AyLmdsb2JhbHNpZ24u
Y29tL2dzYWxwaGFzaGEyZzIwVwYDVR0gBFAwTjBCBgorBgEEAaAyAQoKMDQwMgYI
KwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkv
MAgGBmeBDAECATAJBgNVHRMEAjAAMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9j
..
-----END CERTIFICATE-----
subject=/CN=*.no1-serxxx.com
phaSSL CA - SHA256 - G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3605 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: AB98869F6AA62BD90D91E8F6EAFDB4B0EFD014FFD6019560C21242593A9CF8E9
Session-ID-ctx: 
Master-Key: CFB1310D7B82FCA44346348EB4C2D57FF53E4AFB7A63C7BDA61F772F8DDC2FB73A2C95E1A1EC03CFF52A4186C7748F62
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 37 05 25 6f d9 34 73 41-dd c7 fb 5c b7 61 00 21 7.%o.4sA...\.a.!
0010 - e2 dd 4f 35 c3 f5 86 12-d8 59 39 97 b2 db 66 ec ..O5.....Y9...f.
0020 - 5f e4 70 39 8f 54 e9 46-55 a9 41 6f d6 dd 3b b1 _.p9.T.FU.Ao..;.
0030 - 0a f1 49 64 3e 68 30 fe-ba 93 df 39 da 1a 8d bb ..Id>h0....9....
0040 - 5c 76 e0 5f 34 83 33 b1-d8 67 c2 81 9b 75 bd 79 \v._4.3..g...u.y
0050 - 09 11 bb a0 56 d8 3b a3-e6 fe f2 b5 48 40 2f 43 ....V.;.....H@/C
0060 - 9f f4 0e 25 36 db e0 e4-39 1b 69 be 02 0b 6f 79 ...%6...9.i...oy
0070 - 9e fa 8b 20 73 ff 60 0f-54 cc c4 e9 dc e7 f9 26 ... s.`.T......&
0080 - c9 11 b9 93 7c 40 92 57-2c 1c 2a fc c1 c5 8c fb ....|@.W,.*.....
0090 - 14 34 b3 1d 0f e4 cf 58-d0 0b a4 18 25 61 d6 c3 .4.....X....%a..

Start Time: 1643020850
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 SIZE 20480000

No, greetdelay will not engage your cpu, just absorbs spammers' resources :-)

First of all consider an update of your openssl server or disable the connections with SSL 3.0, because of the POODLE vulberability. Anyway your certificate seems ok.

Can you check the logs (both smtpd and submission) and look for those "454 TLS connection failed"? Can you do

openssl s_client -starttls smtp -crlf -connect yourserver.tld:25/587

from remote, using the port that advertise STARTTLS?

Hi roberto

Today I faced the problem with WBErbxishu_citizen~micro_205_0_0@abc.com

When i remove [~] character everything is ok. So I wonder if we can add exception of [~] character in chckuser.

I checked patch is uncommented [~] character . But it does not work . Can you please check it ?

+#define CHKUSER_ALLOW_SENDER_CHAR_5 '*'
+#define CHKUSER_ALLOW_SENDER_CHAR_6 '^'
+#define CHKUSER_ALLOW_SENDER_CHAR_7 '~'

Hi Jacky, WBErbxishu_citizen~micro_205_0_0@abc.com works here...

Hi roberto

telnet mail-xxx.xxx-xxxx.com 25
Trying 158.101.69.33...
Connected to mail-xxx.xx-xxx.com.
Escape character is '^]'.
220 mail.no1-xxx.com Welcome to SMTP server ESMTP
ehlo
250-mail.no1-xxx.com Welcome to SMTP server
250-STARTTLS
250-PIPELINING
250-8BITMIME
250-AUTH LOGIN PLAIN CRAM-MD5
250 SIZE 20480000
mail from: <WBErbxishu_citizen~micro_205_0_0@biem.eco-serv.jp>
553 5.1.7 sorry, mailbox syntax not allowed (chkuser)
mail from: <WBErbxishu_citizen?micro_205_0_0@rbiem.eco-serv.jp>
553 5.1.7 sorry, mailbox syntax not allowed (chkuser)
mail from: <WBErbxishu_citizen~micro_205_0_0@rbiem.eco-serv.jp>
553 5.1.7 sorry, mailbox syntax not allowed (chkuser)

I deployed newest patch but it does not work for me.

do you have any advice for me.

weird... it's seems like you're not using the same chkuser...

I would check the chkuser's source code in order to verify that you are using the same patch. Check these lines https://notes.sagredo.eu/files/qmail/patches/roberto-netqmail-1.06/2021.06.19_patch.diff

Did you restart qmail after last compile/install?

hi  Roberto

Thank you for your advice.

I figured out my problem. This issue is in my qmail-smtp run config is still using old qmail-smtpd file . i am terribly sorry.

Thank you very much.

Hello Roberto

Thank you for your excellent work, time and support of this patch. 

The latest patch builds fine. I can send outgoing mail. However, problems with vdelivermail leaves mail in the queue, perpetually deffered with database_down errors. Have spent a day troubleshooting this new build and could not locate the issue, hoping you can point me in the right direction. 

Here is what I have:

## -> mlcat send

2021-10-25 16:05:54.914534500 delivery 2: deferral: vdelivermail:_deferred,_database_down/

I have double-checked all the usual suspects... queue looks good, brand new build anyways, still not sure what's missing here. Any pointers is much appreciated. Thank you.

Thank you very much.

Hi, I had a look at the source code

   /* if the database is down, deferr */ 
   if ( verrori == VA_NO_AUTH_CONNECTION ) 
       vexiterr (EXIT_DEFER, "vdelivermail: deferred, database down");

it seems that it cannot connect to your mysql. So, double check your mysql connection/priviledges and your vpopmail/mysql configuration

After the help dealing with the log date patch, this seems to be the error I now face. 

I can successfully make users and valiases, can successfully query those on port 89, can successfully do

mysql -h 127.0.0.1 -u vpopmail -pPASSWORD vpopmail 

and the same if I swap it to 0.0.0.0 

the line in

more /home/vpopmail/etc/vpopmail.mysql is: 0.0.0.0|0|vpopmail|PASSWORD|vpopmail

though has been in testing this, localhost and 127.0.0.1. 

I the various GRANT etc statements gave me issues and seemed to be related to:

https://stackoverflow.com/questions/52372165/mysql-error-1064-42000-you-have-an-error-in-your-sql-syntax

But I assumed that once I navigated to a place where I could make accounts and the like I was fine, as I was the last time I did this whole process and had the same error with the GRANT commands. 

What is the best way to find out where this is now failing and remedy it? 

System is Ubuntu 22.04 LTS with the database packages installed from apt. 

I will  try tomorrow with your Ubuntu version also to try to reproduce the bug with the daemontools patch. Regarding the database/user query, I don't see the problem in the page you link. My query is exactly as suggested there...

BTW, which is the exact query are you using? I suggest to use localhost everywhere if the mail server and the mysql server are the same

I'm floored with the level you're willing to go to help people with this process and the guide. Very impressive. Thank you again. 

The last time I did this my notes on the

>GRANT USAGE ON * . * TO 'vpopmail'@'mailserver-IP' IDENTIFIED BY 'jz_jcsX4yW' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;

Command prompted me to make note of the URL shared above in my build log. That was with 20.04 LTS (MySQL Server version: 8.0.27-0ubuntu0.20.04.1 (Ubuntu) )

This time:

Server version: 8.0.34-0ubuntu0.22.04.1 (Ubuntu)
Copyright (c) 2000, 2023, Oracle and/or its affiliates.

mysql> GRANT USAGE ON * . * TO 'vpopmail'@'localhost' IDENTIFIED BY 'PASSWORD' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IDENTIFIED BY 'X8vFVtChqVwf' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOU' at line 1

In both cases I was able to proceed with a GRANT USAGE that trunkates after localhost - not applying the limits. But in the 20.04 case I did not run into the vdelivermail:_deferred,_database_down/ error. 

Many things have changed in the years gap. I find myself wondering if the default mysql password type matters, as that appears to have changed from then to now based on my trying to resolve this. 

I have another error in my qmail/send/current log regarding a TLS_connect_failed when sending a remote message, unsupported protocol an I'd have expected that to fall back to unsecure for non-submission ie: port 25. I know a good deal about the other server as the one I'm building is backupmx for some of it's domains, so ideally I just need this to work too - until that other one gets rebuilt. Given this is the rather minimal rc run script I'm not sure how to adjust that setting. 

I'm also happen to take the more extended conversation on this to email or another system if you'd rather not have all of it here. 

Try to use 

GRANT USAGE ON * . * TO 'vpopmail'@'localhost' WITH MAX_QUERIES_PER_HOUR and all the rest

as explained in the link you provided above.

Let's continue the conversation here for now, as it can be of interest for others

mysql> GRANT USAGE ON * . * TO 'vpopmail'@'localhost' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USE' at line 1

Removing the password section does not seem to be enough. 

No idea... is there a particular reason why you are using MySQL? What about switching to mariadb and get rid of these issues? It's available in the Ubuntu store, as you know

I've swapped databases as suggested, the grant statements now work with the limits. 

I've rebuilt the vdomains, vusers, valiases due to switching databases. All went as smoothly as before. 

Messages still do not get delivered with the same 

2023-09-03 13:40:07.895332212 delivery 10: deferral: vdelivermail:_deferred,_database_down/

Though operations work on the database to make the users etc which I assume uses the same authentication file and the same data channel as vdelivermail does. 

Thank you again for all of your assistance.

You have a failed connection to database (VA_NO_AUTH_CONNECTION) while attempting to read the virtual aliases. Did you test vpopmail with telnet 0 89?

Do you have mariadb and qmail on the same host? Try to do a connection from the commad line:

mysql -u vpopmail -p vpopmailpwd

look for errors in mariadb log.

Check the priviledge. What do you have in vpopmail.mysql? Of course hide your pwd. Be aware that vpopmail@localhost is a different user than vpopmail@127.0.0.1 from the database point of view...

postmaster for a vdomain can successfully authenticate with the telnet 0 89 test yes. 

Both are hosted on the same machine yes:

# mysql -u vpopmail -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 1496
Server version: 10.6.12-MariaDB-0ubuntu0.22.04.1 Ubuntu 22.04
mariadb(mysql) error log is empty, 0 bytes. 

vpopmail.mysql file:

-rw-r----- 1 vpopmail vchkpw   43 Sep  3 14:39 vpopmail.mysql
localhost|0|vpopmail|PASSWORD|vpopmail

localhost was used for all the GRANT statements - so matching that seemed important but in testing I've cycled through 'localhost' '127.0.0.1' and '0.0.0.0' - am tempted to add additional matching GRANT statements for all of these in hopes it would help. 

Ok. So I assume that you have a database user vpopmail@localhost with privileges to use the vpopmail db.

The delivery fails only when sending to a valias or even to an ordinary mailbox?

I re-ran 

MariaDB [(none)]> CREATE USER 'vpopmail'@'localhost' IDENTIFIED BY 'PASSWORD'; 
ERROR 1396 (HY000): Operation CREATE USER failed for 'vpopmail'@'localhost'
MariaDB [(none)]> select User from mysql.user;
+-------------+
| User        |
+-------------+
| mariadb.sys |
| mysql       |
| root        |
| vpopmail    |
+-------------+
4 rows in set (0.001 sec)

MariaDB [(none)]>  GRANT USAGE ON * . * TO 'vpopmail'@'localhost' IDENTIFIED BY 'PASSWORD' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> GRANT ALL PRIVILEGES ON `vpopmail` . * TO 'vpopmail'@'localhost';
Query OK, 0 rows affected (0.001 sec)

Failure is happening on non-alias virtualusers. Haven't tested the aliases, though I have made aliases.

You should select not only the user field but also the host. Anyway it seems that vpopmail@localhost exists.

I've no idea. I think that if you recompiile without valias it will work as no dB connection is needed.

Does the valias table exist? Try to create a valias and see if it's written correctly

I'd also try to connect with the vpopmail account and to

USE vpopmail;
SELECT * from valias;

I'm really at a loss. 

As posted the other day the valias database seems to be correctly populated. 

I've now granted access on all three of 0.0.0.0 localhost and 127.0.0.1 and tried those values in the file. 

I've been able to get errors out of mariadb by looking at the service status and if I mangle the password intentionally it will throw a password error. When I restart qmail there is an aborted connection warning. 

I've now set the vpopmail.mysql file to be 127.0.0.1 and changed the port to 3306. Per: 

Sep 05 11:56:08  mariadbd[431485]: 2023-09-05 11:56:08 0 [Note] Server socket created on IP: '127.0.0.1'.
Sep 05 11:56:08 mariadbd[431485]: 2023-09-05 11:56:08 0 [Note] /usr/sbin/mariadbd: ready for connections.
Sep 05 11:56:08 mariadbd[431485]: Version: '10.6.12-MariaDB-0ubuntu0.22.04.1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 22.04

Though from this perspective 0 seemed to work as did 0.0.0.0 and localhost. 

I recompiled vpopmail without valias, no change. I attempted to recompile it without any of the sql-database options (I could live without it using mysql/mariadb as long as dovecot pop/imap also works down the line) and that wouldn't compile at all.

Hi, can we continue the discussion via mail, just to avoid the bombing for those who subscribed the comments? :-) Please use the contact button above.

Please send the errors you eventually get in the mysql log. 

If you disabled valias and continue to get db connections errors like "vdelivermail: deferred, database down", your vpopmail installation is a mess. The code speaks clearly:

file vdelivermail.c:

#ifdef VALIAS 
   /* process valiases if configured */ 
   if ( process_valias() == 1 ) 
       vexiterr (EXIT_OK, "vdelivermail: valiases processed"); 

   /* if the database is down, deferr */ 
   if ( verrori == VA_NO_AUTH_CONNECTION ) 
       vexiterr (EXIT_DEFER, "vdelivermail: deferred, database down"); 
#endif

You can't get that error without VALIAS defined. Or your previous installation has not been overwritten. Check if VALIAS has been defined or not in ~vpopmail/include/config.h

Also you may have called an old vdelivermail and not installed vpopmail in another folder. Please post the following

which vdelivermail
grep -r vpopmail /etc/passwd

and the content of your .qmail-default

# mysql -u vpopmail -p                
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
our MariaDB connection id is 1508
Server version: 10.6.12-MariaDB-0ubuntu0.22.04.1 Ubuntu 22.04
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> USE vpopmail;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [vpopmail]> SELECT * from valias;
+----+---------------+------------------------+--------------------------+
| id | alias         | domain                 | valias_line              |
+----+---------------+------------------------+--------------------------+

(and it appears correctly populated)

I need aliases. though can get away with using .qmail-VUSER files if need be. 

Hi all,

I search "Ipv6" keyword on this page but can not find the answer.

So qmail can send email to other mail server with IPv6 support or not?

I use tcpserver daemon to run qmail.

Not with this qmail patch.

Edit: Only ucspi-tcp6 is ipv6 ready

Hi Roberto

I will install ucspi-tcp6 and try to send and receive with IPv6

Sorry , anyone can help me install qmail-spp http://qmail-spp.sourceforge.net/doc/ with this patch?

Hi, it should be quite easy to add the patch that was built for the old Bill Shupp's combined patch. But you should do it by hand because the qmail-smtpd.c from Shupp's patch is very different from mine

Hi Roberto ,

Thank you for your reply. I will try to add by hand .

Remember that those two qmail-qpp files are new and can be copied from a vanilla qmail  patched with the same patch.

Then you only have to take care of the makefile, which is easy to adjust,  and qmail-smtpd.c, where you just have to put those  new lines in the right place

Hi Roberto,

My qmail installation (netqmail-tls 1.06.20110119_1 over the FreeBSD ports) can't send mails to Microsoft (and others) anymore for a few month. qmail tries to send it for a week and then give up. I read that Microsoft (and others) rejects TLSv1.0 now and accepts only TLSv1.2.

I just checked the last FreeBSD port. It uses the latest Frederik Vermeulen's patch (https://inoa.net/qmail-tls/netqmail-1.06-tls-20200107.patch). But I couldn't find any version number like TLSv1.0, TLSv1.1, TLSv1.2, etc.

• Does it not depend on qmail but on OpenSSL?
• So the patch from f.vermeulen will work with TLSv1.2?

I think that the latest version will work with all TLS versions, I just remember that the SSLv3 support was removed after POODLE was spotted, but I'm not sure. You should contact the author of the patch for further informations

Or you can install the latest tls patch and test the connection against microsoft using openssl as explained in this guide

Hi Roberto,

in the patch there are a range of characters that are allowed in the mail address. The CHKUSER_ALLOW_RCPT_CHAR_* variables are used in the functions check_sender_address_format and check_rcpt_address_format in chkuser.c.

Our server with your latest patch rejects mails because of the address includes slashes. I really have no idea why people are thinking this is a good idea :)

2021-06-14 14:41:18.754723500 qlogenvelope: result=rejected code=553 reason=chkusersender detail=senderformat helo=**************** mailfrom=SRS0=R/yv=LI=**************** rcptto= relay=no rcpthosts= size= authuser= authtype= encrypted=tls sslverified=no localip=**************** localport=25 remoteip=**************** remoteport=56562 remotehost=**************** qp= pid=4456
2021-06-14 15:07:27.879168500 CHKUSER rejected sender: from <SRS0=R/yv=LI=****************|remoteinfo/auth:|chkuser-identify:> remote <helo:|remotehostname:****************|remotehostip:****************> rcpt <> : invalid sender address format

What do you think about either replace f.e. #define CHKUSER_ALLOW_RCPT_CHAR_9 '#' (because of '#' is also declared in the 2 functions ) or (my favorite) patch the 2 functions to declare the rest of the allowed characters?

&& (user->s[x] != '#')
&& (user->s[x] != '/')
and so on ...

As I understand the rfc the allowed characters are: !#$%&'*+-/=?^_`.{|}~

Regards Thomas

Hi Thomas,

I think we can patch to define a CHKUSER_ALLOW_RCPT/SENDER_CHAR_11 for the slash character, so that those addresses will be allowed even when CHKUSER_ALLOW_RCPT_SRS is not defined. I'll do it in the following days.

This will be good. I am awaiting your patch :)

The patch is already in place ;)

Oh. I did not realise this. Thank you :)

Hi Roberto,

I noticed the change of RSA/DH keys (rsa4096.pem/dh4096.pem) to length 4096 created by 'update_tmprsadh.sh', but the code has not changed, qmail-smtpd.c still only opens the rsa/dh pem files (below) of 2048 and 1024 length:

FILE *in = fopen("control/rsa2048.pem", "r")
FILE *in = fopen("control/dh2048.pem", "r") 
FILE *in = fopen("control/dh1024.pem", "r");

This may be a stupid question by how does qmail utilize these new keys?

Eric

Hi Eric, 

yes, you are right. Actually I'm not using the self signed cert and didn't realized the problem.

Hi Roberto,

Thanks for your great website. I really learn a lot from you.

In your combined patch, below code from "qmail-smpt.c" looks buggy, and may cause performance issues when using TLS.

The statement "if (keylen == 2048)" will always fail and an ephemeral key will be created on every request, instead of using the static one:

+RSA *tmp_rsa_cb(SSL *ssl, int export, int keylen)
+{
+ ;
+
+ if (!export) keylen = 4096;
+ if (keylen == 2048) {
+ FILE *in = fopen("control/rsa4096.pem", "r");
+ if (in) {
+ rsa = PEM_read_RSAPrivateKey(in, NULL, NULL, NULL);
+ fclose(in);
+ if (rsa) return rsa;
+ }
+ }

Hi Ali, thanks for your comment.

I don't remember much of that piece of code, but I see that it's different from the original tls patch here

+if (!export) keylen = 4096;
-if (!export) keylen = 2048;
if (keylen == 2048) {

I think it was changed when there was a request to icreasethe  RSA key and DH parameters to 4096 bit.

Unfortunately I'm very busy these days and I can't play with this before a couple of weeks. If you already know how to correct this, please post your solution

Hi again Roberto,

If you consider the file it tries to open is named rsa4096.pem, "keylen == 2048" is meaningless there,

and this bug will cause the creation of a temporary key in every request, which is a bad thing (TM).

The fix is pretty straightforward (build tested):

diff -ruN netqmail-1.06/qmail-smtpd.c netqmail-1.06-fixed/qmail-smtpd.c
--- netqmail-1.06/qmail-smtpd.c 2023-01-30 17:01:57.920116546 +0400
+++ netqmail-1.06-fixed/qmail-smtpd.c 2023-01-30 17:03:03.752370617 +0400
@@ -2156,7 +2156,7 @@
RSA *rsa;

if (!export) keylen = 4096;
- if (keylen == 2048) {
+ if (keylen == 4096) {
FILE *in = fopen("control/rsa4096.pem", "r");
if (in) {
rsa = PEM_read_RSAPrivateKey(in, NULL, NULL, NULL);

Thank you. I'll correct as soon as possible

Debian 10 after update openssl have error

TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small

which version of openssl? what do you have in your /etc/ssl/openssl.cnf -> default_bits? do you get the error if you put default_bits=2048?

yes i have
default_bits = 2048

What openssl version? Do you have any hint to exactly reproduce the issue?

This problem is caused by target domains which do not support current encryption standards.

Some current examples for such domains are foni.net or versanet.de.

You can use https://www.checktls.com/TestReceiver to find out if a certain domain is affected; in the test output you should then see something like this:

Of course the best way to solve this would be that the administrators of the target domain update their configuration. However, since we are currently experiencing this problem with a bunch of target domains since upgrading our system, I am currently looking for a workaround how we can still/again send e-mails to them encrypted until they have done so.

I find it interesting that sending an e-mail to these domains still works when I use "swaks -tls …" on the same system. But qmail refuses to talk to them. Any hints?

Or even:

FYI: My current workaround is now:

cat /var/qmail/control/tlsclientciphers 
DEFAULT:!DH

I'm a bit afraid, however, that this might cause TLS problems with other target servers.

Ok, thanks for your hint. Let us know if this causes problems with other servers

I didn't checked, but I think tls won't work if you disable SSL and leave active only TLS-1.x in your openssl configuration.

OpenSSL 1.1.1d 10 Sep 2019

Hi,

I'm using Debian 10.7.0-amd64. Installation followed step-by-step with your directions.

During last recompiling (chkuser options included) I've got such errors

./compile chkuser.c
In file included from chkuser.c:43:
chkuser_settings.h:54:1: error: unknown type name ‘define’
define CHKUSER_STARTING_VARIABLE "CHKUSER_START"
^~~~~~
chkuser_settings.h:54:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before string constant
define CHKUSER_STARTING_VARIABLE "CHKUSER_START"

When chkuser all variables commented, recompilling qmail without any errors.

please post your chkuser_settings.h somewhere (not here, 'cause it's too long), so that I can check the syntax

I don't see my reply with link to my chkuser_settings.h so here post the part that generate errors

/*
* Uncomment the following line if you want chkuser to work depending on a VARIABLE setting
* VALUE HERE DEFINED is the name of the variable
* Values admitted inside the variable: NONE | ALWAYS | DOMAIN
* NONE = chkuser will not work
* ALWAYS = chkuser will work always
* DOMAIN = chkuser will work depending by single domain settings
* CHKUSER_STARTING_VARIABLE cannot be defined together with CHKUSER_ALWAYS_ON
* if CHKUSER_STARTING_VARIABLE is defined, and no variable or no value is set, then chkuser is disabled
*/
define CHKUSER_STARTING_VARIABLE "CHKUSER_START"

You should not delete that hash # which goes before define, because in C language it's not intended as a character for comments. So it will be

#define CHKUSER_STARTING_VARIABLE "CHKUSER_START"

If you want to comment out a line, do like this

/* #define CHKUSER_STARTING_VARIABLE "CHKUSER_START" */

Thx very much.

I don't know C language, in bash # is a comment so my misunderstunding.

Hi,

I have problem with compiling vpopmail and qmail with your patchset.
I can not compile qmail with chkuser because he required vpopmail:

./compile chkuser.c
chkuser.c:38:10: fatal error: vpopmail.h: No such file or directory
38 | #include "vpopmail.h"
| ^~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:334: chkuser.o] Error 1

I can not compile vpopmail because he reqired qmail:

configure: error: Unable to find your qmail-newu file, specify --enable-qmail-newu=/full/path/to/qmail-newu

Please take the time needed to read these pages.

You must compile vanilla qmail, not the patched one, and then compile vpopmail on top of it. Then patch and  recompile

Hi Roberto.

I'm using your directions to build some qmail servers. Pretty good job, sure.

Now I'm trying to update one of the servers, and receive a compilation error.  I only have modified the chkuser_settings.h uncommenting the setting that you have noted.  I was using the patch from 26-Aug-2018 before without those modification to this file, just apply patch and compile. My system is a Centos 7.5.1804.

./compile chkuser.c
In file included from chkuser.c:43:0:
chkuser_settings.h:306:1: error: nombre de tipo ‘define’ desconocido
define CHKUSER_RCPT_MX
^
chkuser_settings.h:313:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘define’
define CHKUSER_SENDER_FORMAT
^
chkuser_settings.h:313:1: error: nombre de tipo ‘define’ desconocido
make: *** [chkuser.o] Error 1

Hi Ruben, can you post the content of line 306?

I am a qmail fan and i like your website ... used it to install qmailservers several times

please take this into consideration add the pach in your bundle if possible: https://cxsecurity.com/issue/WLB-2020050189

Thanks in advance

Thank you. Patch added

I ran across a situation I did not know existed until yesterday when I was building an e-mail webapp and I'm hoping you can help explain and/or solve this.

When I send an e-mail to two aliases that both resolve to the same user account, only a single message gets delivered.

For example:

To: foo@bar.com

CC: foo2@bar.com

Both of these addresses are .qmail-foo and .qmail-foo2 inside the bar.com domain directory. Inside these files is the same real user's e-mail address so that they are forwarding accounts only.

If I send that e-mail to both of those aliases, only the latter gets delivered (i.e. the headers show that it was delivered to foo2@bar.com, even though qmail logs that it should be sending two e-mails and both the To and Cc headers are present).

If I change the message to send to foo@bar.com and bar@yahoo.com everything gets delivered properly. I read about someone else seeing the same thing with EXIM and while I'm sure it's a cool feature to limit bandwidth, it cause me hours of trying to nail down a problem with my code that didn't exist. So, I'd love to be able to disable this feature if possible. Thanks!

Never mind. This was traced out and qmail is working just fine, as is Vpopmail. It appears that Apple Mail is automatically deleting duplicate messages delivered to the same inbox.

I had some customers that create several emails in offline mode and when they connect, their outlook starts sending the emails saved in the outbox but some times gives the maxrcpt error (like when the mail has more rcpt to than "control/maxrcpt").

I noted that Outlook sends all emails sequentially, in a single connection, giving a rset after each message sending. But rcptcount is not reset.

to get around this, I had to add:

rcptcount = 0;

within the void smtp_rset function in qmail-smtpd.c

this solved the problem, so the maxrcpto error only occurs if you exceed the limit "control/maxrcpt" in the same email, but not in multiple messages sequentially.

regards,

void smtp_rset(arg) char *arg;
{
seenmail = 0; /* seenauth = 0; RFC 5321: retain authentication */
mailfrom.len = 0; rcptto.len = 0;
rcptcount = 0; // add by me
out("250 flushed\r\n");
}

Thanks for the advise, I've updated my patch.

After speaking with Luca Franceschini, my italian friend who authored qlogenvelope and heavily modified the qmail-smtpd stuff, I patched as follows

void smtp_rset(arg) char *arg;
{
seenmail = 0; /* seenauth = 0; RFC 5321: retain authentication */
mailfrom.len = 0; rcptto.len = 0;
+rcptcount = 0;
+envelopepos = 1;
out("250 flushed\r\n");
}

Luca suggested also to add envelopepos = 1 just to set qlogenvelope as we are after an HELO/EHLO. 

It's not clear WHEN outlook is going to RSET the session, hopefully not after the data has been sent, in that case we should also verify that the total size of the message is reset as well, not to exceed the 'datalimit' for multiple messages. 

I am using your previous patch (Dec 8, 2019) and chkuser and vpopmail are playing nicely. I am not using Mysql with vpopmail, just file based.

When I installed your latest patch (Jan 11, 2020) I could send e-mails out but could not receive anything. All messages failed back to the sender with a failure notice stating "sorry, no mailbox here by that name (chkuser)"

I stopped all qmail services and installed the previous version I kept as a backup, just in case I had issues with the new patch, and everything is back and working.

So, it would be great to get this resolved.

That being said, I am having a major issue with how qmail is processing e-mails prior to sending through SpamAssassin. This is an old system and I am using Qmail-Scanner to connect SA and Qmail. It works just fine, but Qmail is apparently stripping out certain portions of the e-mail because two things are occurring:

1. None of my whitelist_from_rcvd or whitelist_auth lines work.

We tested this against a postfix system and used the entire text of the e-mail against SpamAssassin on this server, and sure enough whitelisting worked as it should. DKIM headers are missing and who knows what else.

2. Every e-mail gets tagged with no rDNS, even though obviously Yahoo, Gmail, etc. all have correct PTR entries for their domain names. Again, when the same e-mail from postfix was tested on this server, SA had no issues finding the rDNS for the sender's domain.

Thanks!

This is strange as the latest modifications did not touch qmail-smtpd.c, where chkuser acts and concerns only ssl (diff here). Can you post your run and tcp.smtp files?

Concerning the qmail-scanner issue, I replaced it with simscan ages ago and I don't even remember how it works, I'm sorry.

The good news is that I finally solved my whitelisting and rdns issue by removing the -H flag from my /service/qmail-smtpd/run file (i.e. /usr/bin/tcpserver -v -R -l "$LOCAL"). That re-enabled dns lookups and everything started working properly again on that front. The other issue with chkuser is still a problem of course so I'm using your previous patch as mentioned above.

This is my /service/qmail-smtpd run file

#!/bin/sh

QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SOFTLIMIT=`cat /var/qmail/control/softlimit`
LOCAL=`head -1 /var/qmail/control/me`

# This enables greetdelay for qmail-smtpd
export SMTPD_GREETDELAY=20
export DROP_PRE_GREET=1

# This enables chkuser
export CHKUSER_START=ALWAYS

# DKIM - SURBL configuration
# DKIMQUEUE and SURBLQUEUE are front-ends of qmail-queue
export SURBL=1 # Comment out to disable SURBL filtering
export QMAILQUEUE=/var/qmail/bin/surblqueue # executes surblfilter
export SURBLQUEUE=/var/qmail/bin/qmail-dkim # executes qmail-dkim afer sublfilter
export DKIMQUEUE=/var/qmail/bin/simscan # simscan is executed after qmail-dkim
# DKIM verification. Use carefully 
#export DKIMVERIFY="FGHKLMNOQRTVWjp"
# This is to avoid verification of outgoing messages
export RELAYCLIENT_NODKIMVERIFY=1

# This turns off TLS on port 25
export DISABLETLS="1"

# Requires that authenticated user and 'mail from' are identical
#export FORCEAUTHMAILFROM="1"

# rcptcheck-overlimit. Limits the number of emails sent by relayclients
#export RCPTCHECK=/var/qmail/bin/rcptcheck-overlimit.sh
#export RCPTCHECKRELAYCLIENT="1"

# This enables simscan debug
#export SIMSCAN_DEBUG=4

exec /usr/local/bin/softlimit -m "$SOFTLIMIT" \
/usr/bin/tcpserver -v -R -l "$LOCAL" \
-x tcp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 25 \
/var/qmail/bin/qmail-smtpd \
/home/vpopmail/bin/vchkpw /bin/tru 2>&1

This is my /service/qmail-smtpd/tcp file

# rules for qmail-smtpd see tcprules(1)
127.:allow,RELAYCLIENT="",QS_SPAMASSASSIN="",QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue"
:allow,QS_SPAMASSASSIN="",QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue"
:allow,DKVERIFY="DEGIJKfh,CGHIJMQRkl",AUTH_UNSET_DKVERIFY=""

you should run qmail-smtpd as vpopmail, not qmaild

Secondly, assigning QMAILQUEUE to qmail-scanner in your tcp.smtp certainly prevents dkim to sign your outgoing mails.

I use a qmail-remote wrapper script so that my outgoing messages are signed, which works perfectly.

Not sure about running as vpopmail as your previous patch works just fine. It's only the new patch that seems to break chkuser against vpopmail.

So how can chkuser check users' existence without vpopmail priviledges?

I guess that in your previous installation you enabled CHKUSER_ENABLE_UIDGID before compiling, in order to run qmail-smtpd with a user diffrerent from vpopmail (look here).

Nope. I compared the previous chkuser_settings.h with the new one and the new one has quite a bit more code in it. However, the exact same lines were commented out in both.

Here are the variables that are commented out in both:

ALWAYS_ON
ENABLE_UIDGID
SPECIFIC_BOUNCING
VGET_REAL_DOMAIN
ENABLE_VALIAS
ENABLE_USERS_EXTENSIONS
ENABLE_MAILMAN_LISTS
ACCEPT_NULL_SENDER
ENABLE_NULL_SENDER_WITH_TCPREMOTEHOST
EXTRA_MUSTAUTH_VARIABLE

My apologies that I did not come back and post the solution to this issue, which btw, is still present in your latest patch.

Here's how to solve it:

nano chkuser_settings.h

Look for the line
#define CHKUSER_STARTING_VARIABLE "CHKUSER_START"

Comment out this line by:

/*
#define CHKUSER_STARTING_VARIABLE "CHKUSER_START"
*/

Not defining CHKUSER_STARTING_VARIABLE completely disables chkuser, unless you have CHKUSER_ALWAYS_ON defined. I don't think this is what we want

Makes sense, however this is the only way I can get qmail to compile and install with your latest patches, and everything works just fine for me. If chkuser was disabled, wouldn't vpopmail fail to send and deliver messages?

chkuser is disabled in this way, and even though qmail/vpopmail can work without it you'll get an increase of spam. chkuser and vpopmail can work together with my configuration, which is the same suggested by the author, i.e. running qmail as vpopmail

Hi Roberto,

We have an old issue here that we were never able to understand or fix.

We have concurrencyremote set to 120

When sending out a newsletter to 400,000 subscribers, the number of concurrent connections always drops to less than 10.

Right now we are sending our newsletter and here is what we have:

@400000005e146a3a2ef8509c status: local 0/40 remote 7/120 suppl0 0/1 suppl1 2/5 suppl2 0/1