Mailing List Archive

[ANNOUNCE] eQmail-1.08.1 released
Minor version eQmail 1.08.1 is released and available here:

ftp://ftp.dyndn.es/eqmail-1.08.1.tgz

Checksums:

md5: 633b7793e44589395535446464fb4de0
(ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5)

sha256: 326739d0be31b246d4262c6773f3a01ecf4a0d0d6a5f144ea5fa07db56264911
(ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256)

This is a bugfix release. Through packaging of eQmail-1.08 round about
6 weeks ago, there came a patch with development code in. This causes
that qmail-remote didn't work correctly. Do no longer use package
eQmail-1.08.tgz. Sorry for inconvenience.

My (weak) online documentation is still at
https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08

Kai
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
Kai,


On 2015-06-14 19:03, K. Peter wrote:
> Minor version eQmail 1.08.1 is released and available here:
>
> ftp://ftp.dyndn.es/eqmail-1.08.1.tgz
>
> Checksums:
>
> md5: 633b7793e44589395535446464fb4de0
> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5)
>
> sha256:
> 326739d0be31b246d4262c6773f3a01ecf4a0d0d6a5f144ea5fa07db56264911
> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256)
>
> This is a bugfix release. Through packaging of eQmail-1.08 round about
> 6 weeks ago, there came a patch with development code in. This causes
> that qmail-remote didn't work correctly. Do no longer use package
> eQmail-1.08.tgz. Sorry for inconvenience.
>
> My (weak) online documentation is still at
> https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08


I am just about to move my server from Fedora 21 to 22 (x86_64) so this
would be good timing to test out eQmail to see if it suits my setup. I
make use of GreyLite (which is no longer supported) and my own Ruby spam
script that is called via qmail-qfilter. I show bits of relevant files
below - can you see any issue with using my setup with eQmail?

/var/qmail/bin/qmail-queue is renamed to /var/qmail/bin/qmail-queue.old

In qmail-qfilter.c there is:

#define QMAIL_QUEUE "/var/qmail/bin/qmail-queue.old"

so if the filter scipt fails for some reason, the mail falls through to
the normal qmail-queue.


/var/qmail/bin/qmail-queue:

!/bin/sh

export LD_LIBRARY_PATH=/usr/local/bglibs/lib:$LD_LIBRARY_PATH
export LC_CTYPE="en_US.UTF-8"
exec /var/qmail/bin/qmail-qfilter /var/qmail/bin/srejector2.rb


/var/qmail/supervise/qmail-smtpd/run:

#!/bin/sh

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

if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
"$LOCAL" ]; then
echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
echo /var/qmail/supervise/qmail-smtpd/run
exit 1
fi

if [ ! -f /var/qmail/control/rcpthosts ]; then
echo "No /var/qmail/control/rcpthosts!"
echo "Refusing to start SMTP listener because it'll create an open
relay"
exit 1
fi

exec /usr/local/bin/softlimit -m 64000000 \
/usr/local/bin/tcpserver -v -R -H -l "$LOCAL" \
-x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
/usr/local/bin/greylite \
/var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log


Thanks,

Phil.

--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
On 2015-06-15 11:38, Philip Rhoades wrote:
> Kai,
>
>
> On 2015-06-14 19:03, K. Peter wrote:
>> Minor version eQmail 1.08.1 is released and available here:
>>
>> ftp://ftp.dyndn.es/eqmail-1.08.1.tgz
>>
>> Checksums:
>>
>> md5: 633b7793e44589395535446464fb4de0
>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5)
>>
>> sha256:
>> 326739d0be31b246d4262c6773f3a01ecf4a0d0d6a5f144ea5fa07db56264911
>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256)
>>
>> This is a bugfix release. Through packaging of eQmail-1.08 round about
>> 6 weeks ago, there came a patch with development code in. This causes
>> that qmail-remote didn't work correctly. Do no longer use package
>> eQmail-1.08.tgz. Sorry for inconvenience.
>>
>> My (weak) online documentation is still at
>> https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08
>
>
> I am just about to move my server from Fedora 21 to 22 (x86_64) so
> this would be good timing to test out eQmail to see if it suits my
> setup. I make use of GreyLite (which is no longer supported) and my
> own Ruby spam script that is called via qmail-qfilter. I show bits of
> relevant files below - can you see any issue with using my setup with
> eQmail?
>
> /var/qmail/bin/qmail-queue is renamed to /var/qmail/bin/qmail-queue.old
>
> In qmail-qfilter.c there is:
>
> #define QMAIL_QUEUE "/var/qmail/bin/qmail-queue.old"
>
> so if the filter scipt fails for some reason, the mail falls through
> to the normal qmail-queue.
>
I would expect if this was working correctly then there should be no
issue with eqmail. But I don't use qmail-qfilter/spamassassin/greylite.
>
> /var/qmail/bin/qmail-queue:
>
> !/bin/sh
>
> export LD_LIBRARY_PATH=/usr/local/bglibs/lib:$LD_LIBRARY_PATH
> export LC_CTYPE="en_US.UTF-8"
> exec /var/qmail/bin/qmail-qfilter /var/qmail/bin/srejector2.rb
>
>
> /var/qmail/supervise/qmail-smtpd/run:
>
> #!/bin/sh
>
> QMAILDUID=`id -u qmaild`
> NOFILESGID=`id -g qmaild`
> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
> LOCAL=`head -1 /var/qmail/control/me`
>
> if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
> "$LOCAL" ]; then
> echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
> echo /var/qmail/supervise/qmail-smtpd/run
> exit 1
> fi
>
> if [ ! -f /var/qmail/control/rcpthosts ]; then
> echo "No /var/qmail/control/rcpthosts!"
> echo "Refusing to start SMTP listener because it'll create an open
> relay"
> exit 1
> fi
>
> exec /usr/local/bin/softlimit -m 64000000 \
> /usr/local/bin/tcpserver -v -R -H -l "$LOCAL" \
> -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
> /usr/local/bin/greylite \
> /var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log
>
This looks good for me on the first view too. And if the last 2 lines
are working then there should be no issue. Nevertheless some unexpected
things can happen always.
>
> Thanks,
>
> Phil.

