[qmailtoaster] QMT on CentOS 6? Alternatives?

[Angus McIntyre]

Reading the list archives, it looks as if QMT on CentOS 6 is more or less
at the "It won't work but you're welcome to try" stage.

Can anyone tell me exactly which parts of QMT are broken? Most of the
messages I've seen suggest that it's primarily down to issues with current
versions of PHP which, if I understand correctly, affect the web-based
admin tools rather than the core qmail stuff.

Is it possible to do a QMT install leaving out certain packages and, if
so, which ones?

I've not done a qmailtoaster install before; previously, I've used
qmailrocks, but to judge by the website (which no longer even loads
properly), QMR is pretty much dead. Are there other routes to getting a
QMT/QMR-like ecosystem up and running without too much effort?

Thanks in advance for any recommendations or insights,

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] Problems building vpopmail on CentOS 6

[Angus McIntyre]

I'm trying to build qmailtoaster on a CentOS 6 box, and I've made reasonable 
progress so far (I'll post my install notes when done, in the hope that they 
may help someone).

However, I've run up against a blocker that I don't know how to solve.

Using the install script, the build of 'vpopmail' fails with a spray of 
warnings and a linker error. Here's the relevant part:

gcc  -g -O2 -Wall   -o vchkpw  vchkpw.o md5.o hmac_md5.o libvpopmail.a 
-L/usr/lib64/mysql  -lmysqlclient -lz -lm -lcrypt 
/usr/lib64/mysql/libmysqlclient.a(charset.c.o): In function `get_charset_name':
/pb2/build/sb_0-4575859-1324066572.98/rpm/BUILD/mysql-5.5.20/mysql-5.5.20/mysys/charset.c:533:
 undefined reference to `pthread_once'
/usr/lib64/mysql/libmysqlclient.a(charset.c.o): In function 
`get_charset_number':
/pb2/build/sb_0-4575859-1324066572.98/rpm/BUILD/mysql-5.5.20/mysql-5.5.20/mysys/charset.c:522:
 undefined reference to `pthread_once'
/usr/lib64/mysql/libmysqlclient.a(charset.c.o): In function 
`get_charset_by_csname':
/pb2/build/sb_0-4575859-1324066572.98/rpm/BUILD/mysql-5.5.20/mysql-5.5.20/mysys/charset.c:644:
 undefined reference to `pthread_once'
/usr/lib64/mysql/libmysqlclient.a(charset.c.o): In function `get_charset':
/pb2/build/sb_0-4575859-1324066572.98/rpm/BUILD/mysql-5.5.20/mysql-5.5.20/mysys/charset.c:597:
 undefined reference to `pthread_once'
/usr/lib64/mysql/libmysqlclient.a(charset.c.o): In function 
`get_collation_number':

[ … snip … ]

/pb2/build/sb_0-4575859-1324066572.98/rpm/BUILD/mysql-5.5.20/mysql-5.5.20/mysys/my_thr_init.c:424:
 undefined reference to `pthread_setspecific'
/usr/lib64/mysql/libmysqlclient.a(my_thr_init.c.o): In function 
`_my_thread_var':
/pb2/build/sb_0-4575859-1324066572.98/rpm/BUILD/mysql-5.5.20/mysql-5.5.20/mysys/my_thr_init.c:429:
 undefined reference to `pthread_getspecific'
/usr/lib64/mysql/libmysqlclient.a(thr_mutex.c.o): In function 
`my_pthread_fastmutex_lock':
/pb2/build/sb_0-4575859-1324066572.98/rpm/BUILD/mysql-5.5.20/mysql-5.5.20/mysys/thr_mutex.c:481:
 undefined reference to `pthread_mutex_trylock'
collect2: ld returned 1 exit status

My reading of this is that the attempt to build 'vchkpw' is blowing up, 
possibly because … based on some Googling around for similar errors … I don't 
have '-lpthread -ldl' included in my arguments to the linker.

You will notice that I'm building against mysql-5.5.20 which was a custom 
install: the current CentOS 6 package lags behind, so I went ahead and did an 
RPM installation from the current stable distribution with:

rpm -i --replacefiles MySQL-server-5.5.20-1.linux2.6.x86_64.rpm
rpm -i MySQL-client-5.5.20-1.linux2.6.x86_64.rpm 
rpm -i MySQL-devel-5.5.20-1.linux2.6.x86_64.rpm 
rpm -i MySQL-shared-5.5.20-1.linux2.6.x86_64.rpm 

There is a 'libpthread.so.0' library in '/lib64', incidentally.

Can anyone suggest a way that I can work around this and get the compiler and 
linker to find the correct libraries?

Alternatively, is there another way to build the required components of 
vpopmail that doesn't use the QMT RPMs?

Thanks in advance for any help,

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.

  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] How to pass library arguments to rpmbuild?

[Angus McIntyre]

I'm trying to build qmailtoaster on a CentOS 5.7 build, and the
vpopmail-toaster build is failing.

The exact command that's breaking it is:

   gcc  -g -O2 -Wall   -o vchkpw  vchkpw.o md5.o hmac_md5.o libvpopmail.a
-L/usr/lib64/mysql  -lmysqlclient -lz -lm -lcrypt

which throws lots of undefined reference errors related to 'pthread'
(POSIX thread library) before dying in the linker.

If I do:

   gcc  -g -O2 -Wall   -o vchkpw  vchkpw.o md5.o hmac_md5.o libvpopmail.a
-L/usr/lib64/mysql  -lmysqlclient -lz -lm -lcrypt -lpthread -ldl

the command completes without error.

Is there a way that I can force "-lpthread -ldl" to be passed to 'gcc' at
that point? Or can I edit the RPM spec file to add those arguments
somehow?

Thanks in advance for any suggestions

Angus




-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] qtp-newmodel breaks on SpamAssassin install on CentOS 5.7

[Angus McIntyre]

