Issue with email delivery to distribution list after patching.
Brought to you by:
mbhangui
Menu
▾
▴
#30 Issue with email delivery to distribution list after patching.
1) Yesterday patching was done for standby mail-server and following packages were upgraded
dnf history info 30 | egrep "indimail|ezmlm|iweb|daemon"
Upgrade indimail-3.4.6-1.1.x86_64 @home_indimail
Upgraded indimail-3.4.5-5.1.x86_64 @@System
Upgrade indimail-access-1.2-1.1.x86_64 @home_indimail
Upgraded indimail-access-1.1.1-6.1.x86_64 @@System
Upgrade indimail-mta-3.0.6-2.1.x86_64 @home_indimail
Upgraded indimail-mta-3.0.5-44.1.x86_64 @@System
Upgrade libindimail-3.4.6-1.1.x86_64 @home_indimail
Upgraded libindimail-3.4.5-5.1.x86_64 @@System
Upgrade libqmail-1.2.1-1.1.x86_64 @home_indimail
2 warning: /etc/indimail/backup.conf created as /etc/indimail/backup.conf.rpmnew
2) post upgrade, post reboot when we run qmailctl queue, we got error messages. Screen shot of error not available. As this was a standby system, the sysadmin deleted the queues and recreated them using queue-fix utility.
3) test email was sent to local-user as well as outside domain, it was recieved back successfully.
4) test email to local distribution list is failing with error message as
@4000000065b8b955062dcb74 delivery 1.4: deferral: ezmlm-send:fatal:_temporary_qmail-queue_error::qq_trouble_creating_files_in_queue(#4.3.0)/ queue4
@4000000065b8b955062de2e4 status: local 0/10 remote 0/20 queue4
5) if we compare the patched and unpatched systems (current live-production system), one observation is that after runing queue fix sub-directories under /var/indimail/queue/queue4/intd/* are not present
qmailctl queue shows (exerpt for queue4 only, test is blank)
processing queue /var/indimail/queue/queue4
Tue, 30 Jan 2024 11:02:48 GMT 28/#139346446 1287 sharad@softenger.co.in
local softenger.co.in-dltest@softenger.co.in
done local softenger.co.in-inarch@softenger.co.in
ls -ld /var/indimail/queue/queue4///205845493
-rw-------. 1 qmails qmail 40 Jan 30 14:24 /var/indimail/queue/queue4/info/28/139346446
-rw-------. 1 qmails qmail 80 Jan 30 14:24 /var/indimail/queue/queue4/local/28/139346446
-rw-r--r--. 1 qmailq qmail 20422 Jan 30 14:24 /var/indimail/queue/queue4/mess/28/139346446
ls -ld /var/indimail/queue/queue4/intd/28
ls: cannot access '/var/indimail/queue/queue4/intd/28': No such file or directory
on the patched system if we try to run create the directories under /var/indimail/queue/queue4/intd/ by copying them from local
i.e. cd /var/indimail/queue/queue4/local
cp -rp * /var/indimail/queue/queue4/intd/
chown qmailq /var/indimail/queue/queue4/intd/
chmod 700 /var/indimail/queue/queue4/intd/
now
cd /var/indimail/queue/
queue-fix queue4
queue-fix: warn: fix strays: Failed while checking directory structure.
Make sure the given queue exists and you have permission to access it.
Exiting...
The directory permissions are changed to 640
As of now after stoping qmail, we have removed and recreated all queues them using queue-fix
Related
patched System Info
uname -a
Linux train1.softenger.com 4.18.0-513.11.1.el8_9.x86_64 #1 SMP Wed Jan 10 22:58:54 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/redhat-release
Rocky Linux release 8.9 (Green Obsidian)
Diff:
what is the value of /etc/indimail/control/global_vars/CONFSPLIT?
and what does ls -l /etc/indimail/control/ezmlm/global_vars show?
[root@train1 ~]# cat /etc/indimail/control/global_vars/CONFSPLIT
151
[root@train1 ~]# ls -l /etc/indimail/control/ezmlm/global_vars
ls: cannot access '/etc/indimail/control/ezmlm/global_vars': No such file or directory
[root@train1 ~]# cd /etc/indimail/control/
[root@train1 control]# cd ezmlm
-bash: cd: ezmlm: No such file or directory
[root@train1 control]# pwd
/etc/indimail/control
[root@train1 control]# ls
cache defaultdelivery domainkeys hostip libindimail me rcpthosts servicedir.conf timeoutsmtpd
clientcert.pem defaultdomain envnoathost host.mysql libmysql nodnscheck recipients signatures tlsclientmethod
clientcipherlist defaulthost filterargs inarchive.rules localiphost outarchive.rules servercert.pem smtpgreeting tlsservermethod
clientciphersuite defaultqueue global_vars level2-tlds locals plusdomain servercipherlist spamignore virtualdomains
databytes dnsbllist greylist.white level3-tlds mailarchive queue_base serverciphersuite timeoutremote
[root@train1 control]#
On Tue, 30 Jan 2024 at 14:42, Abhijit Chaphekar abhijitsipl@users.sourceforge.net wrote:
When you say patching, you mean the system was upgraded using the dnf
command, right?
This is OK. The file /etc/indimail/backup.conf has additional directories,
files to be backed up. This config file is used by svctool --backup command
to backup indimail minus the queue. This file can be modified by the
end-use to include additional files to be backed up. Hence, during upgrade,
this file is not replaced during the upgrade process. If you have not made
any custom changes you can rename backup.conf.rpmnew to backup.conf. If you
have made any changes you can add those to backup.conf.rpmnew and then
rename backup.conf.rpmnew to backup.conf
OK.
OK
sub-directories are needed only when BIGTODO environment variable is
non-zero. The sub-directories helped for old filesystems that were used on
systems like Solaris/SunOS systems which were extemely inefficient handling
large number of files in a single directory. This type of queue is known as
big-todo setup.
This is OK if BIGTODO environment variable doesn't exist or if it exists
and the value is 0.
queue-fix will complain because it expects intd and todo without these
sub-directories. If you want to use the old-style queue, you have to have
BIGTODO as non-zero in qmail-smtpd., qmail-send. and
/etc/indimail/ezmlm/global_vars
queue-fix is complaining because it doesn't expect the sub-directories and
files under it with a non big-todo queue setup.
This is strange. Which directories are you referring to?
To have a big-todo setup, queue-fix needs to be passed -b 1 argument. After
that one has to set BIGTODO as non-zero for any program that writes or
reads from the queue. So
I think what is happening is that there is a mismatch regarding big-todo
config. Most likely indimail-mta is using big-todo setup because BIGTODO is
non-zero in /etc/indimail/control/global_vars and ezmlm which uses
/etc/indimail/ezmlm/global_vars for global env variables doesn't have
BIGTODO defined. You can simply create the link as shown above. You can use
the below commands to see what env variables are set for indimail-mta and
ezmlm
On Tue, 30 Jan 2024 at 14:42, Abhijit Chaphekar abhijitsipl@users.sourceforge.net wrote:
Now I understand why some directories had 0640 permissions. for a
non-bigtodo setup, queue-fix expects regular files in intd and todo
subdirectories with 0640 permission. queue-fix should have instead
complained that these are directories and not regular files. I will modify
queue-fix to return error when it finds the wrong type of files in the sub
directories.
understood the part about BIGTODO environment variable.
Based on this understanding I did the R&D is towards, identifying why the mail-delivery to distribution list is failing after patching.
on comparing patched and unpatched systems, I notice that the patched system, has BIGTODO variable defined in /etc/indimail/control/global_vars/ with value as ZERO,
where as the unpached system, does not have this variable defined in /etc/indimail/control/global_vars/
TEST-1:
removed the variable BIGTODO and recreated the queues and sent email to email-ID inside the domain, outside the domain and to a DL
ezmlm index is getting corrupted / has wrong format on delivery each email. If you reindex the DL, first delivery goes through subsequent delivery gives the same error
TEST-2:
as soon as reintoduced the BIGTODO variable back, it gave error message on executing CMD> qmailctl queue
I guess the sysadmin would have seen this error post patching and had recreated the queues.
Observations:
Presence of this variable BIGTODO, even if the value of the variable is ZERO, is causing a change in behavior.
details of test-1 and test-2 attached in zip file for reference.
Note:
I understand that the files under the queue directories have innode numbers as the file names. However as this is a test system that does not have any active mails, deleting queue and recreating them does not pose any challenge, just gives a clean setup for testing.
Fixing his took longer than I anticipated. There were two issues
deferral: ezmlm-send:_fatal:_Old_format_or_corrupted_index._Run_ezmlm-idx!_(#5.3.0). This too has been fixed in the latest build.I will update this ticket when the build on open buld service for ezmlm-idx with the fix is completed
The relevant section in RFC2821, section 4.4
RFC2822, section 3.6.7 also specifies how the Received header should be. Though it doesn't explicity mentions FWS usage in the Received header, it does mention
Further restrictions may be applied to the syntax of the trace fields by standards that provide for their use, such as [RFC2821]The relevant quote form Section 3.6.7 is
The build on open build service for the ezmlm-idx with the fixes has been completed successfuly.
I forgot to mention that you have to update libqmail too.
Have noted the changes, will update the BCP system tomorrow and test it out.
Thank you Manny.
delivery to DL is not working. Summary data
[root@train1 indimail]# dnf history info 31
Transaction ID : 31
Begin time : Tue 06 Feb 2024 07:42:40 PM IST
Begin rpmdb : 723:eb0bd2f70a7c077a9100e39eec73829546fe017c
End time : Tue 06 Feb 2024 07:44:36 PM IST (116 seconds)
End rpmdb : 723:00c8429e3149753595b0eb694ad60a6c00b71ba2
User : root <root>
Return-Code : Success
Releasever : 8
Command Line : update -y
Comment :
Packages Altered:
Upgrade openssh-8.0p1-19.el8_9.2.x86_64 @baseos
Upgraded openssh-8.0p1-19.el8_8.x86_64 @@System
Upgrade openssh-clients-8.0p1-19.el8_9.2.x86_64 @baseos
Upgraded openssh-clients-8.0p1-19.el8_8.x86_64 @@System
Upgrade openssh-server-8.0p1-19.el8_9.2.x86_64 @baseos
Upgraded openssh-server-8.0p1-19.el8_8.x86_64 @@System
Upgrade daemontools-1.1.3-3.2.x86_64 @home_indimail
Upgraded daemontools-1.1.3-2.4.x86_64 @@System
Upgrade indimail-3.4.6-3.2.x86_64 @home_indimail
Upgraded indimail-3.4.6-1.1.x86_64 @@System
Upgrade indimail-mta-3.0.6-3.2.x86_64 @home_indimail
Upgraded indimail-mta-3.0.6-2.1.x86_64 @@System
Upgrade libindimail-3.4.6-3.2.x86_64 @home_indimail
Upgraded libindimail-3.4.6-1.1.x86_64 @@System
Upgrade libqmail-1.2.1-3.1.x86_64 @home_indimail
Upgraded libqmail-1.2.1-1.1.x86_64 @@System
Scriptlet output:</root>
output truncated.
A fresh DL was created with two subscribers, with anyone can post setting without moderation.
[root@train1 indimail]# ezmlm-list /var/indimail/domains/softenger.co.in/dltest/
sita@softenger.co.in
aaac00@softenger.co.in
[root@train1 indimail]# tail -f /var/log/svc/deliver.25/current (wd: /var/indimail/queue/queue1/mess)
@4000000065c2448a0284a54c new msg 4438430 queue2
@4000000065c2448a0284b104 info msg 4438430: bytes 8187 from abhijit69@hotmail.com qp 5402 uid 1002 queue2
@4000000065c2448a0284b4ec local: abhijit69@hotmail.com dltest@softenger.co.in 4438430 8187 bytes queue2 opendir mode
@4000000065c2448a0284b8d4 starting delivery 1.2: msg 4438430 to local softenger.co.in-dltest@softenger.co.in queue2
@4000000065c2448a0284bcbc status: local 1/10 remote 0/20 queue2
@4000000065c2448a09924b64 delivery 1.2: deferral: ezmlm-send:fatal:temporaryqmail-queueerror::qqtroublecreatingfilesinqueue(#4.3.0)/ queue2
@4000000065c2448a099262d4 status: local 0/10 remote 0/20 queue2
[root@train1 softenger.co.in]# qmailctl queue
processing queue /var/indimail/queue/queue2
Tue, 6 Feb 2024 19:58:01 GMT 120/#201328571 8188 abhijit69@hotmail.com
local softenger.co.in-dltest@softenger.co.in
Trace file enclosed for qmail delivery for queue2 enclosed for reference.
missed attaching the log.
is this because ezmlm has not been updated as a part of current dnf update
The output is truncated. I cannot see if ezmlm-idx has been updated or not.
ezmlm-idx needs to be updated. It has a bug that corrupts the index
On Tue, 6 Feb 2024 at 23:25, Abhijit Chaphekar abhijitsipl@users.sourceforge.net wrote:
--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Related
Support Requests:
#30The error message trouble creating file in the queue happens when ezmlm-idx
and indimail-mta don't use the same queue definitions. ls -l of
/etc/indimail/ezmlm/global_vars to find if a link .envdir to
/etc/indimail/control/global_vars exists
The error related to corruption is a bug in the original ezmlm-send.c. It is
related to parsing of date from the Received header. For this ezmlm-idx
needs to be updated. The new ezmlm-idx also creates the .envdir link in
/etc/indimail/ezmlm/global_vars. This will also fix the error message "trouble creating files in the queue"
On Tue, 6 Feb 2024 at 23:28, Manvendra Bhangui mbhangui@gmail.com wrote:
--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Related
Support Requests:
#30Last edit: Manvendra Bhangui 2024-02-06
ezmlm-idx has not been updated. I have only trucated the part that gives other installation details.
created a link
ln -s /etc/indimail/control/global_vars /etc/indimail/ezmlm/global_vars/.envdir
now the DL delivery is going through
@4000000065c278b212e3b75c new msg 71346462 queue5
@4000000065c278b212e3c314 info msg 71346462: bytes 7867 from abhijit69@hotmail.com qp 12163 uid 1002 queue5
@4000000065c278b212e3cae4 local: abhijit69@hotmail.com dltest@softenger.co.in 71346462 7867 bytes queue5 opendir mode
@4000000065c278b212e48e34 starting delivery 1.5: msg 71346462 to local softenger.co.in-dltest@softenger.co.in queue5
@4000000065c278b212e499ec status: local 1/10 remote 0/20 queue5
@4000000065c278b2183b50d4 new msg 139356547 queue4
@4000000065c278b2183b5c8c info msg 139356547: bytes 7610 from dltest-return-1-@softenger.co.in-@[] qp 12173 uid 555 queue4
@4000000065c278b2183b645c local: dltest-return-1-@softenger.co.in-@[] sita@softenger.co.in 139356547 7610 bytes queue4 opendir mode
@4000000065c278b2183b7014 local: dltest-return-1-@softenger.co.in-@[] aaac00@softenger.co.in 139356547 7610 bytes queue4 opendir mode
@4000000065c278b2183b7bcc starting delivery 1.4: msg 139356547 to local softenger.co.in-sita@softenger.co.in queue4
@4000000065c278b2183be15c status: local 1/10 remote 0/20 queue4
@4000000065c278b2183be544 starting delivery 2.4: msg 139356547 to local softenger.co.in-aaac00@softenger.co.in queue4
@4000000065c278b2183bed14 status: local 2/10 remote 0/20 queue4
@4000000065c278b21a4891ac delivery 2.4: success: did_0+0+1/ queue4
@4000000065c278b21a48997c status: local 1/10 remote 0/20 queue4
@4000000065c278b21a596a2c delivery 1.4: success: did_0+0+1/ queue4
@4000000065c278b21a5971fc status: local 0/10 remote 0/20 queue4
@4000000065c278b21a5971fc end msg 139356547 qmail-send: queue4
@4000000065c278b21b5b596c delivery 1.5: success: ezmlm-send:_info:_qp_12173/did_0+0+10/ queue5
@4000000065c278b21b5d68c4 status: local 0/10 remote 0/20 queue5
@4000000065c278b21b5d6cac end msg 71346462 qmail-send: queue5
will complete remaining test and confirm ticket closure by tomorrow.
My strong suggestion to you is that you create your own dnf repo. All that is required is
1) A rocky linux distribution with httpd installed. It can be a virtual server with minimal RAM and around 100gb of disk space to hold RPM for many years
2) run the attached shell script in cron. If something changes it will build the RPM
3) It will keep all versions of RPM. This will allow you to downgrade to the last working version. opensuse build service keeps only the latest version
4) I can help you setup this server. One of my customer for whom mail is critical is doing this
Makes sense. Will setup the base machine by end of this week. Will reach out in case if any issues. thank you.
Hi Manny,
We are running our mail server on Rocky 8.9, however this is slated for EOS
by 31May2024. So, we have decided to move to Rocky 9.3 as base OS. We have
built a new machine on Rocky 9.3 to manage the indimail-repo and builds.
Do I need to create a github account to connect and download source. Could
you share the options with which I need to run the repo-build.
Linux build.softenger.com 5.14.0-362.18.1.el9_3.0.1.x86_64 #1 SMP
PREEMPT_DYNAMIC Sun Feb 11 13:49:23 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Rocky Linux release 9.3 (Blue Onyx)
Regards
Abhijit
SOFTENGER
India | Singapore | Malaysia
ISO 27001:2013 and ISO 9001:2015 Certified
http://www.softenger.com/ www.softenger.com
Disclaimer: Although the company has taken reasonable precautions to ensure
no viruses are present in this email, the company cannot accept
responsibility for any loss or damage arising from the use of this email or
attachments.
From: support-requests@indimail.p.re.sourceforge.net
support-requests@indimail.p.re.sourceforge.net On Behalf Of Manvendra
Bhangui
Sent: Tuesday, February 6, 2024 11:55 PM
To: [indimail:support-requests]
30@support-requests.indimail.p.re.sourceforge.net
Subject: [indimail:support-requests] #30 Issue with email delivery to
distribution list after patching.
My strong suggestion to you is that you create your own dnf repo. All that
is required is
1) A rocky linux distribution with httpd installed. It can be a virtual
server with minimal RAM and around 100gb of disk space to hold RPM for many
years
2) run the attached shell script in cron. If something changes it will build
the RPM
3) It will keep all versions of RPM. This will allow you to downgrade to the
last working version. opensuse build service keeps only the latest version
4) I can help you setup this server. One of my customer for whom mail is
critical is doing this
Attachments:
https://sourceforge.net/p/indimail/support-requests/_discuss/thread/de8405b f5b/5697/attachment/repo-build (17.0 kB; application/octet-stream)
[support-requests:#30]
https://sourceforge.net/p/indimail/support-requests/30/ Issue with email
delivery to distribution list after patching.
Status: open
Group: v1.0_(example)
Created: Tue Jan 30, 2024 09:12 AM UTC by Abhijit Chaphekar
Last Updated: Tue Feb 06, 2024 06:23 PM UTC
Owner: Manvendra Bhangui
1) Yesterday patching was done for standby mail-server and following
packages were upgraded
dnf history info 30 | egrep "indimail|ezmlm|iweb|daemon"
Upgrade indimail-3.4.6-1.1.x86_64
@home_indimail
Upgraded indimail-3.4.5-5.1.x86_64 @@System
Upgrade indimail-access-1.2-1.1.x86_64
@home_indimail
Upgraded indimail-access-1.1.1-6.1.x86_64 @@System
Upgrade indimail-mta-3.0.6-2.1.x86_64
@home_indimail
Upgraded indimail-mta-3.0.5-44.1.x86_64 @@System
Upgrade libindimail-3.4.6-1.1.x86_64
@home_indimail
Upgraded libindimail-3.4.5-5.1.x86_64 @@System
Upgrade libqmail-1.2.1-1.1.x86_64
@home_indimail
2 warning: /etc/indimail/backup.conf created as
/etc/indimail/backup.conf.rpmnew
2) post upgrade, post reboot when we run qmailctl queue, we got error
messages. Screen shot of error not available. As this was a standby system,
the sysadmin deleted the queues and recreated them using queue-fix utility.
3) test email was sent to local-user as well as outside domain, it was
recieved back successfully.
4) test email to local distribution list is failing with error message as
@4000000065b8b955062dcb74 delivery 1.4: deferral:
ezmlm-send:fatal:temporary_qmail-queue_error::qq_trouble_creating_files_in
queue(#4.3.0)/ queue4
@4000000065b8b955062de2e4 status: local 0/10 remote 0/20 queue4
5) if we compare the patched and unpatched systems (current live-production
system), one observation is that after runing queue fix sub-directories
under /var/indimail/queue/queue4/intd/* are not present
qmailctl queue shows (exerpt for queue4 only, test is blank)
processing queue /var/indimail/queue/queue4
Tue, 30 Jan 2024 11:02:48 GMT 28/#139346446 1287 sharad@softenger.co.in
sharad@softenger.co.in
local softenger.co.in-dltest@softenger.co.in
softenger.co.in-dltest@softenger.co.in
done local softenger.co.in-inarch@softenger.co.in
softenger.co.in-inarch@softenger.co.in
ls -ld /var/indimail/queue/queue4///205845493
-rw-------. 1 qmails qmail 40 Jan 30 14:24
/var/indimail/queue/queue4/info/28/139346446
-rw-------. 1 qmails qmail 80 Jan 30 14:24
/var/indimail/queue/queue4/local/28/139346446
-rw-r--r--. 1 qmailq qmail 20422 Jan 30 14:24
/var/indimail/queue/queue4/mess/28/139346446
ls -ld /var/indimail/queue/queue4/intd/28
ls: cannot access '/var/indimail/queue/queue4/intd/28': No such file or
directory
on the patched system if we try to run create the directories under
/var/indimail/queue/queue4/intd/ by copying them from local
i.e. cd /var/indimail/queue/queue4/local
cp -rp * /var/indimail/queue/queue4/intd/
chown qmailq /var/indimail/queue/queue4/intd/
chmod 700 /var/indimail/queue/queue4/intd/
now
cd /var/indimail/queue/
queue-fix queue4
queue-fix: warn: fix strays: Failed while checking directory structure.
Make sure the given queue exists and you have permission to access it.
Exiting...
The directory permissions are changed to 640
As of now after stoping qmail, we have removed and recreated all queues them
using queue-fix
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/indimail/support-requests/30/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
Related
Support Requests:
#30You don't require a git account. You will have to install a few
development packages and rpmdevtools package. You will also have to
create your own gpg keys for signing the package. See this
https://earthly.dev/blog/creating-and-hosting-your-own-rpm-packages-and-yum-repo/
and this
https://help.sonatype.com/en/gpg-signatures-for-yum-proxy-group.html#:~:text=Create%20Yum%20Proxy%20or%20Group,%2DGPG%2DKEY%2Dnxrmtest.
This is how I run on my system
repo-build -d fc39 -rvi
On Fri, 1 Mar 2024 at 10:34, Abhijit Chaphekar
abhijitsipl@users.sourceforge.net wrote:
--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Last edit: Manvendra Bhangui 2024-03-01
Issue resolved. We can close this ticket. Thank you