The qmail-queue.c of my sources is only affected through the
big-todo-patch directly. In case something goes wrong please let me
know. Maybe spamdyke can be an alternative for greylisting/spamfiltering
than.

Thanks
Kai
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
Kai,


On 2015-06-16 00:31, K. Peter wrote:
> On 2015-06-15 11:38, Philip Rhoades wrote:
>> Kai,
>>
>>
>> On 2015-06-14 19:03, K. Peter wrote:
>>> Minor version eQmail 1.08.1 is released and available here:
>>>
>>> ftp://ftp.dyndn.es/eqmail-1.08.1.tgz
>>>
>>> Checksums:
>>>
>>> md5: 633b7793e44589395535446464fb4de0
>>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5)
>>>
>>> sha256:
>>> 326739d0be31b246d4262c6773f3a01ecf4a0d0d6a5f144ea5fa07db56264911
>>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256)
>>>
>>> This is a bugfix release. Through packaging of eQmail-1.08 round
>>> about
>>> 6 weeks ago, there came a patch with development code in. This causes
>>> that qmail-remote didn't work correctly. Do no longer use package
>>> eQmail-1.08.tgz. Sorry for inconvenience.
>>>
>>> My (weak) online documentation is still at
>>> https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08
>>
>>
>> I am just about to move my server from Fedora 21 to 22 (x86_64) so
>> this would be good timing to test out eQmail to see if it suits my
>> setup. I make use of GreyLite (which is no longer supported) and my
>> own Ruby spam script that is called via qmail-qfilter. I show bits of
>> relevant files below - can you see any issue with using my setup with
>> eQmail?
>>
>> /var/qmail/bin/qmail-queue is renamed to
>> /var/qmail/bin/qmail-queue.old
>>
>> In qmail-qfilter.c there is:
>>
>> #define QMAIL_QUEUE "/var/qmail/bin/qmail-queue.old"
>>
>> so if the filter scipt fails for some reason, the mail falls through
>> to the normal qmail-queue.
>> I would expect if this was working correctly then there should be no
>> issue with eqmail. But I don't use
>> qmail-qfilter/spamassassin/greylite.
>>
>> /var/qmail/bin/qmail-queue:
>>
>> !/bin/sh
>>
>> export LD_LIBRARY_PATH=/usr/local/bglibs/lib:$LD_LIBRARY_PATH
>> export LC_CTYPE="en_US.UTF-8"
>> exec /var/qmail/bin/qmail-qfilter /var/qmail/bin/srejector2.rb
>>
>>
>> /var/qmail/supervise/qmail-smtpd/run:
>>
>> #!/bin/sh
>>
>> QMAILDUID=`id -u qmaild`
>> NOFILESGID=`id -g qmaild`
>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>> LOCAL=`head -1 /var/qmail/control/me`
>>
>> if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
>> "$LOCAL" ]; then
>> echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
>> echo /var/qmail/supervise/qmail-smtpd/run
>> exit 1
>> fi
>>
>> if [ ! -f /var/qmail/control/rcpthosts ]; then
>> echo "No /var/qmail/control/rcpthosts!"
>> echo "Refusing to start SMTP listener because it'll create an open
>> relay"
>> exit 1
>> fi
>>
>> exec /usr/local/bin/softlimit -m 64000000 \
>> /usr/local/bin/tcpserver -v -R -H -l "$LOCAL" \
>> -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
>> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
>> /usr/local/bin/greylite \
>> /var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log
>> This looks good for me on the first view too. And if the last 2 lines
>> are working then there should be no issue. Nevertheless some
>> unexpected things can happen always.
>>
>> Thanks,
>>
>> Phil.
>
> The qmail-queue.c of my sources is only affected through the
> big-todo-patch directly. In case something goes wrong please let me
> know. Maybe spamdyke can be an alternative for
> greylisting/spamfiltering than.


I left out all the greylite and qmail-qfilter stuff to begin with on the
new Fedora 22 server and got to the stage where I could send a mail on
the local server and have it delivered to the user - however there is a
problem with getting external mail delivered. I can see from tcpdump
that connections are being attempted but a test with:

telnet pricom.com.au 25

from a remote server connects but then is immediately disconnected by
pricom. I see this in the /var/log/messages file:

Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295 uid=181
gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
exe="/var/qmail/bin/qmail-smtpd" sig=11
Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0 ip
000000000040a3b0 sp 00007ffc8d185718 error 4 in
qmail-smtpd[400000+10000]

- not sure where to go from here . .

Thanks,

Phil.

--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
Shepherd,


On 2015-06-18 02:20, Shepherd Nhongo wrote:
> increase the softlimit and that should clear out this error.
>
> exec /usr/local/bin/softlimit -m 2000000


? - if you look below at the configuration I posted originally it is
already set at 64000000 . .

Thanks anyway,

Phil.