I've worked past most of my previous problems trying to install QmailToaster 
(many of which seem to have been associated with making changes to the CentOS 
base install - apparently, Honey Badger don't like that). However, I've come up 
against another blocker.

While building spamassassin-toaster, the build errors out with:

+ chmod 755 '/var/tmp/spamassassin-toaster-root/usr/bin/*' 
chmod: cannot access `/var/tmp/spamassassin-toaster-root/usr/bin/*': No 
such file or directory error: 
Bad exit status from /var/tmp/rpm-tmp.28381 (%install) 

Checking on the sandbox, I see that there is indeed nothing at that path.

I see that this question has been asked before, but - as far as I can tell from 
the mailing lists - there's no resolution to the issue.

Looking at the full log, there are no obvious build errors (a few deprecated 
warnings, but that's all).

My guess is that this might be because I have done a source install of Perl to 
get a current version of Perl.

Is there any way that I can work around this? Can I skip the 
spamassassin-toaster component and then build it manually somehow later? Can I 
retrofit a toaster built without SA with a straight source-install of 
SpamAssassin?

Failing that, does anyone know of a source for a current Perl RPM?  (I know 
that we're not supposed to "play the numbers game" with CentOS", but Perl 5.8.8 
is not even maintained any longer). My experience has been that a lot of 
problems with QMT - and believe me, I _have_ had a lot of problems with QMT - 
can be resolved by doing things the CentOS way, with yum installs rather than 
source builds.

Thanks for any help,

Angus
-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.

  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] CentOS and Perl versions

[Angus McIntyre]

Dan McAllister wrote:
> If you want "bleeding edge" support for packages, you shouldn't be
> running CentOS because that runs counter to the very principles of that
> Linux Distribution.

So I have discovered.

Yes, the fault is mine because I didn't read the label on the tin that
said "Just do it our way and everyone will be happy". I'm actually
upgrading from a CentOS 5.2 system which - not knowing any better - I
filled with a whole raft of source-installed software. That ran quite
happily for years, with no mysterious conflicts, so I was fooled into
thinking that what I was doing was OK. My experience of trying to install
QMT on my new box has set me straight on that score in no uncertain terms.

> NOTE: Its not fair to say that Perl 5.8.8 is "unmaintained" -- Perl 5.8
> is the "supported" version of Perl for RHEL 5 (the CentOS upline) will
> not likely upgrade (heck, CentOS 6 only takes Perl to 5.10) -- and it
> will continue to be "maintained" (by Red Hat, if no one else) until 2017!

"unmaintained" is perhaps the wrong word, but it's end-of-life'd and
unsupported by the Perl porters. By any standards, it is a very very old
Perl.

Anyway, this is somewhat off-topic for QMT, so perhaps the lesson to take
home is:

Do things the CentOS way, or CentOS will _hurt_ you.

and this applies to installing QMT as much as (or more than) doing
anything else on CentOS.

Thanks for your help,

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Backscatter Block Listing

[Angus McIntyre]

Eric Shubert wrote:
> ... Authenticated users on port 25 bypass
> all of spamdyke's filters, so my guess at this point is that one (or
> more) of your users' login credentials have been compromised. Have a
> look at your smtp log, and see if you can determine which account(s) is
> being authenticated against with the bad emails.

Do the back-scattered messages necessarily have to originate from your
server?

I've seen plenty of bounce messages that were sent to me simply because
the spammer had forged an email address in the 'From' line or envelope of
the message. Often, the address is not even an address that exists, but
just one of the many nonsense addresses that not-too-smart spamware will
extract from message IDs, mangled versions of real addresses, or fake
addresses forged by other spammers.

There are a lot of hosts out there that will still send NDRs to the
envelope sender or 'From' address even though an SPF check ought to tell
them that that address should never be sending mail from
some-hacked-pc.bigtelco.ru.

Angus





-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] QMT CentOS 5.7/64 - submission port "cannot allocate memory"

[Angus McIntyre]

I have a qmailtoaster install running on a 64-bit CentOS 5.7.

As far as I can tell, almost all of it works correctly - mail is flowing
in and out successfully.

However, when I try to submit a message on port 587, the connection
closes. The log shows:

2012-02-14 22:26:16.919911500 tcpserver: ok 4502
xx.nameofmyserver.com:xx.xx.xx.xx:587 :xx.xx.xx.xx::50888
2012-02-14 22:26:16.920568500 /var/qmail/bin/qmail-smtpd: error while
loading shared libraries: libgcc_s.so.1: failed to map segment from shared
object: Cannot allocate memory
2012-02-14 22:26:16.920737500 tcpserver: end 4502 status 32512

I have tried raising the softlimit in
'/var/qmail/supervise/submission/run' and restarting qmail (I raised the
limit to 25600), but I still get the error.

Can anyone suggest anything else I can try in order to fix this?

Thanks,

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] QMT CentOS 5.7/64 - submission port "cannot allocate memory"

[Angus McIntyre]

Thanks for your response.

Unfortunately, even with a softlimit of 102400, it still gives the
same error.

Can you think of anything else I could try?

Angus


Délsio Cabá wrote:
> Hi,
> Try to raise even more.
> I had this issue also and I just raised the limit.
>
> I believe this one of the reasons qmailtoaster will be distributed in rpm
> packages
>
> Regards
>
> On 15 February 2012 05:32, Angus McIntyre  wrote:
>
>> I have a qmailtoaster install running on a 64-bit CentOS 5.7.
>>
>> As far as I can tell, almost all of it works correctly - mail is flowing
>> in and out successfully.
>>
>> However, when I try to submit a message on port 587, the connection
>> closes. The log shows:
>>
>> 2012-02-14 22:26:16.919911500 tcpserver: ok 4502
>> xx.nameofmyserver.com:xx.xx.xx.xx:587 :xx.xx.xx.xx::50888
>> 2012-02-14 22:26:16.920568500 /var/qmail/bin/qmail-smtpd: error while
>> loading shared libraries: libgcc_s.so.1: failed to map segment from
>> shared
>> object: Cannot allocate memory
>> 2012-02-14 22:26:16.920737500 tcpserver: end 4502 status 32512
>>
>> I have tried raising the softlimit in
>> '/var/qmail/supervise/submission/run' and restarting qmail (I raised the
>> limit to 25600), but I still get the error.
>>
>> Can anyone suggest anything else I can try in order to fix this?
>>
>> Thanks,
>>
>> Angus
>>
>>
>>
>> -
>> Qmailtoaster is sponsored by Vickers Consulting Group (
>> www.vickersconsulting.com)
>>Vickers Consulting Group offers Qmailtoaster support and
>> installations.
>>  If you need professional help with your setup, contact them today!
>>
>> -
>> Please visit qmailtoaster.com for the latest news, updates, and
>> packages.
>>
>>  To unsubscribe, e-mail:
>> qmailtoaster-list-unsubscr...@qmailtoaster.com
>> For additional commands, e-mail:
>> qmailtoaster-list-h...@qmailtoaster.com
>>
>>
>>
>


-- 



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] QMT CentOS 5.7/64 - submission port "cannot allocate memory"

[Angus McIntyre]

Délsio Cabá wrote:
> Try to upgade gcc and recompite it again

gcc seems to be the latest approved version for CentOS. QMT was built with
that version.

I'm also having trouble with POP. The logs don't show any problems (except
for a 'status 256' response) but no mail is transferred.

When I manually run a POP session, I get:

/home/vpopmail/bin/vchkpw: error while loading shared libraries:
libresolv.so.2: failed to map segment from shared object: Cannot allocate
memory
-ERR unable to write pipe
Connection closed by foreign host.

Again, raising the softlimit on the pop3 supervisor doesn't seem to solve
this problem.

Do I need to do anything after editing the 'run' file to raise the
softlimit? I've been simply restarting qmail with 'qmailctl restart', but
perhaps something else is needed to get the changes to take effect?

Angus



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] SOLVED Re: [qmailtoaster] QMT CentOS 5.7/64 - submission port "cannot allocate memory"

[Angus McIntyre]

And the solution was ... raise the softlimit.

   "But I thought we told you to raise the softlimit?" the assembled
members of qmailtoaster-list cried with one voice.

Well, yes. You did. And so did all the four hundred archive postings on
the subject.

But the secret, boys and girls, is that you have to restart qmail. And I
did, but:

   qmailctl restart

doesn't cut it. You have to do:

   qmailctl stop
   qmailctl start

I finally figured this out when, after doing 'qmailctl restart', I then
did 'qmailctl stat' and noticed that while 'send' and 'smtp' were shown as
having been up for SMALL-NUMBER-OF-SECONDS, everything else was shown as
having been up for REALLY-BIG-NUMBER-OF-SECONDS. This made me think that
they hadn't got the message that it was time to restart.

So I stop-started the whole shebang and, mirabile dictu, 'submission' and
'pop3' and all the other things that hadn't been working suddenly started
working.

Incidentally, one really weird thing: while 'pop3' choked under the
default softlimit, 'pop3-ssl' worked flawlessly with the same limit. Go
figure.

Thanks to Délsio Cabá for helping, and thank you all (especially Jake and
Eric) for supporting qmailtoaster. Now that I think I'm almost at the end
of the things-that-can-go-wrong (many of which were the product of my own
boneheadedness), I really appreciate all the hard work you guys put in to
save me from all the things that could go wrong but didn't.

Thanks again,

Angus


Angus McIntyre wrote:
>
> Délsio Cabá wrote:
>> Try to upgade gcc and recompite it again
>
> gcc seems to be the latest approved version for CentOS. QMT was built with
> that version.
>
> I'm also having trouble with POP. The logs don't show any problems (except
> for a 'status 256' response) but no mail is transferred.
>
> When I manually run a POP session, I get:
>
> /home/vpopmail/bin/vchkpw: error while loading shared libraries:
> libresolv.so.2: failed to map segment from shared object: Cannot allocate
> memory
> -ERR unable to write pipe
> Connection closed by foreign host.
>
> Again, raising the softlimit on the pop3 supervisor doesn't seem to solve
> this problem.
>
> Do I need to do anything after editing the 'run' file to raise the
> softlimit? I've been simply restarting qmail with 'qmailctl restart', but
> perhaps something else is needed to get the changes to take effect?
>
> Angus
>
>
>
> -
> Qmailtoaster is sponsored by Vickers Consulting Group
> (www.vickersconsulting.com)
> Vickers Consulting Group offers Qmailtoaster support and
> installations.
>   If you need professional help with your setup, contact them today!
> -
>  Please visit qmailtoaster.com for the latest news, updates, and
> packages.
>
>   To unsubscribe, e-mail:
> qmailtoaster-list-unsubscr...@qmailtoaster.com
>  For additional commands, e-mail:
> qmailtoaster-list-h...@qmailtoaster.com
>
>
>


-- 



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] QMT CentOS 5.7/64 - submission port "cannot allocate memory"

[Angus McIntyre]

Johannes Weberhofer wrote:
> I have seen problems like that after replacing the server by a new one:
> When I falsely copied over the complete /home/vpopmail and /var/qmail
> directories from the old systems, I overwrote the newly compiled binaries
> on the target systems...
>
> Am 15.02.12 16:38, schrieb Dan McAllister:
>> ... have you checked to make sure your filesystem (whichever one
>> holds /tmp) isn't full?
>>
>> I tend to get these errors when I've accidentally let /var (which is the
>> home of /var/tmp -- which is the target of my sym-link /tmp) get
>> full

Thank you both for the comments.

In my case, it turned out really to be a memory issue, and raising the
softlimit and _fully_ restarting qmail took care of it.

It seems to me that these three causes/solutions all belong in the
Troubleshooting section of the wiki. Should I create a wiki login and add
them, or would someone more familiar with qmailtoaster prefer to do it?

(Incidentally, I noticed some minor wiki spam-vandalism on the
Troubleshooting page, which probably needs cleaning up at the same time).

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: QMT CentOS 5.7/64 - submission port "cannot allocate memory"

[Angus McIntyre]

Eric Shubert wrote:
> On 02/16/2012 05:28 AM, Angus McIntyre wrote:
>> It seems to me that these three causes/solutions all belong in the
>> Troubleshooting section of the wiki. Should I create a wiki login and
>> add them ...
>
> Please do this yourself if you will Angus. As you're the person who
> experienced the problem, you're probably most qualified to write about
> it. ;)

OK, I've added the sum of what I've learned (including contributions from
other posters) at:

  
http://wiki.qmailtoaster.com/index.php/Troubleshooting#Memory_allocation_errors_in_daemons

Please feel free to correct any errors, improve my style, etc.

>> (Incidentally, I noticed some minor wiki spam-vandalism on the
>> Troubleshooting page, which probably needs cleaning up at the same
>> time).
>
> Please do this as well.

I killed the ones I saw; there may be more elsewhere in the wiki.

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Authentication methods

[Angus McIntyre]

Eric Shubert wrote:
> I've been wanting for some time now to get a team of people together to
> address webmail for QMT. The horde toaster project stalled because of me
> (sorry for that).

My recollection of horde is that it's a horror to install and administer,
but I may be behind the times.

Atmail and Roundcube are pretty, but last time I looked at them (which
admittedly was a while ago) they both had some odd glitches. Maybe I
should take another look.

Squirrelmail has at least the virtue of simplicity.

Just my 2c.

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] qmailtoaster and mailman - group mismatch error

[Angus McIntyre]

I'm trying to get Mailman working with qmailtoaster on CentOS 5.7, in
order to support some existing mailman groups.

I'm following the instructions given at:

http://wiki.qmailtoaster.com/index.php/Mailman

including downloading the patched version of Mailman from the qtp-CentOS
repository.

This patched version is supposed to allow Mailman to be invoked by
'vchkpw'. However, each time that I send a test message, the 'current' log
for the 'send' daemon reports:

 Group mismatch error. Mailman expected the mail wrapper script
 to be executed as one of the following groups:
 [mail, postfix, mailman, nobody, daemon],
 but the system's mail server executed the mail script
 as group: "vchkpw".
 Try tweaking the mail server to run the script as one
 of these groups:
 [mail, postfix, mailman, nobody, daemon],
 or re-run configure providing the command line option:
 '--with-mail-gid=vchkpw'

Is it certain that the version of Mailman currently in the qtp-CentOS
repository was built with the '--with-mail-gid=vchkpw' option? I have
de-installed and re-installed to make sure that 'yum' is really getting
that version, so about the only explanation I can think of is that the
version on the repository has somehow reverted. (Or that I'm an idiot,
which is always a possibility).

Has anyone else encountered this problem or found a fix? Is my best option
to download the source RPM, hand-patch it, and rebuild it myself and, if
so, can anyone point me at detailed instructions for doing this?

Thanks,

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: qmailtoaster and mailman - group mismatch error

[Angus McIntyre]

Eric Shubert wrote:
> On 02/24/2012 07:33 AM, Angus McIntyre wrote:
>> I'm trying to get Mailman working with qmailtoaster on CentOS 5.7, in
>> order to support some existing mailman groups.
>
> Good for you, Angus. I hope I'm not the only one using mailman w/ QMT,
> but you might be the first to do this since I did.

Thanks Eric - it's extremely encouraging to know that you've been down
this road before, and I'd very much welcome any help you can give me.

>> I'm following the instructions given at:
>>
>>  http://wiki.qmailtoaster.com/index.php/Mailman
>>
>> including downloading the patched version of Mailman from the qtp-CentOS
>> repository.
>
> I hope they're right. I tried to be complete, but I may have missed
> something (always a possibility).

They look very good and comprehensive.

> I'm a little confused why this message would be showing in your qmail
> send log. I'm thinking that by the time qmail-send gets the message,
> Mailman would no longer be involved. What do you have for your outbound
> configuration settings in mailman? Is this message perhaps in one of the
> mailman logs instead?

Nope, definitely in 'send'.

> cat /var/log/qmail/send/current | grep mailman | tai64nlocal
2012-02-24 13:49:40.079484500 delivery 10082: deferral:
Group_mismatch_error._Mailman_expected_the_mail_wrapper_script_to_be/executed_as_one_of_the_following_groups:/[mail,_postfix,_mailman,_nobody,_daemon],/but_the_system's_mail_server_executed_the_mail_script_as_group:_"vchkpw"./Try_tweaking_the_mail_server_to_run_the_script_as_one_of_these_groups:/[mail,_postfix,_mailman,_nobody,_daemon],/or_re-run_configure_providing_the_command_line_option:/'--with-mail-gid=vchkpw'./

> It's been quite a while since I set one of these up, so bear with me if
> I don't see something right away.

My 'sitelist.cfg' is unaltered from the defaults; my 'mm_cfg.py' has been
changed only by changing:

   add_virtual_host(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

to

   add_virtual_host('lists.mydomain.com','lists.mydomain.com')

(where 'mydomain.com' is the domain for the virtual host handling the
mail) and then adding:

MTA = None
ALLOW_SITE_ADMIN_COOKIES = Yes
ARCHIVER_OBSCURES_EMAILADDRS = No
DEFAULT_ADMIN_NOTIFY_MCHANGES = Yes
DEFAULT_ARCHIVE_PRIVATE = 1
DEFAULT_ARCHIVE_VOLUME_FREQUENCY = 0
DEFAULT_DIGEST_VOLUME_FREQUENCY = 4
DEFAULT_REPLY_GOES_TO_LIST = 1
DEFAULT_SEND_REMINDERS = No
DEFAULT_SUBSCRIBE_POLICY = 3
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
VERP_CONFIRMATIONS = Yes
VERP_DELIVERY_INTERVAL = 1
VERP_PERSONALIZED_DELIVERIES = Yes

at the end of the file.

In '/home/vpopmail/domains/lists.mydomain.com/.qmail-default', I have:

   |/var/qmail/bin/preline /usr/bin/python
/usr/lib/mailman/Mailman/MTA/qmail-to-mailman.py

The configuration variables in the head of that file are:

  MailmanHome = "/usr/lib/mailman";
  MailmanVar = "/var/lib/mailman";
  MailmanOwner = "postmaster@localhost";

I added the domain 'lists.mydomain.com' with 'vadddomain'.

Where else should I look for possibly relevant configuration information?

Thanks again,

Angus



-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] qmailtoaster and mailman - group mismatch error

[Angus McIntyre]

On Feb 24, 2012, at 2:38 PM, Eric Shubert wrote:
> I think I understand better now. I think it's in the local delivery part 
> where the message is passed to mailman that's kicking the error.
> 
> Let me double check the spec for that config option, and rebuild the binary. 
> Then we'll know for sure. I'll let you know when it's up on QTP.

Hi Eric

Thanks for your reply.

Did you have any further ideas on this issue? Is there somewhere that I should 
start looking to try to identify the problem, or at least gather more 
evidence/information about my particular configuration?

Thanks,

Angus
-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.

  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: qmailtoaster and mailman - group mismatch error

[Angus McIntyre]

Eric Shubert wrote:
> While I rebuild the package (which arch are you running?), please try
> this:
>
> # grep vchkpw $(rpm -ql mailman)
> Binary file /etc/smrsh/mailman matches
> Binary file /usr/lib/mailman/mail/mailman matches
>
> Do you get a similar result, or nothing?

I got nothing.

I'm running on CentOS 5.7 (64-bit).

Thanks,

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] qmailtoaster and mailman - group mismatch error

[Angus McIntyre]

On Mar 2, 2012, at 5:52 PM, Eric Shubert wrote:
> I think I found your problem. There was no qtp mailman package for x86_64 
> built, so I'm guessing you had the stock version. I've built mailman-2.1.12 
> for x86_64 and put it in the qtp-CentOS repo. That should get you further. 
> Let us know how you make out.

Eric

Sorry for the delay in getting back to you.

I think that took care of it. My mailman install is up and running on … well, 
not quite all cylinders, but running, anyway.

Residual issues that I still have to clean up involve the archives (which I 
think are due to my questionable configuration) and handling of bounces, which 
I suspect may be fixed by the latest QMT release (if I'm reading between the 
lines of the release notes correctly).

Thanks very much indeed for your help,

Angus
-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.

  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: CentOS 6 install update?

[Angus McIntyre]

Eric Shubert wrote:
> Is there some sort of urgency about COS6 that I'm missing? There's
> nothing in it that I'm aware of which QMT can leverage in any way. I'm
> all ears if someone would care to fill me in.

The interest in CentOS 6 is presumably not that it provides new features
that QMT can leverage, but that it provides updated (not to say
up-to-date) versions of some other core software.

For people who are running a dedicated mailserver machine, it's easy
enough to accept that CentOS 5 is the right version to use to support QMT.
However, some people will be running boxes that serve multiple functions -
app/web servers, DNS, mail, DB, etc etc - and they may be looking to
CentOS 6 as a solution to some of their other requirements, and wishing
that QMT could be easily installed on it.

Angus


-
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
  If you need professional help with your setup, contact them today!
-
 Please visit qmailtoaster.com for the latest news, updates, and packages.
 
  To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
 For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] qtp-newmodel and non-standard packages

[Angus McIntyre]

The release of the new toaster (thank you, Eric) has made me eager to
upgrade to the latest and greatest.

But ... I have upgraded a couple of packages (ssh, php) past their
expected/approved version for CentOS 5. As a result, when I try to
install, I get:

   Missing Dependency: php-common = 5.1.6-39.el5_8 is needed by package
php-ldap-5.1.6-39.el5_8.x86_64

and

   Missing Dependency: openssh = 4.3p2-82.el5 is needed by package
openssh-askpass-4.3p2-82.el5.x86_64

and

   Error: mysql55 conflicts with mysql

I currently have:

   php-common.x86_64   5.3.15-1.w5
   openssh.x86_64  5.9p1-1

There will now be a brief pause while you all shake your heads sadly and
say "Well, that's why we told you not to do that. You have only yourself
to blame."

Which is true, but my questions are:

a. Am I totally screwed, or is there a workaround that will allow me to
install anyway? (FWIW, everything in QMT works just fine with my
non-standard system currently).

b. Is there a safe/easy way to move back to earlier versions? (this is
more a yum/rpm question than a QMT question, but I thought I'd ask
anyway).

Any helpful hints and advice gratefully received. Thanks,

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Move SPAM mail automatically

[Angus McIntyre]

Eric Broch wrote:
> On 8/20/2012 8:40 AM, Christian Ferrati wrote:
>> There is a way to set qmail-spamassin to automatically move all
>> incoming Email renamed as ***SPAM*** to a "spam folder"?
>>
> I have the users I consult use the email client--Thunderbird, etc...--to
> move all mail marked as spam (***SPAM***) to the folder of their choice.

You might like to look at procmail (http://www.procmail.org/) as a way of
providing this capability. You'll need to modify your '.qmail-' files to
pass incoming mail through procmail, and then write procmail recipes to
handle the spam. For example, my personal .qmail- file looks approximately
like:

   | preline /usr/bin/procmail -p -m /path/to/my/.procmail-rc-file

(obviously that '/path/to/my/.procmail-rc-file' isn't the real path, but
you get the idea). A simple .procmailrc file might look something like:

SHELL=/bin/sh

LOGFILE=/path/to/my/procmail-log
VERBOSE=on
CRLF="
"

MAILDIR=/path/to/my/Maildir/
SPAMDIR=/path/to/my/Maildir/.Spam/

:0:
* ^X-Subject:.*\*\*\*SPAM\*\*\*
$SPAMDIR

:0w
$MAILDIR

I'm doing this on a per-user basis, so if you want to have centralized
procmail management for all users (i.e. use a '.qmail-default' to route
everything through procmail, then somehow use variables to construct a
delivery path dynamically so that mail gets routed to the appropriate user
vpopmail directory) you may need to do something cleverer.

Procmail may be overkill for your application; there may be a simpler way
to do this using tools already in QMT, in which case Eric will be along in
a moment or two to explain it. If not, however, it's certainly something
you could look at.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Non Alpha characters in email addresses!

[Angus McIntyre]

Eric Shubert wrote:
> On 10/01/2012 08:49 AM, Tony White wrote:
>> Hi all,
>>Can someone enlighten me please?
>> I have a client that would like to have their
>> new email address like this...
>>
>> fred&ma...@mydomain.com
>>
>>Will the ampersand cause any issues please?
>
> Qmail will handle it ok ... You might run into a problem with
> qmailadmin though ...

You probably need to think not just about the qmail install on your
server, but also about 'everything else out there'. Qmail may be able to
handle incoming mail for fred&mabel, but what about all the other mail
systems in the universe, which are going to have to handle mail to/from
this user? If an & in the address will choke any of them, you have a
problem.

As far as I can see, '&' is not forbidden in the local-part of a mail
address by RFC 2822. However, it's also true that it doesn't commonly
feature in people's notions of "what's allowed in an email address". I
would not be surprised if there's something out there that is going to
have trouble with it. At a minimum, it probably won't take Fred and Mabel
very long to run into a field validation script on a webpage form that
doesn't like the ampersand.

You might consider using '+' in its place, as '+' is usually benign
(although it may sometimes have special meaning).

Of course, if it were up to me, I'd encourage Fred and Mabel to each get
their own address. No good can come of sharing mailboxes ...

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Clam and Spam Issues

[Angus McIntyre]

Mike Tirpak wrote:
>>> On 04/10/2012 14:19, Mike Tirpak wrote:
 I upgraded clamav a couple of days ago and everything went fine.
 Clamav would catch everything with a virus attached inside a zip
 file.  Over the past two days, I've gotten two emails that have zip
 files with viruses inside them.  Is there a tweek I should do with the
 new version of clam?

Clamav will catch many viruses, but is not guaranteed to catch everything.
Make sure that freshclam is able to download the latest definitions from
ClamAv.net. Check your freshclam logs in:

/var/log/clamav

to ensure that freshclam is running regularly and successfully downloading
the new definitions.

If you find a viral payload that ClamAV didn't catch, you can submit it at:

   http://www.clamav.net/lang/en/sendvirus/

 Another strange issue is spamassassin is marking mail as spam when it
 should not be.  An example is I have received emails from a person
 last week that was not spam and it went through just fine. Today, the
 same type of email from the same person got marked as spam.  I know
 that there are a lot of ways to configure spamassassin.  What can I do
 to prevent this from happening?

Take a look at the logs in:

   /var/log/qmail/spamd

Find the message ID for the wrongly-matched message, then grep through the
logs in that directory for that message. For example, if your message ID
was '1...@foo.com', you might do:

   cat `ls -t | head -10` | grep -C 2 "1...@foo.com"

(that stuff with 'ls -t' and 'head -10' is just a trick to search only the
most recent log files; change the '10' to something else if you want to
look further back.

The output should include something like:

@4000507611f819ccb6a4 [16130] info: spamd: result: Y 33 -
BAYES_99,FORGED_IMS_HTML,FORGED_MSGID_YAHOO,FORGED_MUA_IMS,FROM_LOCAL_NOVOWEL,HTML_IMAGE_ONLY_12,HTML_MESSAGE,HTML_SHORT_LINK_IMG_2,HTTP_ESCAPED_HOST,HTTP_EXCESSIVE_ESCAPES,MIME_BASE64_TEXT

scantime=0.7,size=3046,user=clamav,uid=89,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=43925,mid=,bayes=1.00,autolearn=spam

which lists the names of all the SpamAssassin rules that matched. You can
find your SpamAssassin rulesets in:

   /etc/mail/spamassassin

Search the .cf files in that directories for the rules that matched. This
will give you an idea of why the message was considered spam. If you think
that one of the rules is likely to yield false positives, you can edit the
definition to disable it or reduce the weight.

You can also manually whitelist users to ensure that their mail always
arrives. See:

   http://wiki.apache.org/spamassassin/ManualWhitelist

Be aware, however, that whitelisting opens the door to any spammer who
forges that particular sender's email address.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] isolog

[Angus McIntyre]

Eric Broch wrote:
> ... I'm getting the following error after the fact and don't know
> what it means.
>
> /usr/share/toaster/isoqlog/bin/cron.sh: line 20: 12280 Segmentation
> fault $ISOQLOG > /dev/null 2> /dev/null

I see those occasionally during the course of normal operations.

My guess has been that the program isn't able to handle all the possible
data that can occur in the logs, and segfaults when it hits something it's
not prepared to handle. Double-byte characters? Overlong strings?
Malformed log lines?

Your crash might have corrupted one of the logs being processed.

My experience has been that, left to itself, these errors will go away
after a while, as log rotation rotates the 'damaged' log out of the way.

If you care particularly about the output of isoqlog, then you'll want to
identify the problem logfile and patch it up by hand. If you don't, then
you may be able to just wait it out.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] re: attacks

[Angus McIntyre]

Cecil Yother, Jr. wrote:
> I am seeing a pronounced increase in attacks on one of my servers. Is
> anyone else experiencing this too?

If by attacks you mean grinders attempting to guess SMTP usernames and
passwords, yes. Over the last few months, they seem to be getting faster,
and over the last week or so I've been seeing an uptick in the number of
different hosts trying it.

fail2ban seems to handle them quite nicely.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Squirrelmail alternatives? Looking for recs

[Angus McIntyre]

Eric Shubert wrote:
> Why wouldn't you use the native mail program on an Ipad?
> I use a native mail program on any mobile device. (K-9 mail on android)

The Apple Mail client will pull stuff only from your top-level inbox.

I use procmail to sort some kinds of traffic - mailing lists, for example
- into other mailboxes. If I use Apple Mail or Sparrow or whatever, I
can't see those (unless I get fancy by setting up fake users for each
one). So I end up using a webmail client to get at the contents of the
other mailboxes.

SquirrelMail is OK, but not great for this on iPad, and close to unusable
on smaller form-factor devices. Haven't tried Roundcube.

That's my reason for wanting a mobile-friendly webmail client. Others may
have other reasons.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Gmail and ATT blacklisted my server - HELP!?

[Angus McIntyre]

Michael Maness wrote:
> My qmail toaster has been installed and running for 6+ years and now gmail
> and ATT have blacklisted my server from sending email to their domains.
> They claim blacklisting due to abuse, I've looked at the logs through
> ISOQLOG and everything appears to be normal.

You may be being blacklisted as part of a block, rather than as a result
of traffic originating from your server.

At one point last year, my server was blacklisted by Gmail, AT&T, and
Microsoft. I eventually found a tool - can't remember where it was, sorry
- that displayed spam complaints for individual IPs and blocks. My IPs
were all green, with no current complaints, but they were squarely in the
middle of a block full of active spam sources.

My hosting provider at the time declined to take any action against their
spamming customers, allocate me new IPs in a non-spammy block or,
eventually, even to respond to my support tickets. In the end, I changed
providers, which resolved the problem.

Try searching Google for "ip reputation" or "netblock reputation" and see
if you can find a tool that shows the reputation of your server and its
immediate neighbors. This may tell you whether the problem is really with
your server, or with the neighborhood it lives in.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Detecting compromised accounts

[Angus McIntyre]

Eric Shubert wrote:
> I'd very much like to see a throttle put on qmail-remote which would
> allow a per-user interval to be specified. When abuse occurs, the send
> queue would grow noticably, which could easily be monitored.

Can you run Spamassassin on outgoing mails? If a user account suddenly
starts sending spammy emails, that could trigger an audit.

This would come at a certain efficiency cost. It would also fail to catch
cases where a compromised user is sending a torrent of emails that don't
look spammy ... but it might catch cases where they're sending a trickle
of emails that _do_ look spammy.

Another trouble with this approach is that you might end up needing to
manually inspect any suspicious outgoing mails, which has privacy
implications.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Probably a simple question....databytes

[Angus McIntyre]

Kelly Cobean wrote:
> I'm running the default databytes value as listed here:
>
> http://wiki.qmailtoaster.com/index.php/Databytes
>
> Someone just tried to send me a 15MB file and got a bounce message that
> the messages exceeded the Databytes size.  How is a 15MB file tripping
> the Databytes limitation which is set to 20MB?

The original file may have been 15MB in size, but the email could well
have been larger. When a binary file is encoded for transmission by email,
the size of the resulting email is substantially greater. For example, I
think MIME encoding inflates the email by around 33%.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] I did not send that email titled "Hey"? Any ideas how it got sent please?

[Angus McIntyre]

Tony White wrote:
> I only recently opened up a Yahoo email account for testing.
> It seems that email came from there!  Can anyone suggest
> how it got to you folks?

Yahoo! accounts have been generating a lot of this kind of spam lately.
Yahoo! have claimed to have fixed the exploit that allows spammers to take
over their webmail accounts pretty much at will, but it keeps on coming.

See:

 
http://thenextweb.com/insider/2013/01/31/yahoo-mail-users-still-seeing-accounts-hacked-via-xss-exploit-amid-reports-yahoo-failed-to-fix-old-flaw/

(which repeats the claim that Yahoo! has now fixed the problem).

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Blacklist Script

[Angus McIntyre]

Gilbert T. Gutierrez, Jr. wrote:
> Does anyone have a script that can populate the blacklist_ip file on
> SpamDyke using designated spam emails? ...
>
> In the header of every email there is a line for Received that could be
> parsed to grab IPs. I want to try to cut down on the number of messages
> coming in that are spam in the spam folder.

Your mileage may vary, but I'm not convinced that this would necessarily
be effective. Spammers hop IP addresses continuously, either by using
botnets or snowshoe-spamming techniques.

I just scanned my own mailboxes and found 3626 unique IPs since May 1st (I
get a _lot_ of spam). Among those, there was one IP that had delivered 4
spam messages, 4 that had delivered 3 spam messages, 221 that had
delivered 2 spam messages, and the remainder - around 3400 - had each
delivered only a single message. If your patterns are anything like mine,
you'd end up with an awful lot of blacklist entries for not very much
gain.

There are visibly 'bad' IP blocks - I think eSecureData.com and nac.net
are currently hosting one of the biggest affiliate spammers, for example -
so blacklisting those blocks might not hurt. But those might be caught by
one of the RBLs anyway.

You might get an idea of whether it's likely to work for you by using:

   grep -h 'Received:' /path/to/your/mail/directory/* | grep -Eo
'[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | grep -v 127.0.0.1 |
uniq -c | sort -n

(replace '/path/to/your/mail/directory' with something that identifies
where your sample spams can be found). Unless I've screwed up, that should
give you a list of IPs preceded by the number of messages that passed
through each one.

(Actually, a message can have multiple 'Received' lines, some of which
represent intermediate hosts, so not all the IPs listed will have talked
directly to your server. But this will at least let you get an idea of
whether it's worth doing).

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] SpamAssassin Working?

[Angus McIntyre]

Tim Whitaker wrote:
> "Are you running Spamdyke?"
>
> No I don't believe so, but I can look into installing it.

Spamdyke is definitely worth having. It will reject a large amount of spam
at the earliest possible point, through things like graylisting and rDNS
checks. This means that the spam doesn't have to be passed through more
expensive checks such as SpamAssassin later in the pipeline, so it
lightens the load on your server overall.

You can check to see if Spamdyke is installed and working with:

   tail -f /var/log/qmail/smtp/current | grep spamdyke

> "SpamAssassin logs to /var/log/qmail/spamd."
>
> Yeah I know about that log, but that only shows you that it's running, has
> pids and children, etc.  It doesn't actually give me any type of "I
> blocked this email because of X" kind of logging.

On my toaster, I can get information about SpamAssassin's activities with:

   tail -f /var/log/qmail/spamd/current | grep result | tai64nlocal

(the 'tai64nlocal' program is just there to descramble qmail's somewhat
eccentric timestamps; it may not necessarily be installed on your system,
so just leave it out if you have problems).

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Blocked.

[Angus McIntyre]

Eric Shubert wrote:
> I honestly don't understand fail2ban in any detail. I wonder though, if
> perhaps it's set up such that if someone's authentication fails, then it
> changes iptables such that nobody can attempt to authenticate any more
> (like blocking port 587 for any address). That'd be pretty bad. :(

If you get a certain number of failed authentications from a particular IP
(usually 3 or 4), it will use iptables to ban that IP from connecting to
the port in question. So 'nobody' means 'nobody at that IP', not 'nobody
in the world'.

Incidentally, when I got tired of grinders trying to guess passwords on my
toaster, I banned a bunch of Chinese class C's (banning a surprisingly
small number took care of most of the attempts I was seeing) and added a
fail2ban filter that does an insta-kill (1 attempt is enough to invoke the
rule) on anything that tries to authenticate with a username that doesn't
include a domain name. That's been pretty effective.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: failure notice

[Angus McIntyre]

System Admin wrote:
> Hi Angus,
>
> Care to share
>
> "  I banned a bunch of Chinese class C's"

I think these were the networks I ended up banning because they had so
many grinders running on them. Not all are Chinese: the 195.x are Czech,
the 62.x are Polish, and the 193.x are in Latvia, so consider carefully
before casting them into the Outer Darkness.

20   DROP   all  --  62.122.72.0/24   0.0.0.0/0
21   DROP   all  --  195.78.108.0/24  0.0.0.0/0
22   DROP   all  --  62.122.73.0/24   0.0.0.0/0
23   DROP   all  --  195.78.109.0/24  0.0.0.0/0
24   DROP   all  --  91.229.248.0/24  0.0.0.0/0
25   DROP   all  --  91.210.101.0/24  0.0.0.0/0
26   DROP   all  --  91.210.100.0/24  0.0.0.0/0
27   DROP   all  --  222.52.118.0/24  0.0.0.0/0
28   DROP   all  --  193.104.110.0/24 0.0.0.0/0
29   DROP   all  --  193.105.154.0/24 0.0.0.0/0

> I tried to attach my iptables , but get bounce back saying file to big.

:o

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] clamav-toaster-0.98.1-1.4.6 is available

[Angus McIntyre]

On Jan 18, 2014, at 11:08 AM, Eric Shubert  wrote:

> The latest clamav (0.98.1, released this past Tuesday) is available for QMT. 
> It can be upgraded via traditional methods (qtp-newmodel) ...
> 
> As always, please post here if you have any problem with it. I've installed 
> it on a few servers with no apparent problems.

Thank you, Eric.

I didn't have any problems with clamav specifically. However, I let 
qtp-newmodel bring my other packages up to date, including some core packages: 
qmail-toaster-1.03-1.3.22 and vpopmail-toaster-5.4.33-1.4.0. Shortly 
thereafter, I noticed that POP and SMTP submission had stopped working.

I hand-simulated a POP session and got the error:

/home/vpopmail/bin/vchkpw: error while loading shared libraries: 
libresolv.so.2: failed to map segment from shared object: Cannot allocate memory

The fix for this turned out to be to go through the 'supervise' scripts and 
raise the 'softlimit' for any script that references it from 4800 to 
6400.

I wrote this up at:

  
http://wiki.qmailtoaster.com/index.php/Resolving_apparent_login_failures_with_SMTP_and_POP

Wiser (i.e. more knowledgeable) users should feel free to correct any errors or 
ambiguities in what I've written.

Incidentally, I've read that 64-bit systems may require larger softlimits. 
Would it be worth making the QTP installer scripts smart enough to configure a 
larger softlimit by default for such systems?

Thanks, as always, Eric & friends, for all the hard work you do.

Angus

Re: [qmailtoaster] re: hack attempts

[Angus McIntyre]

cj yother wrote:
> Is anyone else experiencing a rise in attempted account access over the
> past 24 hours?

Over the past week or so, I've seen very large numbers of
password-guessing attempts: other hosts trying to authenticate against
SMTP. They seem to try 'admin@', 'info@', 'support@', 'webmaster@' and, in
some cases, 'name-of-domain@name-of-domain'.

On my box, they get exactly three attempts and then 'fail2ban' knocks them
on the head and I don't hear from them again. However, they appear to have
an extensive botnet at their disposal, so I see hundreds of attempts a
day, from different hosts.

I host a number of domains, and the first few attacks were targeted at
three that are owned by a slightly controversial humanitarian
organization, so I thought it might be a targeted attack. However, they're
now hitting other domains as well, so I think it's just the latest
installment of Stupid Spammer Tricks.

It seems completely pointless, because 'fail2ban' takes care of it so
easily (and if you don't have 'fail2ban' installed, this is your cue).

Back when I thought it was a targeted attack, I thought about writing to
the group to ask if there was a way to configure qmail so that one of
their attempts would 'succeed', and then capture whatever messages they
were trying to send. However, given that it looks like it's just clueless
spammers trying to spam, I'm less interested in knowing what they have in
mind.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] re: hack attempts

[Angus McIntyre]

Dan McAllister wrote:
> Angus -- would you mind sharing with the group how you implemented the
> fail2ban on your system. It should probably go into the WIKI (if its not
> already there -- too lazy to check just now).

I added a write-up of the things that have worked for me at:

   
http://wiki.qmailtoaster.com/index.php/Hardening_your_toaster#Implementing_fail2ban

I am not an expert, so I'd appreciate it if people with more system
administration chops than me could check/try this and correct any flagrant
mistakes I've made.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] re: hack attempts

[Angus McIntyre]

Dave M wrote:
> I installed long time ago from this guide
> and tweeked it for my needs.
> http://wiki.qmailtoaster.com/index.php/Fail2Ban



I should have searched, instead of eye-balling the contents list (and
somehow missing that the guide was already there).

I'll back out my changes and link to the existing guide. Sorry.

Incidentally, if it's easy to do, I'd strongly recommend making a fail2ban
install part of the stock qmailtoaster setup. With password-guessing
attempts clearly on the rise, fail2ban can greatly reduce wear-and-tear on
your mailserver.

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] hack attempts

[Angus McIntyre]

On Feb 20, 2014, at 11:27 AM, cj yother  wrote:

> I see you all are experiencing basically what I am.  I have Fail2Ban 
> installed with e mail notifications and that's what brought it to my 
> attention.  I usually see 3 or 4 attempts a day and over the past few days 
> it's been 30 to 40.

It seems to have gone crazy recently. fail2ban banned more than 120 hosts 
already today.

Spammer's have always followed the rule "If it doesn't work, do it MORE!", but 
this seems extreme even by that metric.

Mind you, if you're accustomed to accepting a 0.001% success rate, then I 
suppose SMTP password guessing makes sense. But I'm still betting that if each 
of their robots gets three attempts every 24 hours before my robots shut them 
down, it'll be a long long long time before they successfully guess any 
passwords for accounts that don't exist on my server anyway.

Angus
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Blocking more spam

[Angus McIntyre]

On Feb 22, 2014, at 12:18 PM, Eric Shubert  wrote:
> It's not a terrible idea though. I wonder if fail2ban could be configured to 
> count DENIED_RDNS messages for each IP address, and if there were more than a 
> certain number of failed attempts in a given time period, then block the IP 
> address.
> 
> I'd like to hear from anyone with more familiarity with F2B than myself about 
> this possibility. This might be an additional F2B configuration we could 
> include.


For Fail2Ban to be effective, you'd want (a) repeat attempts from one IP to be 
large enough that you could usefully reduce load by banning offenders, and (b) 
the total number of offenders to be small enough that you don't end up adding 
thousands of entries to iptables. (I'm assuming that if you add enough entries 
to iptables you will eventually start seeing some kind of a performance hit, 
but I don't know if that is in fact the case, or where the cutoff point comes).

I did a quick informal study with:

grep DENIED_RDNS /var/log/qmail/smtp/current | awk '{print $9}' | sort 
| uniq -c  | grep -v " 1 " | grep -v " 2 " 

to find out how many hosts made 3 or more attempts.

In a sample based on about 90 minutes worth of mail, there were just over 100 
hosts, only 8 of which made 3 or more attempts to deliver. The 'worst offender' 
made 15 attempts.

In a larger sample, representing about 10 days worth of mail, 8206 hosts were 
denied, with the 'worst offender' making 1325 attempts, and 528 hosts making 3 
or more attempts.

In my (unscientific) sample, just under 7000 of the hosts sent a single message 
each. There were 27 hosts that tried to send more than 100 messages, and that 
accounted for just over 10,000 messages, about 40% of the total. Of course, if 
you set 100 as the cut-off point, you can't ban them until they deliver their 
100th message, so - based on my sample - you'd reduce load by about 25%.

That doesn't sound bad, though.

If you set the ban point at 20 messages, you'd ban about 100 hosts, and reduce 
load by 47%.

Banning at 10 messages leads to banning 150 hosts, and reduces load by about 
52%.

But I've been looking at 10 days of mail, which is probably unreasonable. 
Fail2Ban allows you to tune the 'findtime' for a jail (i.e. the period for 
which Fail2Ban will track failed attempts). The default seems to be 600 seconds 
(10 minutes). Would a 1-day window be appropriate for this application?

cat `find /var/log/qmail/smtp/ -mtime -1` | grep DENIED_RDNS | awk 
'{print $9}' | more | sort | uniq -c

gets me results for just 1 day.

A 1-day sample of my messages turned up 941 unique hosts, and 2672 messages. 
Banning after 10 failures would have banned 43 hosts and reduced load by about 
37% (i.e. 37% of the attempted delivery connections would have been rejected by 
iptables rather than spamdyke).

Incidentally, things get interesting if you look at networks rather than 
individual IPs. There are definite 'clusters', and it could be that banning a 
few selected class C's would have substantial payoff. (The old joke about 
eliminating 95% of all spam by null-routing China, Florida and BurstNet comes 
to mind). But you might not want to give a robot power to ban class C's without 
supervision ("Things have gotten awfully quiet around here lately ...")

I think you could write a Fail2Ban rule, and depending on where you set the 
cutoff point, it would probably reduce your server load by 25-50% of the 
difference between banning-by-spamdyke and banning-by-firewall. Assume that if 
you keep the number of entries in iptables reasonably low, there's no cost to 
an iptables ban. Assume also that having fail2ban scan the quickly-changing 
smtp/current log and tracking up to n hosts (where 'n' is the number of hosts 
failing for RDNS_DENIED per day) is also 'free'. Then you can reduce load by 
25-50% of however much load spamdyke is putting on your box. And I have no idea 
how to calculate what that might be.

TL;DR: It looks as if this approach would offer savings, but you need to look 
at usage patterns on your own servers to figure out how big those savings might 
be.

Angus
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] dspam

[Angus McIntyre]

On Nov 18, 2013, at 10:32 AM, Eric Broch  wrote:
> I've been working on getting DSPAM deployed and have implemented it on my own 
> (CentOS 5) email server with great results. 

Eric, many belated thanks for this detailed write-up.

Using this, plus the John M. Simpson page that you pointed to, I was able to 
get dspam installed and running on my server.

I'm now testing it with a single user, and if it works well, then I'll roll it 
out to the others. I'll be curious to see how well dspam performs on a lot of 
the spam that I see, which is filled with hashbuster text intended precisely to 
defeat statistical filters like dspam.

Two minor corrections to the very helpful instructions that you published.

First, I think step 4 should come before step 3 (so that you have access to the 
dspam setup scripts when you configure your MySQL).

Second in step 7, it should be 'service dspam start' rather than 'service start 
dspam'.

I don't know if it's worth adding this stuff to the wiki yet, because I don't 
know how Eric will choose to support dspam in QMT. When it does get added to 
the wiki, it would be worth including some of the configuration information 
from JMS's page, as that's crucial to getting dspam working properly. (I almost 
got stuck with dspam failing to start because it was still running in the 
default mode - as an adjunct to a mail server - rather than as a 
client/server-style filtering system, and was throwing an error when it tried 
to access a port).

Thanks again

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] dspam

[Angus McIntyre]

On Mar 20, 2014, at 6:34 PM, Eric Broch  wrote:
> Your welcome. Since November, I've created a much easier automated install 
> here. Be sure to look at the Readme file. And, as always, check the script.

Hmm. That seems to be an FTP link. I tried logging on as 'guest', but it 
doesn't seem to want to talk to me.

I'm not really convinced by dspam yet. Untrained, it classifies everything as 
'Innocent'. I fed it a massive corpus of spam and it then classified everything 
as 'Spam'. So I blew everything away and started over. This time, I've been 
feeding it an unrecognized spam (which is to say, all of it) in correction mode 
(i.e. --source=error). This is having a limited effect. After feeding it many 
hundreds of spams, it still believes that all my spam is actually 'Innocent', 
but at least I've shaken its confidence a bit - it's now only 85% convinced 
that 'Pro Viagra for Men' is a valid message.

It looks like I will have a lot more training to do before I can persuade it to 
successfully recognize any spam at all … and then only for the particular user 
that I've trained. I'm also concerned that many of the messages I see are 
filled with hash buster text, which is designed specifically to dodge and 
poison statistical filters like dspam.

Apologies if this is slightly off-topic, but given that dspam is under 
consideration for future QMT releases, I felt that I should share my 
experience. It's certainly not looking like a magic bullet to me at the moment.

Angus

[qmailtoaster] qmail-dk

[Angus McIntyre]

What's the current thinking on qmail-dk?

I've been debugging a case where some emails that I was expecting didn't 
arrive, and I eventually traced it to:

@4000533200332362fb9c qmail-smtpd: qq hard reject (qmail-dk: Cannot 
sign message due to invalid message syntax. (#5.3.0)): 
MAILFROM: RCPTTO:an...@mydomain.com
@40005332003323630754 spamdyke[13764]: DENIED_OTHER from: 
myredirector@s2.mydomain.com to: an...@mydomain.com origin_ip: 127.0.0.1 
origin_rdns: localhost.0.0.127.in-addr.arpa auth: (unknown) encryption: (none) 
reason: 
554_qmail-dk:_Cannot_sign_message_due_to_invalid_message_syntax._(#5.3.0)

(for reference, the domain that I have named 'myredirector.com' is a local 
domain that I use to implement a tagged email system; it accepts emails, 
processes them and reinjects for delivery to my main domain).

Checking with:

grep "qq hard reject" * | grep qmail-dk | tai64nlocal | more

reveals that issues with qmail-dk have resulted in quite a lot of 
non-deliveries over time.

From:

http://comments.gmane.org/gmane.mail.qmail.toaster/35191

it seems that Eric's advice was to disable it. 

I've done that now, but I just wanted to check if there were any implications 
of disabling qmail-dk that I should be aware of. Any advice?

Thanks,

Angus

[qmailtoaster] fail2ban - now more than ever

[Angus McIntyre]

If you haven't implemented fail2ban on your qmail toasters, think seriously 
about doing so.

There are at least two botnet-based password-guessing campaigns currently 
ongoing. One is trying SMTP authentication against role accounts (e.g. 
'admin@', 'info@') at known domains. It was this one that prompted initial 
recent discussion of fail2ban on this list.

The other, which I think just started today, is trying to do POP3 
authentication, using email addresses taken from mailing lists used by 
spammers. Because these lists are mostly nonsense, this will result in hundreds 
or thousands of attempts to authenticate against non-existent users, but I 
suppose they might eventually start hitting some existing addresses.

Because of the stupidity of these attempts, I would think that they're very 
unlikely to succeed at most hosts. However, if left to run unchecked they will 
probably start to soak up noticeable amounts of resources. The spammers appear 
to be deploying increasingly large botnets, and each host will keep trying 
until banned.

The instructions at:

http://wiki.qmailtoaster.com/index.php/Fail2Ban

for setting up fail2ban seem pretty good.

This has been a public service announcement.

Angus

Re: [qmailtoaster] fail2ban - now more than ever

[Angus McIntyre]

Eric Broch wrote:
> I've installed f2b on my home and a clients email server. One problem
> that manifested itself was the inability to use FTP, from anywhere
> outside my network firewall. Before turning on f2b and the QTP firewall
> script (firewall.sh) those 'outside' could access my ftp site. After
> iptables is turned on, no such luck. I think the problem is with
> iptables and not f2b. I worked for about 6 hours on this to get it
> resolved after one from the QTP community could not download my DSPAM
> project. Finally, I simply turned of iptables and everything works. I'd
> sure like to get f2b with iptables working again.

Odd.

fail2ban would only affect your FTP if you have a jail set up to deny
failed FTP connections. It looks to me as if the only jail for FTP in the
default configuration is disabled by default.

FTP could be affected if your iptables configuration doesn't allow routing
to the ports used by FTP. I periodically have issues when I set up a new
web server on some non-standard port and wonder why I can't connect to it,
then remember that I have to do something like:

   /sbin/iptables -I INPUT -p tcp --dport 8080 -j ACCEPT

to make it work.

FTP uses port 20 and 21, but it quickly gets weird, because it also uses
randomly-chosen high-numbered ports for data transfer. This article:

   
http://www.techrepublic.com/article/how-ftp-port-requests-challenge-firewall-security/

discusses the implications.

If you Google 'iptables ftp ports' there are quite a few articles that
claim to tell you how to do it, but you may already have tried everything
they suggest.

In your position, I might choose to enable iptables again and just serve
my projects to the world over HTTP rather than FTP. If you don't want the
overhead of Apache running on your box, something like nginx or lighttpd
might give you everything you need with a much smaller footprint.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: fail2ban - now more than ever

[Angus McIntyre]

Eric Shubert wrote:
> You probably should also change the listen_port so you're not using
> standard ports at all. Same rationale as not using ssh on port 22. I
> generally don't believe in security by obscurity, but at least it keeps
> the script kiddies at bay.

Sadly, not for long. I get periodic attempts to ssh into my box on the
alternative port I chose for it.

Of course, for every one I see on [otherport], there are probably a
million script kiddies failing to connect on 22 and going away.

One of the reasons I like fail2ban is that it implements "security by
obscenity" -- they try something and it tells them to f*ck off. ;-)

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: fail2ban - now more than ever

[Angus McIntyre]

Dan McAllister wrote:
> I'm very much not a fan of re-assigning well-known-ports to other
> locations (like FTP or SSH).
>
> Most of us admins have static IPs where we work, if not where we live.
> If you try to SSH into any of my servers (other than just 1 that is not
> especially public), you'll be denied (connection dropped).
> I can get in because of my [source] IP address and my iptables rules.

I think what you say is true for 'pro' admins, but may be less true for
others. For instance, I'm on the road a lot, so it wouldn't work for me.
Anyone who uses a home broadband connection that gets dynamically-assigned
IPs is also in trouble (unless they widen the iptables rule to allow
anything from the blocks assigned to their ISP's pool).

One thing that is certain is that moving, say, SSH to another port isn't
going to prevent script kiddies and SSH grinders from targeting it. On the
other hand, in my experience it does significantly reduce the volume of
attempts, at least for now.

It's not "security by obscurity", but "aggravation minimization by
obscurity". The important thing is not to have any illusions about its
effectiveness.

Although I have to say that incoming spam volume has plummeted since I
moved SMTP from port 25 to port 10347. :-o ;-)

> I also use a "trigger port" (try to open this "odd" port and it will
> fail -- but my SSH port will be OPEN for 3 minutes!

I'm not convinced that port-knocking is any more or less elegant than
port-moving, but I am far from being an expert admin, so I'm sure I could
be persuaded. I do know that I wouldn't like to have to explain
port-knocking to some of the people who need SFTP access to some of my
servers.

Although maybe the ability to understand basic security techniques ought
to be a requirement for access, and people who can't get their heads
around it don't have any business on my boxes.

One slight weakness of port-knocking is that a grinder can simply hit a
range of ports, then make a second pass to access the now-open well-known
port (at which point they get three attempts to guess the password before
fail2ban knocks them on the head). I would guess that SSH grinders will
eventually start doing this, although at least port-knocking adds an extra
layer of complexity for them.

I guess if you're truly paranoid, you could take the scheme further, and
either require users to visit a login web page (obscure location, https,
authentication) or to send some kind of verification message to the
'knock' port before the protected port is opened up for the precise IP
address making the request. But the arms race hasn't yet reached the point
at which such heroic measures are necessary.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: to catch all or no

[Angus McIntyre]

Tonix - Antonio Nati wrote:
> About deleting all email for not existing users, I consider it a bad
> service to customers, as they have legitimate raports with business
> partners, and if someone writes to the wrong address it is correct and
> ethical to report them back that address is wrong, so they can use
> another way to contact the recipient, instead of waiting for never
> coming reply messages.

I take your point, but the volume of attempted deliveries to non-existent
addresses is increasing continuously. Some of the domains I manage each
receive messages daily sent to literally hundreds if not thousands of
addresses that do not exist and have never existed.

Sometimes the bogus addresses are clearly the result of bad de-munging by
spamlist generators. For example, if you have a real address
'system-reports@', the spammer might try to send to 'reports@', having
mistakenly stripped off the first part. I've also seen attempts to deliver
to what were obviously once message IDs that have somehow been scraped up
by spammers and added to a list under the impression that they were email
addresses. Then there are the spammers who permute real addresses (i.e. if
you have someuser@, they might create a fake sender address of
'xyzsomeuser@') and these get fed back into the address collectors as
well. And some just seem to be invented by combining random characters.

If you bounce all these, then you will generate huge amounts of email,
much of it going back to real users whose addresses have been forged in
the 'From' line of the spam message.

> More, the abuse of deletion and missing respect for RFC forces users to
> ask always for delivery and read receipt, incrementing the volume of
> useless emails.

I don't like read receipts, but I think the volume of worthless mail
generated is a fraction of what you'd get if you bounce every message to a
non-existent user.

Of course, I have to admit that the spammers who are targeting these
nonsense addresses are more likely than others to be rejected at
connection time by spamdyke's RDNS checks or SaneSecurity, so maybe the
bounce volume would be smaller than I expect. Still, the potential is
there.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] http service survey

[Angus McIntyre]

On May 28, 2014, at 3:17 AM, Erik Wramner  wrote:
> Personally I would prefer to stick with Apache or (ideally) to make the 
> package work with both depending on which one is available. Nginx is great, 
> but most shops I work with use Apache and know it well. It works and they 
> don't want to switch.

+1 to this.

For (reasons) I need to run Apache on my mail server. It would be awkward for 
me if nginx was also on there and contending for ownership of port 80.

I guess this is a roundabout way of saying that if we switch to nginx, can the 
setup be arranged so that nginx can easily/optionally be run on an alternate 
port where it can coexist rather than conflict with Apache?

One other, peripherally related thing: I am following with interest the 
development of Mailpile (https://www.mailpile.is/) which I think may become a 
popular option. It's in early alpha currently, so it's perhaps too soon to make 
any decisions based on what it might or might not do. But I hope that any 
decisions made about the future of qmailtoaster won't rule out the possibility 
of a Mailpile install.

Angus

Re: [qmailtoaster] Re: Roundcube Survey

[Angus McIntyre]

Eric Broch wrote:
> On 5/29/2014 2:59 PM, Eric Shubert wrote:
>> On 05/29/2014 12:01 PM, Edwin Casimero wrote:
>>> What my users demand is a company wide address book.
>>
>> Have you implemented this on QMT?
>> If so, would you care to explain how you did it?
>>
> And, calendering.

Sounds like what you need is Horde.

(ducks hastily)

;-)

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Roundcube Survey

[Angus McIntyre]

Eric Shubert wrote:
> I'm not necessarily against providing horde .qt. packages, but someone
> else will need to step up to help make that happen. Note, it's possible
> that I'll change my tune once I become more familiar with it. ;)

Horde has the reputation of being horrifying to install and configure.
However, my last brush with Horde was many years ago, and it may have
moved on since then.

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] TLS 'connect failed' issues mailing 'me.com'

[Angus McIntyre]

Attempts to send messages to a user at 'me.com' (whose mail exchanger is
at Apple's 'icloud.com') have been failing consistently with the error:

   TLS connect failed: error:14077410:SSL
   routines:SSL23_GET_SERVER_HELLO:sslv3 alert
   handshake failure; connected to 17.158.8.113.

Does anyone know whether this indicates a possible issue with my toaster
setup, or is the fault at the other end?

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: DSPAM status

[Angus McIntyre]

Eric Shubert wrote:
> P.S. Anyone else using DSPAM?

I set up DSPAM and have it running, but I haven't had much luck with it.

I have a vague memory of seeing someone claim that you could train DSPAM
using only 'spam' samples (no 'ham'), so I fed it my entire spam archive
for the month, with only a very small number of 'ham' examples.
Afterwards, DSPAM decided that all email was spam. (Granted, that probably
gives it a false-positive rate of about 3%, but still).

I then blew away its databases and tried to train it more selectively,
letting it rate everything and forcing it to re-learn (as Spam) any
messages that it had wrongly classified as Innocent. Unfortunately, I
never seemed to be able to even "move the needle": feeding numerous
samples of a highly-recognizable type of spam only reduced DSPAM's
confidence that they were Innocent, but it never seemed to tip over into
considering them Spam. I think the best that I ever got was a verdict that
some particularly flagrant piece of spam was only Innocent with 60%
probability.

I should work out a more intelligent training regime and see if I can't
get it to behave as advertised, but for me it certainly hasn't been the
'out-of-the-box' spam-recognizing miracle that it has been for some
people.

Angus




-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: DSPAM status

[Angus McIntyre]

Sebastian Grewe wrote:
> Maybe I just fed it better files back then or spam was more obvious back
> in the days ;-)

Are you saying that your spam is better than my spam? ;-)

I do now see a lot of spam that is full of hashbuster text, specifically
designed to 'poison' or dodge Bayesian filters. That might explain why
DSPAM struggled more when I tried to train it.

Angus


> Cheers,
> Sebastian
>
>> On 11.07.2014, at 20:15, "Angus McIntyre"  wrote:
>>
>> Eric Shubert wrote:
>>> P.S. Anyone else using DSPAM?
>>
>> I set up DSPAM and have it running, but I haven't had much luck with it.
>>
>> I have a vague memory of seeing someone claim that you could train DSPAM
>> using only 'spam' samples (no 'ham'), so I fed it my entire spam archive
>> for the month, with only a very small number of 'ham' examples.
>> Afterwards, DSPAM decided that all email was spam. (Granted, that
>> probably
>> gives it a false-positive rate of about 3%, but still).
>>
>> I then blew away its databases and tried to train it more selectively,
>> letting it rate everything and forcing it to re-learn (as Spam) any
>> messages that it had wrongly classified as Innocent. Unfortunately, I
>> never seemed to be able to even "move the needle": feeding numerous
>> samples of a highly-recognizable type of spam only reduced DSPAM's
>> confidence that they were Innocent, but it never seemed to tip over into
>> considering them Spam. I think the best that I ever got was a verdict
>> that
>> some particularly flagrant piece of spam was only Innocent with 60%
>> probability.
>>
>> I should work out a more intelligent training regime and see if I can't
>> get it to behave as advertised, but for me it certainly hasn't been the
>> 'out-of-the-box' spam-recognizing miracle that it has been for some
>> people.
>>
>> Angus
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>>
>
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>


-- 



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] TLS 'connect failed' issues mailing 'me.com'

[Angus McIntyre]

Thanks for this, Eric.

I created an ‘iCloud.com’ address for myself, and did some tests.

First, I tried sending to it with my existing tlsserverciphers file, which 
contained:


ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:ADH-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA

and the log file showed:

delivery 25433: deferral:   
TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:
sslv3_alert_handshake_failure;_connected_to_17.172.34.65./

Next, I tested rebuilding the tlsserverciphers file using the qmail.spec code 
that you provided. This generated a new file that was, as far as I could see, 
identical to the existing one. Again, my test message failed.

I then copy-pasted your enormous cipher list into the tlsserverciphers file and 
tried again (I stopped and started qmail between each attempt). Again, I got a 
failure.

However, I noticed that in addition to ‘tlsserverciphers’ I also had a 
‘tlsserverciphers.dist’ file, which contained:


DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:KRB5-DES-CBC3-MD5:KRB5-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:KRB5-DES-CBC-MD5:KRB5-DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-KRB5-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-RC4-MD5:EXP-RC4-MD5
 

I copied this to ‘tlsserverciphers’, did the stop/start dance again, and tried 
one last time.

This went through without generating an error in the log file.

When I checked my iCloud.com mailbox, I found that three of my test messages 
(tests 2, 3 and 4), which puzzled me, because 2 and 3 definitely generated 
errors when I first tried to send them. I think the explanation must be that 
qmail retried these messages quite soon after the initial failure, by which 
time I had installed the ‘correct’ cipher file. 

So it looks as if ‘tlsserverciphers.dist’ contains the necessary mix of 
ciphers. I’m not sure why your monster list failed, but looking at it I notice 
that there was a line break in the middle of 'DHE-RSA-AES128-SHA’, which may 
have screwed things up.

I have a vague memory that there was a reason why my ciphers file looked the 
way it did, and that it was based on past advice on this list. So this may yet 
come back to bite me.

"Do not meddle in the affairs of ciphers, for they are subtle and quick to 
anger."

Angus


On Jul 12, 2014, at 12:52 PM, Eric Shubert  wrote:

> On 07/11/2014 11:18 AM, Angus McIntyre wrote:
>> Attempts to send messages to a user at 'me.com' (whose mail exchanger is
>> at Apple's 'icloud.com') have been failing consistently with the error:
>> 
>>TLS connect failed: error:14077410:SSL
>>routines:SSL23_GET_SERVER_HELLO:sslv3 alert
>>handshake failure; connected to 17.158.8.113.
>> 
>> Does anyone know whether this indicates a possible issue with my toaster
>> setup, or is the fault at the other end?
>> 
>> Angus
>> 
>> -
> 
> Could be either end. Have you modified your tlsserverciphers phile ;) 
> according to what was discussed here a few months back? We changed the 
> ciphers to use stronger keys, IIRC.
> 
> I'm guessing that me.com is either not capable of using the stronger ciphers 
> you're using (if you're doing so), or perhaps me.com is requiring only 
> stronger ciphers that you're not set up to use.
> 
> My file is as follows:
> DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:KRB5-IDEA-CBC-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128
> -SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECD

Re: [qmailtoaster] Queue problem update -- and TLS issue

[Angus McIntyre]

Dan McAllister wrote:
> On a separate note, one of my older QMT systems has suddenly stopped
> being able to send mail to *me.com* (Apple)... the error says its a TLS
> failure.
>
> TLS connect failed: error:100AE081:elliptic curve
> routines:EC_GROUP_new_by_curve_name:unknown groupZConnected to
> 17.172.34.70 but connection died. error:100AE081:elliptic curve
> routines:EC_GROUP_new_by_curve_name:unknown group (#4.4.2)
>
> This is a new one for me... curious if anyone else is having issues with
> me.com?

Yes, I ran into this just recently. See:

   http://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg37904.html

for my fumblings, I mean, findings.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Question about lists (other than ezmlm)

[Angus McIntyre]

Dan McAllister wrote:
> Ok, I know STOCK QMT comes with mlm -- but I also recall others talking
> about other list management tools for QMT
>
> I have a client that wants to use a mail list (tens of thousands of
> entries, he says -- I've warned him of the blacklist risk!)
>
> What are our other alternatives?

If you're running CentOS ... which you presumably are ... you can use
'yum' to install 'mailman'. There's no specific integration with QMT, but
in my experience they play fairly nicely together.

In a past life, I did a whole 'mailman' setup by hand, including
installing from source. _That_ I do not recommend. But my recollection is
that using 'yum' to get it going was pretty painless. While 'mailman' has
an interface that only Richard Stallman could love, once it's installed it
requires minimal attention.

Your mileage may vary.

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] One user account can't login to Squirrelmail

[Angus McIntyre]

Diana Calder wrote:
> I have an odd problem with one user account. When trying to login to
> Squirrelmail, the login will hang for several seconds then result in:
>
> ERROR: Connection dropped by IMAP server.
>
>   [ ... snip ... ]
>
> A possible symptom or secondary issue is that the problem account is
> using 78% of its 1Gb quota ... He has about 700
> messages in his Inbox ...

That might be the issue.

I've seen SquirrelMail serve up blank pages, apparently due to timeout
issues, when trying to open mail folders that contained very large numbers
of messages. I'd give serious consideration to the possibility that
something like that is happening here.

You can test this idea by manually moving most of the user's messages to
another directory temporarily (using the shell and your administrator
superpowers), then having the user try to login. If they're able to log in
successfully, then that was probably your issue. If they're still stuck,
well, at least it was an easy test.

You could also try increasing the:

max_execution_time

in your 'php.ini' file to see if that helps. That might resolve timeout
issues (if this is a timeout issue) associated with execution of
SquirrelMail's PHP scripts. If it's a timeout issue with the IMAP server,
there may be an equivalent setting that you could tweak somewhere in the
configuration files for your server.

Another possibility is that it's not the sheer number of messages that's
causing the issue, but one particular message which is either overlarge or
malformed. In that case, moving some messages aside temporarily, then
putting them back into the mailbox in small batches may help isolate the
problem.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Qmail's handling of same account in both TO: and CC: headers

[Angus McIntyre]

If memory serves correctly, MTAs like qmail do not read the 'To' and 'Cc'
headers at all. The 'To' and 'Cc' fields are written by the MUA (i.e. the
email client) and constitute part of the message text delivered to the
server by the DATA command. The server doesn't look inside that text at
all. The thing that tells it where to deliver the message is an RCPT
command which is sent as part of the SMTP session.

So if your developer is obsessing over the content of the 'To' and 'Cc'
fields, it suggests that he doesn't know as much about email as he thinks
he does. Or, more likely, that he's using a library that abstracts away
the details. He's doing something like:

message = new Message();
message.add_to_recipient("someone@somewhere")
message.add_cc_recipient("someone@somewhere")
message.add_cc_recipient("someones-boss@somewhere")

and the library is configured to send an RCPT command for every address in
the 'to' and 'cc' slots of the message object, so it's doing:

RCPT TO: someone@somewhere
RCPT TO: someone@somewhere
RCPT TO: someones-boss@somewhere

The first question that comes to my mind is why he's adding the same email
to both 'To' and 'Cc'. That just seems sloppy to me.

Leaving that aside -- maybe he has a reason -- I did a manual telnet
session to both a qmail server and to Gmail to see how they'd handle the
case where successive RCPT commands name the same recipient.

Qmail didn't blink when I told it to deliver to the same recipient three
times, and did indeed deliver three messages. Gmail, on the other hand,
said:

   250 2.1.5 OK, duplicate recipients will be consolidated

I haven't found any RFC's at all that specify that this is a required or
even optional behavior. Implementing it does not seem to violate the RFCs
(so long as the server sends a 250 response), but not implementing it
doesn't seem to violate any either.

I think he's correct that Gmail et all are "smart enough" to consolidate
duplicate addresses, but that this is not a required behavior and Qmail is
perfectly compliant. I might be tempted to point out that other developers
are "smart enough" not to address their messages redundantly, but that
might lead to violence.

Angus







Diana Calder wrote:
> We are implementing a new piece of software to handle vacation
> requests. The program connects directly to our Qmail server's SMTP - no
other mail servers are involved. Said software sends an email to the
requester and their supervisor when the supervisor okays the vacation
request. The requester currently receives the same email twice because
the program puts the requester's email address in both the TO: and the
CC: headers. The software developer and I are having a bit of a
"discussion" regarding this.
>
> My position is that Qmail is doing its job correctly by delivering the
email exactly as it is addressed and the problem lies in his program
which is clearly incorrect in the way that it addresses the message.
>
> The developer's position is that our email server is at fault. He
"proved" this by sending an email with his address in it 5 times (once
in TO: and 4x in CC:). He claims that Qmail is at fault because other
email servers (like Exchange and Gmail) are, and I quote, "smart enough
to recognize that all copies are for one person therefore instead of 5
emails only one copy is in my inbox." Because of this, getting him to
fix his broken program is becoming somewhat of an issue.
>
> Just to confirm here - anybody have a handy RFC to prove that Qmail is
actually doing what it should by delivering email as addressed and the
other mail servers are actually behaving in a non-standard way by
"deciding" that the emails are all the same and only delivering one
copy? Or am I wrong and Qmail is indeed in the wrong by delivering
exactly what the headers tell it to?
>
>
> --
> Best regards,
>  Diana Calder
mailto:dcal...@essexcountylibrary.ca
> Automation Technician(519) 776-5241 x.131
> Essex County Library
> Essex, ON
>
>
> - To
unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For
additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>


-- 





-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Re: Fail2Ban

[Angus McIntyre]

Eric Shubert wrote:
> On a general note, I believe several people here have implemented f2b on
> QMT. You should find discussions and perhaps some other configurations
> in the list archives. It'd be nice if people would share their
> configurations here (even if they've done so before).

A while back, I actually wrote a guide to f2b for the wiki ... and then
someone pointed out that there was already a very good one, so I backed
out my changes. The existing guide on the wiki is pretty comprehensive.

I think my configuration is pretty stock, but I've added the following
lines to the end of 'jail.conf'

= jail.conf 

# CUSTOM JAILS

[courierimap-iptables]

enabled  = true
filter   = courierlogin
action   = iptables[name=IMAP, port=imap, protocol=tcp]
   sendmail-whois[name=IMAP, dest=root, 
sender=fail2...@mydomain.com]
logpath  = /var/log/secure
maxretry = 4

[vpopmail-iptables]

enabled  = true
filter   = vpopmail
action   = iptables-multiport[name=VPOPMAIL, port="smtp,pop3,587",
protocol=tcp]
   sendmail-whois[name=VPOPMAIL, dest=root, 
sender=fail2...@mydomain.com]
logpath  = /var/log/maillog
maxretry = 3
bantime = 86400

[vpopmail-bonus-iptables]

enabled  = true
filter   = vpopmail-bonus
action   = iptables[name=VPOPMAIL-BONUS, port=smtp, protocol=tcp]
   sendmail-whois[name=VPOPMAIL-BONUS, dest=root,
sender=fail2...@mydomain.com]
logpath  = /var/log/maillog
maxretry = 1
bantime = 86400

[imapd-iptables]

enabled  = true
filter   = imapd
action   = iptables[name=IMAPD, port=imap, protocol=tcp]
   sendmail-whois[name=IMAPD, dest=root, 
sender=fail2...@mydomain.com]
logpath  = /var/log/secure

= jail.conf 

Then, I have some individual filters in 'filter.d' to handle mail-related
stuff (see below)

You'll notice that some of the filters contain the line:

   ignoreregex = (user1|user2|user3)

Because I handle a relatively small number of users, I actually list the
usernames of legitimate users so that they don't get locked out if they
flub their password repeatedly.

These filters were all borrowed from somewhere else -- I can't remember if
they're in the f2b distro, or if I found them somewhere else on the web --
with the exception of 'vpopmail-bonus', which I wrote myself.

'vpopmail-bonus' leverages the fact that many abusers like to connect with
no domain name, i.e. they try to connect as:

user@

rather than

u...@domain.com

This filter matches that. It also matches attempts to connect using a
subdomain, i.e.

u...@s2.abc.com

and a couple of domains that no one ever logs into:

u...@xyz.com
u...@xyz.info

In the corresponding jail configuration in 'jail.conf', I specify that
anything that trips the 'vpopmail-bonus.conf' filter should be
insta-banned: even 1 failure is enough to get them banned, whereas the
regular 'vpopmail' jail allows them 3 tries before bringing the hammer
down.

I still haven't made up my mind whether this is a good strategy or not.
The rule certainly matches. But I've noticed that the current crop of
password guessers don't make repeat attempts in short order. It used to be
the case that grinders would lock on and work through all the user/pw
combos they could think of, until they either reached the end of their
list or got blocked by something like f2b.

Now, it seems that the attackers prefer to deploy a gigantic botnet, with
each machine in it making just one attempt (I'd love to know how they
coordinate that, so that they don't have multiple machines redundantly
guessing the same user/pw combo). So my bonus filter bans them, but it's
wasted effort because they weren't planning on making a second attempt or,
if they were, they weren't going to do it immediately. The result is that
the filter adds lots of entries to iptables, in a way that may not
actually be useful.

So you could try 'vpopmail-bonus' if you like, but I think it's less
useful than the others.

Angus

== courierlogin.conf ===

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#  host must be matched by a group named "host". The tag "" can
#  be used for standard IP/hostname matching and is only an alias for
#  (?:::f{4,6}:)?(?P[\w\-.^_]+)
# Values:  TEXT
#
failregex = LOGIN FAILED, .*, ip=\[\]$

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

 vpopmail.conf =

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#  host must be matched by a group named "host". The tag "" can
#  be used for standard IP/hostname matching and is only an alias for
#  (?:::f{4,6

[qmailtoaster] Special-case spam filtering based on envelope sender

[Angus McIntyre]

I’m seeing an uptick in a particular type of spam that I would very much like 
to filter. Fortunately, the spam has a quite distinctive fingerprint: the 
envelope sender of each message matches the regex:

^[A-Za-z0-9_-]+-realuser=realdomain\.realtld\@[a-z0-9-]+\.[a-z]{2,4}$

(where ‘realuser’, ‘realdomain’ and ‘realtld’ jointly match an email address 
hosted on my server.

For example, if I had a user ‘f...@example.com’, the envelope sender on the 
spams might look like:

garcinia-fred=example@spammydomain.com

The ‘fred=example.com@’ is pretty distinctive for this spammer. There are a few 
legitimate domains that use an approximately similar convention, but the regex 
above will not match them.

spammydomain.com, obviously, changes from run to run. They seem to be 
snowshoe’ing their way all over Cloudflare, with a few instances on HiVelocity.

My impression is that Spamdyke’s sender blacklists only allow simplified 
wildcards, i.e. specifying @example.com to block all email from the 
‘example.com’, so that’s probably not an option. Spamdyke’s header blacklist 
feature is slightly more complex/capable, but doesn’t match on the envelope 
sender (or allow me the full expressiveness I need).

I could add a SpamAssassin rule to take care of these cases, but the way my 
system is configured, SpamAssassin will only flag spam, not delete it. Some of 
the addresses targeted by this particular spammer are set to forward to 
external systems, so — in order to preserve the reputation of my mail server — 
I’d like to kill this spam dead.

I could use procmail, but this is something of a hassle. So before I go down 
that route, I wanted to ask whether there’s anything in the qmailtoaster 
toolbox that would allow me to block email based on applying the regex above to 
the envelope sender. 

I could also just use iptables to block CloudFlare entirely, but that seems a 
little extreme.

Any suggestions would be gratefully received.

Angus
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] New format for spam enlargement emails

[Angus McIntyre]

Tony White wrote:
> nothing seems to stop this Subject passing through
> all the filters in QMT.
>
> P_E N-I_S --E-N..L_A-R-G-E_M-E N-T.._ P_I-L L_S

The regex:

P(\.\.|_| |-)E(\.\.|_| |-)N(\.\.|_| |-)I(\.\.|_| |-)S

applied to the Subject should get pretty much all of them.

Looking at my records, it seems that a typical SpamAssassin result for one
of these looks like:

  * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
  *  trust
  *  [208.72.237.26 listed in list.dnswl.org]
  *  3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
  *  [score: 1.]
  *  0.0 HTML_MESSAGE BODY: HTML included in message
  *  0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or identical to
  *   background
  *  0.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
  *  2.0 GAPPY_SUBJECT Subject: contains G.a.p.p.y-T.e.x.t
  *  0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
  *  1.0 BODY_URI_ONLY Message body is only a URI in one line of text or for
  *  an image

It looks like the bulk of the work is being done by BAYES_99, so maybe
when you've seen a few more of them and trained your SpamAssassin against
them, you'll start seeing more tagged as spam.

I don't know if there's a SpamAssassin rule that checks for 'excessive use
of the HTML entities', particularly in URLs, but if there was then
something like:

   http://яфаичч ...

really ought to set it off.

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Fwd: ezmlm warning

[Angus McIntyre]

I received one of those a few days ago.

I did some digging and figured out what was happening.

   1. Someone posted to the qmailtoaster list from a host that is 
currently listed in an RBL.
   2. Spamdyke on my server checked their IP against the RBL and 
rejected the message(s).
   3. The qmailtoaster ezmlm server received the bounce(s) and noted 
that my server was bouncing mail.
   4. After a set number of bounces, it sent me the same warning that 
you've all received.


Basically, if you get one, it means that (a) your qmailtoaster setup is 
behaving as it should, and (b) the qmailtoaster ezmlm software is 
behaving as it should. But the end result is these warning messages.


What I can't now remember was whose IP was blacklisted. It might have 
been Fabian's (74.125.129.26), but that IP seems to be clear now, so it 
was probably a transient issue.


Angus


On 2015-04-12 18:46, Eric Broch wrote:

I wonder why we would be receiving these? Does anyone know?
 And, who's running the qmailtoaster mail server?

 On 4/12/2015 4:42 PM, Fabian Santiago wrote:


I received this:

Hi! This is the ezmlm program. I'm managing the
qmailtoaster-list@qmailtoaster.com mailing list.

I'm working for my owner, who can be reached
at qmailtoaster-list-ow...@qmailtoaster.com.

Messages to you from the qmailtoaster-list mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.

If this message bounces too, I will send you a probe. If the probe
bounces,
I will remove your address from the qmailtoaster-list mailing list,
without further notice.

I've kept a list of which messages from the qmailtoaster-list
mailing list have
bounced from your address.

Copies of these messages may be in the archive.

To retrieve a set of messages 123-145 (a maximum of 100 per
request),
send an empty message to:


To receive a subject and author list for the last 100 or so
messages,
send an empty message to:


Here are the message numbers:

17822

--- Enclosed is a copy of the bounce message I received.

Return-Path: <>
Received: (qmail 5440 invoked for bounce); 1 Apr 2015 01:04:06
-
Date: 1 Apr 2015 01:04:06 -
From: mailer-dae...@mail.qmailtoaster.com
To: qmailtoaster-list-return-178...@qmailtoaster.com
Subject: failure notice

Hi. This is the qmail-send program at mail.qmailtoaster.com [4].
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
User and password not set, continuing without authentication.
 74.125.129.26 failed after I sent the
message.
Remote host said: 552-5.7.0 This message was blocked because its
content presents a potential
552-5.7.0 security issue. Please visit
552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590
[5] to review our
552 5.7.0 message content and attachment content guidelines.
k6si19967000pdm.248 - gsmtp

Sincerely,

Fabian Santiago

Sent from my iPhone

On Apr 12, 2015, at 6:39 PM, Eric Broch 
wrote:


Has anyone on the list received one of these?

 Forwarded Message 

RETURN-PATH:







DELIVERED-TO:
whitehorsetc.com-ebr...@whitehorsetc.com

RECEIVED:
(qmail 15878 invoked by uid 89); 12 Apr 2015 22:33:10 -

RECEIVED:
by simscan 1.4.0 ppid: 15859, pid: 15862, t: 2.5894s scanners:
attach: 1.4.0 clamav: 0.98.6/m:55/d:20315 spam: 3.4.0

X-SPAM-CHECKER-VERSION:
SpamAssassin 3.4.0 (2014-02-07) on pet110II.whitehorsetc.com
[2]

X-SPAM-LEVEL:
*

X-SPAM-STATUS:
No, score=1.8 required=5.0 tests=AWL,BAYES_60,RDNS_NONE
autolearn=no autolearn_force=no version=3.4.0

RECEIVED:
from unknown (HELO mail.qmailtoaster.com [1]) (162.213.42.64)
by pet110II.whitehorsetc.com [2] with SMTP; 12 Apr 2015 22:33:08
-

RECEIVED-SPF:
pass (pet110II.whitehorsetc.com [2]: SPF record at
qmailtoaster.com [3] designates 162.213.42.64 as permitted sender)

RECEIVED:
(qmail 27565 invoked by uid 89); 12 Apr 2015 22:32:56 -

MAILING-LIST:
contact qmailtoaster-list-h...@qmailtoaster.com; run by ezmlm

DATE:
12 Apr 2015 22:32:56 -

MESSAGE-ID:
<1428877976.27265.ezmlm-w...@qmailtoaster.com>

FROM:
qmailtoaster-list-h...@qmailtoaster.com

TO:
ebr...@whitehorsetc.com

CONTENT-TYPE:
text/plain; charset=us-ascii

SUBJECT:
ezmlm warning

X-DSPAM-RESULT:
Innocent

X-DSPAM-PROCESSED:
Sun Apr 12 16:33:16 2015

X-DSPAM-CONFIDENCE:
0.9989

X-DSPAM-IMPROBABILITY:
1 in 90997 chance of being spam

X-DSPAM-PROBABILITY:
0.

X-DSPAM-SIGNATURE:
1,552af2ac36691819825128

Hi! This is the ezmlm program. I'm managing the
qmailtoaster-list@qmailtoaster.com mailing list.

I'm working for my owner, who can be reached
at qmailtoaster-list-ow...@qmailtoaster.com.

Messages to you from the qmailtoaster-list mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.

If this message bounces too, I will send you a probe. If the probe
bounces,
I will remove your address from the qmailtoaster-list mailing
list,
without further notice.

I'

Re: [qmailtoaster] Fwd: ezmlm warning

[Angus McIntyre]

On 2015-04-12 20:06, Eric Broch wrote:

Are you the administrator of the qmailtoaster MX?


No, I'm not.

I assume that's Eric "shubes".

I'm just a qmailtoaster user, not part of the 'inner circle' (if such a 
thing exists) in any way.


Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] what does this command do?

[Angus McIntyre]

On 2015-04-16 15:43, fsanti...@deviltracks.net wrote:
perl -pi -e 's/global.key._domainkey/dkim1/' 
/var/qmail/control/dkim/public.txt


can someone explain this command to me exactly? Thanks.


It edits the file '/var/qmail/control/dkim/public.txt' and replaces the 
string 'global.key._domainkey' by the string 'dkim1'.


Angus

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] spf

[Angus McIntyre]

On 2015-04-29 10:03, Dave M wrote:

What test to confirm the SPF records ?


There are some good tools at:

http://www.kitterman.com/spf/validate.html

Incidentally, don't expect too much from SPF. There are plenty of 
services (Yahoo!, I'm looking at you) which will happily try to deliver 
spam even when your SPF record indicates that the sender can't possibly 
be a legitimate sender. And they will also send all the non-delivery 
reports straight to the forged address in the 'From' line.


Some Russian watches'n'pills spammers regularly forge the 'admin@' 
addresses of a couple of my domains in the 'From' lines of their spams, 
and each time they do, I get a metric ton of backscatter.


However, I suspect that the spammers _do_ pay attention to SPF records. 
The domains that the Russians have picked to abuse originally had more 
permissive SPF settings; domains that have more restrictive settings 
don't get abused this way. So it's probably worth getting the correct 
settings right when you first set up a domain, just to make sure they 
don't add you to their 'forge-this-domain-for-the-rest-of-time' lists.


Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] qtp-install-sanesecurity needs update for new SaneSecurity script version

[Angus McIntyre]

It seems that there’ve been some changes in the SaneSecurity package, which 
provides additional ‘virus’ signatures for ClamAV.

Recently, the cron job that pulls down new definitions has started erroring out 
on my server with reports such as:

Clamscan reports Sanesecurity honeynet.hdb database integrity tested BAD - 
SKIPPING
rsync: link_stat "/usr/share/clamav/unofficial-dbs/si-dbs/honeynet.hdb" failed: 
No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 
23) at main.c(1039) [sender=3.0.6]

I tried to refresh the SaneSecurity install using:

   qtp-install-sanesecurity

but this generated the error:

   unable to reach 
http://sourceforge.net/projects/unofficial-sigs/files/clamav-unofficial-sigs-3.7.1.tar.gz/download,
 please try again later.

It seems that the installer should now be at:

   
http://sourceforge.net/projects/unofficial-sigs/files/clamav-unofficial-sigs-3.7.2.tar.gz/download
 


To try to fix this, I opened up 
'/opt/qmailtoaster-plus/bin/qtp-install-sanesecurity’ and changed the line:

   PKG_VER=3.7.1

to

   PKG_VER=3.7.2

and then ran the install script.

Running the update command usually run by the cron job:

   /usr/sbin/clamav-unofficial-sigs.sh -c /etc/clamav-unofficial-sigs.conf

seems to have executed without error.

I’m not sure who’s currently maintaining this package, but in the meantime if 
you’re encountering issues with this, then you might like to try this fix.

Angus

Re: [qmailtoaster] qtp-install-sanesecurity needs update for new SaneSecurity script version

[Angus McIntyre]

It’s probably worth doing (thank you, Eric), but it doesn’t seem to have 
resolved the issue with the missing databases.

It looks to me as if one of the signature providers, SecuriteInfo, has 
withdrawn some of their databases.

I’ve tried a new manual fix, which is to edit:

/etc/clamav-unofficial-sigs.conf

and set the ‘si_dbs’ variable to just:

si_dbs=“
securiteinfo.hdb
securiteinfohtml.hdb
"

I’ll let you know if that turns out to fix the issue.

Angus


> On May 29, 2015, at 11:52 PM, Eric Broch  wrote:
> 
> Thanks for the info, Angus. I'm going to create an rpm for this.
> 
> On 5/29/2015 8:30 AM, Angus McIntyre wrote:
>> It seems that there’ve been some changes in the SaneSecurity package, which 
>> provides additional ‘virus’ signatures for ClamAV.
>> 
>> Recently, the cron job that pulls down new definitions has started erroring 
>> out on my server with reports such as:
>> 
>> Clamscan reports Sanesecurity honeynet.hdb database integrity tested BAD - 
>> SKIPPING
>> rsync: link_stat "/usr/share/clamav/unofficial-dbs/si-dbs/honeynet.hdb" 
>> failed: No such file or directory (2)
>> rsync error: some files/attrs were not transferred (see previous errors) 
>> (code 23) at main.c(1039) [sender=3.0.6]
>> 
>> I tried to refresh the SaneSecurity install using:
>> 
>>qtp-install-sanesecurity
>> 
>> but this generated the error:
>> 
>>unable to reach 
>> http://sourceforge.net/projects/unofficial-sigs/files/clamav-unofficial-sigs-3.7.1.tar.gz/download
>>  
>> <http://sourceforge.net/projects/unofficial-sigs/files/clamav-unofficial-sigs-3.7.1.tar.gz/download>,
>>  please try again later.
>> 
>> It seems that the installer should now be at:
>> 
>>
>> http://sourceforge.net/projects/unofficial-sigs/files/clamav-unofficial-sigs-3.7.2.tar.gz/download
>>  
>> <http://sourceforge.net/projects/unofficial-sigs/files/clamav-unofficial-sigs-3.7.2.tar.gz/download>
>> 
>> To try to fix this, I opened up 
>> '/opt/qmailtoaster-plus/bin/qtp-install-sanesecurity’ and changed the line:
>> 
>>PKG_VER=3.7.1
>> 
>> to
>> 
>>PKG_VER=3.7.2
>> 
>> and then ran the install script.
>> 
>> Running the update command usually run by the cron job:
>> 
>>/usr/sbin/clamav-unofficial-sigs.sh -c /etc/clamav-unofficial-sigs.conf
>> 
>> seems to have executed without error.
>> 
>> I’m not sure who’s currently maintaining this package, but in the meantime 
>> if you’re encountering issues with this, then you might like to try this fix.
>> 
>> Angus
> 

Re: [qmailtoaster] protection against word / excel macro viruses

[Angus McIntyre]

> On Jun 12, 2015, at 1:32 PM, Rajesh M <24x7ser...@24x7server.net> wrote:
> but the issue is that we need a tool that will read the body of thedoc/excel 
> attachment and detect if any macros are present and mark it as spam -- clam 
> does not detect macros many a time since there are too many variations.

Just out of curiosity, are you using the SaneSecurity ClamAV extensions? They 
provide additional signatures for ClamAV, detecting some more malware and some 
other threats. I don’t know if they detect macro viruses, but if you haven’t 
tried them, you might want to give them a try.

If you’re using the new model, you can install them simply enough with:

qtp-install-sanesecurity

You may need to refresh your QMailToaster install scripts, as I believe Eric B. 
has recently updated the qtp-install-security script to use the latest version 
of the SaneSecurity installer.

If you’re not running Spamdyke, I’d strongly recommend that too. It won’t 
specifically look for macro viruses, but some probably non-trivial percentage 
of your incoming macro viruses are going to fail some of Spamdyke’s other 
checks (such as RDNS), so it will at least reduce the numbers you have to deal 
with, and thus the load on your system.

With regard to procmail, as you say, it’s good for moving stuff that has 
already been flagged by another program, and the action part of the procmail 
recipe can do some fairly complex things (for example, I have some recipes that 
add headers to the email, move the message, and then invoke a logging script 
written in Perl on certain conditions). But as far as I know, the pattern part 
of the recipe can only do relatively simple matches; it can’t hand off to a 
scanner script written to detect specific features of a message.

If you had a scanner that could detect the macro viruses you want to eliminate, 
you could put it as part of a preline pipeline in your .qmail-* files. For 
example, this was how I integrated DSPAM into my procmail-based delivery system:

| /usr/bin/dspamc --user "$EXT@$HOST" --deliver=stdout | 
/var/qmail/bin/preline /usr/bin/procmail -p -m 
/home/vpopmail/domains/domain.com/.procmailrc-user

(substitute ‘domain.com’ and ‘user’ as appropriate). You could just write your 
own scanner script in Perl or Python, and drop it in in place of DSPAM in a 
pipeline like that one.

Unfortunately, I haven’t found any information on ways to detect macro viruses 
in a file, so I don’t know how you’d go about writing such a scanner. There’s 
also the performance issue to consider; if you fork a Perl interpreter for 
every email, it could affect performance on your mail server.

What you might do is study all the sample viral files that you have, and try to 
identify common patterns in the messages (not the attachments) that could be 
used to write SpamAssassin rules. In my experience, viral emails often have 
distinctive errors or key phrases that can be used for matching. Of course, 
you’re then committed to an almost permanent arms-race, continually monitoring 
for any viral mails that get past your scanners and developing new rules to 
catch them.

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Shubes

[Angus McIntyre]

> On Sep 17, 2015, at 6:09 PM, Fabian Santiago  
> wrote:
> That's wild. I also ventured over to another mailing list for an organization 
> he's been involved in, main plug. They claim he should be just fine and well 
> and someone claimed to have just recently spoken to him or to have seen a 
> post from him somewhere online about a month ago. I could find no evidence of 
> that and he never chimed into the list discussion as others thought he might. 
> Just my 2 cents. 

I did a little bit of Google stalking, but my results were largely inconclusive.

He hasn’t contributed anything at all to Github for almost exactly a year (last 
activity was, I think, 2014-09-12).

I hope that he’s well and happy and simply taking a break from things for a 
while.

That said, I don’t think there’s anything wrong with taking whatever steps are 
necessary to ensure that -- if he’s not coming back -- the project and its 
critical infrastructure don’t fall apart. I think it should be obvious that it 
wouldn’t be a hostile takeover aimed at wresting control from him, but simply a 
case of passing the torch. The best way to show our appreciation for all the 
hard work Eric has done is by _not_ letting qmailtoaster disappear.

Just my 2c,

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Request for ideas: limiting outbound traffic

[Angus McIntyre]

> On Oct 20, 2015, at 10:29 AM, Dan McAllister  wrote:
> I have an issue I'd like to throw out there -- I have a small number of users 
> (on a server with about 20,000 users) that are abusing the service in that 
> they're purposefully sending out huge amounts of mail.
> 
> Fortunately, so far none of their email campaigns have resulted in any RBL 
> activity, but nearly every large-scale ESP (Email Service Provider) has 
> limits set on the number of outbound messages per day (or per hour) that can 
> be sent. I think we need the ability to enforce that too, but how?

Scanning the outbound logs would tell you when they’re exceeding their quota.

The brute-force solution then be to have a script that scanned the outbound 
logs, counted the number of mails sent, and then changed their password if it 
exceeded the limits. They’d then be shut out, and they’d have to ask you to 
restore their account. The script could also generate a warning mail to them.

That ought to be fairly straightforward to implement, but it’s not very clean.

I’ve come across references to Bruce Guenter’s qmail-qfilter:

http://untroubled.org/qmail-qfilter/ 


which sounds as if it might provide a basis for what you want to do. However, I 
have no experience with this, and no idea whether it’s something supported by 
an un-patched qmailtoaster install.

Angus

[qmailtoaster] QMT -- state of the union?

[Angus McIntyre]

I’ve been running a QMT server on a CentOS 5 VPS for a while, and I’m now 
looking to migrate it to a newer host.

What’s the currently-preferred platform? CentOS 6, or CentOS 7? Are there any 
other special requirements?

Also, I know that in the absence of Eric Shubart, Eric Broch has been doing all 
the heavy lifting and maintaining the RPMs. Is there a document anywhere that 
describes the current step-by-step installation procedure using the RPMs on 
whitehorsetc.com ? Is it essentially unchanged from 
before, or are there new things we need to know?

Final question: has anyone tried using Ansible to manage a QMT install? I’ve 
just started to play around with Ansible, and it seems like a well thought-out 
tool, so I’m wondering how easy it would be to use to automate the process of 
getting QMT up and running.

Thanks,

Angus

Re: [qmailtoaster] QMT -- state of the union?

[Angus McIntyre]

Thank you, Eric.

Ansible is pretty nice:

http://www.ansible.com/get-started <http://www.ansible.com/get-started>

Seems to be a good balance between simplicity and power.

I will probably end up using it to manage my QMT host(s) if I can, so I may 
document my experience here in due course.

Angus


> On Dec 11, 2015, at 10:55 AM, Eric  wrote:
> 
> Hi Angus,
> 
> I've never tried Ansible, I'll have a look at it.
> 
> CentOS 6 is still installed via Github. Look through the list and you can 
> find the procedure to install it.
> 
> For  CentOS 6 updates use the WHTC repo: # rpm -Uvh 
> ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/6/current/noarch/whtc-qmt-1-1.qt.el6.noarch.rpm
>  
> <ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/6/current/noarch/whtc-qmt-1-1.qt.el6.noarch.rpm>
> 
> As for CentOS 7 there are two methods:
>  
> 
> 1) Install CentOS 7 minimal install (I install both options under 
> minimal install. One is development tools and I can't remember the other). 
> 2) curl ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh 
> <ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh>  
> >qt_prep.sh 
> 3) sh qt_prep.sh (Automatic reboot) 
> 4) sh qt_install.sh 
>  
> 
> Or
> 
> 
> 1) Install CentOS 7 minimal install (I install both options under 
> minimal install. One is development tools and I can't remember the other). 
> 2) curl ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh 
> <ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh>  
> >qt_prep.sh 
> 3) sh qt_prep.sh (Automatic reboot) 
> 4) curl 
> ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_grp_install.sh 
> <ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_grp_install.sh> 
> >qt_grp_install.sh
> 5) sh qt_grp_install.sh
>  
> <ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/noarch/whtc-qmt-7-1.noarch.rpm>  2>
> 
> Eric Shubert is still the lead for QMT. I will continue to do packaging in 
> his absence. Eventually, I'd like to move all the work that I've done to 
> GitHub. There are many people using and updating CentOS 7 and have been since 
> near the beginning of this year with success. I'd say that its stable.
> 
> EricB
> 
> On 12/11/2015 8:15 AM, Angus McIntyre wrote:
>> I’ve been running a QMT server on a CentOS 5 VPS for a while, and I’m now 
>> looking to migrate it to a newer host.
>> 
>> What’s the currently-preferred platform? CentOS 6, or CentOS 7? Are there 
>> any other special requirements?
>> 
>> Also, I know that in the absence of Eric Shubart, Eric Broch has been doing 
>> all the heavy lifting and maintaining the RPMs. Is there a document anywhere 
>> that describes the current step-by-step installation procedure using the 
>> RPMs on whitehorsetc.com <http://whitehorsetc.com/>? Is it essentially 
>> unchanged from before, or are there new things we need to know?
>> 
>> Final question: has anyone tried using Ansible to manage a QMT install? I’ve 
>> just started to play around with Ansible, and it seems like a well 
>> thought-out tool, so I’m wondering how easy it would be to use to automate 
>> the process of getting QMT up and running.
>> 
>> Thanks,
>> 
>> Angus
>> 
>> 
> 

Re: [qmailtoaster] Qmail queue is stuck

[Angus McIntyre]

> On Apr 1, 2016, at 10:59 PM, Aneesh Hariyappan  wrote:
> I killed the qmail send pid s and started qmail again .. now the current log 
> shows the following...  and the email queue is piling up.
> 
>  I am using qmail for intranet only.. some of the users enabled forwarding 
> option in their mailbox to their personal email address. From last two days 
> users are not getting any forwarded mails from the intranet mail...
> 
> @400056ff34bb21dfc2b4 delivery 45: deferral: 
> Connected_to_74.125.200.26_but_connection_died._(#4.4.2)/
> @400056ff34bb21dfca84 status: local 0/10 remote 59/60
> @400056ff34bb3420333c delivery 173: deferral: 
> Connected_to_74.125.200.27_but_connection_died._(#4.4.2)/

The first thing I’d try at this point would be:

telnet 74.125.200.27 smtp

and then fake an SMTP session by hand (see 
http://www.anta.net/misc/telnet-troubleshooting/smtp.shtml 
 for an example of 
how to do this).

If you can see what messages the remote side is sending back when it drops the 
connection, that might give you a clue.

If 74.125.200.27 is a box that you control, log on there and start looking at 
logs. If it’s running qmail, then ‘/var/log/qmail/smtp/current’ might give you 
some hints. Running:

tail -f /var/log/qmail/smtp/current | tai64nlocal

in one window while faking your SMTP session in another could be informative.

The ‘Connected … but connection died’ suggests to me that it isn’t a firewall 
issue. If I read that correctly, your sending host is actually able to connect, 
but then the connection is terminated, presumably by the other side (the 
74.125.200.x hosts). My assumption would be that it’s the MTA (mail transport 
agent, i.e. qmail or something like it) that sees the start of your incoming 
messages, goes “Uh, nope” and terminates the connection.

One thing that I know of that will terminate connections is spamdyke. If that’s 
what’s doing it, the reason may show up in the ‘qmail/smtp/current’ log 
(assuming that qmail is running on the 74.125.200.x hosts). Another possibility 
is that the MTA on the 74.125.200.x boxes is simply crashing out, perhaps 
because it can’t allocate memory or because a library is corrupt. However, if 
that were the case I’d expect users on those machines not to be able to receive 
_any_ mail.

Angus

Re: [qmailtoaster] catch all account and the spam

[Angus McIntyre]

> On Jul 7, 2016, at 1:10 PM, Jim Shupert  wrote:
> I am wondering what a "wise" method of doing the catch all account regarding 
> spam might be
> 
> To limit the amount of spam that a standard user who is catch all (me for 
> example )
> 
> I have created a usr named d...@mydom.com 
> this "usr" has a quota of 40 MB … so it goes over quota in a day or so...
> It is ,for the sake of argument , ALL spam.
> what are you wise folk doing?

Because spammers will spam anything and everything — I have seen spam targeting 
‘email addresses’ that were obviously created by some scraper program so dumb 
that it thought a message ID (something like 
“122324313109.1231...@somedomain.com”) was an email account — I would question 
whether there’s any value in having a catch-all. Better to set up .qmail files 
for the addresses you actually want, and then just send everything else to 
/dev/null.

To do that, create a ‘.qmail-default’ file for your domain, enter a ‘#’ 
character on the first line, and then add one blank line after it.

If you think that you might some day get useful mail sent to a catch-all 
address, then you’ll probably want to do two things. 

One is to set up a cron job that just throws away everything in the catch-all 
account at regular intervals, so that you don’t go over quota and start 
bouncing mail.

The other is to use something like procmail to filter the mail coming into the 
catch-all. You can write two kinds of filters. One filter will throw away stuff 
that’s known to be spam (to prevent the mailbox overflowing, and to reduce the 
amount of mail you need to review manually). The other should look for 
particular keywords that indicate something that might be interesting to you, 
and divert that to one of your active mailboxes.

Also consider making use of Spamdyke features — for example, rejecting messages 
from domains without valid RDNS — to reduce the amount of spam you need to 
process.

Angus

Re: [qmailtoaster] catch all account and the spam

[Angus McIntyre]

> On Jul 11, 2016, at 2:16 PM, CarlC Internet Services Service Desk 
>  wrote:
> I know a few years ago, I did have a few customers this happened to. We had 
> to disable the catch-all and instead, set it to bounce-no-mailbox. When we 
> did that, the spammers stopped trying to use the domain as a “from” address 
> [and yes, SPF records made no difference… it was the open catch-all that led 
> the spammers to use the domain as a “from” address].

Can’t resist sticking in my 2c here.

I really have no idea how an open catch-all would make a domain attractive to 
spammers, but let’s leave that aside for now.

As for SPF, the situation is a bit complicated.

I have several domains that — at one time — were set up with SPF records that 
permitted any host to send email with that domain in the ‘From’ line (I had to 
have things that way because I was supporting mobile users).

Spammers picked up two of these domains and added them to their list of 
‘domains to use when forging From lines’. Ever since, every few months, I see a 
flood of backscatter to those two domains. It peaks, then dies away as the 
spammer switches to other domains.

It’s always just those two domains: other domains that used to have similarly 
permissive settings have not been abused. And domains with more restrictive SPF 
settings have not been abused.

I eventually changed the domains to use much less permissive SPF settings. 
Those domains are now only authorized for a single mail server. Hasn’t changed 
a thing: every few months, the backscatter flood resumes.

Things I conclude:

1. Restrictive SPF records _do_ discourage spammers from forging that domain in 
their ‘From’ lines.

2. Spammers _will_ forge domains with permissive SPF records, but they choose 
them arbitrarily.

3. Once a spammer has added your domain to their list, they will continue 
forging mail from that domain until the Heat Death of the Universe, 
irrespective of the SPF settings. Spammers never revise their domain lists any 
more than they revise their target email lists.

4. A very large number of recipient hosts ignore SPF when deciding whether to 
bounce mail or not. In other words, they don’t look at the SPF record and say 
“Hmm, this message says it comes from f...@bar.com, but bar.com’s SPF record 
says that IP isn’t authorized to send mail. No point sending a bounce message 
that’ll only annoy r...@bar.com.” Instead they just say “Can’t deliver? Bouncey 
bouncey bounce!”

5. Bonus observation: there is not a single ISP on the planet that gives a shit 
about whether a domain that they host is being advertised by spam sent with 
someone else’s domain in the ‘From’ line. Don’t even bother.

This is not a scientific study, and the plural of anecdote is not data. 
Nevertheless, this is what I have observed.

Angus

Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check

[Angus McIntyre]

Peter Peltonen wrote on 1/2/23 11:57 AM:
> Some of my toaster users have their email forwarded to Gmail ... Some
> googling around tells me that SRS could be the solution for this 
> problem.
> 
> There is info on this at Qmailtoaster Wiki, but the site seems to be 
> somehow broken.

Which page are you looking at, and in what way does it seem broken?


http://wiki.qmailtoaster.com/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B

currently loads fine for me, and looks as if it has good information.

I should stress that I haven't tried this yet. I didn't know about SRS
until you posted this (thank you!) but I'm having the same issue as you
and it sounds as if this might be just what I need.

Would anyone who's actually implemented this care to comment?

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] Mail not delivering ... CHKUSER not accepting recipients

[Angus McIntyre]

I have a qmailtoaster that's been running without problems for a while.
I haven't made any configuration changes, and the server is healthy,
with enough disk space available etc.

Today, I noticed that certain expected messages are not getting
delivered. Lots of mail is still coming in without problems, but certain
transactions are failing silently.

The normal pattern that I see in the logs for a healthy delivery looks
something like:

  tcpserver: pid 2356283 from 123.123.123.123
  tcpserver: ok 2356283 s6:111.111.111.111:25 :123.123.123.123::40631
  CHKUSER accepted sender: from  remote  rcpt <> : sender accepted
  CHKUSER accepted any rcpt: from  remote  rcpt
   : accepted any recipient for this domain
  policy_check: remote otheru...@gmail.com -> local myu...@mydomain.com
  (UNAUTHENTICATED SENDER)
  policy_check: policy allows transmission
  simscan:[2356286]:CLEAN (-0.30/100.00):1.9436s:Re_ Some
  Topic:123.123.123.123:otheru...@gmail.com:myu...@mydomain.com
  mail recv: pid 2356286 from  qp 2356287

For the problem ones, it gets as far as:

  CHKUSER accepted sender: from  remote  rcpt <> : sender accepted

and then stops. There's no "CHKUSER accepted any rcpt" and the delivery
never completes.

This doesn't seem to be connected to the actual recipient: all
recipients receive some mail, just not all of it. However, specific
incoming messages appear to fail consistently.

Has anyone encountered this? And do you have any insight into what could
be causing an apparent failure between sender acceptance and recipient
acceptance in CHKUSER? What tests does CHKUSER perform to determine if a
recipient is accepted?

Thanks for any help or suggestions,

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Mail not delivering ... CHKUSER not accepting recipients

[Angus McIntyre]

Answering my own question for the sake of posterity:

The issue turned out to be a timeout while handling TLS encrypted
connections. I was able to fix the problem by editing
`/etc/spamdyke/spamdyke.conf` to change:

  idle-timeout-secs=60

to

  idle-timeout-secs=540

(probably overkill, but I'm leaving it at that until I figure out what
an acceptable setting is).

I still don't understand why this should be happening, when the server
was working fine until yesterday, and nothing in my configuration has
changed. The server is under almost no load (load average: 0.15 or
less), so it's not as if it's overwhelmed.

It also doesn't seem to affect all TLS encrypted messages equally; some
are processed in a couple of seconds at most, others take several minutes.

If anyone has any thoughts on this, I'd be interested to hear them.

Angus




Angus McIntyre wrote on 1/16/23 8:22 PM:
> I have a qmailtoaster that's been running without problems for a while.
> I haven't made any configuration changes, and the server is healthy,
> with enough disk space available etc.
> 
> Today, I noticed that certain expected messages are not getting
> delivered. Lots of mail is still coming in without problems, but certain
> transactions are failing silently.
> 
> The normal pattern that I see in the logs for a healthy delivery looks
> something like:
> 
>   tcpserver: pid 2356283 from 123.123.123.123
>   tcpserver: ok 2356283 s6:111.111.111.111:25 :123.123.123.123::40631
>   CHKUSER accepted sender: from  remoteqt1-f176.google.com:unknown:123.123.123.123> rcpt <> : sender accepted
>   CHKUSER accepted any rcpt: from  remoteqt1-f176.google.com:unknown:123.123.123.123> rcpt
>: accepted any recipient for this domain
>   policy_check: remote otheru...@gmail.com -> local myu...@mydomain.com
>   (UNAUTHENTICATED SENDER)
>   policy_check: policy allows transmission
>   simscan:[2356286]:CLEAN (-0.30/100.00):1.9436s:Re_ Some
>   Topic:123.123.123.123:otheru...@gmail.com:myu...@mydomain.com
>   mail recv: pid 2356286 from  qp 2356287
> 
> For the problem ones, it gets as far as:
> 
>   CHKUSER accepted sender: from  remoteqt1-f176.google.com:unknown:123.123.123.123> rcpt <> : sender accepted
> 
> and then stops. There's no "CHKUSER accepted any rcpt" and the delivery
> never completes.
> 
> This doesn't seem to be connected to the actual recipient: all
> recipients receive some mail, just not all of it. However, specific
> incoming messages appear to fail consistently.
> 
> Has anyone encountered this? And do you have any insight into what could
> be causing an apparent failure between sender acceptance and recipient
> acceptance in CHKUSER? What tests does CHKUSER perform to determine if a
> recipient is accepted?
> 
> Thanks for any help or suggestions,
> 
> Angus
> 
> 
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
> 

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Mail not delivering ... CHKUSER not accepting recipients

[Angus McIntyre]

I'm using 1.03-3.3.1.qt.el8.

I actually found that setting `full-log-dir=/tmp/spamdyke-logs` in the
`spamdyke.conf` file gave me quite a lot of actionable information. I
don't know if it's exactly the same as you'd get by using `SMTP_DEBUG`,
but I found it helpful.

Thanks for your advice,

Angus



Eric Broch wrote on 1/16/23 10:03 PM:
> What version of qmail are you using?
> 
> In the later versions, <=1.03-3.3.4, you can use SMTP_DEBUG to monitor
> the SMTP transaction logged to a different file.
> 
> 
> On 1/16/2023 6:22 PM, Angus McIntyre wrote:
>> I have a qmailtoaster that's been running without problems for a while.
>> I haven't made any configuration changes, and the server is healthy,
>> with enough disk space available etc.
>>
>> Today, I noticed that certain expected messages are not getting
>> delivered. Lots of mail is still coming in without problems, but certain
>> transactions are failing silently.
>>
>> The normal pattern that I see in the logs for a healthy delivery looks
>> something like:
>>
>>    tcpserver: pid 2356283 from 123.123.123.123
>>    tcpserver: ok 2356283 s6:111.111.111.111:25 :123.123.123.123::40631
>>    CHKUSER accepted sender: from  remote >    qt1-f176.google.com:unknown:123.123.123.123> rcpt <> : sender accepted
>>    CHKUSER accepted any rcpt: from  remote >    qt1-f176.google.com:unknown:123.123.123.123> rcpt
>>     : accepted any recipient for this domain
>>    policy_check: remote otheru...@gmail.com -> local myu...@mydomain.com
>>    (UNAUTHENTICATED SENDER)
>>    policy_check: policy allows transmission
>>    simscan:[2356286]:CLEAN (-0.30/100.00):1.9436s:Re_ Some
>>    Topic:123.123.123.123:otheru...@gmail.com:myu...@mydomain.com
>>    mail recv: pid 2356286 from  qp 2356287
>>
>> For the problem ones, it gets as far as:
>>
>>    CHKUSER accepted sender: from  remote >    qt1-f176.google.com:unknown:123.123.123.123> rcpt <> : sender accepted
>>
>> and then stops. There's no "CHKUSER accepted any rcpt" and the delivery
>> never completes.
>>
>> This doesn't seem to be connected to the actual recipient: all
>> recipients receive some mail, just not all of it. However, specific
>> incoming messages appear to fail consistently.
>>
>> Has anyone encountered this? And do you have any insight into what could
>> be causing an apparent failure between sender acceptance and recipient
>> acceptance in CHKUSER? What tests does CHKUSER perform to determine if a
>> recipient is accepted?
>>
>> Thanks for any help or suggestions,
>>
>> Angus
>>
>>
>> -
>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>>
> 
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
> 

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] do we support php 8 ?

[Angus McIntyre]

According to the RoundCube website, the latest version of RoundCube --
v1.6.0 -- should work with PHP 8.1.

Squirrelmail says that the "nightly snapshots" of recent versions are
compatible with "the newest versions of PHP8". That announcement dates
from mid-2021, which is a little ominous.

I haven't tested either of these to confirm.

Angus



Eric Broch wrote on 1/19/23 11:31 PM:
> It seems squirrelmail and roundcubemail don't work with pho 8
> On Jan 17, 2023, at 2:02 PM, Eric Broch  > wrote:
> 
> I just upgraded from 7.4 to 8.0 on a test springdale 8 linux machine
> 
> # dnf module reset php
> # dnf module install php:remi-8.0
> # dnf update
> 
> All the toaster webpages* seem to work (Added user in qmailadmin).
> 
> *qmailadmin
> vqadmin
> isoqlog
> mrtq
> 
> 
> On 1/16/2023 10:09 PM, Remo wrote:
>> Hello I just notice that php 7.4 is going out do we support php 8?
>>
>> Thanks 
>>
>> —
>> Ciao, 
>> Remo
>>

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Issues with wiki.qmailtoaster.com

[Angus McIntyre]

Tony White wrote on 7/11/23 9:10 AM:
>   Can anyone tell me why this is happening please?

At a guess, the site's database is down or unreachable.

> Is anyone else seeing it?

Yes.

We'll probably need to wait for Eric to give the DB a kick.

Eric, would it be worth putting the wiki behind Cloudflare or a Varnish
cache or something to prevent this kind of thing? Or is that not an option?

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] OT - Question about Rocky Linux

[Angus McIntyre]

Remo Mattei wrote on 2/18/24 5:40 PM:

Nevertheless, I would not change Rocky Linux to others at this point.
It rocks. If you have been a Red Hat customer and CentOS then you are
 perfect to become a Rocky guy.


Is Rocky the approved/most-recommended OS for qmailtoaster these days? 
(I believe Alma is also a contender, and there may be others).


I wrote an ansible role to deploy qmailtoaster on CentOS 8 and had it 
just about ready to share when RedHat killed CentOS 8. I'm 
understandably a little wary of trying to repeat the exercise with 
whatever is the new hotness until I'm sure that the new hotness is going 
to stick around for a few years.


Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Qmail Admin File error 6 - IP Address Change

[Angus McIntyre]

Jeff Koch wrote on 4/2/24 9:27 AM:
Hi - we have a user getting File error 6  errors ( IP != IP) when he 
uses qmail admin on his cell phone and tablet and sometimes from his 
office. This is due to his provider changing his IP address during his 
session. I understand qmail admin may view the IP change as session 
spoofing and cancels authentication. Is there any work-around that still 
provides session security?


Would using a VPN help? That way he should at least get an IP that 
remains stable for the duration of a session.


(Although VPN use may trigger heightened security checks at other sites 
that he uses; he may need to be prepared to identify a lot of fire 
hydrants and crosswalks).


Angus




--
https://nomadcode.com/

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Roundcube with QMT

[Angus McIntyre]

> On Feb 13, 2017, at 2:57 PM, CarlC Internet Services Service Desk 
>  wrote:
> Cool, I was always interested in Roundcube.
> 
> Any gotcha's on installation? Or do I just "yum install roundcube" [Doubt
> it's that easy or I would be that lucky] :) ?

I don’t know if it’s as simple as ‘yum install roundcube’. I suspect not.

Below are the notes that I wrote for myself when I set it up on my mailserver. 
I don’t know if this is actually the recommended install procedure, but it 
worked for me. If no one else comes up with a better guide, you could try this 
recipe.

Replace strings such as ,  and  with appropriate 
values for your installation.

I note that I needed to get some PHP components from the ‘webtatic’ repo. This 
may or may not be necessary for you, depending on the version of PHP you have 
and how you have it set up.

I have to say that Roundcube is pretty good; definitely nicer to use than 
Squirrelmail.

Angus


==

Download the latest Roundcube distro from http://roundcube.net/.

Unpack and upload it to '/usr/share/roundcube'.

Make directories writeable:

cd /usr/share/roundcube/
chown -R : temp/ logs/
chmod g+w temp/ logs/

Set up the roundcube database with:

mysql --user=root --pass
> CREATE DATABASE roundcubemail /*!40101 CHARACTER SET utf8 COLLATE 
utf8_general_ci */;
> GRANT ALL PRIVILEGES ON roundcubemail.* TO roundcube@localhost 
IDENTIFIED BY 'password';
> FLUSH PRIVILEGES
> quit

mysql --user=root --pass roundcubemail < SQL/mysql.initial.sql

Add to a suitable Apache vhost configuration file, such as:

/etc/httpd/conf/vhosts/.conf

the following:


Alias /email/rc /usr/share/roundcube


Options None
Order allow,deny
allow from all


Install PHP DOM support with:

yum --enablerepo=webtatic install php-xml php-mcrypt php-intl

Check the Apache configuration and restart.

In a web browser, go to:

https:///email/rc/installer/

In the General Configuration section:

spellcheck_engine: ATD

In the Database Setup section

Enter database password

In IMAP Settings section

username_domain: 

In SMTP Settings section

smtp_server: 
smtp_port: 587
smtp_user/smtp_pass:
[x] Use the current IMAP username and password for SMTP 
authentication

On the next screen, download the configuration file. Then upload it to

/usr/share/roundcube/config

Open the configuration file and edit it to apply the following SMTP settings:

$config['smtp_server'] = 'tls://';
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
$config['smtp_port'] = 587;

Also, enable the Mark as Junk button with:

   $config['plugins'] = array('markasjunk');

In /usr/share/roundcube/config/defaults.inc.php, change the MIME types setting 
to:

$config['mime_types'] = '/usr/share/roundcube/mime.types';

Get a MIME types file with:

cd /usr/share/roundcube
wget 
http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

Then disable the installer:

mv installer/ installer-done


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] QMT install and Ansible

[Angus McIntyre]

I’m in the process of setting up a new qmailtoaster box for the first time in 
many years, and I’m checking over the install scripts. It looks like Eric has 
done an amazing job of packaging the process.

My tool of choice for system administration now is Ansible 
(https://www.ansible.com/), which allows you to write ‘playbooks’ that list 
tasks to be carried out to set up software. For me, Ansible is pretty much at 
the sweet spot for the tradeoff between power and simplicity, but there are 
other near-alternatives such as Chef, Puppet and Terraform.

The qt_install.sh script isn’t suitable for running via Ansible, because it 
prompts the user at various points (Ansible is non-interactive). What I’d 
probably need to do in order to install QMT via Ansible is convert the whole 
script to an Ansible playbook. Fortunately, the script is very clear and not 
that complex, so this looks quite achievable.

So I have three questions before I dive in:

  1. Has anyone else tried to write an Ansible role for qmailtoaster?
  2. Is the script as it stands reasonably stable/unlikely to change 
significantly in the near future?
  3. Do any of the commands that the script invokes also prompt for input?

Thanks in advance for any help,

Angus



P.S. If I do get a working Ansible role to deploy QMT, I’ll open-source once 
I’m satisfied that it’s more or less stable and useful.
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] CNAME lookup failed temporarily -- workarounds?

[Angus McIntyre]

I'm running a fairly ancient qmail (netqmail-1.0.5, according to the 
manual) on CentOS 5, and I'm starting to get bitten with increasing 
frequency by the 'CNAME lookup failed temporarily' bug.


I urgently need to build a new host with an up-to-date OS and the latest 
version of qmail and move everything over, but I don't have the time to 
do that right now. I'm very hesitant to screw with this particular 
configuration (which is a mess) in case I bring everything crashing down 
around my ears.


So the question is, is there any easy (temporary) fix for this issue?

Thanks,

Angus

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] CNAME lookup failed temporarily -- workarounds?

[Angus McIntyre]

Eric, very many thanks for this.

I've done the upgrade using the RPMs that you provided and, touch wood, 
everything seems to be going smoothly.


The only problem that I encountered (so far) was with authenticating on 
submission. This turned out to be a softlimit issue: softlimit had 
reverted to its original, lower value in a couple of the supervise 
scripts, and this was stopping a shared library loading. Once I put the 
softlimit back to what it should be, everything returned to normal.


Once again, many thanks for your help with this, and with qmailtoaster 
in general.


Angus



Eric Broch wrote:

Angus,

qmail-toaster ( and pop3d) x86_64 RPMS (CNAME lookup removed) in this
folder:
ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/5/development/x86_64/


On 2/15/2018 7:16 AM, Angus McIntyre wrote:

I'm running a fairly ancient qmail (netqmail-1.0.5, according to the
manual) on CentOS 5, and I'm starting to get bitten with increasing
frequency by the 'CNAME lookup failed temporarily' bug.

I urgently need to build a new host with an up-to-date OS and the
latest version of qmail and move everything over, but I don't have the
time to do that right now. I'm very hesitant to screw with this
particular configuration (which is a mess) in case I bring everything
crashing down around my ears.

So the question is, is there any easy (temporary) fix for this issue?

Thanks,

Angus

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com





-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Simultaneous pop3 connections from two devices

[Angus McIntyre]

I doubt a single user would ever need 256 simultaneous connections, but 
-- judging by the name -- the setting might specify the number of 
connections allowed from a single IP, which would be different.


If you had a large number of users on a NAT'ted network, so that they 
looked to the server as if they were coming in from a single IP, maybe 
bumping the allowed connections up to 256 would make sense?


Angus


On 2018-10-24 13:52, Jeff Koch wrote:

Hi Nori:

 Thanks, but why would any user need 256 simultaneous pop3
connections?

 Jeff

On 10/24/2018 6:40 AM, Noriyuki Hayashi wrote:


Hi,

Just addtional information.

/etc/dovecot/dovecot.conf

###--- High-performance mode ---###
###--- Do not use imap for SquirrelMail ---###
#service imap-login {
# service_count = 0
# #client_limit = $default_client_limit
# #process_min_avail = 0
# #vsz_limit = 64M
#}
###--- Do not use imap for SquirrelMail ---###
service pop3-login {
service_count = 0
}
###--- High-performance mode ---###

/etc/dovecot/conf.d/20-pop3.conf
#pop3_client_workarounds =

protocol pop3 {
# Space separated list of plugins to load (default is global
mail_plugins).
#mail_plugins = $mail_plugins

# Maximum number of POP3 connections allowed for a user from each
IP address.
# NOTE: The username is compared case-sensitively.
#mail_max_userip_connections = 10
mail_max_userip_connections = 256
}

In my case, I am using 256.

Kind regards,
Nori

On Mon, 22 Oct 2018 20:03:08 -0400
Jeff Koch  wrote:


Hi Eric:

We just installed another CDB version of the QMT. It's working
great - thanks. I have a question.

We have a situation where a user wants to have multiple devices
concurrently connecting via pop3 to his email account so that each
device is downloading messages. He is finding that the second
device is getting a message that only one user can connect to his
pop3 account at a time. Seems to me this used to work on the older
QMT's. Is this behavior normal?

Regards, Jeff Koch


/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Telecommunications Association License No. A-18-9191
Government Resell License No. 301039703002
WATS CO.,LTD.
Kawana Bldg, 5F Kamata
Ota-ku Tokyo, 144-0052 JAPAN
Phone 81-50-5830-5940　
Ext&Mobile：201 VoiceMailDirect：201*1
FAX 81-50-5830-5941
http://wats.gr.jp [1]
Mail： wats @ wats.gr.jp
Please remove the space between @ as double side

Key fingerprint = B53D FF2F BFEA FDA8 1439 38AA 8281 9A3E C9B6 2FC9

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



-

To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com




Links:
--
[1] http://wats.gr.jp


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Mailing list -- frontend web

[Angus McIntyre]

I have used mailman on a qmailtoaster host.

I never loved it. Everything about it, from the UI to the general 
technical approach, seemed to be stuck in about 1996. However, once I'd 
got it set up and working, it did the job and needed very little 
attention.


I'd like to think that there's something nicer available by now, but if 
you can't find it, then mailman will certainly get the job done.


Angus


On 2019-02-01 04:09, Remo Mattei wrote:

Thanks Fabian, I never used mailman myself for a reason or another I
never had the need  until now.

Remo

On Jan 31, 2019, at 17:31, Fabian A. Santiago 
 wrote:




‐‐‐ Original Message ‐‐‐
On Thursday, January 31, 2019 8:13 PM, Remo Mattei  
wrote:


Hello I wonder if anyone has any suggestions on which mailing list to 
use for a project I am going to work on, so clients can automatically 
unsubscribe etc.. Any tips are welcome.


Remo

--

To unsubscribe, e-mail: 
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com


Hello,

I've always been a fan of mailman and have myself used it with 
qmailtoaster in the past. i don't have all the helpful little tidbits 
as to how at my disposal currently but it is very much possible to get 
it working. I'll send along whatever i can dig up. personally i would 
stick with the 2.x version series but that's just out of familiarity. 
the 3.x series is still a little new'ish.



--

Thanks,

Fabian S.

OpenPGP:

0x643082042DC83E6D94B86C405E3DAA18A1C22D8F


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com





-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Mailing list -- frontend web

[Angus McIntyre]

My own notes are a mess, and I did this a long time ago, on a CentOS 5 
server, so I'm not sure how much I can help you.


However, there's actually a page at:

   http://wiki.qmailtoaster.com/index.php/Mailman

that describes how to do it, and I think I followed the instructions there.

That page describes an install on CentOS 6; I don't know if the mailman 
package has been updated for CentOS 7, or whether any of this is still 
relevant.


From my notes, it looks as if the basic installation was done with:

yum --enablerepo=qtp-CentOS install mailman

Following that, I did:

vi /etc/mailman/mm_cfg.py

and added the line:

add_virtualhost('lists.myhost.com','lists.myhost.com')

where 'lists.myhost.com' was a subdomain I set up for this purpose. This 
will set up a virtual host under mailman's control for your web UI. 
Obviously, replace 'lists.myhost.com' with whatever domain you want to use.


Next, I did:

/usr/lib/mailman/bin/genaliases

and then copied the output from that to the end of the '/etc/aliases' file.

I also added a Vpopmail domain with:

  /home/vpopmail/bin/vadddomain lists.myhost.com MyPostmasterPass

and ran the command:

  /usr/lib/mailman/bin/check_perms -f

to check that all permissions were set up properly.

Then I did:

  cp /usr/share/doc/mailman-2.1.*/contrib/qmail-to-mailman.py \
  /usr/lib/mailman/Mailman/MTA/.

(copying the 'qmail-to-mailman.py' script included with the distribution 
into the appropriate place in the installed mailman) and then edited the 
script with:


  vi /usr/lib/mailman/Mailman/MTA/qmail-to-mailman.py

to ensure the following two variables were defined as below:

  MailmanHome = "/usr/lib/mailman"
  MailmanVar = "/var/lib/mailman"

One last thing: the Apache vhost configuration file for this subdomain 
looked like:



ServerName lists.myhost.com
#ServerAlias lists.myhost.com

DocumentRoot /home/www/mylists/www/

ErrorLog /home/www/mylists/logs/error-log
LogLevel error
LogFormat "combined"
CustomLog /home/www/mylists/logs/access-log "combined"

ServerAdmin webmas...@nomadcode.com

AddDefaultCharset UTF-8

ErrorDocument 404 /errordocs/Error404.php
ErrorDocument 403 /errordocs/Error403.html

ScriptAlias /cgi-bin/ "/home/www/mylists/www/cgi-bin/"
ScriptAlias /mailman/ "/usr/lib/mailman/cgi-bin/"

Alias   /pipermail/ /var/lib/mailman/archives/public/


AllowOverride None
Options ExecCGI FollowSymLinks
Order allow,deny
Allow from all



Options Indexes FollowSymLinks
AllowOverride None
Order Deny,Allow
Allow from all



Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all


(obviously, replace 'myhost.com' with whatever domain you're using, and 
'/home/www/mylists/www' by an appropriate path to your host's document 
tree).


I think that should get you most of the way there. I'm sorry not to be 
able to give you more exact instructions, but, as I say, I did this a 
very long time ago and I didn't take the time to document what I did 
properly. Sorry.


Angus

Remo Mattei wrote on 2/1/19 9:03 PM:

Can you share the installation steps?

I need something that has like unsubscribe using a web page, and something I am 
also looking on how to use the ezmlm-cron if anyone has set that up please let 
me know for tips etc.

Remo


On Feb 1, 2019, at 12:56, Angus McIntyre  wrote:

I have used mailman on a qmailtoaster host.

I never loved it. Everything about it, from the UI to the general technical 
approach, seemed to be stuck in about 1996. However, once I'd got it set up and 
working, it did the job and needed very little attention.

I'd like to think that there's something nicer available by now, but if you 
can't find it, then mailman will certainly get the job done.

Angus


On 2019-02-01 04:09, Remo Mattei wrote:

Thanks Fabian, I never used mailman myself for a reason or another I
never had the need  until now.
Remo

On Jan 31, 2019, at 17:31, Fabian A. Santiago  
wrote:
‐‐‐ Original Message ‐‐‐
On Thursday, January 31, 2019 8:13 PM, Remo Mattei  wrote:

Hello I wonder if anyone has any suggestions on which mailing list to use for a 
project I am going to work on, so clients can automatically unsubscribe etc.. 
Any tips are welcome.
Remo
-

Re: [qmailtoaster] Getting multiple copies of emails

[Angus McIntyre]

I've seen duplicate emails when the server is very heavily loaded. If 
you had any runaway processes that were causing loads to spike, you 
could get duplicates.


Angus


On 2019-05-31 09:34, Peter Peltonen wrote:
In the past I remember this kind thing happening with the old Courier 
IMAP.


Upgrading to Dovecot solved the issue.

Buit you probably are running Dovecot already?

Best,
Peter

On Thu, May 30, 2019 at 3:14 AM Jeff Koch  
wrote:



Hi List:

All of a sudden this morning everyone using one of our QMT7 
mailservers has started getting 6,7,8 copies of each email. This is 
with IMAP accounts. It seems as if the mailserver is not registering 
or marking the emails that they have already been downloaded. I 
checked and we don't have multiple copies on the mailserver itself - 
just on the email clients that connect to it.


Any ideas ? Everything was working fine until this morning.

Regards, Jeff


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] fail2ban and 'null password given'

[Angus McIntyre]

If you're smart, you're probably running 'fail2ban' (or something 
similar) on your qmailtoaster to block password-guessing attempts. You 
may also have used the rules given at:


    http://wiki.qmailtoaster.com/index.php/Fail2Ban

to configure it.

This morning I happened to check my logs and discovered a ridiculous 
number of password-guessing attempts from a single IP, all of which had 
apparently gone unblocked by fail2ban. It turned out that the attacker 
was sending an empty password string, so that the log lines looked 
something like:


 vchkpw-submission: null password given phil:192.129.186.58

There was no corresponding rule in my 
'/etc/fail2ban/filter.d/vpopmail.conf' to capture this case, so the 
attacker was able to try over and over again, unbanned.


The attack script seems to be badly broken: it hits the same usernames 
over and over again, always with the same null password, and without 
even including the hostname part of the username (i.e. 'phil' rather 
than 'p...@example.com'), so I'd rate its chances of succeeding as 
minimal. Still, it'll inflate your log files, so you probably want to 
ban it.


So you might want to consider tweaking your fail2ban configuration to 
ensure that the failregex in 'vpopmail.conf' successfully matches 'null 
password given' as well as the default 'vpopmail user not found' string.


Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] sslv3 alert handshake failure

[Angus McIntyre]

I've recently started getting bounces when trying to send email to one 
particular domain. The errors read:


  TLS connect failed:
  error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:
  sslv3 alert handshake failure

I'm running a probably fairly elderly version of QMT on CentOS 5 (yes, I 
know, I know ...). I assume that what's happening is that the remote 
site has disabled support for SSL 3.0 for security reasons, and that 
what I need to do is to switch sslv3 off on my server, to prevent it 
trying that protocol.


Can anyone confirm that, and remind me what part of my configuration I 
need to change to make that happen?


Thanks,

Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] sslv3 alert handshake failure

[Angus McIntyre]

Thank you, Eric.

Unfortunately, I've hit a "can't get there from here" situation. 
Upgrading the SSL library requires a newer version of SSL than I have 
installed. After a lot of repo tweaking, I end up with:


   M2Crypto.SSL.SSLError: tlsv1 alert protocol version

I suspect that this is insoluble, and my best bet is to build a new 
qmailtoaster on a modern version of CentOS. I was hoping to keep this 
one limping along a little longer, but -- unless you have any other 
suggestions -- I think I've come to the end of the line.


Thanks,

Angus




On 2019-06-17 09:27, Eric's mail wrote:

https://www.qmailtoaster.org/newopensslclamavcnt50.html [1]

Get Outlook for Android [2]

On Mon, Jun 17, 2019 at 5:40 AM -0600, "Angus McIntyre"
 wrote:


I've recently started getting bounces when trying to send email to
one
particular domain. The errors read:

TLS connect failed:
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:
sslv3 alert handshake failure

I'm running a probably fairly elderly version of QMT on CentOS 5
(yes, I
know, I know ...). I assume that what's happening is that the remote

site has disabled support for SSL 3.0 for security reasons, and that

what I need to do is to switch sslv3 off on my server, to prevent it

trying that protocol.

Can anyone confirm that, and remind me what part of my configuration
I
need to change to make that happen?

Thanks,

Angus



-

To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com



Links:
--
[1] https://www.qmailtoaster.org//newopensslclamavcnt50.html
[2] https://aka.ms/ghei36


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] sslv3 alert handshake failure

[Angus McIntyre]

Thanks Eric

The problem, as far as I can tell, isn't compatibility with other older 
software. It's that my existing library is too ancient to even pull down 
the 101e version.


I've bitten the bullet and started to build a new toaster, which is 
something I should have done long ago anyway.


One question for you (and the list): what's an appropriate spec for a 
qmailtoaster host? I've created a 2GB Linode instance and am starting to 
build on that, but I could double the memory if necessary. This is for a 
 low-traffic mailserver, handling a good number of domains (30?) but 
each with only a few active users. It will essentially _only_ be running 
the toaster, and possibly DNS, but not much more than that.


Thanks again for your help,

Angus




On 2019-06-17 23:06, Eric Broch wrote:

Angus,

Upgrading will not interfere with present ssl library as the 101e
version is installed under a different name and qmail is linked to it.
Every other package will  continue as usual using older version.

Eric

On 6/17/2019 8:10 PM, Angus McIntyre wrote:

Thank you, Eric.

Unfortunately, I've hit a "can't get there from here" situation. 
Upgrading the SSL library requires a newer version of SSL than I have 
installed. After aA lot of repo tweaking, I end up with:


   M2Crypto.SSL.SSLError: tlsv1 alert protocol version

I suspect that this is insoluble, and my best bet is to build a new 
qmailtoaster on a modern version of CentOS. I was hoping to keep this 
one limping along a little longer, but -- unless you have any other 
suggestions -- I think I've come to the end of the line.


Thanks,

Angus




On 2019-06-17 09:27, Eric's mail wrote:

https://www.qmailtoaster.org/newopensslclamavcnt50.html [1]

Get Outlook for Android [2]

On Mon, Jun 17, 2019 at 5:40 AM -0600, "Angus McIntyre"
 wrote:


I've recently started getting bounces when trying to send email to
one
particular domain. The errors read:

TLS connect failed:
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:
sslv3 alert handshake failure

I'm running a probably fairly elderly version of QMT on CentOS 5
(yes, I
know, I know ...). I assume that what's happening is that the remote

site has disabled support for SSL 3.0 for security reasons, and that

what I need to do is to switch sslv3 off on my server, to prevent it

trying that protocol.

Can anyone confirm that, and remind me what part of my configuration
I
need to change to make that happen?

Thanks,

Angus



-

To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com



Links:
--
[1] https://www.qmailtoaster.org//newopensslclamavcnt50.html
[2] https://aka.ms/ghei36


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com




-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: 
qmailtoaster-list-h...@qmailtoaster.com


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] vpopmail in the latest toaster

[Angus McIntyre]

I'm currently building out a new server, and I'm trying to automate the 
qmailtoaster install process using Ansible.


The last time I did a full qmailtoaster install was several years ago, 
on CentOS 5, and I understand that things have changed a bit since then.


In particular, I believe that vpopmail has moved to a database-backed, 
instead of file-based system. Is that right? If so, is the format 
documented anywhere? I'm basically interested in working out what 
happens when you run 'vadddomain' or 'vadduser': do they only change the 
database, or do they modify other files as well?


I assume that '.qmail' files are still a thing, and that that stuff 
hasn't been offloaded to a database somewhere. Correct?


Any tips or pointers you can give me would be welcome.

Thanks,

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] Testing and development repos

[Angus McIntyre]

This is probably a question for Eric B.

On the 'qmailtoaster.com' homepage, under CentOS 7 QMT Host, section 3, 
it offers three apparent alternatives -- a straight yum update, followed 
by yum update with 'qmt-testing' enabled, and yum update with 
'qmt-devel' enabled. There are then four qmail versions described, one 
current, and three development.


My reading of this is that you get to pick one of these options, and if 
you choose the basic yum update, you get the qmail-1.03-2.1 install, if 
you use 'qmt-testing' you get qmail-1.03-2.1 but with updated versions 
of the supporting software, and if you choose 'qmt-devel', you get one 
of the versions listed as 'development repo'.


Is this more or less correct?

Which development version do you get if you choose 'qmt-devel'?

The qmail-1.03-3.1 repo is shown as having been installed at the end of 
September last year; has it proven stable enough that you'd recommend 
installing it in production?


Thanks in advance for any advice,

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Testing and development repos

[Angus McIntyre]

Thank you, Eric.

And thank you also (again) for all your hard work in maintaining the 
qmailtoaster site and the associated software.


I'm in the process of developing an ansible role for setting up a 
qmailtoaster installation, as another option for people who want to 
install QMT. I'm fairly far along in the process, and it's given me a 
new appreciation of how much work you've put into making everything fit 
together.


The role isn't quite ready for prime time yet, but when I'm satisfied 
that it does everything it should, I'll announce it here and invite 
comments and code reviews.


Thanks,

Angus




Eric Broch wrote on 7/12/19 9:05 AM:

Angus,

Yes, that is correct with respect to versioning.

I believe you get the lastest 1.03-3.1 with update from development.

I've been using this version since creation date and have found no ill 
effects. There have been MANY downloads of this from the repos I 
control, and I can't be sure what people are using it for, hopefully 
production use. There are several other people I know of using the 
latest version successfully.


If there are others please pipe in and let us know your experience.

I wouldn't hesitate to install it in a production environment.

Eric

On 7/11/2019 6:23 PM, Angus McIntyre wrote:

This is probably a question for Eric B.

On the 'qmailtoaster.com' homepage, under CentOS 7 QMT Host, section 
3, it offers three apparent alternatives -- a straight yum update, 
followed by yum update with 'qmt-testing' enabled, and yum update with 
'qmt-devel' enabled. There are then four qmail versions described, one 
current, and three development.


My reading of this is that you get to pick one of these options, and 
if you choose the basic yum update, you get the qmail-1.03-2.1 
install, if you use 'qmt-testing' you get qmail-1.03-2.1 but with 
updated versions of the supporting software, and if you choose 
'qmt-devel', you get one of the versions listed as 'development repo'.


Is this more or less correct?

Which development version do you get if you choose 'qmt-devel'?

The qmail-1.03-3.1 repo is shown as having been installed at the end 
of September last year; has it proven stable enough that you'd 
recommend installing it in production?


Thanks in advance for any advice,

Angus



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] Roundcube login fails on PHP 7.x

[Angus McIntyre]

Has anyone been able to successfully run Roundcube with PHP7 on a QMT 
install?


I'm following -- more or less -- the install guidelines given on the 
qmailtoaster site.


When I have PHP 5.4 installed, I am able to log in and use Roundcube 
without problems.


When I have PHP7.2 or 7.3 installed, attempts to log in fail with the 
error message 'Invalid request! No data was saved.'


Does this sound familiar to anyone and, if so, how did you solve it?

Thanks,

Angus




TECHNICAL DETAILS

Checking the logs at '/var/log/roundcubemail/errors' shows a slew of 
warning messages, most of which read:


	PHP Warning:  count(): Parameter must be an array or an object that 
implements Countable in 
/usr/share/roundcubemail/program/lib/Roundcube/rcube_plugin_api.php on 
line 406


Mixed in with those is a single instance of:

	PHP Warning:  session_start(): Failed to read session data: user (path: 
/var/lib/php/session) in 
/usr/share/roundcubemail/program/lib/Roundcube/rcube_session.php on line 117


It looks to me as if Roundcube is trying and failing to find a plugin 
(or anything else) that implements the 'authenticate' hook. It's 
possible that that's not critical, and that it falls back to some core 
authentication method -- which is then failing because of a 
session-related issue.


Some other data points:

The directory '/var/lib/php/session' exists, and can be read and written 
by the 'apache' user.


The database parameters in '/etc/roundcubemail/config.inc.php' are able 
to connect to the database.


Session storage is set to 'db':

  $config['session_storage'] = 'db'

Changing this to 'php' does not resolve the issue.

Rainloop and Squirrelmail both run without problems on this host. 
Squirrelmail creates session records in '/var/lib/php/session' successfully.


Roundcube version is 1.1.12, and configuration files are taken directly 
from the qmailtoaster.com site.





-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com