> On Wed, Jun 17, 2015 at 4:29 PM, Philip Rhoades <phil@pricom.com.au>
> wrote:
>
>> Kai,
>>
>> On 2015-06-16 00:31, K. Peter wrote:
>> On 2015-06-15 11:38, Philip Rhoades wrote:
>> Kai,
>>
>> On 2015-06-14 19:03, K. Peter wrote:
>> Minor version eQmail 1.08.1 is released and available here:
>>
>> ftp://ftp.dyndn.es/eqmail-1.08.1.tgz [1]
>>
>> Checksums:
>>
>> md5: 633b7793e44589395535446464fb4de0
>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5 [2])
>>
>> sha256:
>> 326739d0be31b246d4262c6773f3a01ecf4a0d0d6a5f144ea5fa07db56264911
>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256 [3])
>>
>> This is a bugfix release. Through packaging of eQmail-1.08 round
>> about
>> 6 weeks ago, there came a patch with development code in. This
>> causes
>> that qmail-remote didn't work correctly. Do no longer use package
>> eQmail-1.08.tgz. Sorry for inconvenience.
>>
>> My (weak) online documentation is still at
>> https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08 [4]
>>
>> I am just about to move my server from Fedora 21 to 22 (x86_64) so
>> this would be good timing to test out eQmail to see if it suits my
>> setup. I make use of GreyLite (which is no longer supported) and
>> my
>> own Ruby spam script that is called via qmail-qfilter. I show bits
>> of
>> relevant files below - can you see any issue with using my setup
>> with
>> eQmail?
>>
>> /var/qmail/bin/qmail-queue is renamed to
>> /var/qmail/bin/qmail-queue.old
>>
>> In qmail-qfilter.c there is:
>>
>> #define QMAIL_QUEUE "/var/qmail/bin/qmail-queue.old"
>>
>> so if the filter scipt fails for some reason, the mail falls
>> through
>> to the normal qmail-queue.
>> I would expect if this was working correctly then there should be
>> no issue with eqmail. But I don't use
>> qmail-qfilter/spamassassin/greylite.
>>
>> /var/qmail/bin/qmail-queue:
>>
>> !/bin/sh
>>
>> export LD_LIBRARY_PATH=/usr/local/bglibs/lib:$LD_LIBRARY_PATH
>> export LC_CTYPE="en_US.UTF-8"
>> exec /var/qmail/bin/qmail-qfilter /var/qmail/bin/srejector2.rb
>>
>> /var/qmail/supervise/qmail-smtpd/run:
>>
>> #!/bin/sh
>>
>> QMAILDUID=`id -u qmaild`
>> NOFILESGID=`id -g qmaild`
>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>> LOCAL=`head -1 /var/qmail/control/me`
>>
>> if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
>> "$LOCAL" ]; then
>> echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
>> echo /var/qmail/supervise/qmail-smtpd/run
>> exit 1
>> fi
>>
>> if [ ! -f /var/qmail/control/rcpthosts ]; then
>> echo "No /var/qmail/control/rcpthosts!"
>> echo "Refusing to start SMTP listener because it'll create an
>> open relay"
>> exit 1
>> fi
>>
>> exec /usr/local/bin/softlimit -m 64000000
>> /usr/local/bin/tcpserver -v -R -H -l "$LOCAL"
>> -x /etc/tcp.smtp.cdb -c "$MAXSMTPD"
>> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp
>> /usr/local/bin/greylite
>> /var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log
>> This looks good for me on the first view too. And if the last 2
>> lines are working then there should be no issue. Nevertheless some
>> unexpected things can happen always.
>>
>> Thanks,
>>
>> Phil.
>
> The qmail-queue.c of my sources is only affected through the
> big-todo-patch directly. In case something goes wrong please let me
> know. Maybe spamdyke can be an alternative for
> greylisting/spamfiltering than.
>
> I left out all the greylite and qmail-qfilter stuff to begin with on
> the new Fedora 22 server and got to the stage where I could send a
> mail on the local server and have it delivered to the user - however
> there is a problem with getting external mail delivered. I can see
> from tcpdump that connections are being attempted but a test with:
>
> telnet pricom.com.au [5] 25
>
> from a remote server connects but then is immediately disconnected by
> pricom. I see this in the /var/log/messages file:
>
> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295 uid=181
> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
> exe="/var/qmail/bin/qmail-smtpd" sig=11
> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0 ip
> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
> qmail-smtpd[400000+10000]
>
> - not sure where to go from here . .
>
> Thanks,
>
> Phil.
>
> --
> Philip Rhoades
>
> PO Box 896
> Cowra NSW 2794
> Australia
> E-mail: phil@pricom.com.au
>
> --
>
> Shepherd Nhongo
>
> Do not Queue mail with SENDMAIL, send mail with QMAIL
>
> Botswana # +267 744 760 40
> Zimbabwe # +263 772 688 072
>
>
> Links:
> ------
> [1] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz
> [2] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5
> [3] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256
> [4] https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08
> [5] http://pricom.com.au

--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
> I left out all the greylite and qmail-qfilter stuff to begin with on
> the new Fedora 22 server and got to the stage where I could send a
> mail on the local server and have it delivered to the user - however
> there is a problem with getting external mail delivered. I can see
> from tcpdump that connections are being attempted but a test with:
>
> telnet pricom.com.au 25
>
> from a remote server connects but then is immediately disconnected by
> pricom. I see this in the /var/log/messages file:
>
> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295 uid=181
> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
> exe="/var/qmail/bin/qmail-smtpd" sig=11
> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0 ip
> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
> qmail-smtpd[400000+10000]
>
> - not sure where to go from here . .
>
> Thanks,
>
> Phil.

This is strange. I need a bit more info. Is it on a 32Bit or 64bit
System?
I did the "telnet to pricom.com.au 25" and get

$ telnet pricom.com.au 25
Trying 110.142.211.14...
Connected to pricom.com.au.
Escape character is '^]'.
220 pricom.com.au ESMTP
ehlo
250-⁠pricom.com.au
250-⁠PIPELINING
250 8BITMIME
Connection closed by foreign host.

It disconnects after a few seconds. Maybe because latency.
Do you see anything in your logs? Especially in log of qmail-⁠smtpd?

Assuming it is plain eQmail-1.08.1 with ucspi-tcp-0.88. Could you
increase
the softlimit (dramatically)? Could you run it without the softlimit
tool too? Could you send me your run file?

Otherwise what's your kernel version? What says gcc -⁠v?

Maybe you can go through these threads:

http://www.gossamer-threads.com/lists/qmail/users/138469
http://www.gossamer-threads.com/lists/qmail/users/112310

thanks and regards
Kai
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
Kai,


On 2015-06-18 03:18, K. Peter wrote:
>>
>> I left out all the greylite and qmail-qfilter stuff to begin with on
>> the new Fedora 22 server and got to the stage where I could send a
>> mail on the local server and have it delivered to the user - however
>> there is a problem with getting external mail delivered. I can see
>> from tcpdump that connections are being attempted but a test with:
>>
>> telnet pricom.com.au 25
>>
>> from a remote server connects but then is immediately disconnected by
>> pricom. I see this in the /var/log/messages file:
>>
>> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295 uid=181
>> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
>> exe="/var/qmail/bin/qmail-smtpd" sig=11
>> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0 ip
>> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
>> qmail-smtpd[400000+10000]
>>
>> - not sure where to go from here . .
>>
>> Thanks,
>>
>> Phil.
>
> This is strange. I need a bit more info. Is it on a 32Bit or 64bit
> System?


Fedora 22 x86_64.


> I did the "telnet to pricom.com.au 25" and get
>
> $ telnet pricom.com.au 25
> Trying 110.142.211.14...
> Connected to pricom.com.au.
> Escape character is '^]'.
> 220 pricom.com.au ESMTP
> ehlo
> 250-pricom.com.au
> 250-PIPELINING
> 250 8BITMIME
> Connection closed by foreign host.


That result is because I have rebooted on Fedora 21 already so I can
keep working . .


> It disconnects after a few seconds. Maybe because latency.
> Do you see anything in your logs? Especially in log of qmail-smtpd?


0 bytes in all the /var/log/qmail/smtpd/* files.


> Assuming it is plain eQmail-1.08.1 with ucspi-tcp-0.88.


Correct.


> Could you increase
> the softlimit (dramatically)?


On the other note I posted to the list in response to someone else
suggesting the same thing - it was already 64*10^6 . . you mean more
than that?


> Could you run it without the softlimit
> tool too?


Do you mean just take out the reference to the softlimit?


> Could you send me your run file?


I put that in the original mail - here it is again (the only difference
from my current version is that I have taken out the greylite stuff):

#!/bin/sh

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

if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
"$LOCAL" ]; then
echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
echo /var/qmail/supervise/qmail-smtpd/run
exit 1
fi

if [ ! -f /var/qmail/control/rcpthosts ]; then
echo "No /var/qmail/control/rcpthosts!"
echo "Refusing to start SMTP listener because it'll create an open
relay"
exit 1
fi

exec /usr/local/bin/softlimit -m 64000000 \
/usr/local/bin/tcpserver -v -R -H -l "$LOCAL" \
-x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
/var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log



> Otherwise what's your kernel version? What says gcc -v?


kernel-4.0.2-300.fc22-x86_64

gcc-5.1.1-3.fc22-x86_64


> Maybe you can go through these threads:
>
> http://www.gossamer-threads.com/lists/qmail/users/138469
> http://www.gossamer-threads.com/lists/qmail/users/112310


OK, I will have a look.

Thanks,

Phil.
--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
Shepherd,


On 2015-06-18 05:08, Shepherd Nhongo wrote:
> Can you check if your SELINUX is on ? What mode is it running ?
>
> Turn it off and check if you still receive those errors.


It was already off (disabled).

Thanks,

Phil.


> On Wed, Jun 17, 2015 at 8:17 PM, Philip Rhoades <phil@pricom.com.au>
> wrote:
>
>> Shepherd,
>>
>> On 2015-06-18 03:39, Shepherd Nhongo wrote:
>>
>>> Yes i noticed that but 64000000 is a little too much. Maybe
>>> 5000000
>>> would be much better .
>>
>> I am not sure what you mean - if it is segfaulting at 64*10^6 - why
>> is it going to be any better at something less? Years ago I had to
>> keep increasing it to get over these sort of problems - why would
>> reducing it now help?
>>
>> Thanks,
>>
>> Phil.
>>
>> On Wed, Jun 17, 2015 at 7:02 PM, Philip Rhoades
>> <phil@pricom.com.au>
>> wrote:
>>
>> Shepherd,
>>
>> On 2015-06-18 02:20, Shepherd Nhongo wrote:
>>
>> increase the softlimit and that should clear out this error.
>>
>> exec /usr/local/bin/softlimit -m 2000000
>>
>> ? - if you look below at the configuration I posted originally it
>> is already set at 64000000 . .
>>
>> Thanks anyway,
>>
>> Phil.
>>
>> On Wed, Jun 17, 2015 at 4:29 PM, Philip Rhoades
>> <phil@pricom.com.au>
>> wrote:
>>
>> Kai,
>>
>> On 2015-06-16 00:31, K. Peter wrote:
>> On 2015-06-15 11:38, Philip Rhoades wrote:
>> Kai,
>>
>> On 2015-06-14 19:03, K. Peter wrote:
>> Minor version eQmail 1.08.1 is released and available here:
>>
>> ftp://ftp.dyndn.es/eqmail-1.08.1.tgz [1] [1] [1]
>>
>> Checksums:
>>
>> md5: 633b7793e44589395535446464fb4de0
>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5 [2] [2] [2])
>>
>> sha256:
>> 326739d0be31b246d4262c6773f3a01ecf4a0d0d6a5f144ea5fa07db56264911
>> (ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256 [3] [3] [3])
>>
>> This is a bugfix release. Through packaging of eQmail-1.08 round
>> about
>> 6 weeks ago, there came a patch with development code in. This
>> causes
>> that qmail-remote didn't work correctly. Do no longer use package
>> eQmail-1.08.tgz. Sorry for inconvenience.
>>
>> My (weak) online documentation is still at
>> https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08 [4]
>> [4]
>> [4]
>>
>> I am just about to move my server from Fedora 21 to 22 (x86_64) so
>> this would be good timing to test out eQmail to see if it suits my
>> setup. I make use of GreyLite (which is no longer supported) and
>> my
>> own Ruby spam script that is called via qmail-qfilter. I show bits
>> of
>> relevant files below - can you see any issue with using my setup
>> with
>> eQmail?
>>
>> /var/qmail/bin/qmail-queue is renamed to
>> /var/qmail/bin/qmail-queue.old
>>
>> In qmail-qfilter.c there is:
>>
>> #define QMAIL_QUEUE "/var/qmail/bin/qmail-queue.old"
>>
>> so if the filter scipt fails for some reason, the mail falls
>> through
>> to the normal qmail-queue.
>> I would expect if this was working correctly then there should be
>> no issue with eqmail. But I don't use
>> qmail-qfilter/spamassassin/greylite.
>>
>> /var/qmail/bin/qmail-queue:
>>
>> !/bin/sh
>>
>> export LD_LIBRARY_PATH=/usr/local/bglibs/lib:$LD_LIBRARY_PATH
>> export LC_CTYPE="en_US.UTF-8"
>> exec /var/qmail/bin/qmail-qfilter /var/qmail/bin/srejector2.rb
>>
>> /var/qmail/supervise/qmail-smtpd/run:
>>
>> #!/bin/sh
>>
>> QMAILDUID=`id -u qmaild`
>> NOFILESGID=`id -g qmaild`
>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>> LOCAL=`head -1 /var/qmail/control/me`
>>
>> if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
>> "$LOCAL" ]; then
>> echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
>> echo /var/qmail/supervise/qmail-smtpd/run
>> exit 1
>> fi
>>
>> if [ ! -f /var/qmail/control/rcpthosts ]; then
>> echo "No /var/qmail/control/rcpthosts!"
>> echo "Refusing to start SMTP listener because it'll create an
>> open relay"
>> exit 1
>> fi
>>
>> exec /usr/local/bin/softlimit -m 64000000
>> /usr/local/bin/tcpserver -v -R -H -l "$LOCAL"
>> -x /etc/tcp.smtp.cdb -c "$MAXSMTPD"
>> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp
>> /usr/local/bin/greylite
>> /var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log
>> This looks good for me on the first view too. And if the last 2
>> lines are working then there should be no issue. Nevertheless some
>> unexpected things can happen always.
>>
>> Thanks,
>>
>> Phil.
>>
>> The qmail-queue.c of my sources is only affected through the
>> big-todo-patch directly. In case something goes wrong please let
>> me
>> know. Maybe spamdyke can be an alternative for
>> greylisting/spamfiltering than.
>>
>> I left out all the greylite and qmail-qfilter stuff to begin with
>> on
>> the new Fedora 22 server and got to the stage where I could send a
>> mail on the local server and have it delivered to the user -
>> however
>> there is a problem with getting external mail delivered. I can see
>> from tcpdump that connections are being attempted but a test with:
>>
>> telnet pricom.com.au [5] [5] [5] 25
>>
>> from a remote server connects but then is immediately disconnected
>> by
>> pricom. I see this in the /var/log/messages file:
>>
>> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295
>> uid=181
>> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
>> exe="/var/qmail/bin/qmail-smtpd" sig=11
>> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0
>> ip
>> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
>> qmail-smtpd[400000+10000]
>>
>> - not sure where to go from here . .
>>
>> Thanks,
>>
>> Phil.
>>
>> --
>> Philip Rhoades
>>
>> PO Box 896
>> Cowra NSW 2794
>> Australia
>> E-mail: phil@pricom.com.au
>>
>> --
>>
>> Shepherd Nhongo
>>
>> Do not Queue mail with SENDMAIL, send mail with QMAIL
>>
>> Botswana # +267 744 760 40 [6]
>> Zimbabwe # +263 772 688 072 [7]
>>
>> Links:
>> ------
>> [1] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz [1] [1]
>> [2] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5 [2] [2]
>> [3] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256 [3] [3]
>> [4] https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08
>> [4]
>> [4]
>> [5] http://pricom.com.au [5] [5]
>
> --
> Philip Rhoades
>
> PO Box 896
> Cowra NSW 2794
> Australia
> E-mail: phil@pricom.com.au
>
> --
>
> Shepherd Nhongo
>
> Do not Queue mail with SENDMAIL, send mail with QMAIL
>
> Botswana # +267 744 760 40 [6]
> Zimbabwe # +263 772 688 072 [7]
>
> Links:
> ------
> [1] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz [1]
> [2] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5 [2]
> [3] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256 [3]
> [4] https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08 [4]
> [5] http://pricom.com.au [5]
> [6] tel:%2B267%20744%20760%2040
> [7] tel:%2B263%20772%20688%20072
>
> --
> Philip Rhoades
>
> PO Box 896
> Cowra NSW 2794
> Australia
> E-mail: phil@pricom.com.au
>
> --
>
> Shepherd Nhongo
>
> Do not Queue mail with SENDMAIL, send mail with QMAIL
>
> Botswana # +267 744 760 40
> Zimbabwe # +263 772 688 072
>
>
> Links:
> ------
> [1] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz
> [2] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.md5
> [3] ftp://ftp.dyndn.es/eqmail-1.08.1.tgz.sha256
> [4] https://blog.dyndn.es/doku.php?id=blog:2014:10:18_eqmail_1.08
> [5] http://pricom.com.au
> [6] tel:%2B267%20744%20760%2040
> [7] tel:%2B263%20772%20688%20072

--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
On 2015-06-17 20:12, Philip Rhoades wrote:
> Kai,
>
>
> On 2015-06-18 03:18, K. Peter wrote:
>>>
>>> I left out all the greylite and qmail-qfilter stuff to begin with on
>>> the new Fedora 22 server and got to the stage where I could send a
>>> mail on the local server and have it delivered to the user - however
>>> there is a problem with getting external mail delivered. I can see
>>> from tcpdump that connections are being attempted but a test with:
>>>
>>> telnet pricom.com.au 25
>>>
>>> from a remote server connects but then is immediately disconnected by
>>> pricom. I see this in the /var/log/messages file:
>>>
>>> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295 uid=181
>>> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
>>> exe="/var/qmail/bin/qmail-smtpd" sig=11
>>> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0 ip
>>> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
>>> qmail-smtpd[400000+10000]
>>>
>>> - not sure where to go from here . .
>>>
>>> Thanks,
>>>
>>> Phil.
>>
>> This is strange. I need a bit more info. Is it on a 32Bit or 64bit
>> System?
>
>
> Fedora 22 x86_64.
Ok.
>
>
>> I did the "telnet to pricom.com.au 25" and get
>>
>> $ telnet pricom.com.au 25
>> Trying 110.142.211.14...
>> Connected to pricom.com.au.
>> Escape character is '^]'.
>> 220 pricom.com.au ESMTP
>> ehlo
>> 250-pricom.com.au
>> 250-PIPELINING
>> 250 8BITMIME
>> Connection closed by foreign host.
>
>
> That result is because I have rebooted on Fedora 21 already so I can
> keep working . .
But it disconnects to early - I would expect a "250 AUTH ..." at least!?
On the other side it confuses me - above you wrote "Fedora 22 x86_64",
here "rebooted on Fedora 21" ...
Does it mean that eQmail-1.08.1 works on Fedora 21 w/o the segfault? Or
what version of qmail does run?
Also an
openssl s_client -starttls smtp -connect pricom.com.au:25
didn't work.
Main response is:
CONNECTED(00000003)
didn't found starttls in server response, try anyway...
...

However, I would urgently suggest to have a system with eQmail-1.08.1
(and Fedora 22) up and running for further debugging. Otherwise there
could be nothing in the logs.
>
>
>> It disconnects after a few seconds. Maybe because latency.
>> Do you see anything in your logs? Especially in log of qmail-smtpd?
>
>
> 0 bytes in all the /var/log/qmail/smtpd/* files.
>
>
> On the other note I posted to the list in response to someone else
> suggesting the same thing - it was already 64*10^6 . . you mean more
> than that?
>
Yes, give it a try.
>
>> Could you run it without the softlimit
>> tool too?
>
>
> Do you mean just take out the reference to the softlimit?
>
Remove the softlimit completely from the run file.
>
>> Could you send me your run file?
>
>
> I put that in the original mail - here it is again (the only
> difference from my current version is that I have taken out the
> greylite stuff):
>
> #!/bin/sh
>
> QMAILDUID=`id -u qmaild`
> NOFILESGID=`id -g qmaild`
> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
> LOCAL=`head -1 /var/qmail/control/me`
>
> if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
> "$LOCAL" ]; then
> echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
> echo /var/qmail/supervise/qmail-smtpd/run
> exit 1
> fi
>
> if [ ! -f /var/qmail/control/rcpthosts ]; then
> echo "No /var/qmail/control/rcpthosts!"
> echo "Refusing to start SMTP listener because it'll create an open
> relay"
> exit 1
> fi
>
> exec /usr/local/bin/softlimit -m 64000000 \
> /usr/local/bin/tcpserver -v -R -H -l "$LOCAL" \
> -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
> /var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log
>
I wanted to make sure that it there is no critical change. Look so far
ok to me. Maybe you can do some more tests with the tcpserver opts -RHl?
Nevertheless the last line looks critical for me - is anything in
greylite.log?
>
>
>> Otherwise what's your kernel version? What says gcc -v?
>
>
> kernel-4.0.2-300.fc22-x86_64
>
> gcc-5.1.1-3.fc22-x86_64
>
You are using really actual versions. I did test it with kernel 2.6.x
and 3.x and gcc 4.x only.
>
>> Maybe you can go through these threads:
>>
>> http://www.gossamer-threads.com/lists/qmail/users/138469
>> http://www.gossamer-threads.com/lists/qmail/users/112310
>
>
> OK, I will have a look.
>
> Thanks,
>
> Phil.
It seems that the "segfault" happens on Fedora bases distros only. Again
to the list: there were a number of downloads of eqmail-1.08.1 - please
give any feedback!
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
Kai,


On 2015-06-18 06:03, K. Peter wrote:
> On 2015-06-17 20:12, Philip Rhoades wrote:
>> Kai,
>>
>>
>> On 2015-06-18 03:18, K. Peter wrote:
>>>>
>>>> I left out all the greylite and qmail-qfilter stuff to begin with on
>>>> the new Fedora 22 server and got to the stage where I could send a
>>>> mail on the local server and have it delivered to the user - however
>>>> there is a problem with getting external mail delivered. I can see
>>>> from tcpdump that connections are being attempted but a test with:
>>>>
>>>> telnet pricom.com.au 25
>>>>
>>>> from a remote server connects but then is immediately disconnected
>>>> by
>>>> pricom. I see this in the /var/log/messages file:
>>>>
>>>> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295
>>>> uid=181
>>>> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
>>>> exe="/var/qmail/bin/qmail-smtpd" sig=11
>>>> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0
>>>> ip
>>>> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
>>>> qmail-smtpd[400000+10000]
>>>>
>>>> - not sure where to go from here . .
>>>>
>>>> Thanks,
>>>>
>>>> Phil.
>>>
>>> This is strange. I need a bit more info. Is it on a 32Bit or 64bit
>>> System?
>>
>>
>> Fedora 22 x86_64.
> Ok.
>>
>>
>>> I did the "telnet to pricom.com.au 25" and get
>>>
>>> $ telnet pricom.com.au 25
>>> Trying 110.142.211.14...
>>> Connected to pricom.com.au.
>>> Escape character is '^]'.
>>> 220 pricom.com.au ESMTP
>>> ehlo
>>> 250-pricom.com.au
>>> 250-PIPELINING
>>> 250 8BITMIME
>>> Connection closed by foreign host.
>>
>>
>> That result is because I have rebooted on Fedora 21 already so I can
>> keep working . .


> But it disconnects to early - I would expect a "250 AUTH ..." at
> least!?
> On the other side it confuses me - above you wrote "Fedora 22 x86_64",
> here "rebooted on Fedora 21" ...
> Does it mean that eQmail-1.08.1 works on Fedora 21 w/o the segfault?
> Or what version of qmail does run?


As I said in my first post - I am currently using:

- netqmail
- greylite
- qmail-qfilter + my Ruby script

on Fedora 21 x86_64 - which is working fine. I am attempting to get a
standard install of eQmail going on Fedora 22 x86_64 (on a different HD
but the same machine) but have this segfault problem. To enable me to
keep working, I have rebooted on F21 until someone can tell me why I
might be getting the segfaulting on F22.


> Also an
> openssl s_client -starttls smtp -connect pricom.com.au:25
> didn't work.
> Main response is:
> CONNECTED(00000003)
> didn't found starttls in server response, try anyway...
> ...


It doesn't matter - I am on the F21 working system at the moment.


> However, I would urgently suggest to have a system with eQmail-1.08.1
> (and Fedora 22) up and running for further debugging. Otherwise there
> could be nothing in the logs.


Unless there is some useful suggestion about a probable explanation and
how to fix it on F22 . . I have to get some work done on F21 and it is
not really convenient to set up on another machine when I have to come
back to the current one anyway. I have supplied all the log stuff that
had any errors that there were for F22.


>>> It disconnects after a few seconds. Maybe because latency.
>>> Do you see anything in your logs? Especially in log of qmail-smtpd?
>>
>>
>> 0 bytes in all the /var/log/qmail/smtpd/* files.
>>
>>
>> On the other note I posted to the list in response to someone else
>> suggesting the same thing - it was already 64*10^6 . . you mean more
>> than that?
>> Yes, give it a try.
>>
>>> Could you run it without the softlimit
>>> tool too?
>>
>>
>> Do you mean just take out the reference to the softlimit?
>> Remove the softlimit completely from the run file.


You need to be more careful with you inline responses! - the line above
is your response but it looks like mine because you didn't remove the
">>" . . I will try removing the softlimit completely when I have time
to reboot and test F22 again.


>>> Could you send me your run file?
>>
>>
>> I put that in the original mail - here it is again (the only
>> difference from my current version is that I have taken out the
>> greylite stuff):
>>
>> #!/bin/sh
>>
>> QMAILDUID=`id -u qmaild`
>> NOFILESGID=`id -g qmaild`
>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>> LOCAL=`head -1 /var/qmail/control/me`
>>
>> if [. -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z
>> "$LOCAL" ]; then
>> echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
>> echo /var/qmail/supervise/qmail-smtpd/run
>> exit 1
>> fi
>>
>> if [ ! -f /var/qmail/control/rcpthosts ]; then
>> echo "No /var/qmail/control/rcpthosts!"
>> echo "Refusing to start SMTP listener because it'll create an open
>> relay"
>> exit 1
>> fi
>>
>> exec /usr/local/bin/softlimit -m 64000000 \
>> /usr/local/bin/tcpserver -v -R -H -l "$LOCAL" \
>> -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
>> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
>> /var/qmail/bin/qmail-smtpd 2> /var/log/greylite.log

>> I wanted to make sure that it there is no critical change. Look so far
>> ok to me. Maybe you can do some more tests with the tcpserver opts
>> -RHl?
> Nevertheless the last line looks critical for me - is anything in
> greylite.log?


Again you have problems with inline responses and not removing ">>".
There were no errors in the greylite.log .


>>> Otherwise what's your kernel version? What says gcc -v?
>>
>>
>> kernel-4.0.2-300.fc22-x86_64
>>
>> gcc-5.1.1-3.fc22-x86_64
>> You are using really actual versions. I did test it with kernel 2.6.x
>> and 3.x and gcc 4.x only.
>>
>>> Maybe you can go through these threads:
>>>
>>> http://www.gossamer-threads.com/lists/qmail/users/138469
>>> http://www.gossamer-threads.com/lists/qmail/users/112310
>>
>>
>> OK, I will have a look.
>>
>> Thanks,
>>
>> Phil.


> It seems that the "segfault" happens on Fedora bases distros only.
> Again to the list: there were a number of downloads of eqmail-1.08.1 -
> please give any feedback!


OK, has anybody got this working with Fedora 22 x86_64 or RH?

Thanks,

Phil.
--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au
Re: [ANNOUNCE] eQmail-1.08.1 released [ In reply to ]
On 2015-06-17 22:37, Philip Rhoades wrote:
> Kai,
>
>
> On 2015-06-18 06:03, K. Peter wrote:
>> On 2015-06-17 20:12, Philip Rhoades wrote:
>>> Kai,
>>>
>>>
>>> On 2015-06-18 03:18, K. Peter wrote:
>>>>>
>>>>> I left out all the greylite and qmail-qfilter stuff to begin with
>>>>> on
>>>>> the new Fedora 22 server and got to the stage where I could send a
>>>>> mail on the local server and have it delivered to the user -
>>>>> however
>>>>> there is a problem with getting external mail delivered. I can see
>>>>> from tcpdump that connections are being attempted but a test with:
>>>>>
>>>>> telnet pricom.com.au 25
>>>>>
>>>>> from a remote server connects but then is immediately disconnected
>>>>> by
>>>>> pricom. I see this in the /var/log/messages file:
>>>>>
>>>>> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295
>>>>> uid=181
>>>>> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
>>>>> exe="/var/qmail/bin/qmail-smtpd" sig=11
>>>>> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0
>>>>> ip
>>>>> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
>>>>> qmail-smtpd[400000+10000]
>>>>>
>>>>> - not sure where to go from here . .
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Phil.
>>>>

Hi Phil,

did you create the file /var/qmail/control/smtpplugins? It should have
the content:


# qmail-spp configuration file

# plugins to execute on client's connection
[connection]

# plugins to execute on HELO/EHLO commands
[helo]

# plugins to execute on MAIL command
[mail]

# plugins to execute on RCPT command
[rcpt]

# plugins to execute on DATA command
[data]

## NOTE: use below section only if your installation supports it
# plugins to execute on AUTH command
#[auth]


It could be empty but have to exists.

As I created this file by hand always I should improve this to do it
automatically.

Kai
Re: [ANNOUNCE] eQmail-1.08.1 released - SUCCESS! [ In reply to ]
Kai,


On , K. Peter wrote:
> On 2015-06-17 22:37, Philip Rhoades wrote:
>> Kai,
>>
>>
>> On 2015-06-18 06:03, K. Peter wrote:
>>> On 2015-06-17 20:12, Philip Rhoades wrote:
>>>> Kai,
>>>>
>>>>
>>>> On 2015-06-18 03:18, K. Peter wrote:
>>>>>>
>>>>>> I left out all the greylite and qmail-qfilter stuff to begin with
>>>>>> on
>>>>>> the new Fedora 22 server and got to the stage where I could send a
>>>>>> mail on the local server and have it delivered to the user -
>>>>>> however
>>>>>> there is a problem with getting external mail delivered. I can
>>>>>> see
>>>>>> from tcpdump that connections are being attempted but a test with:
>>>>>>
>>>>>> telnet pricom.com.au 25
>>>>>>
>>>>>> from a remote server connects but then is immediately disconnected
>>>>>> by
>>>>>> pricom. I see this in the /var/log/messages file:
>>>>>>
>>>>>> Jun 18 00:11:31 localhost audit: <audit-1701> auid=4294967295
>>>>>> uid=181
>>>>>> gid=180 ses=4294967295 pid=2518 comm="qmail-smtpd"
>>>>>> exe="/var/qmail/bin/qmail-smtpd" sig=11
>>>>>> Jun 18 00:11:31 localhost kernel: qmail-smtpd[2518]: segfault at 0
>>>>>> ip
>>>>>> 000000000040a3b0 sp 00007ffc8d185718 error 4 in
>>>>>> qmail-smtpd[400000+10000]
>>>>>>
>>>>>> - not sure where to go from here . .
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Phil.
>>>>>
>
> Hi Phil,
>
> did you create the file /var/qmail/control/smtpplugins? It should have
> the content:
>
>
> # qmail-spp configuration file
>
> # plugins to execute on client's connection
> [connection]
>
> # plugins to execute on HELO/EHLO commands
> [helo]
>
> # plugins to execute on MAIL command
> [mail]
>
> # plugins to execute on RCPT command
> [rcpt]
>
> # plugins to execute on DATA command
> [data]
>
> ## NOTE: use below section only if your installation supports it
> # plugins to execute on AUTH command
> #[auth]
>
>
> It could be empty but have to exists.
>
> As I created this file by hand always I should improve this to do it
> automatically.


Yes! - that fixed the problem - many thanks!

Now that eQmail is working for me, I would like to investigate the
usefulness of the patches and how I might make better use of some of
them - but I will start another thread for that.

Regards,

Phil.
--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au