Re: [qmailtoaster] How to debug 'qq soft reject'?

[Andrew Swartz]

My machine only had 2GB because I run a VERY bare bones server with no 
web capabilities.


It has been about 8 months since I went down this rabbit hole, so 
forgive me if I get a couple minor points wrong.


* The 'qq soft reject' is generated by qmail-queue (thus the 'qq' part) 
when something in the path between qmail and the queue failed for 
unclear reasons. Therefore the log entry is not super helpful. But if 
you search the web on 'qmail' and 'qq soft reject' all the meaningful 
results are from back in the 2010 era, but they all seemed to have 
determined that clamd and insufficient RAM were the issue.


* For most stable toasters, the clam signature file is the only thing 
between qmail and the the queue file which changes (i.e. grows) 
frequently. But if you upgrade to a different version of clamd, this 
change could easily be enough change in RAM usage to hit your RAM limit.


* I found that the best way to monitor clamd is by installing and 
running "clamdtop" which is a top-like utility which connects to clamd 
and displays its state in real time.  It looks like this:


Notice that it is using 972 megabytes of RAM; that is almost entirely 
the signature file residing in RAM (969 MB).  I just sent a test message 
with a one megabyte attachment, and the total clamd memory went up to 
977 MB for 2-3 seconds while scanning that message (which you can see in 
real time with clamdtop).  When clamd crashes, you'll immediately see it 
because clamdtop immediately exits complaining that it lost its 
connection.  When I first ran clamdtop, I was aghast that clamd was 
using an order of magnitude more memory than anything else on the 
machine, and that this is normal behavior.  But note that this memory 
usage will slowly but relentlessly increase as the size of the signature 
necessarily creeps upward.


As best I can remember, I think that clamd crashes when a message 
arrives to be scanned, but it may be when freshclam runs and clamd 
attempts to load the new signature file (its been 8 months and I did not 
keep notes of the debugging).  You can sort it out by running clamdtop 
in one console and either manually running freshclam or sending a 
message in another console, while also monitoring the log file in 
another console (using 'tailf' command).  You can see the memory usage, 
the crash, and the  'qq soft reject' log entry all in real time.


But the easiest test is to just give the VM another 1-2GB of RAM and see 
if the problem goes away.  If it does, this is almost certainly the problem.


Hope this helps,

-Andy






On 7/23/2020 7:27 AM, Remo Mattei wrote:

well I have 6GB and it still happens at times to get the qq. I have changed the 
ran on the run shall see. This only happens after I convert from Eric original 
Clamv to the new rpm.

Remo


On Jul 23, 2020, at 12:40 AM, Andrew Swartz  wrote:

I had this problem about 8 months ago.  It it was extremely difficult to 
troubleshoot, but I eventually figured it out.

It is a problem which has been around for a decade or more.  The clamav deamon 
signature file, which is updated frequently, continuously grows as the amount 
of malware it needs to recognize grows.  Eventually, the signature file gets so 
big that clamav daemon crashes when it tries to load it due to insufficient 
RAM.  But it was hard to diagnose because the deamon does not crash at startup 
or when it updates the signature file, but rather when it is passed an email to 
scan.  You can confirm this by restarting clamav and noting that it will run 
fine until a mail comes in, at which point it crashes and qmail starts 
reporting the 'qq soft reject' to the log.

I was running on CentOS-7 VM with 2GB of RAM.  I increased the RAM up to 4GB 
and it fixed the problem.

Unfortunately, the signature file will always continue to grow as more malware 
accrues, so in another couple years I'll surely need to increase the RAM again.

Hope this helps.

-Andy



On 7/20/2020 10:01 AM, Angus McIntyre wrote:

My qmailtoaster running on CentOS 7 was behaving fine, but now seems to soft 
reject everything, and I'm having a hard time working out why.
It doesn't seem to be a ClamAV issue: I set 'clam=no' in 
'/var/qmail/control/simcontrol' and restarted qmail, but I still get the 
rejections.
I added 'SIMSCAN_DEBUG="5"' to the list of env vars in 
'/etc/tcprules.d/tcp.smtp', but that doesn't seem to generate any actionable debugging 
output anywhere that I can see.
Does anyone have any suggestions for debugging this issue? I know there's been 
some talk of bad signatures for ClamAV recently, but I _thought_ I'd eliminated 
that as a possibility by turning off clam in simcontrol. If that's not the 
case, how would I identify (and suppress) a bad signature?
Thanks,
Angus
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h

Re: [qmailtoaster] How to debug 'qq soft reject'?

[Andrew Swartz]

I had this problem about 8 months ago.  It it was extremely difficult to 
troubleshoot, but I eventually figured it out.


It is a problem which has been around for a decade or more.  The clamav 
deamon signature file, which is updated frequently, continuously grows 
as the amount of malware it needs to recognize grows.  Eventually, the 
signature file gets so big that clamav daemon crashes when it tries to 
load it due to insufficient RAM.  But it was hard to diagnose because 
the deamon does not crash at startup or when it updates the signature 
file, but rather when it is passed an email to scan.  You can confirm 
this by restarting clamav and noting that it will run fine until a mail 
comes in, at which point it crashes and qmail starts reporting the 'qq 
soft reject' to the log.


I was running on CentOS-7 VM with 2GB of RAM.  I increased the RAM up to 
4GB and it fixed the problem.


Unfortunately, the signature file will always continue to grow as more 
malware accrues, so in another couple years I'll surely need to increase 
the RAM again.


Hope this helps.

-Andy



On 7/20/2020 10:01 AM, Angus McIntyre wrote:
My qmailtoaster running on CentOS 7 was behaving fine, but now seems to 
soft reject everything, and I'm having a hard time working out why.


It doesn't seem to be a ClamAV issue: I set 'clam=no' in 
'/var/qmail/control/simcontrol' and restarted qmail, but I still get the 
rejections.


I added 'SIMSCAN_DEBUG="5"' to the list of env vars in 
'/etc/tcprules.d/tcp.smtp', but that doesn't seem to generate any 
actionable debugging output anywhere that I can see.


Does anyone have any suggestions for debugging this issue? I know 
there's been some talk of bad signatures for ClamAV recently, but I 
_thought_ I'd eliminated that as a possibility by turning off clam in 
simcontrol. If that's not the case, how would I identify (and suppress) 
a bad signature?


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] letsencrypt certificate issue

[Andrew Swartz]

I meant "spamdyke" rather than "spamassassin".

-Andy


On 4/29/2020 7:10 AM, Andrew Swartz wrote:
Letsencrypt certificates are fine for email servers, I've been using 
them for several years.


I initially had this same problem.

Spamassassin/qmail starts a new instance with each new SMTP connection, 
so when a new cert is saved it starts getting used on the next SMTP 
connection.


However, dovecot is a long running daemon and therefore does not work 
like that.  The script which renews the letsencrypt cert must afterwards 
restart dovecot so that the daemon will load the new cert.  That is why 
your email clients are complaining.


You can confirm this by using openssl s_client to connect to SMTP and 
then to pop/imap, and you will likely see that spamassassin/qmail is 
using your new certificate while dovecot is using the old.


-Andy



On 4/29/2020 1:59 AM, Peter Peterse wrote:

Hi,

Are the dovecot and qmail services restarted?

Regarts,
Peter

Solo  schreef op 29 april 2020 11:42:10 CEST:


    Hi.

    I think Letsencrypt are for websites/servers and not for the specifik
    email which require another type of certificate than Letsencrypt 
issues

    - usually that is set up when qmail is installed (openssl) and placed
    /var/qmail/

    /Finn vB

    Den 29-04-2020 kl. 10:52 skrev ChandranManikandan:

    Hi Remo,

    FYI
    ssl_cert = http://panasiagroup.net/fullchain.pem>
    ssl_key = http://panasiagroup.net/privkey.pem>
    # the following will likely be the default at some point
    ssl_dh_parameters_length = 2048


    On Wed, Apr 29, 2020 at 11:48 AM Remo Mattei mailto:r...@mattei.org>> wrote:

    You need to check the /etc/dovecot/toaster.conf file that’s where
    the cert for outlook and thunder lives.

    Remo

    On Apr 28, 2020, at 20:38, ChandranManikandan 

    <mailto:kand...@gmail.com>> wrote:

    Hi Friends,

    certbot renew command showing below message
    Saving debug log to /var/log/letsencrypt/letsencrypt.log

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - -
    - - - - - - -
    Processing /etc/letsencrypt/renewal/xxx.com.conf
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - -
    - - - - - - -
    Cert not yet due for renewal

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - -
    - - - - - - -

    The following certs are not due for renewal yet:
   /etc/letsencrypt/live/xxx.com/fullchain.pem
    <http://xxx.com/fullchain.pem> expires on 2020-06-27 
(skipped)

    No renewals were attempted.
    - - - - - - - - - - - - - - -

    But outlook, thunderbird showing the certificate issue and
    certificate expire date is showing 28-Apr-2020 in 
thunderbird,
    I have checked in website in the same certificate expiry 
date is

    showing 27-06-2020.

    Do i anything done mistake.
    How do i check and fix the above issue.
    Could anyone help me.
    Appreciate your help.

    Note: Centos 7 with qmailtoaster
    --     */Regards,
    Manikandan.C
    /*




    --     */Regards,
    Manikandan.C
    /*



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



--
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn 
beknoptheid.


-
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] letsencrypt certificate issue

[Andrew Swartz]

Letsencrypt certificates are fine for email servers, I've been using 
them for several years.


I initially had this same problem.

Spamassassin/qmail starts a new instance with each new SMTP connection, 
so when a new cert is saved it starts getting used on the next SMTP 
connection.


However, dovecot is a long running daemon and therefore does not work 
like that.  The script which renews the letsencrypt cert must afterwards 
restart dovecot so that the daemon will load the new cert.  That is why 
your email clients are complaining.


You can confirm this by using openssl s_client to connect to SMTP and 
then to pop/imap, and you will likely see that spamassassin/qmail is 
using your new certificate while dovecot is using the old.


-Andy



On 4/29/2020 1:59 AM, Peter Peterse wrote:

Hi,

Are the dovecot and qmail services restarted?

Regarts,
Peter

Solo  schreef op 29 april 2020 11:42:10 CEST:


Hi.

I think Letsencrypt are for websites/servers and not for the specifik
email which require another type of certificate than Letsencrypt issues
- usually that is set up when qmail is installed (openssl) and placed
/var/qmail/

/Finn vB

Den 29-04-2020 kl. 10:52 skrev ChandranManikandan:

Hi Remo,

FYI
ssl_cert = http://panasiagroup.net/fullchain.pem>
ssl_key = http://panasiagroup.net/privkey.pem>
# the following will likely be the default at some point
ssl_dh_parameters_length = 2048


On Wed, Apr 29, 2020 at 11:48 AM Remo Mattei mailto:r...@mattei.org>> wrote:

You need to check the /etc/dovecot/toaster.conf file that’s where
the cert for outlook and thunder lives.

Remo

On Apr 28, 2020, at 20:38, ChandranManikandan mailto:kand...@gmail.com>> wrote:

Hi Friends,

certbot renew command showing below message
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - -
Processing /etc/letsencrypt/renewal/xxx.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - -
Cert not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - -

The following certs are not due for renewal yet:
   /etc/letsencrypt/live/xxx.com/fullchain.pem
 expires on 2020-06-27 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - -

But outlook, thunderbird showing the certificate issue and
certificate expire date is showing 28-Apr-2020 in thunderbird,
I have checked in website in the same certificate expiry date is
showing 27-06-2020.

Do i anything done mistake.
How do i check and fix the above issue.
Could anyone help me.
Appreciate your help.

Note: Centos 7 with qmailtoaster
-- 
*/Regards,

Manikandan.C
/*




-- 
*/Regards,

Manikandan.C
/*


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


--
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn 
beknoptheid.


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

Re: [qmailtoaster] ssl problem

[Andrew Swartz]

Also remember that SSLv3 refers to two different things:

1.  The SSLv3 protocol

2.  The SSLv3 ciphers (known as the ciphersuite).

In the s_client output below, it uses the SSLv3 protocol to negotiate NO 
cipher (i.e. the "Cipher is (NONE)" part).  It establishes a plaintext 
session using the SSLv3 protocol.


Excluding SSLv3 ciphers does not exclude the SSLv3 protocol.  You must 
explicitly exclude both (i.e. the SSLv3 protocol is vulnerable, as are 
some of its ciphers).


You can separately specify protocols and ciphers in the Dovecot config 
file, but I don't remember any way to do it for qmail.


There is a roundabout way, but it has consequences.  SSLv3, TLSv1, 
TLSv1_1 protocols all used the same ciphers (i.e. the SSLv3 ciphers). 
The only way to use the cipher string to forbid the SSLv3 protocol is to 
allow ONLY the TLSv1_2 ciphers.  That works because TLSv1_2 protocol 
introduced new ciphers which are not supported in the older protocols, 
so specifying only TLSv1_2 ciphers forces the TLSv1_2 protocol. However, 
requiring TLSv1_2 protocol has the unintended problem that many older 
OS's (such as CENTOS-5) cannot connect to it because they do not support 
TLSv1_2.


This is not a problem in newer OS's because SSLv3 protocol has been 
removed from newer versions of OpenSSL, so you can pick a ciphersuite 
with the strongest of the old ciphers and it will use the TLSv1 and/or 
TLSv1_1 protocols, which are supported by most older OS's.


If you are savvy/brave enough (I am not), you can recompile OpenSSL with 
SSLv3 protocol disabled.  That is really the effect you want, and may be 
the only way to get it for incoming connections to qmail.


This has been a very long-winded way to say that I don't think you can 
easily accomplish that which you wish.


FYI: this is the issue which prompted me to upgrade from Centos5 to Centos7.

-Andy


PS: It would be nice to have a qmail patch which allows specifying the 
protocols in a file called /control/tlsserverprotocols.






On 4/22/2020 2:53 PM, Eric Broch wrote:
Doesn't '!SSLv3' in your ciphers mean NO SSLv3 is accepted? So, your 
command should be


openssl s_client -connect mx.domain.ltd:25 -starttls smtp -no_ssl3

not the following command which forces ssl3...

openssl s_client -connect mx.domain.ltd:25 -starttls smtp -ssl3

Correct?

On 4/22/2020 9:57 AM, natan maciej milaszewski wrote:

Hi
I have a debian8 and qmail with tcpserver

I have big problem with disable sslv3 - or I dont understand


i crate /var/qmail/control/tlsserverciphers
and put:
ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:+HIGH:+MEDIUM

naw I restart qmail via svc:

svc -d /service/qmail-smtpd
svc -u /service/qmail-smtpd
svc -d /service/qmail
svc -u /service/qmail


and tested via openssl s_client -connect host:25 -starttls smtp -ssl3
and I thinking sslv3 working


openssl s_client -connect mx.domain.ltd:25 -starttls smtp -ssl3
CONNECTED(0003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 127 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
 Protocol  : SSLv3
 Cipher    : 
 Session-ID:
 Session-ID-ctx:
 Master-Key:
 Key-Arg   : None
 Krb5 Principal: None
 PSK identity: None
 PSK identity hint: None
 Start Time: 1587570345
 Timeout   : 7200 (sec)
 Verify return code: 0 (ok)
---

What i doing wrong ?



-
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] SMTPS Port - Who is Failing ?

[Andrew Swartz]

If the problem is arising during the TLS negotiation, then there will 
never be an SMTP session started and therefore there will never be an 
attempt to even submit a password.


I do not think that a TLS negotiation problem will show up in any 
mail-related log file.  I've yet to find it in any log file.


-Andy





On 4/22/2020 5:17 PM, David Bray wrote:

no - but vchkpw, also spamdyke does

so this is blocking people that are providing bad passwords etc ...
but agree, still trying to work out who is doing something other than this

David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 11:15, Remo Mattei > wrote:


qmail does not log to maillog.
Remo

Inviato da iPad


Il giorno 22 apr 2020, alle ore 5:36 PM, David Bray
mailto:da...@brayworth.com.au>> ha scritto:


I agree, have them in place already, they are winners

  * I actually disagree slightly, if I'm not mistaken - it would
be better to have those two entries combined, wouldn't
fail2ban parse the maillog twice in his example ?

I use:
failregex = vchkpw-smtps?: vpopmail user not found .*:
            vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:
            spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: 
origin_rdns:.*$

But - I'm not getting log entries for these guys, maillog is all
silent I watch /var/log/qmail/smtps/current float up and down, CPU
goes up and down, but /var/log/maillog is all silent

David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 00:06, Jaime Lerner
mailto:jaimeler...@geekgoddess.com>>
wrote:

David,

__ __

You might try the suggestions here:
https://www.taverner-rich.com/mitigating-brute-force-attacks/

__ __

I put them in place on my server and it definitely helped.

__ __

Jaime

__ __

*From: *Eric Broch mailto:ebr...@whitehorsetc.com>>
*Reply-To: *mailto:qmailtoaster-list@qmailtoaster.com>>
*Date: *Wednesday, April 22, 2020 at 9:40 AM
*To: *mailto:qmailtoaster-list@qmailtoaster.com>>
*Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?

__ __

Hi David,

I think you're on to something with fail2ban (keying off
maillog). I was monitoring my smtps port (watching the
certificate and encryption scroll by) using /usr/bin/recordio
and /var/log/maillog and found that the bad guys are trying to
login. Here are some failures from maillog:

vchkpw-smtps: vpopmail user not found
testforu...@whitehorsetc.com:92.118.38.83


vchkpw-smtps: password fail (pass: 'somepassword')
someu...@whitehorsetc.com:185.50.149.2


Maybe a fail2ban rule?!

Eric

__ __

On 4/18/2020 4:12 AM, David Bray wrote:

Hi thanks - yes can block that IP

But it’s not just one, and the solution is not fine enough

I want more of a fail2ban rule, bad use bad pass 3 strikes
your out

__ __

I need to know they are mucking round.

__ __

I tried sending myself through the port with a bad
password- sure it blocks it, but there is no log of the
event - it looks like a legit, connection from Ann IP

__ __

On Sat, 18 Apr 2020 at 7:30 pm, Chris mailto:boh...@gmail.com>> wrote:

Here's a great article with instructions on how to
implement an IP blacklist in iptables. Unless you've
got a user in Panama, it looks like you's want to
block 141.98.80.30 



https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/

__ __

On Sat, Apr 18, 2020 at 5:49 PM David Bray
mailto:da...@brayworth.com.au>> wrote:

sure - thanks for replying, this comes in waves
taking the server to it's maximum at times 

__ __

as far as I can see this only logs are this:

__ __

==> /var/log/qmail/smtps/current <==
2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
2020-04-18 05:04:48.480785500 tcpserver: pid 13339
from 141.98.80.30
2020-04-18 05:04:48.480787500 tcpserver: ok 13339
dev.brayworth.com:172.105.181.18:465
:141.98.80.30::25638
2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
2020-04-18 05:04:52.830767500 tcpserver: pid 13340
from 

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Andrew Swartz]

David,

I have no idea where (or even if) incoming TLS sessions are logged.

I've used "openssl s_client" numerous times to see the details of a 
connection, but only from the client perspective.


Openssl does have the "s_server" complement of s_client, but I've never 
used it:


https://www.openssl.org/docs/man1.1.0/man1/s_server.html

Maybe you could:
1. set a firewall rule to redirect the offending IP to a new port, then
2. run openssl s_server listening on the new port in a terminal window 
and thus watch the output of the TLS negotiation (or redirect the output 
to a file).


I've never done this.  But it seems the easiest way to debug a TLS 
negotiation from the server perspective (i.e. see what a remote client 
is doing without access to that client).  Others on the list may have 
better ideas or even some experience doing this.


-Andy



On 4/20/2020 8:15 PM, David Bray wrote:

Hi Andy - you have grasped the problem accurately

As I understand it, the transaction does not leave a great deal of scope 
- negotiate the encryption, send a password successfully or 
unsuccessfully - (at that point it's logged)


So it has to be the negotiation phase ...
but:

  * I've only just built this server
  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
  o I think this adequate I've seen no OOM events - and the size is
what I've used before

The only thing I'm really seeing here that could be an issue is - the 
newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing

I see lots of broken servers, and have to /make allowances/, I do this by:

touch /var/qmail/control/notlshosts/


Noting - that is an outbound thing ... (see 
https://www.qmailtoaster.org/notls.html)


So .. is it possible that a broken client is hitting the port, not 
being able to make the necessary handshake and causing this CPU load 
It's reported in the logs when the server makes an outbound transaction 
like that ...


deferral:

TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./


What would it look like in my logs if they where to have the reverse issue





David Bray
0418 745334
2 ∞ & <


On Tue, 21 Apr 2020 at 02:54, Andrew Swartz <mailto:awswa...@acsalaska.net>> wrote:


Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
events is:

1.  Establish TCP connection
2.  Negotiate SSL/TLS session
3.  Begin SMTP session

Of these, the SSL/TLS negotiation is by far the most CPU-intensive.

Consider trying to see what is happening with the SSL/TLS negotiation.
It may be failing in a way which is slamming the CPU but not showing up
in the SMTP logs because it never completes and thus an SMTP session is
never initiated.

I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
might set a firewall rule where incoming port 465 from that single
IP is
forwarded to stunnel (on another machine) which is set to output
verbose
debug info???

It would be interesting to know the cause.  This could be some clever
DOS attack where a single connection accomplishes the DOS by slamming
the CPU by submitting something invalid to openSSL.  But it might just
be that some spammer is using a home-brewed script which is buggy
and is
unintentionally causing this problem.

There seems no efficient way to block this without figuring out the
cause and doing something to make that cause be logged into some log
file.  Once that is accomplished, fail2ban (or something similar) can
easily add firewall rules to block individual IP's which exhibit this
behavior.

-Andy





On 4/19/2020 10:12 PM, David Bray wrote:
 > Hey thanks Remo
 > smtps is an inbound port, they are contacting me - this IP is in
Russia
 > somewhere - so do I want to engage (perhaps, probably not but ..)
 >
 > I could of course block that IP - but that doesn't help, I'd have to
 > block endless IPs
 >
 > I'd like to know what's taking the CPU load, in theory they
should be
 > connecting, supplying a password (perhaps) and sending data
 > but, there are sometimes bad passwords (2 for the 20th recorded
in maillog)
 >
 > So..
 > What are they doing the other times and why is it taking so much
CPU -
 > if it is just a port knock, why the CPU
 >
 > I need to be able to say, they are bad because ... *what is the
because* ?
 >
 > David Bray
 > 0418 745334
 > 2 ∞ & <
 >
 >
 > On Mon, 20 Apr 2020 at 15:32, Remo Mattei mailto:r...@mattei.org>
 > <mailto:r...@mattei.org <mailto:r...@mattei.org>>> wrote:
 >
 >     Hi,
 >     Can you reach the server?  It mayb

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Andrew Swartz]

David,

I just received this OpenSSL security advisory which may be describing 
your problem.  It describes a vulnerability which allows a DOS attack by 
submitting an invalid certificate.


https://www.openssl.org/news/secadv/20200421.txt


-Andy


On 4/20/2020 8:15 PM, David Bray wrote:

Hi Andy - you have grasped the problem accurately

As I understand it, the transaction does not leave a great deal of scope 
- negotiate the encryption, send a password successfully or 
unsuccessfully - (at that point it's logged)


So it has to be the negotiation phase ...
but:

  * I've only just built this server
  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
  o I think this adequate I've seen no OOM events - and the size is
what I've used before

The only thing I'm really seeing here that could be an issue is - the 
newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing

I see lots of broken servers, and have to /make allowances/, I do this by:

touch /var/qmail/control/notlshosts/


Noting - that is an outbound thing ... (see 
https://www.qmailtoaster.org/notls.html)


So .. is it possible that a broken client is hitting the port, not 
being able to make the necessary handshake and causing this CPU load 
It's reported in the logs when the server makes an outbound transaction 
like that ...


deferral:

TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./


What would it look like in my logs if they where to have the reverse issue





David Bray
0418 745334
2 ∞ & <


On Tue, 21 Apr 2020 at 02:54, Andrew Swartz <mailto:awswa...@acsalaska.net>> wrote:


Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
events is:

1.  Establish TCP connection
2.  Negotiate SSL/TLS session
3.  Begin SMTP session

Of these, the SSL/TLS negotiation is by far the most CPU-intensive.

Consider trying to see what is happening with the SSL/TLS negotiation.
It may be failing in a way which is slamming the CPU but not showing up
in the SMTP logs because it never completes and thus an SMTP session is
never initiated.

I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
might set a firewall rule where incoming port 465 from that single
IP is
forwarded to stunnel (on another machine) which is set to output
verbose
debug info???

It would be interesting to know the cause.  This could be some clever
DOS attack where a single connection accomplishes the DOS by slamming
the CPU by submitting something invalid to openSSL.  But it might just
be that some spammer is using a home-brewed script which is buggy
and is
unintentionally causing this problem.

There seems no efficient way to block this without figuring out the
cause and doing something to make that cause be logged into some log
file.  Once that is accomplished, fail2ban (or something similar) can
easily add firewall rules to block individual IP's which exhibit this
behavior.

-Andy





On 4/19/2020 10:12 PM, David Bray wrote:
 > Hey thanks Remo
 > smtps is an inbound port, they are contacting me - this IP is in
Russia
 > somewhere - so do I want to engage (perhaps, probably not but ..)
 >
 > I could of course block that IP - but that doesn't help, I'd have to
 > block endless IPs
 >
 > I'd like to know what's taking the CPU load, in theory they
should be
 > connecting, supplying a password (perhaps) and sending data
 > but, there are sometimes bad passwords (2 for the 20th recorded
in maillog)
 >
 > So..
 > What are they doing the other times and why is it taking so much
CPU -
 > if it is just a port knock, why the CPU
 >
 > I need to be able to say, they are bad because ... *what is the
because* ?
 >
 > David Bray
 > 0418 745334
 > 2 ∞ & <
 >
 >
 > On Mon, 20 Apr 2020 at 15:32, Remo Mattei mailto:r...@mattei.org>
 > <mailto:r...@mattei.org <mailto:r...@mattei.org>>> wrote:
 >
 >     Hi,
 >     Can you reach the server?  It maybe blocking you. So what
does your
 >     queue looks like?
 >
 >     Here is mine for example:
 >
 >     # qmHandle -L
 >     Messages in local queue: 0
 >     Messages in remote queue: 0
 >
 >     My other server
 >
 >     # qmHandle -L
 >     10355792 (19, L)
 >        Return-path: r...@qmailx.com
<mailto:r...@qmailx.com> <mailto:r...@qmailx.com
<mailto:r...@qmailx.com>>
 >        From: Anacron mailto:r...@qmail.com> <mailto:r...@qmail.com
<mailto:r...@q

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Andrew Swartz]

Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of events is:

1.  Establish TCP connection
2.  Negotiate SSL/TLS session
3.  Begin SMTP session

Of these, the SSL/TLS negotiation is by far the most CPU-intensive.

Consider trying to see what is happening with the SSL/TLS negotiation. 
It may be failing in a way which is slamming the CPU but not showing up 
in the SMTP logs because it never completes and thus an SMTP session is 
never initiated.


I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You 
might set a firewall rule where incoming port 465 from that single IP is 
forwarded to stunnel (on another machine) which is set to output verbose 
debug info???


It would be interesting to know the cause.  This could be some clever 
DOS attack where a single connection accomplishes the DOS by slamming 
the CPU by submitting something invalid to openSSL.  But it might just 
be that some spammer is using a home-brewed script which is buggy and is 
unintentionally causing this problem.


There seems no efficient way to block this without figuring out the 
cause and doing something to make that cause be logged into some log 
file.  Once that is accomplished, fail2ban (or something similar) can 
easily add firewall rules to block individual IP's which exhibit this 
behavior.


-Andy





On 4/19/2020 10:12 PM, David Bray wrote:

Hey thanks Remo
smtps is an inbound port, they are contacting me - this IP is in Russia 
somewhere - so do I want to engage (perhaps, probably not but ..)


I could of course block that IP - but that doesn't help, I'd have to 
block endless IPs


I'd like to know what's taking the CPU load, in theory they should be 
connecting, supplying a password (perhaps) and sending data

but, there are sometimes bad passwords (2 for the 20th recorded in maillog)

So..
What are they doing the other times and why is it taking so much CPU - 
if it is just a port knock, why the CPU


I need to be able to say, they are bad because ... *what is the because* ?

David Bray
0418 745334
2 ∞ & <


On Mon, 20 Apr 2020 at 15:32, Remo Mattei > wrote:


Hi,
Can you reach the server?  It maybe blocking you. So what does your
queue looks like?

Here is mine for example:

# qmHandle -L
Messages in local queue: 0
Messages in remote queue: 0

My other server

# qmHandle -L
10355792 (19, L)
   Return-path: r...@qmailx.com 
   From: Anacron mailto:r...@qmail.com>>
   To: r...@qmailx.com 
   Subject: Anacron job 'cron.daily' on qmailx.com

   Date: 19 Apr 2020 10:28:28 -
   Size: 509 bytes

10358746 (6, L)
   Return-path:
   From: mailer-dae...@qmailxx.com

   To: r...@qmail.com 
   Subject: failure notice
   Date: 19 Apr 2020 11:30:30 -
   Size: 1089 bytes

Messages in local queue: 2
Messages in remote queue: 0

Just wonder it looks that you are using the SMTPs 465, did you try
the 587 Submission that address and see if it goes?
Just wonder if this is tight to that service.

Maybe none of the above but just for troubleshooting steps, I would
try that.

Remo



On Apr 19, 2020, at 22:11, David Bray mailto:da...@brayworth.com.au>> wrote:

Ok - but after all the investigation etc, this is actually the
trigger which caught my eye in the first place

How this comes about is:

 1. User say hey I can't send
 2. I look and see this high CPU load and intermittent failures
for client to send

Any thoughts on where to start looking ..




my smtp/smtps are currently *10*/11 connections


==> /var/log/qmail/smtp/current <==
2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0
2020-04-20 05:07:50.207300500 tcpserver: status: 0/60

==> /var/log/qmail/smtps/current <==
2020-04-20 05:07:54.903665500 tcpserver: status: 9/60
2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5
2020-04-20 05:07:54.936655500 tcpserver: ok 29725
dev.brayworth.com :172.105.181.18:465
 :185.50.149.5::5622
2020-04-20 05:08:00.108657500 tcpserver: status: 10/60
2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5
2020-04-20 05:08:00.152910500 tcpserver: ok 29734
dev.brayworth.com :172.105.181.18:465
 :185.50.149.5::62006
2020-04-20 05:08:05.172650500 tcpserver: status: *11*/60
2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5
2020-04-20 05:08:05.208984500 tcpserver: ok 29740
dev.brayworth.com :172.105.181.18:465
 :185.50.149.5::19686
2020-04-20 

Re: [qmailtoaster] Slow connection and transaction times

[Andrew Swartz]

Are you using Spamdyke?  If so, depending upon configuration, it does
several DNS queries prior to passing the connection to qmail-smtpd.

On mine, it does reverse DNS lookup, checks several DNS blacklists,
etc.  That could easily account for the delayed smtp response.

You could test this by temporarily deactivating Spamdyke and seeing if
that speeds it up.


-Andy



On 12/31/2019 4:41 AM, Angus McIntyre wrote:
> Hmm.
>
> MXToolbox reports that it takes 6 seconds for my server to respond to
> SMTP connections.
>
> spamdyke's 'greeting-delay-secs' is set to 6 seconds.
>
> Well, there's a coincidence. ;-)
>
> Thanks, Eric -- should have thought of that.
>
> Anyone have any intuitions about how effective greeting-delay is as an
> anti-spam tactic, and whether it has any impact on real mail?
>
> Angus
>
>
>
> On 2019-12-31 04:57, Eric Broch wrote:
>> If you have spamdyke installed it may have a timer
>> (greeting-delay-secs=) to inhibit spammers.
>>
>> On 12/31/2019 2:54 AM, Angus McIntyre wrote:
>>> I'm testing a newly-built mail server, and the tool at:
>>>
>>> https://mxtoolbox.com/SuperTool.aspx
>>>
>>> reports very slow connection and transaction times (approx. 6
>>> seconds and 8 seconds respectively). The server is on a reasonably
>>> powerful and very lightly-loaded VM.
>>>
>>> Are these times typical? (I notice that my existing server is
>>> similarly slow). Does qmailtoaster tarpit incoming connections as an
>>> anti-spam measure? Or does this indicate a possible problem
>>> somewhere that I ought to fix?
>>>
>>> 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
>
> -
> 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] spam folder into gmail

[Andrew Swartz]

Your email does not contain a DKIM signature.

The ARC* headers are signatures added by gmail after receipt.

If you had a DKIM signature, it would be below this part of the header 
chain:


Received: frommail.pan-asia.in    ([49.128.33.86])
bymx.google.com    with ESMTPS id 
t6si1129421pgt.557.2019.09.25.21.12.54
for mailto:kand...@gmail.com>>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 25 Sep 2019 21:12:55 -0700 (PDT)
Received-SPF: pass (google.com  : domain 
ofm...@reliancehrconsulting.com    designates 
49.128.33.86 as permitted sender) client-ip=49.128.33.86;
Authentication-Results:mx.google.com  ;
   spf=pass (google.com  : domain ofm...@reliancehrconsulting.com  
  designates 49.128.33.86 as permitted sender) 
smtp.mailfrom=m...@reliancehrconsulting.com  ;
   dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reliancehrconsulting.com  



That and everything above it was added by gmail.

You may have set up the DNS part of DKIM, but your server does not seem 
to be signing the emails.


When you get it working, you can test by sending an email to a 
reflector, like this:


sa-t...@sendmail.net 

It will analyze the smtp session and the email and then email the 
results back to you.


There are several other reflectors listed at the bottom of this page:

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118571-technote-esa-00.html


Hope this helps,

-Andy



On 9/25/2019 8:39 PM, ChandranManikandan wrote:

Hi Friends,

I have tried to send an test email from my domain to gmail.
It is going the gmail spam folder and i have configured SPF and DMARC 
in dns.


Could you look at the below message header in gmail and help me to 
solve this problem.

Delivered-To:kand...@gmail.com  
Received: by 2002:ac0:bf91:0:0:0:0:0 with SMTP id o17csp1656435imk;
 Wed, 25 Sep 2019 21:12:55 -0700 (PDT)
X-Google-Smtp-Source: 
APXvYqxiLedyv3u6JDrnZQHvyrvIcmrH9n2kSrdj3NOCigD3cs53Rm6tgsJPdMbI9UBNqbqOc1Hz
X-Received: by 2002:a63:1720:: with SMTP id x32mr1332168pgl.289.1569471175444;
 Wed, 25 Sep 2019 21:12:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1569471175; cv=none;
 d=google.com  ; s=arc-20160816;
 b=JGxA7PMxFt1qrwUPb9SXj40SHUhyOOPo+pENSvAaYhLkzdijEWpCgu5KWAW3yEfvWA
  a2+Q9sPT9qJQZlwFvFmH4ZRi20KCLo9RMvbkRSW3L/L8Lzztic/OCfj2+o1HKmCKl4gk
  bPWD4Tv9a/0Zg+EqIFUgJD0QhpFnSXMHmw59RoD3EurAA7zex+55NNRdnS2o7aluru0U
  dYI9xixpZd276FwfDDy+FLSh5EYuYTmjkXEMEgmbNCMhGQ5WQ9AASzwVyDbXhFt9ixSN
  JB8MKPw3P8cDyX/+Db1WoflU82H2KbVV+ON4GFhrvDVYkpQiWHbASNVipQfPj2YSItPP
  g6Ng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com  
; s=arc-20160816;
 h=importance:content-transfer-encoding:mime-version:user-agent:cc:to
  :from:subject:date:message-id;
 bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=;
 b=XDv2dnoYR6tpeltyJ8tD82IKUIGCs0888LAX5xt4MqpL8IPAcUqA8xYLJvNx+heJH/
  5xT0tBciuRolqjCA7jRI2BSSTGmO7wKoEuuL8uvaYfpxM+7eGTNpnIV0mLH3V9z7SUr0
  /Wcr/O3KstHzBxoYgAc71UguXyLG6LarOFgjcxvpVh4k3FbMKXJy+7wDDJC5zCfAcSQr
  VrmJqYWJsc4VcgFrs0+O024BqMmlrLn5WycmtpLAZ0LP/tflbx4OzMMoL+K3AvpIdccB
  hHtkCIyNislpUv6EqxxZLvumM2ysFL4Dd7M06ZpBxm5gIA3HVOL33E7JY2YQefIHv/io
  vIpg==
ARC-Authentication-Results: i=1;mx.google.com  ;
spf=pass (google.com  : domain ofm...@reliancehrconsulting.com  
  designates 49.128.33.86 as permitted sender) 
smtp.mailfrom=m...@reliancehrconsulting.com  ;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reliancehrconsulting.com  

Return-Path: mailto:m...@reliancehrconsulting.com>>
Received: frommail.pan-asia.in    ([49.128.33.86])
 bymx.google.com    with ESMTPS id 
t6si1129421pgt.557.2019.09.25.21.12.54
 for mailto:kand...@gmail.com>>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 25 Sep 2019 21:12:55 -0700 (PDT)
Received-SPF: pass (google.com  : domain 
ofm...@reliancehrconsulting.com    designates 
49.128.33.86 as permitted sender) client-ip=49.128.33.86;
Authentication-Results:mx.google.com  ;
spf=pass (google.com  : domain ofm...@reliancehrconsulting.com  
  designates 49.128.33.86 as permitted sender) 

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

I must retract two cipherlist macros which I tossed out in the email 
below.   It was late and I was sleepy.


Both 'HIGH:-SSLv3' and 'ECDHE:DHE:-SSLv3' include ciphersuites with NULL 
encryption, which means unencrypted.  They can be fixed by removing the 
nulls:


'HIGH:-SSLv3:-NULL'

and

'ECDHE:DHE:-SSLv3:-NULL'

However, I was just tossing those out as reasonable quickies.

As a privacy enthusiast, I think it would be more valuable to say that I 
actually USE this:


'TLSv1.2:ECDHE:DHE:-NULL'

Reasons:

1.  It prioritizes the TLS v 1.2 ciphers (all of them)

2.  It adds (at the end) the perfect forward secrecy ciphers from SSLv3 
as long as they don't have NULL encryption.


3.  At the end of the list are about 20 SSLv3 cipher suites that are 
pretty good among that group.  It includes a couple of 3DES and RC4 
ciphersuites, but I'm OK with that considering how weak all of the SSLv3 
MAC routines are (i.e. SHA1 and weaker).


4.  I think this yields a list which prioritizes strong ciphersuites but 
is fairly flexible/tolerant when all else fails. There is no reason that 
an old version of openssl cannot connect using one of the twenty SSLv3 
ciphersuites it includes.


This cipherlist would be problematic for older machines with openssl < 
1.0 because it would not accept the TLSv1.2 and it would add in other 
ridiculously weak ciphers which are no longer available in the newer 
versions (i.e. > 1.0).



Some thoughts about Eric's list 
(ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH):


1.  It looks imported from old versions of openssl.  Many of those are 
no longer available.


2.  When you start with ALL, you have to be very careful to exclude lots 
of the weak stuff.  It seems safer to start with strong ciphers and then 
add some weaker ones as you see fit.


3.  The @STRENGTH macro sorts based upon encryption key size, not 
overall strength of the ciphersuite.  Therefore a lot of SSLv3 
cipersuites are prioritized above TLSv1.2 ciphersuites.  That is 
suboptimal (in general, in my opinion).  Run this to see: /openssl 
ciphers -v 
'ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH'/


I acknowledge that some of these choices are a matter of taste or 
implementation, therefore I'm not recommending this for everyone. But I 
think it makes for good discussion.


Overall, I'm glad people are interested in this.

-Andy



On 9/3/2019 9:46 PM, Andrew Swartz wrote:

Some background:

During the TLS negotiation, the client gives the server a list of 
ciphers which it supports, then from that list the server chooses 
which one to use.


The server's cipher list is a list, in order of preference, of the 
ciphers it will use (from the client's list).  If there is no overlap 
between what the client offers and what the server requires, then the 
connection fails.


The server dose not use the cipher list itself, but rather just passes 
the list to openssl when it requests establishment of the TLS 
connection.  Therefore essentially all servers/clients use the same 
format cipherlist.


The next thing to know is that the list can specify individual ciphers 
or macros like "TLSv1.2".  Most people do not specify individual 
ciphers but rather just use the macros.


There is no right or wrong for a cipher list, as the most appropriate 
list is the one which best meets your security requirements.


The cipherlist "builds" a list of ciphers:

'ALL' adds all of the ciphers (including those with no encrpytion).

'ALL:-SSLv2' adds all the ciphers and then removes all of the SSLv2 
ciphers.


A reasonable cipherlist is:
'HIGH:-SSLv3'

If you want "perfect forward secrecy", try this:
'ECDHE:DHE:-SSLv3'
This will yield a subset of the TLSv1.2 ciphers which has the 
elliptic-curve diffie-hellman-ephemerel ciphers first and then 
standard diffie-hellman-ephemerel ciphers after that.


If you put that into openssl ciphers ( openssl ciphers -v 
'HIGH:-SSLv3') you will note that you only get TLSv1.2 ciphers. That 
is because an important concept is the difference between ciphers and 
protocols.  TLS 1.0 and 1.1 updated the protocol but added no new 
ciphers.  (you can confirm this by comparing "openssl ciphers -v 
'SSLv3' | md5sum" to "openssl ciphers -v 'TLSv1' | md5sum"; you'll get 
an error if you do it with TLSv1.1 because it does not even have a 
list of ciphers).


But note that older servers, such as centos 5, will not be able to 
connect to you (if you use 'ECDHE:DHE:-SSLv3') because their old 
version of openssl does not support TLSv1.2.  In that case, for 
STARTTLS, it will fail, which will default to smtp transmission as 
cleartext.  SMTP is somewhat forgiving, as a failed STARTTLS 
connection will fall back to cleartext, whereas most other TLS 
protocols will fail to connect.


This is a segway into the related topic of "protocols".  Many servers 
(like doveco

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

Theoretically, you can be more strict with dovecot because you are the 
admin for all of those users and you can set the client software 
requirement.  But you have zero input into what every other smtp server 
in the world will use, so you have to be more flexible there.   At least 
in theory.


In monitoring dovecot logs, make sure your .conf has specified the 
ciphers in the highest to lowest order.  If your cipherlist is something 
like 'SSLv3:TLSv1.2" and the client offers SSLv3 ciphers, then your 
server will CHOOSE a SSLv3 cipher.  Example:


Compare the output of /openssl ciphers -v 'SSLv3:TLSv1.2'/ to /openssl 
ciphers -v 'TLSv1.2:SSLv3'/.


Remember, your list is also your order of preference.  I hate using 
'ALL' in the cipherlist because the order is quite random ( try /openssl 
ciphers -v 'ALL'/) and many of the SSLv3 ciphers precede TLSv1.2 
ciphers.  I like to add ciphers in my preferred order rather than state 
ALL and then remove the weak ones.


I used to monitor qmail logs for encryption of incoming mail. But I now 
use spamdyke and it does the encryption, therefore qmail thinks nothing 
is encrypted.  I've yet to find a way around that.


-Andy


On 9/4/2019 5:19 AM, Gary Bowling wrote:



FYI. I wanted to see in the log files, what version people were using 
prior to making changes. To do that you need to add a %k to the 
login_log_format_elements line in the dovecot configuration. So I 
added this to the /etc/dovecot/local.conf file on my toaster.



login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e 
%c %k



After doing this, and watching the logs. I was surprised to find quite 
a few logins with TLSv1. The log file shows "TLSv1 with cipher 
ECDHE-RSA-AES256-SHA (256/256 bits)"



So much for using HIGH:-SSLv3 in the dovecot config!


I'm not sure how to log the version in qmail. Or even which log it 
would be in.



Which also brings up another question. When you require (as we all do 
now) verification of user/password on "send" in the clients. Which is 
an SMTP outgoing server config in most clients. Will that show up in 
the dovecot logs or in the qmail/smtp/send logs? I'm not sure which 
application does that verification.



Thanks, Gary


On 9/4/2019 8:04 AM, Gary Bowling wrote:



That's excellent info Andy, many thanks for that!! I'm going to have 
to go back and read it about 10 times and possibly go read the 
referenced material too!



Questions, I think you are saying that I can put either 'HIGH:-SSLv3' 
in the tlsserverciphers file (and also in the dovecot.conf file) or I 
can do openssl ciphers -v 'HIGH:-SSLv3' > tlsserverciphers to put the 
full individual ciphers in the list?



Can I also put the full individual ciphers in the dovecot.conf? I 
probably wouldn't, but just curious.



I understand the info about the client/server negotiation. But then 
you talk about other servers, I suppose the server to server delivery 
over smtp. In that scenario, does the sending server send the list of 
ciphers and the receiving server match that to what it has and pick 
the first overlapping cipher to use?



In the case of dovecot, if you specify a cipher list and also a min 
protocol, I'm assuming it won't use a cipher for something lower than 
the specified protocol, even if it's in the list? Maybe it doesn't 
offer up a cipher that doesn't meet the min protocol spec?



For my server, I'm not sure I care whether I receive mail from a 
Centos 5 server. I realize many here are still using them, but it's 
been out of support for a while so it should be either patched or 
upgraded. I guess bottom line is I need to try something like the 
following:



tlsservercipher contains ''ECDHE:DHE:-SSLv3'   (without the quotes?)

toaster.conf (in the /etc/dovecot/ dir) contains

ssl_cipher_list = ECDHE:DHE:-SSLv3

ssl_min_protocol = TLSv1.2


Then I need to watch logs to see if I have problems. I'm guessing 
problems would show up in both the dovecot.log and the 
/var/log/qmail/smtp or /var/log/qmail/send logs.



Thanks, Gary



On 9/4/2019 1:46 AM, Andrew Swartz wrote:

Some background:

During the TLS negotiation, the client gives the server a list of 
ciphers which it supports, then from that list the server chooses 
which one to use.


The server's cipher list is a list, in order of preference, of the 
ciphers it will use (from the client's list).  If there is no 
overlap between what the client offers and what the server requires, 
then the connection fails.


The server dose not use the cipher list itself, but rather just 
passes the list to openssl when it requests establishment of the TLS 
connection.  Therefore essentially all servers/clients use the same 
format cipherlist.


The next thing to know is that the list can specify individual 
ciphers or macros like "TLSv1.2".  Most people do not specify 
individual ciphers but rather just use the macros.


There is no right or wrong for a cipher list, as the most 

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

I just fact-checked my statement about enclosing the list in 
single-quotes.  The man page for openssl ciphers specifies only a 
colon-separated list.  The enclosing in single quotes may just be 
community habit rather than an actual requirement.


-Andy


On 9/4/2019 5:04 AM, Andrew Swartz wrote:



On 9/4/2019 4:04 AM, Gary Bowling wrote:



That's excellent info Andy, many thanks for that!! I'm going to have 
to go back and read it about 10 times and possibly go read the 
referenced material too!



Questions, I think you are saying that I can put either 'HIGH:-SSLv3' 
in the tlsserverciphers file (and also in the dovecot.conf file) or I 
can do openssl ciphers -v 'HIGH:-SSLv3' > tlsserverciphers to put the 
full individual ciphers in the list?


Yes, that is correct. But if you use the individual ciphers, the 
format is the same (i.e. enclosed in single quotes, separated by 
colons).  I think the only advantage of using the individual ciphers 
is that you get to put them in the order you prefer.  The advantage of 
the macros is that if you upgrade to openssl 1.1.1 which has TLSv1.3, 
then you automatically get the new ciphers (without having to manually 
regenerate the cipher list).


Can I also put the full individual ciphers in the dovecot.conf? I 
probably wouldn't, but just curious.



Yes, you can (enclosed in single-quotes, colon separated).

I understand the info about the client/server negotiation. But then 
you talk about other servers, I suppose the server to server delivery 
over smtp. In that scenario, does the sending server send the list of 
ciphers and the receiving server match that to what it has and pick 
the first overlapping cipher to use?



With smpt server-to-server, the sending server is considered the 
"client" and the receiving server is considered the "server". Thus the 
two files: //var/qmail/control/tlsserverciphers/ for when you are the 
server and //var/qmail/control/tlsclientciphers/ for when you are the 
client/. /I have the former file as a link to the latter.  I see no 
reason to use a different list for outgoing mail (when you are the 
client) than for incoming mail (when you are the server).  Also, I 
link clientcert.pem to servercert.pem (for the same logic).


In the case of dovecot, if you specify a cipher list and also a min 
protocol, I'm assuming it won't use a cipher for something lower than 
the specified protocol, even if it's in the list? Maybe it doesn't 
offer up a cipher that doesn't meet the min protocol spec?



I believe that that is wrong.  If you configure as such, it will use 
the SSLv3 protocol with TLSv1.2 ciphers.  I'm only 80% sure of this 
answer.


For my server, I'm not sure I care whether I receive mail from a 
Centos 5 server. I realize many here are still using them, but it's 
been out of support for a while so it should be either patched or 
upgraded. I guess bottom line is I need to try something like the 
following:



tlsservercipher contains ''ECDHE:DHE:-SSLv3'   (without the quotes?)


Yes, but use a single-quote at beginning and end.


toaster.conf (in the /etc/dovecot/ dir) contains

ssl_cipher_list = ECDHE:DHE:-SSLv3


use a single-quote at beginning and end


ssl_min_protocol = TLSv1.2


Yes.  Those are good, secure settings.


Then I need to watch logs to see if I have problems. I'm guessing 
problems would show up in both the dovecot.log and the 
/var/log/qmail/smtp or /var/log/qmail/send logs.



Yes.


Thanks, Gary




-Andy




On 9/4/2019 1:46 AM, Andrew Swartz wrote:

Some background:

During the TLS negotiation, the client gives the server a list of 
ciphers which it supports, then from that list the server chooses 
which one to use.


The server's cipher list is a list, in order of preference, of the 
ciphers it will use (from the client's list).  If there is no 
overlap between what the client offers and what the server requires, 
then the connection fails.


The server dose not use the cipher list itself, but rather just 
passes the list to openssl when it requests establishment of the TLS 
connection.  Therefore essentially all servers/clients use the same 
format cipherlist.


The next thing to know is that the list can specify individual 
ciphers or macros like "TLSv1.2".  Most people do not specify 
individual ciphers but rather just use the macros.


There is no right or wrong for a cipher list, as the most 
appropriate list is the one which best meets your security 
requirements.


The cipherlist "builds" a list of ciphers:

'ALL' adds all of the ciphers (including those with no encrpytion).

'ALL:-SSLv2' adds all the ciphers and then removes all of the SSLv2 
ciphers.


A reasonable cipherlist is:
'HIGH:-SSLv3'

If you want "perfect forward secrecy", try this:
'ECDHE:DHE:-SSLv3'
This will yield a subset of the TLSv1.2 ciphers which has the 
elliptic-curve diffie-hellman-ephemerel ciphers first and then 
standard diffie-hellman-ephemerel ciphers after t

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

On 9/4/2019 4:04 AM, Gary Bowling wrote:



That's excellent info Andy, many thanks for that!! I'm going to have 
to go back and read it about 10 times and possibly go read the 
referenced material too!



Questions, I think you are saying that I can put either 'HIGH:-SSLv3' 
in the tlsserverciphers file (and also in the dovecot.conf file) or I 
can do openssl ciphers -v 'HIGH:-SSLv3' > tlsserverciphers to put the 
full individual ciphers in the list?


Yes, that is correct. But if you use the individual ciphers, the format 
is the same (i.e. enclosed in single quotes, separated by colons).  I 
think the only advantage of using the individual ciphers is that you get 
to put them in the order you prefer.  The advantage of the macros is 
that if you upgrade to openssl 1.1.1 which has TLSv1.3, then you 
automatically get the new ciphers (without having to manually regenerate 
the cipher list).


Can I also put the full individual ciphers in the dovecot.conf? I 
probably wouldn't, but just curious.



Yes, you can (enclosed in single-quotes, colon separated).

I understand the info about the client/server negotiation. But then 
you talk about other servers, I suppose the server to server delivery 
over smtp. In that scenario, does the sending server send the list of 
ciphers and the receiving server match that to what it has and pick 
the first overlapping cipher to use?



With smpt server-to-server, the sending server is considered the 
"client" and the receiving server is considered the "server".  Thus the 
two files: //var/qmail/control/tlsserverciphers/ for when you are the 
server and //var/qmail/control/tlsclientciphers/ for when you are the 
client/. /I have the former file as a link to the latter.  I see no 
reason to use a different list for outgoing mail (when you are the 
client) than for incoming mail (when you are the server).  Also, I link 
clientcert.pem to servercert.pem (for the same logic).


In the case of dovecot, if you specify a cipher list and also a min 
protocol, I'm assuming it won't use a cipher for something lower than 
the specified protocol, even if it's in the list? Maybe it doesn't 
offer up a cipher that doesn't meet the min protocol spec?



I believe that that is wrong.  If you configure as such, it will use the 
SSLv3 protocol with TLSv1.2 ciphers.  I'm only 80% sure of this answer.


For my server, I'm not sure I care whether I receive mail from a 
Centos 5 server. I realize many here are still using them, but it's 
been out of support for a while so it should be either patched or 
upgraded. I guess bottom line is I need to try something like the 
following:



tlsservercipher contains ''ECDHE:DHE:-SSLv3'   (without the quotes?)


Yes, but use a single-quote at beginning and end.


toaster.conf (in the /etc/dovecot/ dir) contains

ssl_cipher_list = ECDHE:DHE:-SSLv3


use a single-quote at beginning and end


ssl_min_protocol = TLSv1.2


Yes.  Those are good, secure settings.


Then I need to watch logs to see if I have problems. I'm guessing 
problems would show up in both the dovecot.log and the 
/var/log/qmail/smtp or /var/log/qmail/send logs.



Yes.


Thanks, Gary




-Andy




On 9/4/2019 1:46 AM, Andrew Swartz wrote:

Some background:

During the TLS negotiation, the client gives the server a list of 
ciphers which it supports, then from that list the server chooses 
which one to use.


The server's cipher list is a list, in order of preference, of the 
ciphers it will use (from the client's list).  If there is no overlap 
between what the client offers and what the server requires, then the 
connection fails.


The server dose not use the cipher list itself, but rather just 
passes the list to openssl when it requests establishment of the TLS 
connection.  Therefore essentially all servers/clients use the same 
format cipherlist.


The next thing to know is that the list can specify individual 
ciphers or macros like "TLSv1.2".  Most people do not specify 
individual ciphers but rather just use the macros.


There is no right or wrong for a cipher list, as the most appropriate 
list is the one which best meets your security requirements.


The cipherlist "builds" a list of ciphers:

'ALL' adds all of the ciphers (including those with no encrpytion).

'ALL:-SSLv2' adds all the ciphers and then removes all of the SSLv2 
ciphers.


A reasonable cipherlist is:
'HIGH:-SSLv3'

If you want "perfect forward secrecy", try this:
'ECDHE:DHE:-SSLv3'
This will yield a subset of the TLSv1.2 ciphers which has the 
elliptic-curve diffie-hellman-ephemerel ciphers first and then 
standard diffie-hellman-ephemerel ciphers after that.


If you put that into openssl ciphers ( openssl ciphers -v 
'HIGH:-SSLv3') you will note that you only get TLSv1.2 ciphers. That 
is because an important concept is the difference between ciphers and 
protocols.  TLS 1.0 and 1.1 updated the protocol but added no new 
ciphers.  (you can confirm th

Re: [qmailtoaster] SSL Problem Dovecot

[Andrew Swartz]

Some background:

During the TLS negotiation, the client gives the server a list of 
ciphers which it supports, then from that list the server chooses which 
one to use.


The server's cipher list is a list, in order of preference, of the 
ciphers it will use (from the client's list).  If there is no overlap 
between what the client offers and what the server requires, then the 
connection fails.


The server dose not use the cipher list itself, but rather just passes 
the list to openssl when it requests establishment of the TLS 
connection.  Therefore essentially all servers/clients use the same 
format cipherlist.


The next thing to know is that the list can specify individual ciphers 
or macros like "TLSv1.2".  Most people do not specify individual ciphers 
but rather just use the macros.


There is no right or wrong for a cipher list, as the most appropriate 
list is the one which best meets your security requirements.


The cipherlist "builds" a list of ciphers:

'ALL' adds all of the ciphers (including those with no encrpytion).

'ALL:-SSLv2' adds all the ciphers and then removes all of the SSLv2 ciphers.

A reasonable cipherlist is:
'HIGH:-SSLv3'

If you want "perfect forward secrecy", try this:
'ECDHE:DHE:-SSLv3'
This will yield a subset of the TLSv1.2 ciphers which has the 
elliptic-curve diffie-hellman-ephemerel ciphers first and then standard 
diffie-hellman-ephemerel ciphers after that.


If you put that into openssl ciphers ( openssl ciphers -v 'HIGH:-SSLv3') 
you will note that you only get TLSv1.2 ciphers.  That is because an 
important concept is the difference between ciphers and protocols.  TLS 
1.0 and 1.1 updated the protocol but added no new ciphers.  (you can 
confirm this by comparing "openssl ciphers -v 'SSLv3' | md5sum" to 
"openssl ciphers -v 'TLSv1' | md5sum"; you'll get an error if you do it 
with TLSv1.1 because it does not even have a list of ciphers).


But note that older servers, such as centos 5, will not be able to 
connect to you (if you use 'ECDHE:DHE:-SSLv3') because their old version 
of openssl does not support TLSv1.2.  In that case, for STARTTLS, it 
will fail, which will default to smtp transmission as cleartext.  SMTP 
is somewhat forgiving, as a failed STARTTLS connection will fall back to 
cleartext, whereas most other TLS protocols will fail to connect.


This is a segway into the related topic of "protocols".  Many servers 
(like dovecot) have separate a setting for "TLS cipherlist" and "TLS 
protocol".  The protocol is the algorithm for establishing the 
connection, and it is independent of the ciphers.  You should avoid the 
SSLv3 or TLSv1 protocols, as the these protocols have been found to have 
weaknesses in how they negotiate the connection (completely unrelated to 
the strength of the ciphers).


This manpage is a good explanation of all the macros and has examples at 
the end:

https://www.openssl.org/docs/man1.0.2/man1/ciphers.html

People with older versions of openssl (i.e. Centos 5) cannot do TLSv1.2 
and will have no choice but to use ciphers/protocols with known 
weaknesses, and then hope that the other servers do not try to force a 
certain level of cipher/protocol.  That is not supposed to happen (per 
smtp/STARTTLS protocol), but I know for a fact that does:  I finally 
decided to upgrade from centos-5 because an important mail server 
started refusing to receive mail from mine, with a complaint about not 
accepting the SSLv3 ciphers.  I think it was Outlook Server, but I'm not 
sure.


Hope this helps.

-Andy

PS: Someone running the old version of openssl will need to put '-SSLv2" 
at the end of the cipherlist, whereas the newer version no longer 
supports it so it doesn't require removing it.  And NO ONE should be 
using the SSLv2 protocol, as hacking it is trivial.








On 9/3/2019 1:22 PM, CarlC Internet Services Service Desk wrote:
Actually, doing the openssl ciphers > /var/qmail/control/tlsservercipher 
is a starting point.


After I did that, I then ran my server through some tests. I happen to 
use OpenVAS [which tool you want to use to find insecure SSL connections 
is up to you]. It was able to tell me which ciphers to disable and why. 
Whichever product you use to test the SSL should be one that’s up to 
date [or can be brought up to date]. For example, I run the tests 
against my email server every week [for example, I test against port 25, 
465 and 587]. In my case, I also use OpenVAS to test the HTTPS side as well.


If you’re using dovecot, you will want to also put the ssl_cipher_list 
in /etc/dovecot/dovecot.conf as well as the ssl_protocols list. This 
protects your IMAPS and POP3S protocols. Again, OpenVAS is set to run 
against those protocols as well.


Carl

*From:*Gary Bowling [mailto:g...@gbco.us]
*Sent:* Tuesday, September 03, 2019 03:35 PM
*To:* qmailtoaster-list@qmailtoaster.com
*Subject:* Re: [qmailtoaster] SSL Problem Dovecot

Thanks for that Carl. I'm running openssl-1.0.2k-16.el7_6.1.x86_64

Pretty much 

Re: [qmailtoaster] Emails to Spam folder

[Andrew Swartz]

I send a lot of email to people with gmail accounts.  I can testify that 
gmail will send you a daily DMARC report with pass/fail stats for the 
preceeding 24 hours.  This was really cool at first.  I turned it off 
(i.e. changed the DMARC record) after about 2-3 wks because it quickly 
became an annoyance.


Gmail definitely follows the rules that you specify.  If you specify 
"reject", it will reject any email which fails the spf check or where 
the dkim signature does not verify.  Mine has been set to "reject" for a 
couple years.  But you should leave it set to "none" for a couple weeks 
and read the reports to make darn sure that everything is working properly.


When I was monitoring this, I was surprised that about 5% of emails end 
up with an invalid DKIM signature for unclear reasons.  But it is not a 
problem when the receiving servers check the signature during the smtp 
transaction and reject the mail, because the sending server will just 
try again and it will go through then.  But if the receiving server 
accepts the mail and filters it after the transaction, and the dkim 
signature fails to verify, the mail will likely get a bad rating and go 
to a spam folder.


-Andy


On 8/30/2019 7:36 AM, Eric Broch wrote:

Hi Chandran,

This email landed in my spam folder sorry to say (gmail).

Never set up a DMARC record...any tutorials you recommend (anyone)?

Eric

On Wed, Aug 28, 2019 at 10:16 PM ChandranManikandan <mailto:kand...@gmail.com>> wrote:


Hi Friends,

I have updated SPF and DMARC record into my DNS server after that
the email is delivered to inbox instead spam/junk folder.

Please try to create SPF and DMARC record in your DNS servers

On Wed, Aug 28, 2019 at 11:39 AM ChandranManikandan
 wrote:

Hi Friends,

As per Andrew stats, i have checked all those points in my server.
I have installed letsencrypt certificate in past two years
without any issue and spf record validated and configured on the
DNS server.
DKIM also installed on my server well.

When users send an email to gmail, some emails are going to
inbox and some going to spam with the same my domain.

I have no clue to setup the dmarc record in the dns server.

Could anyone help me for the process of creating dmarc record.
Do i need to create my server or dns server.

My domain result for the reputation.

MEDIUM REPUTATION

Not suspicious. We have not seen any direct references to this
email address, but the sender domain is highly reputable, and
the email is deliverable. We've observed no malicious or
suspicious activity from this address.

curl emailrep.io/m...@panasiagroup.net

{

"email": "x...@xxx.net",

"reputation": "medium",

"suspicious": false,

"references": 0,

"details": {

"blacklisted": false,

"malicious_activity": false,

"malicious_activity_recent": false,

"credentials_leaked": false,

"credentials_leaked_recent": false,

"data_breach": false,

"first_seen": "never",

"last_seen": "never",

"domain_exists": true,

"domain_reputation": "high",

"new_domain": false,

"days_since_domain_creation": 5524,

"suspicious_tld": false,

"spam": false,

"free_provider": false,

"disposable": false,

"deliverable": true,

"accept_all": false,

"valid_mx": true,

"spoofable": true,

"spf_strict": true,

"dmarc_enforced": false,

"profiles": []

}

}


Appreciate of all your supporting.


On Wed, Aug 28, 2019 at 8:49 AM Andrew Swartz
 wrote:

This seems an issue mostly with server "suspiciousness", of
which
reputation is a component.

Of the factors effecting suspiciousness, only two are local
to the smtp
server:
1.  DKIM signatures
2.  TLS certificates

To address these, confirm that both are working properly:
1.  DKIM: send an email to a "dkim reflector" and then
examine the email
you get back.  This pages discusses:

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118571-technote-esa-00.html

2.  Use a proper TLS certificate.  By proper, I mean one
that verifies.
Therefore you need t

Re: [qmailtoaster] Emails to Spam folder

[Andrew Swartz]

https://www.techrepublic.com/blog/google-in-the-enterprise/reduce-spoofed-email-from-your-domain-with-dmarc/

-Andy



On 8/30/2019 7:36 AM, Eric Broch wrote:

Hi Chandran,

This email landed in my spam folder sorry to say (gmail).

Never set up a DMARC record...any tutorials you recommend (anyone)?

Eric

On Wed, Aug 28, 2019 at 10:16 PM ChandranManikandan <mailto:kand...@gmail.com>> wrote:


Hi Friends,

I have updated SPF and DMARC record into my DNS server after that
the email is delivered to inbox instead spam/junk folder.

Please try to create SPF and DMARC record in your DNS servers

On Wed, Aug 28, 2019 at 11:39 AM ChandranManikandan
 wrote:

Hi Friends,

As per Andrew stats, i have checked all those points in my server.
I have installed letsencrypt certificate in past two years
without any issue and spf record validated and configured on the
DNS server.
DKIM also installed on my server well.

When users send an email to gmail, some emails are going to
inbox and some going to spam with the same my domain.

I have no clue to setup the dmarc record in the dns server.

Could anyone help me for the process of creating dmarc record.
Do i need to create my server or dns server.

My domain result for the reputation.

MEDIUM REPUTATION

Not suspicious. We have not seen any direct references to this
email address, but the sender domain is highly reputable, and
the email is deliverable. We've observed no malicious or
suspicious activity from this address.

curl emailrep.io/m...@panasiagroup.net

{

"email": "x...@xxx.net",

"reputation": "medium",

"suspicious": false,

"references": 0,

"details": {

"blacklisted": false,

"malicious_activity": false,

"malicious_activity_recent": false,

"credentials_leaked": false,

"credentials_leaked_recent": false,

"data_breach": false,

"first_seen": "never",

"last_seen": "never",

"domain_exists": true,

"domain_reputation": "high",

"new_domain": false,

"days_since_domain_creation": 5524,

"suspicious_tld": false,

"spam": false,

"free_provider": false,

"disposable": false,

"deliverable": true,

    "accept_all": false,

"valid_mx": true,

"spoofable": true,

"spf_strict": true,

"dmarc_enforced": false,

"profiles": []

}

}


Appreciate of all your supporting.


On Wed, Aug 28, 2019 at 8:49 AM Andrew Swartz
 wrote:

This seems an issue mostly with server "suspiciousness", of
which
reputation is a component.

Of the factors effecting suspiciousness, only two are local
to the smtp
server:
1.  DKIM signatures
2.  TLS certificates

To address these, confirm that both are working properly:
1.  DKIM: send an email to a "dkim reflector" and then
examine the email
you get back.  This pages discusses:

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118571-technote-esa-00.html

2.  Use a proper TLS certificate.  By proper, I mean one
that verifies.
Therefore you need to either purchase one or use "Let's
Encrypt".  I've
been using Lets Encrypt certs for the last year without any
problems.
Setting up the client is not difficult, and it subsequently
auto-renews
every 60 days.

The remaining factors are outside your server, but just as
important:
1.  Reverse-DNS yields same result as the domain MX record. 
This is
known as FCRDNS (forward-confirmed reverse DNS). 
Additionally, that

result must not resemble a dynamic IP address (i.e. have the
IP address
in the domain name).
2.  SPF is properly set up.
3.  DMARC set up and working properly.
4.  Age of the domain name.  If created recently, that looks
bad.
5.  Presence of IP on blacklists.  That is not hard to
check.  If you
acquired an IP recently, it's former owner may have earned
it a place on
a blacklist.  Easiest fix for that s

Re: [qmailtoaster] Emails to Spam folder

[Andrew Swartz]

This seems an issue mostly with server "suspiciousness", of which 
reputation is a component.


Of the factors effecting suspiciousness, only two are local to the smtp 
server:

1.  DKIM signatures
2.  TLS certificates

To address these, confirm that both are working properly:
1.  DKIM: send an email to a "dkim reflector" and then examine the email 
you get back.  This pages discusses:

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118571-technote-esa-00.html

2.  Use a proper TLS certificate.  By proper, I mean one that verifies. 
Therefore you need to either purchase one or use "Let's Encrypt".  I've 
been using Lets Encrypt certs for the last year without any problems. 
Setting up the client is not difficult, and it subsequently auto-renews 
every 60 days.


The remaining factors are outside your server, but just as important:
1.  Reverse-DNS yields same result as the domain MX record.  This is 
known as FCRDNS (forward-confirmed reverse DNS).  Additionally, that 
result must not resemble a dynamic IP address (i.e. have the IP address 
in the domain name).

2.  SPF is properly set up.
3.  DMARC set up and working properly.
4.  Age of the domain name.  If created recently, that looks bad.
5.  Presence of IP on blacklists.  That is not hard to check.  If you 
acquired an IP recently, it's former owner may have earned it a place on 
a blacklist.  Easiest fix for that seems to be to get a different IP.


I'm curious to hear what others might add to this.

A good place for ideas is to browse through the spamdyke.conf file and 
think about all of the things it checks.  Gmail is certainly using 
similar data points, but with neural network analysis rather than simple 
pass/fail rules.


For those who have set up a second server to test things, there is a 
good chance something above is not set up or does not support the new 
server.  Gone are the days when you can bring a new parallel server 
online and start sending mails immediately.  There are lots of "i's" to 
dot and "t's" to cross before other servers will confidently accept your 
mail.


Another thought:
https://emailrep.io/ will give you a report about an email ADDRESS's 
reputation.  It is interesting.  Here is the result for mine (I replaced 
my email address for posting):


curl emailrep.io/first.l...@example.tld
{
"email": "first.l...@example.tld",
"reputation": "low",
"suspicious": true,
"references": 1,
"details": {
"blacklisted": false,
"malicious_activity": false,
"malicious_activity_recent": false,
"credentials_leaked": false,
"credentials_leaked_recent": false,
"data_breach": false,
"first_seen": "never",
"last_seen": "never",
"domain_exists": true,
"domain_reputation": "low",
"new_domain": false,
"days_since_domain_creation": 5654,
"suspicious_tld": false,
"spam": false,
"free_provider": false,
"disposable": false,
"deliverable": false,
"accept_all": false,
"valid_mx": true,
"spoofable": false,
"spf_strict": true,
"dmarc_enforced": true,
"profiles": []
}
}


Though my domain and address are over 10 years old and never been 
blacklisted, the address gets a "low" reputation.  I'm quite sure that 
is because it has determined that my email address cannot accept emails. 
 But it is incorrect.  After testing it a few times, I'm fairly 
confident that it decides that mostly because it tries to connect to my 
server from smtp25a.kickboxio.net, whose IP (72.249.58.154) is blocked 
by Spamdyke due to being on some blacklist.  Therefore it concludes that 
I'm "risky".  Also, they feel the risk is increased because my email has 
never been seen on social media, in credential breaches, etc.  But I 
feel it is a triumph that I've kept my email address off of places where 
spammers harvest addresses.


Gmail is almost certainly considering all these factor and many more in 
deciding whether an email is rejected, sent to spam folder, or sent to 
inbox.  That said, my wife uses gmail and we send numerous emails back 
and forth daily without any problem.


It used to be that setting up an smtp server was the hard part of 
running your own server.  But times have changed, and now factors 
external to your network seem far more complicated and consequential 
than the server itself.


Again, I'm curious to hear other people thoughts.


-Andy

PS: regarding the question of multiple certs, I do not see how that 
could work on the toaster.  And in general, smtp does not work that way. 
 The cert merely needs to be for the domain name pointed to by the MX 
record of the destination domain.  There is no requirement that the 
destination domain be the name on the server certificate.  Thus numerous 
virtual domains all have MX records which point to the same server; that 
server's cert merely needs to be for its own domain name, not 

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

[Andrew Swartz]

Angus,

That is an intriguing error.

SNI adoption has been very slow for email.  Dovecot supports it for 
POP3/IMAP clients.  Opensmtpd may be the only SMTP server which supports it.


The workaround SMTP behavior has been to look up the MX record of the 
"To:" domain, and then connect to THAT server and verify ITS 
certificate.  So contrary to HTTP where the verified certificate MUST 
match the requested domain name, mail only requires that the certificate 
match the server pointed to by the MX record (regardless of message's 
"To:" domain).


So in general, "SNI" does not come up in discussions of mail server 
certificates.


And thus your error message is quite intriguing.

Can you modify the perl script to output verbose information?


-Andy




On 7/23/2019 5:04 AM, Angus McIntyre wrote:

r...@mattei.org wrote on 7/22/19 11:06 PM:
 > I am not sure why you keep having all this issues. Let me
 > know off line maybe I can take a look.

Thanks, Remo. I think I may be getting closer to a fix.

The issues I was having with PHP/Roundcube installation turned out to be 
because I had the IUS repo enabled, and that was introducing conflicts. 
I've now managed to work past that.


My new problems look like a certificate issue, and I think the problem 
is that my certificate requires SNI.


If I run:

   perl analyze-ssl.pl mail.mydomain.dev:465

I get:

    * SNI supported    : certificate verify fails without SNI
    * certificate verified : FAIL: SSL connect attempt failed
    error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed

whereas if I do:

   perl analyze-ssl.pl mail.mydomain.dev:443

I get:

   * SNI supported    : ok
   * certificate verified : ok

I'm using the same certificate for securing the webserver (port 443) and 
SMTPS (port 465). The webserver works fine, probably because Apache is 
passing the requested hostname to Server Name Indication; SMTPS fails 
with a certificate error, probably because there's no hostname passed to 
SNI, and the server's intrinsic hostname (s6.mydomain.com) doesn't match 
the name on the certificate.


Things I'm going to try:

   1. Adding 'mail.mydomain.dev' to /etc/hosts
   2. Using a self-signed certificate signed to 's6.mydomain.com'.
   3. Buying another certificate specifically for 's6.mydomain.com'

Sound reasonable?

Angus



Il giorno 22 lug 2019, alle ore 19:41, Eric's mail 
 ha scritto:



Angus,

Did you think about simply using port 25, no authentication or 
encryption, which is how squirrelmail on QMT used to be configured, 
relying on HTTPS alone for password and email security across the 
cloud as the email (after the cloud) is submitted directly to the 
server (tcpserver) by the server (apache) itself (127.0.0.1) 
rendering encryption useless or redundant. I think this is the route 
I will go because with every upgrade of roundcube, the webmail I 
prefer, there seems to be issues with past configurations.


Eric

Get Outlook for Android 
* SNI supported    : certificate verify fails without SNI
  * certificate verified : FAIL: SSL connect attempt failed 
error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed




On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus McIntyre" 
mailto:an...@pobox.com>> wrote:


    r...@mattei.org wrote on 7/22/19 10:22 AM:
  > You need to install the cert on your machine. Does the 
/etc/hosts

  > have the name of your machine can you try to ping that name to
  > see if it resolves?

    The certificate is installed.

    The hostname in '/etc/hosts' resolves, and responds to pings.


    I replaced the self-signed PEM that shipped with qmailtoaster 
with one
    that I made myself by concatenating the ‘.key’ and ‘.crt’ files 
from my
    server certificate. Inspecting the resulting .pem with ‘openssl 
x509 -in
    servercert.pem -text’ confirms that the resulting .pem is for the 
domain

    that I expect. File permissions and ownership are correct.

    '/etc/hosts' for my newly-built server contains the following line:

    127.0.1.1 s6.mydomain.com s6

    (obviously, 'mydomain' is not the actual name here). The .pem file
    contains the lines:

    Subject: OU=Domain Control Validated, OU=PositiveSSL,
    CN=mail.mydomain.dev

    and

    X509v3 Subject Alternative Name:
  DNS:mail.mydomain.dev, DNS:www.mail.mydomain.dev

    's6.mydomain.com' and 'mail.mydomain.dev' all resolve to the same 
IP.


    My existing qmailtoaster server (running an older version of the
    software) has '/etc/hosts' containing:

    127.0.1.1 s2.mydomain.com s2

    and the .pem file contains:

    Subject: OU=Domain Control Validated, OU=PositiveSSL 
Multi-Domain,

    CN=mydomain.com

    and

    X509v3 Subject Alternative Name:
  DNS:mydomain.com, DNS:mail.mydomain.com, DNS:www.mydomain.com

    's6.mydomain.com' resolves to the same IP as 'mail.mydomain.dev';
    's2.mydomain.com' resolves to the same IP as 

Re: [qmailtoaster] vpopmail in the latest toaster

[Andrew Swartz]

I built a Centos 7 toaster last year (upgrading from Centos 5).

vpopmail is unchanged and still uses a file system structure for mail 
storage.  Therefore the vpopmail management commands are unchanged.


As I recall, the major headache was migrating the login credentials. 
And once migrated, a snafu was that the old toaster was authenticating 
against a hash of the passwords whereas the new toaster was merely 
matching the plaintext.  Though the full hash was stored, only the first 
16 characters of the plaintext was stored.  Therefore accounts with 
passwords longer than 16 characters could not log in.  The fix was to 
switch to NOT using plaintext password storage which forces 
authentication against the hash.  I think this was a vpopmail setting, 
but I'm not 100% sure.


-Andy



On 6/22/2019 4:23 PM, Angus McIntyre wrote:
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




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

Re: [qmailtoaster] Development version

[Andrew Swartz]

Eric,

I use port 465/TLS for submission, so I agree completely with you.

But I think the discussion was regarding using port 587/STARTTLS.  In 
that setting, STARTTLS is vulnerable to a downgrade attack which tricks 
the conversation to authenticating without the STARTTLS encryption.  So 
if one uses STARTTLS, one must rely on the SMTPAUTH encryption 
(cram-md5).  However, that too is vulnerable (dictionary attack, I 
believe).  This is the reason the RFC now recommends port 465/TLS.


At least, that's my understanding.

-Andy


On 1/27/2019 6:19 PM, Eric Broch wrote:
The password encryption is inside an encrypted tunnel. IMHO opinion it's 
really quite useless.


On 1/27/2019 8:16 PM, Andrew Swartz wrote:

Ahhh... that's right.

But then the next question is should one use cram-md5?  I believe it 
is currently considered insecure.


I just found this link which explains the qmail SMTPAUTH options:
https://www.fehcom.de/qmail/smtpauth.html##SETUP

Unless there is a newer patch, it looks like cram-md5 is the only 
password encryption option.


-Andy


On 1/27/2019 11:20 AM, Philip Nix Guru wrote:

Hello Andy

it is indeed a parameter you set in the env variable in the run file 
(in my case I set it up in the submission run file)


cat /var/qmail/supervise/submission/run
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export SMTPAUTH="!+cram" <<<<<<<<<--

exec /usr/bin/softlimit -m 12800 \
 /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c 
"$MAXSMTPD" \

 -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \
 $SMTPD $VCHKPW /bin/true 2>&1

The current _qmail-authentication_ patch allows you to use the 
environment variable SMTPAUTH for *qmail-smtpd* in the following way:


SMTPAUTH settings for *qmail-smtpd



* *SMTPAUTH* *Meaning*
"" Left blank to allow Authentication types "PLAIN" and "LOGIN"
"+cram" Add "CRAM-MD5" support
"cram" Just (secure) "CRAM-MD5" support, no other types offered
"!" Enforcing SMTP Auth (of type "LOGIN" or "PLAIN")
"!cram" Enforcing SMTP Auth of type "CRAM-MD5"
"!+cram" Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5"
"-" Disabling SMTP Auth (for a particular connection)

The complete patch info is listed here :
https://www.fehcom.de/qmail/smtpauth.html


Regards
-P


On 1/26/19 8:06 PM, Andrew Swartz wrote:
My guess is that there must be a difference in the patches applied 
to qmail-smtpd or a different compile time option.  I don't think 
this is a simple setting (like in qmail/control).


When the connection comes in, tcpserver forwards it to qmail-smtpd. 
If STARTTLS is invoked, qmail-smtpd hands that task off to openssl, 
which then returns the decrypted plaintext.  But the password 
processing, whether plain, login, or encrypted, is likely handled 
directly by qmail-smtpd.


Is anyone out there familiar enough with the source code to confirm 
or refute this?


If it is a compile option, it should be fixable with mild to 
moderate effort.  If it is a patch change, that seems more difficult 
(at least with my skill level).


If you figure this out, please let us know, as others will likely be 
making the migration in the future.



-Andy



On 1/25/2019 1:21 AM, Philip Nix Guru wrote:
I tested with Thunderbird (where the account was working fine with 
stable version and encrypted password on starttls)


and the message came up after the upgrade to change to normal 
password.


When lamba users will get that message they ll just panic and wont 
know what to do.



I still need to check how outlook will react ...


On 1/25/19 10:52 AM, Tommi Järvilehto wrote:
Was there a problem with Outlook and encrypted passwords? Or the 
password cache?


On 25.1.2019 11:43, Philip Nix Guru wrote:

Hello

Yes that's one of the reason I was wondering why encrypted 
password was no longer supported for STARTTLS in the lastest dev 
version


Regards

-P

On 1/25/19 8:56 AM, Andrew Swartz wrote:

I would add the caveat that STARTTLS is only "probably safe".

Unfortunately, it suffers from a critical error in the very 
concept of going from an plaintext session to a TLS session, 
resulting in an unfixable (as far as I know) vulnerability.  A 
man-in-the-middle can inject text into the server response to 
tell the client that STARTTLS is not available and that the 
conversation should therefore continue in plaintext.  I've read 
that several ISP's have been caught using this vulnerability to 
scan people's outgoing email. That means PLAIN or LOGIN ty

Re: [qmailtoaster] Development version

[Andrew Swartz]

Ahhh... that's right.

But then the next question is should one use cram-md5?  I believe it is 
currently considered insecure.


I just found this link which explains the qmail SMTPAUTH options:
https://www.fehcom.de/qmail/smtpauth.html##SETUP

Unless there is a newer patch, it looks like cram-md5 is the only 
password encryption option.


-Andy


On 1/27/2019 11:20 AM, Philip Nix Guru wrote:

Hello Andy

it is indeed a parameter you set in the env variable in the run file (in 
my case I set it up in the submission run file)


cat /var/qmail/supervise/submission/run
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export SMTPAUTH="!+cram" <<<<<<<<<--

exec /usr/bin/softlimit -m 12800 \
     /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
     -u "$QMAILDUID" -g "$NOFILESGID" 0 587 \
     $SMTPD $VCHKPW /bin/true 2>&1

The current _qmail-authentication_ patch allows you to use the 
environment variable SMTPAUTH for *qmail-smtpd* in the following way:


SMTPAUTH settings for *qmail-smtpd



* *SMTPAUTH**Meaning*
""Left blank to allow Authentication types "PLAIN" and "LOGIN"
"+cram"   Add "CRAM-MD5" support
"cram"Just (secure) "CRAM-MD5" support, no other types offered
"!"   Enforcing SMTP Auth (of type "LOGIN" or "PLAIN")
"!cram"   Enforcing SMTP Auth of type "CRAM-MD5"
"!+cram"  Enforcing SMTP Auth of type "LOGIN", "PLAIN", or "CRAM-MD5"
"-"   Disabling SMTP Auth (for a particular connection)

The complete patch info is listed here :
https://www.fehcom.de/qmail/smtpauth.html


Regards
-P


On 1/26/19 8:06 PM, Andrew Swartz wrote:
My guess is that there must be a difference in the patches applied to 
qmail-smtpd or a different compile time option.  I don't think this is 
a simple setting (like in qmail/control).


When the connection comes in, tcpserver forwards it to qmail-smtpd.  
If STARTTLS is invoked, qmail-smtpd hands that task off to openssl, 
which then returns the decrypted plaintext.  But the password 
processing, whether plain, login, or encrypted, is likely handled 
directly by qmail-smtpd.


Is anyone out there familiar enough with the source code to confirm or 
refute this?


If it is a compile option, it should be fixable with mild to moderate 
effort.  If it is a patch change, that seems more difficult (at least 
with my skill level).


If you figure this out, please let us know, as others will likely be 
making the migration in the future.



-Andy



On 1/25/2019 1:21 AM, Philip Nix Guru wrote:
I tested with Thunderbird (where the account was working fine with 
stable version and encrypted password on starttls)


and the message came up after the upgrade to change to normal password.

When lamba users will get that message they ll just panic and wont 
know what to do.



I still need to check how outlook will react ...


On 1/25/19 10:52 AM, Tommi Järvilehto wrote:
Was there a problem with Outlook and encrypted passwords? Or the 
password cache?


On 25.1.2019 11:43, Philip Nix Guru wrote:

Hello

Yes that's one of the reason I was wondering why encrypted password 
was no longer supported for STARTTLS in the lastest dev version


Regards

-P

On 1/25/19 8:56 AM, Andrew Swartz wrote:

I would add the caveat that STARTTLS is only "probably safe".

Unfortunately, it suffers from a critical error in the very 
concept of going from an plaintext session to a TLS session, 
resulting in an unfixable (as far as I know) vulnerability.  A 
man-in-the-middle can inject text into the server response to tell 
the client that STARTTLS is not available and that the 
conversation should therefore continue in plaintext.  I've read 
that several ISP's have been caught using this vulnerability to 
scan people's outgoing email. That means PLAIN or LOGIN type 
submission passwords can be seen.


This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has 
strongly recommended abandoning STARTTLS on port 587 and using 
dedicated TLS on port 465 for mail submission.


-Andy





On 1/24/2019 9:30 PM, Eric Broch wrote:
The password is not encrypted (Normal) but is sent over an 
encrypted connection, it's safe.


On 1/24/2019 5:39 PM, Philip Nix Guru wrote:

Hello

I was testing the dev version (an upgrade over the stable 
version) and came through that annoying problem


if I have to advise all users to change their config :


Sending of the message failed.
The Outgoing server (SMTP) xx does not seem to support 
encrypted passwords. If you just set up the acco

Re: [qmailtoaster] Development version

[Andrew Swartz]

I would add the caveat that STARTTLS is only "probably safe".

Unfortunately, it suffers from a critical error in the very concept of 
going from an plaintext session to a TLS session, resulting in an 
unfixable (as far as I know) vulnerability.  A man-in-the-middle can 
inject text into the server response to tell the client that STARTTLS is 
not available and that the conversation should therefore continue in 
plaintext.  I've read that several ISP's have been caught using this 
vulnerability to scan people's outgoing email.  That means PLAIN or 
LOGIN type submission passwords can be seen.


This is why the 2018 RFC (https://tools.ietf.org/html/rfc8314) has 
strongly recommended abandoning STARTTLS on port 587 and using dedicated 
TLS on port 465 for mail submission.


-Andy





On 1/24/2019 9:30 PM, Eric Broch wrote:
The password is not encrypted (Normal) but is sent over an encrypted 
connection, it's safe.


On 1/24/2019 5:39 PM, Philip Nix Guru wrote:

Hello

I was testing the dev version (an upgrade over the stable version) and 
came through that annoying problem


if I have to advise all users to change their config :


Sending of the message failed.
The Outgoing server (SMTP) xx does not seem to support encrypted 
passwords. If you just set up the account, try changing the 
'Authentication method' in 'Account settings | Outgoing server (SMTP)' 
to 'Normal password'.


All the users having a starttls config in their mail client had to 
change from encrypted to normal


which of course brought the question "oh it is not safe anymore ..."


Regards

-Philip





-
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] my qmailtoaster queue full, send a lot of spam

[Andrew Swartz]

Sounds suspicious for malware.

Check the logs (var/log/qmail/smtp/cur and the similar one for the 
submission port) to see if email is coming from outside the system.


If it is not from outside the system, then I would go looking for some 
sort of rogue running process (likely malware) which is injecting mail 
directly into the queue.  If this is occurring, you will likely need to 
reformat the drive and rebuild from scratch.


-Andy



On 1/7/2019 6:30 AM, Giuseppe Perna wrote:

Thanks  Eric Broch for your replay,

yes, the queue is continuing to fill up even after password reset!!
i reset password email and clear the queue  qmHandle -D , but i see the 
log contains many emails that send mail to the whole world

is there another queue where it allocates messages?

thanks


Il giorno lun 7 gen 2019 alle ore 14:42 Eric Broch 
mailto:ebr...@whitehorsetc.com>> ha scritto:


Clarification:

The queue is continuing to fill up even after password reset!?

If not:

I've used 'qmHandle -D' to delete all messages in the queue WITH THE
UNDERSTANDING THAT GOOD MESSAGES ARE DELETED AS WELL.


On 1/7/2019 12:15 AM, Giuseppe Perna wrote:

Hello,

qmailtoaster has a full tail,
qmHandle -L and qmHandle -l contains many emails that send mail to
the whole world.
I reset the password for these email addresses, but the queues
still fill up.

in qmlog -f send i see:

01-07 07:15:08 info msg 5012912: bytes 2911 from <#@[]> qp 16477
uid 7790
01-07 07:15:08 new msg 5077748
01-07 07:15:08 info msg 5077748: bytes 2705 from <#@[]> qp 16482
uid 7790
01-07 07:15:08 new msg 5992194
01-07 07:15:08 info msg 5992194: bytes 2748 from <#@[]> qp 16514
uid 7790
01-07 07:15:08 new msg 5992748
01-07 07:15:08 info msg 5992748: bytes 2623 from <#@[]> qp 16524
uid 7790

info msg 5993280: bytes 2747 from <#@[]> qp 1329 uid 7796
01-07 07:15:28 starting delivery 511: msg 5992631 to local
postmas...@mail.miodominio.it 
01-07 07:15:28 status: local 2/10 remote 60/60
01-07 07:15:28 delivery 510: success: did_0+1+0/qp_17982/
01-07 07:15:28 status: local 1/10 remote 60/60
01-07 07:15:28 new msg 4961868
01-07 07:15:28 info msg 4961868: bytes 2657 from <#@[]> qp 2989
uid 7796
01-07 07:15:28 end msg 5209073
01-07 07:15:28 new msg 5993966
01-07 07:15:28 info msg 5993966: bytes 3133 from <#@[]> qp 8580
uid 7796
01-07 07:15:28 starting delivery 512: msg 5993280 to local
postmas...@mail.miodominio.it 
01-07 07:15:28 status: local 2/10 remote 60/60
01-07 07:15:28 new msg 5993571
01-07 07:15:28 info msg 5993571: bytes 2844 from <#@[]> qp 4724
uid 7790
01-07 07:15:28 delivery 511: success: did_0+1+0/qp_17985/
01-07 07:15:28 status: local 1/10 remote 60/60
01-07 07:15:28 new msg 5992368



i have this version qmailtoaster:
 rpm -qa | grep toaster*
ucspi-tcp-toaster-0.88-1.3.5
qmail-toaster-1.03-1.3.15
autorespond-toaster-2.0.4-1.3.3
qmailadmin-toaster-1.2.11-1.3.4
isoqlog-toaster-2.1-1.3.4
qmailtoaster-plus-0.3.0-1.4.4
daemontools-toaster-0.76-1.3.3
vpopmail-toaster-5.4.17-1.3.4
libsrs2-toaster-1.0.18-1.3.3
qmail-pop3d-toaster-1.03-1.3.15
courier-imap-toaster-4.1.2-1.3.7
control-panel-toaster-0.5-1.3.4
ezmlm-cgi-toaster-0.53.324-1.3.3
qmailmrtg-toaster-4.2-1.3.3
maildrop-toaster-devel-2.0.3-1.3.5
vqadmin-toaster-2.3.4-1.3.3
spamassassin-toaster-3.2.4-1.3.13
ripmime-toaster-1.4.0.6-1.3.3
clamav-toaster-0.95.2-1.3.30
libdomainkeys-toaster-0.68-1.3.3
courier-authlib-toaster-0.59.2-1.3.6
ezmlm-toaster-0.53.324-1.3.3
maildrop-toaster-2.0.3-1.3.5
squirrelmail-toaster-1.4.13-1.3.9
simscan-toaster-1.3.1-1.3.6


thanks

-- 
Eric Broch

White Horse Technical Consulting (WHTC)



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

Re: [qmailtoaster] Fwd: Re: vpopmail

[Andrew Swartz]

Agreed.

-Andy


On 10/5/2018 10:40 AM, Remo Mattei wrote:
> My suggestions is to give an option to select which one the user wants to 
> install. 
> 
> So maybe we have one version with clear and one without, which means the 
> script will need to prompt you to select 
> 
> Remo 
> 
>> On Oct 5, 2018, at 11:35, Eric Broch  wrote:
>>
>> actual:
>>
>> vdir=/home/vpopmail
>>
>> ./configure --prefix=%{vdir} \
>> --enable-vpopuser=vpopmail \
>> --enable-vpopgroup=vchkpw \
>> --enable-libdir=%{_libdir}/mysql \
>> --disable-roaming-users \
>> --enable-tcprules-prog=/usr/bin/tcprules \
>> --enable-tcpserver-file=/etc/tcprules.d/tcp.smtp \
>> --enable-make-seekable \
>> --enable-clear-passwd \
>> --disable-users-big-dir \
>> --enable-qmail-ext \
>> --disable-ip-alias-domains \
>> --enable-auth-module=mysql \
>> --disable-passwd \
>> --enable-logging=v \
>> --enable-log-name=vpopmail \
>> --disable-mysql-limits \
>> --enable-valias \
>> --disable-many-domains \
>> --enable-non-root-build
>>
>>
>> On 10/5/2018 12:25 PM, Eric Broch wrote:
>>> vpopmail directory = /home/vpopmail
>>>uid = 89
>>>gid = 89
>>>  roaming users = OFF --disable-roaming-users   (default)
>>>  password learning = OFF --disable-learn-passwords (default)
>>>  md5 passwords = ON  --enable-md5-passwords(default)
>>>   file locking = ON  --enable-file-locking (default)
>>> vdelivermail fsync = OFF --disable-file-sync   (default)
>>>  make seekable = ON  --enable-make-seekable(default)
>>>   clear passwd = ON  --enable-clear-passwd (default)
>>>  user dir hashing  = OFF --disable-users-big-dir
>>> address extensions = ON  --enable-qmail-ext
>>>   ip alias = OFF --disable-ip-alias-domains (default)
>>>auth module = mysql --enable-auth-module=mysql
>>>  mysql replication = OFF --disable-mysql-replication (default)
>>>sql logging = OFF --disable-sql-logging   (default)
>>>   mysql limits = OFF --disable-mysql-limits  (default)
>>>   MySQL valias = ON  --enable-valias
>>>   auth inc = -I/usr/include/mysql
>>>   auth lib = -L/usr/lib64/mysql  -lmysqlclient -lz -lm
>>>   system passwords = OFF --disable-passwd (default)
>>> pop syslog = log success and errors including passwords
>>>  --enable-logging=v
>>>   auth logging = ON  --enable-auth-logging (default)
>>> one domain per SQL table = --disable-many-domains
>>>
>>>
>>> On 10/5/2018 11:03 AM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> What configuration options do you use when compiling vpopmail?
>>>>
>>>> -Andy
>>>>
>>>>
>>>>
>>>>
>>>> On 10/4/2018 9:17 AM, Andrew Swartz wrote:
>>>>> Yet I believe we have solved this problem:
>>>>>
>>>>> Remote IMAP/POP3 authentication should be done via STARTTLS or TLS.
>>>>> Therefore CRAM-MD5 is not necessary and PLAIN or LOGIN auth mechanisms
>>>>> can be used.
>>>>>
>>>>> Local authentication (i.e. the webmail server authenticating through
>>>>> IMAP) can use unsecure connection with PLAIN/LOGIN mechanisms without
>>>>> substantial risk.
>>>>>
>>>>> If PLAIN or LOGIN mechanisms are used exclusively, then the cleartext
>>>>> passwords are not needed and can be set to NULL.
>>>>>
>>>>> Both IMAP and webmail should be set to use PLAIN or LOGIN mechanisms.
>>>>>
>>>>> vpopmail should be configured with the '--disable-clear-passwd' option.
>>>>>
>>>>> Unless I'm missing something, the above steps solve the problem.
>>>>> Dovecot using cleartext passwords for CRAM-MD5 authentication is not a
>>>>> bug, it is correct functioning (because the server requires the
>>>>> cleartext password to authenticate the client).
>>>>>
>>>>> However, the problem is unsolved for admins who want to serve IMAP/POP3
>>>>> over an unencrypted channel.  Then they have to maintain CRAM-MD5
>>>>> capability, which means they must maintain cleartext passw

Re: [qmailtoaster] Fwd: Re: vpopmail

[Andrew Swartz]

Eric,

What configuration options do you use when compiling vpopmail?

-Andy




On 10/4/2018 9:17 AM, Andrew Swartz wrote:
> Yet I believe we have solved this problem:
> 
> Remote IMAP/POP3 authentication should be done via STARTTLS or TLS.
> Therefore CRAM-MD5 is not necessary and PLAIN or LOGIN auth mechanisms
> can be used.
> 
> Local authentication (i.e. the webmail server authenticating through
> IMAP) can use unsecure connection with PLAIN/LOGIN mechanisms without
> substantial risk.
> 
> If PLAIN or LOGIN mechanisms are used exclusively, then the cleartext
> passwords are not needed and can be set to NULL.
> 
> Both IMAP and webmail should be set to use PLAIN or LOGIN mechanisms.
> 
> vpopmail should be configured with the '--disable-clear-passwd' option.
> 
> Unless I'm missing something, the above steps solve the problem.
> Dovecot using cleartext passwords for CRAM-MD5 authentication is not a
> bug, it is correct functioning (because the server requires the
> cleartext password to authenticate the client).
> 
> However, the problem is unsolved for admins who want to serve IMAP/POP3
> over an unencrypted channel.  Then they have to maintain CRAM-MD5
> capability, which means they must maintain cleartext passwords which do
> not exceed 16 characters.  I would argue that this should not be the
> default configuration, but rather something that someone can configure
> if they desire an especially insecure configuration.
> 
> -Andy
> 
> 
> 
> On 10/4/2018 8:00 AM, Remo Mattei wrote:
>> +1 
>>
>> When I read it.. 
>>
>>> On Oct 4, 2018, at 08:10, Andrew Swartz  wrote:
>>>
>>> I have ABSOLUTELY NO IDEA what that is supposed to mean.
>>>
>>> -Andy
>>>
>>>
>>> On 10/4/2018 3:56 AM, Eric Broch wrote:
>>>> Here's the answer I got from the Dovecot mailing list concerning the
>>>> question of clear text password authentication...not sure how to
>>>> implement...ideas? :
>>>>
>>>> On 03.10.2018 23:30, Eric Broch wrote:
>>>>> Hello list,
>>>>>
>>>>> I run Dovecot with the vpopmail driver and have found that it
>>>>> authenticates against the clear text password in the vpopmail
>>>>> database. Is there a configuration option either at compile time, link
>>>>> time, or a setting in one of the configuration files that tells the
>>>>> program to authenticate against the hash instead of the clear text?
>>>>>
>>>>
>>>> Prefix your passwords in vpopmail with {SCHEME} (like,  {CRYPT})
>>>>  
>>>>
>>>>
>>>> -
>>>> 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
>>
>>
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Fwd: Re: vpopmail

[Andrew Swartz]

Yet I believe we have solved this problem:

Remote IMAP/POP3 authentication should be done via STARTTLS or TLS.
Therefore CRAM-MD5 is not necessary and PLAIN or LOGIN auth mechanisms
can be used.

Local authentication (i.e. the webmail server authenticating through
IMAP) can use unsecure connection with PLAIN/LOGIN mechanisms without
substantial risk.

If PLAIN or LOGIN mechanisms are used exclusively, then the cleartext
passwords are not needed and can be set to NULL.

Both IMAP and webmail should be set to use PLAIN or LOGIN mechanisms.

vpopmail should be configured with the '--disable-clear-passwd' option.

Unless I'm missing something, the above steps solve the problem.
Dovecot using cleartext passwords for CRAM-MD5 authentication is not a
bug, it is correct functioning (because the server requires the
cleartext password to authenticate the client).

However, the problem is unsolved for admins who want to serve IMAP/POP3
over an unencrypted channel.  Then they have to maintain CRAM-MD5
capability, which means they must maintain cleartext passwords which do
not exceed 16 characters.  I would argue that this should not be the
default configuration, but rather something that someone can configure
if they desire an especially insecure configuration.

-Andy



On 10/4/2018 8:00 AM, Remo Mattei wrote:
> +1 
> 
> When I read it.. 
> 
>> On Oct 4, 2018, at 08:10, Andrew Swartz  wrote:
>>
>> I have ABSOLUTELY NO IDEA what that is supposed to mean.
>>
>> -Andy
>>
>>
>> On 10/4/2018 3:56 AM, Eric Broch wrote:
>>> Here's the answer I got from the Dovecot mailing list concerning the
>>> question of clear text password authentication...not sure how to
>>> implement...ideas? :
>>>
>>> On 03.10.2018 23:30, Eric Broch wrote:
>>>> Hello list,
>>>>
>>>> I run Dovecot with the vpopmail driver and have found that it
>>>> authenticates against the clear text password in the vpopmail
>>>> database. Is there a configuration option either at compile time, link
>>>> time, or a setting in one of the configuration files that tells the
>>>> program to authenticate against the hash instead of the clear text?
>>>>
>>>
>>> Prefix your passwords in vpopmail with {SCHEME} (like,  {CRYPT})
>>>  
>>>
>>>
>>> -
>>> 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
> 
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Fwd: Re: vpopmail

[Andrew Swartz]

I have ABSOLUTELY NO IDEA what that is supposed to mean.

-Andy


On 10/4/2018 3:56 AM, Eric Broch wrote:
> Here's the answer I got from the Dovecot mailing list concerning the
> question of clear text password authentication...not sure how to
> implement...ideas? :
> 
> On 03.10.2018 23:30, Eric Broch wrote:
>> Hello list,
>>
>> I run Dovecot with the vpopmail driver and have found that it
>> authenticates against the clear text password in the vpopmail
>> database. Is there a configuration option either at compile time, link
>> time, or a setting in one of the configuration files that tells the
>> program to authenticate against the hash instead of the clear text?
>>
> 
> Prefix your passwords in vpopmail with {SCHEME} (like,  {CRYPT})
>  
> 
> 
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
> 
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: [qmailtoaster] dovecot

[Andrew Swartz]

I ~may~ have just figured out why vpopmail stores cleartext passwords:

It is so it can support CRAM-MD5.

CRAM-MD5 is a challenge-response protocol used to provide privacy over
unencrypted connections.  The server challenges the client with a
pseudorandom challenge.  The client uses the password with HMAC-MD5 to
hash the challenge and send it back.  The server repeats the client
procedure to confirm that the client used (and thus has) the correct
password.

But this means that the server MUST have access to the cleartext
password, otherwise it cannot repeat the clients actions and confirm
authentication.  This cannot be accomplished with a salted hashed password.

If you remove the use of CRAM-MD5 and use PLAIN or LOGIN, the server
does not need access to the cleartext password.

Back when vpopmail was written, cleartext password storage was already
out of favor.  But TLS was not widely used, and the only way to not send
passwords in the clear was CRAM-MD5 (or a similar scheme), and this
required storing cleartext passwords.  Though storing cleartext
passwords is unsafe, it is much safer than sending cleartext passwords
over an encrypted channel.

I suspect that this is the primary reason that vpopmail primarily uses
hashed passwords but supports cleartext passwords with the option to
disable them.

-Andy


On 10/3/2018 7:51 PM, Eric Broch wrote:
> Hi Andy,
> 
> I got it to work.
> 
> In '/etc/dovecot/toaster.conf' add 'mail_location = maildir:~/Maildir'
> 
> and make sure of 'auth_mechanisms = plain login'
> 
> In '/etc/squirrelmail/config_local.php' here are my imap settings:
> 
> $imapServerAddress  = 'localhost';
> $imap_server_type   = 'dovecot';
> $imap_auth_mech = 'login';
> 
> worked for my squirrelmail setup, hope you get it working
> 
> -Eric
> 
> 
> On 10/3/2018 9:18 PM, Andrew Swartz wrote:
>> And I'll add that at the end, with pw_clear_passwd set to null, login
>> succeeds via IMAP but fails via Squirrelmail.
>>
>> -Andy
>>
>>
>>
>>  Forwarded Message ----
>> Subject: Re: [qmailtoaster] dovecot
>> Date: Wed, 3 Oct 2018 19:12:11 -0800
>> From: Andrew Swartz 
>> To: qmailtoaster-list@qmailtoaster.com
>>
>> Eric,
>>
>> With pw_clear_passwd set to '0123456789' I successfully logged in via
>> this technique using password '0123456789'.
>>
>> I used SQL to reset pw_clear_passwd to null.
>>
>> Again I successfully logged in via this technique using password
>> '0123456789'.
>>
>>
>> -Andy
>>
>>
>>
>> On 10/3/2018 6:02 PM, Eric Broch wrote:
>>> Try the CLI commands I sent. There can be issues with the configuration
>>> of squirrelmail and roundcube.
>>>
>>> IMAP:
>>>
>>> # openssl s_client -crlf -connect localhost:993
>>>
>>> imap> tag login u...@domain.tld  $userpassword
>>>
>>>
>>> Submission:
>>>
>>> # cd /usr/local/bin
>>> # wget http://www.jetmore.org/john/code/swaks/latest/swaks
>>> # chown root.root swaks
>>> # chmod +x swaks
>>>
>>> # swaks --to some...@remotedomain.tld --from u...@domain.tld --server
>>> $yourqmthost --port 587 --ehlo test -tls --auth login --auth-user
>>> u...@domain.tld --auth-password $userpassword
>>>
>>>
>>> On 10/3/2018 7:45 PM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> On Centos7 QMT:
>>>>
>>>> I just created a new user account and set the password to '0123456789'.
>>>> Then I used your SQL command to set pw_clear_passwd to null.
>>>> Then I viewed the table to confirm it was empty (it was).
>>>> Then I tried to log in to Squirrelmail using password '0123456789':
>>>> Login failed.
>>>> Then I used your SQL command to reset pw_clear_passwd back to
>>>> '0123456789'.
>>>> Then I tried to log in to Squirrelmail using password '0123456789':
>>>> success.
>>>>
>>>> This seems different from your experience.
>>>>
>>>> This sucks because it seems to mean no easy fix for this problem.
>>>>
>>>>
>>>> -Andy
>>>>
>>>>
>>>>
>>>>
>>>> On 10/3/2018 4:24 PM, Eric Broch wrote:
>>>>> I've been contacted by someone who removed the clear text password
>>>>> from
>>>>> an account and had issued logging into Dovecot even after a
>>>>> restart. The
>>>>> fix of course is to reset the password with
>>>>> /home/vpopmail/bin/vpasswd.
>>>>> Does anyone else want to confirm/refute my findings that w/o the clear
>>>>> text password Dovecot will work?
>>>>>
>>> -- 
>>> Eric Broch
>>> White Horse Technical Consulting (WHTC)
>>>
>>
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Fwd: [qmailtoaster] dovecot

[Andrew Swartz]

Great minds think alike!

I also just got Squirrelmail working with the same change to
/etc/squirrelmail/config_local.php

I had already done the change to toaster.conf based on a thread about 4
weeks ago.

-Andy


On 10/3/2018 7:51 PM, Eric Broch wrote:
> Hi Andy,
> 
> I got it to work.
> 
> In '/etc/dovecot/toaster.conf' add 'mail_location = maildir:~/Maildir'
> 
> and make sure of 'auth_mechanisms = plain login'
> 
> In '/etc/squirrelmail/config_local.php' here are my imap settings:
> 
> $imapServerAddress  = 'localhost';
> $imap_server_type   = 'dovecot';
> $imap_auth_mech = 'login';
> 
> worked for my squirrelmail setup, hope you get it working
> 
> -Eric
> 
> 
> On 10/3/2018 9:18 PM, Andrew Swartz wrote:
>> And I'll add that at the end, with pw_clear_passwd set to null, login
>> succeeds via IMAP but fails via Squirrelmail.
>>
>> -Andy
>>
>>
>>
>>  Forwarded Message ----
>> Subject: Re: [qmailtoaster] dovecot
>> Date: Wed, 3 Oct 2018 19:12:11 -0800
>> From: Andrew Swartz 
>> To: qmailtoaster-list@qmailtoaster.com
>>
>> Eric,
>>
>> With pw_clear_passwd set to '0123456789' I successfully logged in via
>> this technique using password '0123456789'.
>>
>> I used SQL to reset pw_clear_passwd to null.
>>
>> Again I successfully logged in via this technique using password
>> '0123456789'.
>>
>>
>> -Andy
>>
>>
>>
>> On 10/3/2018 6:02 PM, Eric Broch wrote:
>>> Try the CLI commands I sent. There can be issues with the configuration
>>> of squirrelmail and roundcube.
>>>
>>> IMAP:
>>>
>>> # openssl s_client -crlf -connect localhost:993
>>>
>>> imap> tag login u...@domain.tld  $userpassword
>>>
>>>
>>> Submission:
>>>
>>> # cd /usr/local/bin
>>> # wget http://www.jetmore.org/john/code/swaks/latest/swaks
>>> # chown root.root swaks
>>> # chmod +x swaks
>>>
>>> # swaks --to some...@remotedomain.tld --from u...@domain.tld --server
>>> $yourqmthost --port 587 --ehlo test -tls --auth login --auth-user
>>> u...@domain.tld --auth-password $userpassword
>>>
>>>
>>> On 10/3/2018 7:45 PM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> On Centos7 QMT:
>>>>
>>>> I just created a new user account and set the password to '0123456789'.
>>>> Then I used your SQL command to set pw_clear_passwd to null.
>>>> Then I viewed the table to confirm it was empty (it was).
>>>> Then I tried to log in to Squirrelmail using password '0123456789':
>>>> Login failed.
>>>> Then I used your SQL command to reset pw_clear_passwd back to
>>>> '0123456789'.
>>>> Then I tried to log in to Squirrelmail using password '0123456789':
>>>> success.
>>>>
>>>> This seems different from your experience.
>>>>
>>>> This sucks because it seems to mean no easy fix for this problem.
>>>>
>>>>
>>>> -Andy
>>>>
>>>>
>>>>
>>>>
>>>> On 10/3/2018 4:24 PM, Eric Broch wrote:
>>>>> I've been contacted by someone who removed the clear text password
>>>>> from
>>>>> an account and had issued logging into Dovecot even after a
>>>>> restart. The
>>>>> fix of course is to reset the password with
>>>>> /home/vpopmail/bin/vpasswd.
>>>>> Does anyone else want to confirm/refute my findings that w/o the clear
>>>>> text password Dovecot will work?
>>>>>
>>> -- 
>>> Eric Broch
>>> White Horse Technical Consulting (WHTC)
>>>
>>
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] dovecot

[Andrew Swartz]

Eric,

With pw_clear_passwd set to '0123456789' I successfully logged in via
this technique using password '0123456789'.

I used SQL to reset pw_clear_passwd to null.

Again I successfully logged in via this technique using password
'0123456789'.


-Andy



On 10/3/2018 6:02 PM, Eric Broch wrote:
> Try the CLI commands I sent. There can be issues with the configuration
> of squirrelmail and roundcube.
> 
> IMAP:
> 
> # openssl s_client -crlf -connect localhost:993
> 
> imap> tag login u...@domain.tld  $userpassword
> 
> 
> Submission:
> 
> # cd /usr/local/bin
> # wget http://www.jetmore.org/john/code/swaks/latest/swaks
> # chown root.root swaks
> # chmod +x swaks
> 
> # swaks --to some...@remotedomain.tld --from u...@domain.tld --server
> $yourqmthost --port 587 --ehlo test -tls --auth login --auth-user 
> u...@domain.tld --auth-password $userpassword
> 
> 
> On 10/3/2018 7:45 PM, Andrew Swartz wrote:
>> Eric,
>>
>> On Centos7 QMT:
>>
>> I just created a new user account and set the password to '0123456789'.
>> Then I used your SQL command to set pw_clear_passwd to null.
>> Then I viewed the table to confirm it was empty (it was).
>> Then I tried to log in to Squirrelmail using password '0123456789':
>> Login failed.
>> Then I used your SQL command to reset pw_clear_passwd back to '0123456789'.
>> Then I tried to log in to Squirrelmail using password '0123456789':
>> success.
>>
>> This seems different from your experience.
>>
>> This sucks because it seems to mean no easy fix for this problem.
>>
>>
>> -Andy
>>
>>
>>
>>
>> On 10/3/2018 4:24 PM, Eric Broch wrote:
>>> I've been contacted by someone who removed the clear text password from
>>> an account and had issued logging into Dovecot even after a restart. The
>>> fix of course is to reset the password with /home/vpopmail/bin/vpasswd.
>>> Does anyone else want to confirm/refute my findings that w/o the clear
>>> text password Dovecot will work?
>>>
> 
> -- 
> Eric Broch
> White Horse Technical Consulting (WHTC)
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Fwd: [qmailtoaster] dovecot

[Andrew Swartz]

And I'll add that at the end, with pw_clear_passwd set to null, login
succeeds via IMAP but fails via Squirrelmail.

-Andy



 Forwarded Message 
Subject: Re: [qmailtoaster] dovecot
Date: Wed, 3 Oct 2018 19:12:11 -0800
From: Andrew Swartz 
To: qmailtoaster-list@qmailtoaster.com

Eric,

With pw_clear_passwd set to '0123456789' I successfully logged in via
this technique using password '0123456789'.

I used SQL to reset pw_clear_passwd to null.

Again I successfully logged in via this technique using password
'0123456789'.


-Andy



On 10/3/2018 6:02 PM, Eric Broch wrote:
> Try the CLI commands I sent. There can be issues with the configuration
> of squirrelmail and roundcube.
> 
> IMAP:
> 
> # openssl s_client -crlf -connect localhost:993
> 
> imap> tag login u...@domain.tld  $userpassword
> 
> 
> Submission:
> 
> # cd /usr/local/bin
> # wget http://www.jetmore.org/john/code/swaks/latest/swaks
> # chown root.root swaks
> # chmod +x swaks
> 
> # swaks --to some...@remotedomain.tld --from u...@domain.tld --server
> $yourqmthost --port 587 --ehlo test -tls --auth login --auth-user 
> u...@domain.tld --auth-password $userpassword
> 
> 
> On 10/3/2018 7:45 PM, Andrew Swartz wrote:
>> Eric,
>>
>> On Centos7 QMT:
>>
>> I just created a new user account and set the password to '0123456789'.
>> Then I used your SQL command to set pw_clear_passwd to null.
>> Then I viewed the table to confirm it was empty (it was).
>> Then I tried to log in to Squirrelmail using password '0123456789':
>> Login failed.
>> Then I used your SQL command to reset pw_clear_passwd back to '0123456789'.
>> Then I tried to log in to Squirrelmail using password '0123456789':
>> success.
>>
>> This seems different from your experience.
>>
>> This sucks because it seems to mean no easy fix for this problem.
>>
>>
>> -Andy
>>
>>
>>
>>
>> On 10/3/2018 4:24 PM, Eric Broch wrote:
>>> I've been contacted by someone who removed the clear text password from
>>> an account and had issued logging into Dovecot even after a restart. The
>>> fix of course is to reset the password with /home/vpopmail/bin/vpasswd.
>>> Does anyone else want to confirm/refute my findings that w/o the clear
>>> text password Dovecot will work?
>>>
> 
> -- 
> Eric Broch
> White Horse Technical Consulting (WHTC)
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] dovecot

[Andrew Swartz]

Eric,

On Centos7 QMT:

I just created a new user account and set the password to '0123456789'.
Then I used your SQL command to set pw_clear_passwd to null.
Then I viewed the table to confirm it was empty (it was).
Then I tried to log in to Squirrelmail using password '0123456789':
Login failed.
Then I used your SQL command to reset pw_clear_passwd back to '0123456789'.
Then I tried to log in to Squirrelmail using password '0123456789':
success.

This seems different from your experience.

This sucks because it seems to mean no easy fix for this problem.


-Andy




On 10/3/2018 4:24 PM, Eric Broch wrote:
> I've been contacted by someone who removed the clear text password from
> an account and had issued logging into Dovecot even after a restart. The
> fix of course is to reset the password with /home/vpopmail/bin/vpasswd.
> Does anyone else want to confirm/refute my findings that w/o the clear
> text password Dovecot will work?
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Eric,

I am missing something:  what is the utility of keeping the plaintext
passwords for any of the accounts if QMT is 100% functional without them?

I cringe when I use WebMin to click to view the vpopmail database and
literally scroll through cleartext passwords.


-Andy



On 10/3/2018 2:36 PM, Eric Broch wrote:
> I guess that a couple of lines could be add to the script below to test
> if the clear text password with the extracted salt match the hashed
> password (see below). If so skip the user/domain entry. If not set clear
> text password to 'null'
> 
> if [ $hashedpasswd != `openssl passwd -1 -salt $usersalt $userpasswd` ];
> then
> 
> clear entry
> 
> fi
> 
> -EricB
> 
> 
> On 10/3/2018 3:48 PM, Eric Broch wrote:
>> In the mean time, I've written a script to null the clear text pwd
>> field, look at it, TEST IT, add suggestions, and use at your own risk:
>>
>> 
>>
>> IFS=$'\n'
>> pass=`cat pfile`
>> for domain in `echo "show tables" | mysql -u root -p$pass vpopmail |
>> grep -v dir_control | grep -v Tables_in_vpopmail | grep -v valias |
>> grep -v lastauth`
>> do
>>     for user in `echo "select pw_name from $domain" | mysql -u root
>> -p$pass vpopmail | grep -v pw_name`
>>     do
>>    clear=`echo "select pw_clear_passwd from $domain where
>> pw_name='$user'" | mysql -u root -p$pass vpopmail | grep -v
>> pw_clear_passwd`
>>    echo "$user:$domain:($clear)"
>>    # update $domain set pw_clear_passwd='' where pw_name ='$user';
>>    clear=`echo "select pw_clear_passwd from $domain where
>> pw_name='$user'" | mysql -u root -p$pass vpopmail | grep -v
>> pw_clear_passwd`
>>    echo "$user:$domain:($clear)"
>>    echo
>> "--"
>>
>>     done
>> done
>>
>> 
>>
>>
>> Eric
>>
>>
>> On 10/3/2018 3:30 PM, Dan McAllister - QMT DNS wrote:
>>> One more item -- I agree that the password hashing algorithm could
>>> stand to be updated -- and there is NOT a backward compatibility
>>> issue with updating our algorithms because the mechanism is CODED to
>>> show which algorithm is used (the $1$ currently there, maybe a $6$ in
>>> the future?)
>>>
>>> However, we would need to check with the qmail code, as well as
>>> DoveCot, to determine if they can support/recognize those other
>>> algorithms.
>>>
>>> Dan
>>>
>>> -Original Message-
>>> From: Eric Broch 
>>> Sent: Wednesday, October 3, 2018 4:34 PM
>>> To: qmailtoaster-list@qmailtoaster.com
>>> Subject: Re: [qmailtoaster] Passwords after backup/restore
>>>
 The newer DoveCot IMAP server "appears" to be authenticating against
 the cleartext password
>>> It does. I checked the code.
>>>
>>> I've submitted a question to the Dovecot mailing list concerning
>>> this, that is, whether there is a configuration option to authorize
>>> against the hash, or whether there is an option at compile or link
>>> time to accomplish the same. It'd be nice to have a configuration
>>> option, IMHO, that way no re-compilation would be necessary.
>>>
>>
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Dan,

Good explanations of how the crypted password contains the hash
specification and the salt.  Thank you.  I looked through the dovecot
documentation, and they describe the $1$ through $6$ just as you did.
Therefore this seems a generally accepted password storage format.

However, I just searched through all of the vpopmail source code
(v5.4.33).  There are numerous hits for "md5" but none for "sha1",
"sha-1", "sha256", or "sha-256".  I visually inspected the header files,
and there is a #define for MD5_PASSWORDS but for no other hashes.

As best I can tell, it seems that the crypted password is stored using a
format which accepts newer hashes, but it seems that vpopmail currently
has no ability to use newer hashes.

-Andy


On 10/3/2018 1:30 PM, Dan McAllister - QMT DNS wrote:
> One more item -- I agree that the password hashing algorithm could stand to 
> be updated -- and there is NOT a backward compatibility issue with updating 
> our algorithms because the mechanism is CODED to show which algorithm is used 
> (the $1$ currently there, maybe a $6$ in the future?)
> 
> However, we would need to check with the qmail code, as well as DoveCot, to 
> determine if they can support/recognize those other algorithms.
> 
> Dan
> 
> -Original Message-
> From: Eric Broch  
> Sent: Wednesday, October 3, 2018 4:34 PM
> To: qmailtoaster-list@qmailtoaster.com
> Subject: Re: [qmailtoaster] Passwords after backup/restore
> 
>> The newer DoveCot IMAP server "appears" to be authenticating against 
>> the cleartext password
> It does. I checked the code.
> 
> I've submitted a question to the Dovecot mailing list concerning this, that 
> is, whether there is a configuration option to authorize against the hash, or 
> whether there is an option at compile or link time to accomplish the same. 
> It'd be nice to have a configuration option, IMHO, that way no re-compilation 
> would be necessary.
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Fixing the backup/restore might not be too difficult.  The backup script
exports the database to a text file of comma separated values.  Seems
like a clever AWK one-liner could go through that file and set that
field in each line equal to an empty string.  Then continue as normal
with the restore script.  That would likely end up with null values for
all of the cleartext passwords in the new database.

-Andy



On 10/2/2018 10:28 PM, Eric Broch wrote:
> It would be very easy to compile vpopmail disabling clear passwords, but
> the immediate problem for those migrating is the fact that the clear
> password already exists and changing vpopmail wouldn't deal with
> existing accounts.
> 
> Only newly created accounts would have 'null' clear text passwords.
> 
> Also, the hash used by vpopmail is MD5 by default which QMT utilizes,
> DES is also available.
> 
> 
> On 10/3/2018 12:10 AM, Andrew Swartz wrote:
>> Eric,
>>
>> Excellent test with very useful results!
>>
>> Modern security practice would indicate elimination of the cleartext
>> passwords.  How difficult would it be compile vpopmail without cleartext
>> passwords?
>>
>> I propose two reasons for this path:
>> 1)  The one of the biggest reasons to use qmail is it's security record.
>>   We should try as much a possible to make the accessories as secure as
>> qmail.  There are a lot of people who would not use QMT because storage
>> of cleartext passwords SOUNDS medieval and dangerous at this point,
>> regardless of whether or not it is.  My understanding is that DJB wrote
>> the qmail modules with each assuming that the others had been
>> compromised.  I think that the qmail accessories should be configured
>> using this same philosophy as much as possible.  Assuming that no
>> intruder could ever get in or get root access is a path to making lots
>> poor decisions which could eventually be regretted.
>>
>> 2) Using only the hash allows infinite size passwords.  Admittedly, 40
>> characters sounds adequate.  But that might be eventually outgrown and
>> we would have the same problem again.  But any size password will always
>> yield the same size hash.
>>
>> One extra thought:
>>
>> If vpopmail were to be patched or recompiled, one thought might be to
>> check what hash routine it uses.  If it is weaker than SHA256, it
>> probably ought to be updated to this or SHA512.  I've not looked at the
>> vpopmail source code so I have no idea if that is feasible.  But it
>> might be quite easy.
>>
>> -Andy
>>
>>
>> On 10/2/2018 9:28 PM, Eric Broch wrote:
>>> The solution might be to either patch dovecot with our own QMT patch at
>>> compile time to avoid the clear text password altogether during
>>> authentication,
>>>
>>> Or compile vpopmail clear text password field disabled,
>>>
>>> Or, Another solution would be for users to clear all clear text password
>>> fields from the vpopmail database before migration,
>>>
>>> Or as Tony brought up changing the size of the clear password field to
>>> 40 chars.
>>>
>>> Any opinions?
>>>
>>>
>>> On 10/2/2018 11:21 PM, Eric Broch wrote:
>>>> Dovecot will authenticate against the clear text password if it is
>>>> present.
>>>>
>>>> Upon updating the clear text password (encrypted 17 characters) to
>>>> 'null', I authenticated using Dovecot against the 17 character
>>>> password.
>>>>
>>>> Here's the command I used to set the clear text password to null:
>>>> mysql> update mydomain_tld set pw_clear_passwd='' where pw_name
>>>> ='user';
>>>>
>>>> Then Dovecot authenticated fine against the 17 character
>>>> password...now encrypted to 40 chars.
>>>>
>>>>
>>>> On 10/2/2018 11:09 PM, Andrew Swartz wrote:
>>>>> On further review, your debug output looks pretty definitive for
>>>>> Dovecot
>>>>> directly accessing the database.  Given that the hash cannot be
>>>>> reversed, the only way to get the cleartext password is direct
>>>>> database
>>>>> access.
>>>>>
>>>>> This seems a pretty substantial problem, as it means that the hash and
>>>>> cleartext will be discordant for passwords >16 characters. But nothing
>>>>> stops users from choosing such passwords.
>>>>>
>>>>> Or alternately, could be an interesting bug to capitalize on. It
>>>>> allows
&

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Eric,

Excellent test with very useful results!

Modern security practice would indicate elimination of the cleartext
passwords.  How difficult would it be compile vpopmail without cleartext
passwords?

I propose two reasons for this path:
1)  The one of the biggest reasons to use qmail is it's security record.
 We should try as much a possible to make the accessories as secure as
qmail.  There are a lot of people who would not use QMT because storage
of cleartext passwords SOUNDS medieval and dangerous at this point,
regardless of whether or not it is.  My understanding is that DJB wrote
the qmail modules with each assuming that the others had been
compromised.  I think that the qmail accessories should be configured
using this same philosophy as much as possible.  Assuming that no
intruder could ever get in or get root access is a path to making lots
poor decisions which could eventually be regretted.

2) Using only the hash allows infinite size passwords.  Admittedly, 40
characters sounds adequate.  But that might be eventually outgrown and
we would have the same problem again.  But any size password will always
yield the same size hash.

One extra thought:

If vpopmail were to be patched or recompiled, one thought might be to
check what hash routine it uses.  If it is weaker than SHA256, it
probably ought to be updated to this or SHA512.  I've not looked at the
vpopmail source code so I have no idea if that is feasible.  But it
might be quite easy.

-Andy


On 10/2/2018 9:28 PM, Eric Broch wrote:
> The solution might be to either patch dovecot with our own QMT patch at
> compile time to avoid the clear text password altogether during
> authentication,
> 
> Or compile vpopmail clear text password field disabled,
> 
> Or, Another solution would be for users to clear all clear text password
> fields from the vpopmail database before migration,
> 
> Or as Tony brought up changing the size of the clear password field to
> 40 chars.
> 
> Any opinions?
> 
> 
> On 10/2/2018 11:21 PM, Eric Broch wrote:
>> Dovecot will authenticate against the clear text password if it is
>> present.
>>
>> Upon updating the clear text password (encrypted 17 characters) to
>> 'null', I authenticated using Dovecot against the 17 character password.
>>
>> Here's the command I used to set the clear text password to null:
>> mysql> update mydomain_tld set pw_clear_passwd='' where pw_name ='user';
>>
>> Then Dovecot authenticated fine against the 17 character
>> password...now encrypted to 40 chars.
>>
>>
>> On 10/2/2018 11:09 PM, Andrew Swartz wrote:
>>> On further review, your debug output looks pretty definitive for Dovecot
>>> directly accessing the database.  Given that the hash cannot be
>>> reversed, the only way to get the cleartext password is direct database
>>> access.
>>>
>>> This seems a pretty substantial problem, as it means that the hash and
>>> cleartext will be discordant for passwords >16 characters. But nothing
>>> stops users from choosing such passwords.
>>>
>>> Or alternately, could be an interesting bug to capitalize on. It allows
>>> creation of relay-only passwords.  I could use this for accounts which
>>> only send mail but which should never check it (like my UPS or system
>>> monitoring scripts).  From one perspective, this could be a security
>>> advantage.  But forcing real users to use small passwords is probably a
>>> much bigger disadvantage.
>>>
>>> -Andy
>>>
>>>
>>> On 10/2/2018 8:47 PM, Eric Broch wrote:
>>>> And when debugging authentication with Dovecot, I get...
>>>>
>>>> CLEARTEXT(password entered in webmail) != 'password in the database'
>>>>
>>>>  From dovecot.log the actual output:
>>>>
>>>> Oct 02 22:05:45 auth-worker(19953): Debug:
>>>> vpopmail(someu...@domain.tld,127.0.0.1,):
>>>> CLEARTEXT(x) != ''
>>>> Oct 02 22:05:47 auth: Debug: client passdb out: FAIL    1
>>>> user=someu...@domain.tld
>>>>
>>>>
>>>>
>>>>
>>>> On 10/2/2018 10:25 PM, Eric Broch wrote:
>>>>> So, I think Dovecot MAY be authenticating against the plain text
>>>>> password. I can't be sure until I look at the code or ask on the
>>>>> Dovecot mailing list.
>>>>>
>>>>>
>>>>> On 10/2/2018 10:22 PM, Eric Broch wrote:
>>>>>> Okay,
>>>>>>
>>>>>> 17 character password works with Submission port. Not with IMAP which
>>>>>> is authentica

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

On further review, your debug output looks pretty definitive for Dovecot
directly accessing the database.  Given that the hash cannot be
reversed, the only way to get the cleartext password is direct database
access.

This seems a pretty substantial problem, as it means that the hash and
cleartext will be discordant for passwords >16 characters. But nothing
stops users from choosing such passwords.

Or alternately, could be an interesting bug to capitalize on.  It allows
creation of relay-only passwords.  I could use this for accounts which
only send mail but which should never check it (like my UPS or system
monitoring scripts).  From one perspective, this could be a security
advantage.  But forcing real users to use small passwords is probably a
much bigger disadvantage.

-Andy


On 10/2/2018 8:47 PM, Eric Broch wrote:
> And when debugging authentication with Dovecot, I get...
> 
> CLEARTEXT(password entered in webmail) != 'password in the database'
> 
> From dovecot.log the actual output:
> 
> Oct 02 22:05:45 auth-worker(19953): Debug:
> vpopmail(someu...@domain.tld,127.0.0.1,):
> CLEARTEXT(x) != ''
> Oct 02 22:05:47 auth: Debug: client passdb out: FAIL    1
> user=someu...@domain.tld
> 
> 
> 
> 
> On 10/2/2018 10:25 PM, Eric Broch wrote:
>> So, I think Dovecot MAY be authenticating against the plain text
>> password. I can't be sure until I look at the code or ask on the
>> Dovecot mailing list.
>>
>>
>> On 10/2/2018 10:22 PM, Eric Broch wrote:
>>> Okay,
>>>
>>> 17 character password works with Submission port. Not with IMAP which
>>> is authenticated through Dovecot.
>>>
>>> Eric
>>>
>>>
>>> On 10/2/2018 9:21 PM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> Regarding the hash: difficult to answer because of the atypical storage
>>>> method (in the database).  It looks like two items (username and
>>>> password???), each stored in an atypical base64 (using "." instead of
>>>> "+" for the 64th character) and each prefixed with a "$" and then
>>>> concatenated. Unfortunately, this makes it difficult to know what the
>>>> hash "should" be.  Each of these could also be salted. Browsing the
>>>> vpopmail source code would likely clear this up. Unsure when I'll have
>>>> time for that.
>>>>
>>>> I was testing passwords using Squirrelmail, which goes through IMAP,
>>>> which means that Dovecot does the authentication (I believe). It is
>>>> possible that dovecot (Centos7) is authenticating differently than did
>>>> courier-IMAP (Centos5).  There are two places in
>>>> /etc/dovecot/toaster.conf which specify "driver = vpopmail". I have no
>>>> idea what the detailed implications of that setting are.
>>>>
>>>> It would be interesting to see if the 16 or 17 character passwords work
>>>> for qmail-smtp.  Could try to telnet to port 25 and see if qmail
>>>> accepts
>>>> the 16 or 17 character password for relay.  If qmail takes the 17
>>>> character password and not the 16, it would indicate a different
>>>> authentication method than via IMAP.  This would mean that the database
>>>> is not the problem.
>>>>
>>>> Unfortunately, and not somewhere that allows me to try this right now.
>>>>
>>>> -Andy
>>>>
>>>>
>>>>
>>>> On 10/2/2018 6:47 PM, Eric Broch wrote:
>>>>> Okay,
>>>>>
>>>>> Set user's password to 17 x's, eg: x
>>>>>
>>>>> I could not log in with 17x password but I could with 16x password.
>>>>>
>>>>> Not sure what this means, I'm open to enlightenment. Could it be
>>>>> the hash?
>>>>>
>>>>>
>>>>>
>>>>> On 10/2/2018 8:41 PM, Eric Broch wrote:
>>>>>> Will do.
>>>>>>
>>>>>>
>>>>>> On 10/2/2018 8:40 PM, Andrew Swartz wrote:
>>>>>>> Eric,
>>>>>>>
>>>>>>> Before I do that, can you see if you can replicate the problem: On
>>>>>>> Centos7, create an account with a long password and see if you
>>>>>>> can then
>>>>>>> log in with the long password.  If that fails, then try with the
>>>>>>> first
>>>>>>> 16 characters of that password.
>>&

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Definitive test would be to use an SQL statement to manually change the
cleartext password in the database, and then see if Dovecot allows
authentication against that new password.  If authentication succeeds,
then the only plausible explanation is that Dovecot is directly
accessing the cleartext passwords.

I have little SQL knowledge and even less experience, so I'm not brave
enough to try this on my system. :)

-Andy


On 10/2/2018 8:47 PM, Eric Broch wrote:
> And when debugging authentication with Dovecot, I get...
> 
> CLEARTEXT(password entered in webmail) != 'password in the database'
> 
> From dovecot.log the actual output:
> 
> Oct 02 22:05:45 auth-worker(19953): Debug:
> vpopmail(someu...@domain.tld,127.0.0.1,):
> CLEARTEXT(x) != ''
> Oct 02 22:05:47 auth: Debug: client passdb out: FAIL    1
> user=someu...@domain.tld
> 
> 
> 
> 
> On 10/2/2018 10:25 PM, Eric Broch wrote:
>> So, I think Dovecot MAY be authenticating against the plain text
>> password. I can't be sure until I look at the code or ask on the
>> Dovecot mailing list.
>>
>>
>> On 10/2/2018 10:22 PM, Eric Broch wrote:
>>> Okay,
>>>
>>> 17 character password works with Submission port. Not with IMAP which
>>> is authenticated through Dovecot.
>>>
>>> Eric
>>>
>>>
>>> On 10/2/2018 9:21 PM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> Regarding the hash: difficult to answer because of the atypical storage
>>>> method (in the database).  It looks like two items (username and
>>>> password???), each stored in an atypical base64 (using "." instead of
>>>> "+" for the 64th character) and each prefixed with a "$" and then
>>>> concatenated. Unfortunately, this makes it difficult to know what the
>>>> hash "should" be.  Each of these could also be salted. Browsing the
>>>> vpopmail source code would likely clear this up. Unsure when I'll have
>>>> time for that.
>>>>
>>>> I was testing passwords using Squirrelmail, which goes through IMAP,
>>>> which means that Dovecot does the authentication (I believe). It is
>>>> possible that dovecot (Centos7) is authenticating differently than did
>>>> courier-IMAP (Centos5).  There are two places in
>>>> /etc/dovecot/toaster.conf which specify "driver = vpopmail". I have no
>>>> idea what the detailed implications of that setting are.
>>>>
>>>> It would be interesting to see if the 16 or 17 character passwords work
>>>> for qmail-smtp.  Could try to telnet to port 25 and see if qmail
>>>> accepts
>>>> the 16 or 17 character password for relay.  If qmail takes the 17
>>>> character password and not the 16, it would indicate a different
>>>> authentication method than via IMAP.  This would mean that the database
>>>> is not the problem.
>>>>
>>>> Unfortunately, and not somewhere that allows me to try this right now.
>>>>
>>>> -Andy
>>>>
>>>>
>>>>
>>>> On 10/2/2018 6:47 PM, Eric Broch wrote:
>>>>> Okay,
>>>>>
>>>>> Set user's password to 17 x's, eg: x
>>>>>
>>>>> I could not log in with 17x password but I could with 16x password.
>>>>>
>>>>> Not sure what this means, I'm open to enlightenment. Could it be
>>>>> the hash?
>>>>>
>>>>>
>>>>>
>>>>> On 10/2/2018 8:41 PM, Eric Broch wrote:
>>>>>> Will do.
>>>>>>
>>>>>>
>>>>>> On 10/2/2018 8:40 PM, Andrew Swartz wrote:
>>>>>>> Eric,
>>>>>>>
>>>>>>> Before I do that, can you see if you can replicate the problem: On
>>>>>>> Centos7, create an account with a long password and see if you
>>>>>>> can then
>>>>>>> log in with the long password.  If that fails, then try with the
>>>>>>> first
>>>>>>> 16 characters of that password.
>>>>>>>
>>>>>>> -Andy
>>>>>>>
>>>>>>>
>>>>>>> On 10/2/2018 6:28 PM, Eric Broch wrote:
>>>>>>>> Andrew,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/2/2018 7:34 PM, Andrew Swartz wrote:
>>>&g

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Eric,

On Centos7, I just successfully authenticated for relay on port 587 with
a 26-character password.  That same username/password fails with
Squirrelmail.  But it works with Squirrelmail if using only the first
16-characters of the password.

Since qmail-smtpd DEFINITELY authenticates through vpopmail, I think
that this indicates that both vpopmail and the database are functioning
correctly.

I originally found this problem because my IMAP client (Thunderbird) was
getting long passwords rejected.  Since Squirrelmail also authenticates
through IMAP, this suggests that Dovecot is the problem.

I hope that Dovecot is not directly accessing the database (i.e.
bypassing vpopmail) and authenticating with the cleartext (truncation
of) the password.  I'm open to other theories which can explain this
behavior.

-Andy




On 10/2/2018 7:21 PM, Andrew Swartz wrote:
> Eric,
> 
> Regarding the hash: difficult to answer because of the atypical storage
> method (in the database).  It looks like two items (username and
> password???), each stored in an atypical base64 (using "." instead of
> "+" for the 64th character) and each prefixed with a "$" and then
> concatenated. Unfortunately, this makes it difficult to know what the
> hash "should" be.  Each of these could also be salted.  Browsing the
> vpopmail source code would likely clear this up. Unsure when I'll have
> time for that.
> 
> I was testing passwords using Squirrelmail, which goes through IMAP,
> which means that Dovecot does the authentication (I believe).  It is
> possible that dovecot (Centos7) is authenticating differently than did
> courier-IMAP (Centos5).  There are two places in
> /etc/dovecot/toaster.conf which specify "driver = vpopmail".  I have no
> idea what the detailed implications of that setting are.
> 
> It would be interesting to see if the 16 or 17 character passwords work
> for qmail-smtp.  Could try to telnet to port 25 and see if qmail accepts
> the 16 or 17 character password for relay.  If qmail takes the 17
> character password and not the 16, it would indicate a different
> authentication method than via IMAP.  This would mean that the database
> is not the problem.
> 
> Unfortunately, and not somewhere that allows me to try this right now.
> 
> -Andy
> 
> 
> 
> On 10/2/2018 6:47 PM, Eric Broch wrote:
>> Okay,
>>
>> Set user's password to 17 x's, eg: x
>>
>> I could not log in with 17x password but I could with 16x password.
>>
>> Not sure what this means, I'm open to enlightenment. Could it be the hash?
>>
>>
>>
>> On 10/2/2018 8:41 PM, Eric Broch wrote:
>>> Will do.
>>>
>>>
>>> On 10/2/2018 8:40 PM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> Before I do that, can you see if you can replicate the problem: On
>>>> Centos7, create an account with a long password and see if you can then
>>>> log in with the long password.  If that fails, then try with the first
>>>> 16 characters of that password.
>>>>
>>>> -Andy
>>>>
>>>>
>>>> On 10/2/2018 6:28 PM, Eric Broch wrote:
>>>>> Andrew,
>>>>>
>>>>>
>>>>> On 10/2/2018 7:34 PM, Andrew Swartz wrote:
>>>>>> 1.  vpopmail (or something else) is NOW authenticating against the
>>>>>> cleartext password instead of the hash.
>>>>> I don't think so, or I hope not. I've done nothing except compile
>>>>> vpopmail on CentOS 7 back in 2015 no patches.
>>>>> The only change, if I remember correctly, is MariaDB requirements
>>>>> rather
>>>>> the MySQL.
>>>>>> 2.  vpopmail (or something else) is NOW truncating the password at 16
>>>>>> characters when it is set (i.e. hashed), but not during subsequent
>>>>>> authentication.
>>>>> I hope it's something else.
>>>>>> 3.  mysql was storing something in the cleartext password field
>>>>>> which it
>>>>>> did not export.  This seems unlikely, as I can see 16 characters
>>>>>> and the
>>>>>> field type is "char(16)".  I went through the database export file,
>>>>>> and
>>>>>> its contents appear the same as those of the running mysql database on
>>>>>> Centos5, which is the same as the running mariadb database on
>>>>>> Centos7 (I
>>>>>> view the contents with WebMin).  Therefore it appears that the
>>>>>> backup/restore wor

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Eric,

Regarding the hash: difficult to answer because of the atypical storage
method (in the database).  It looks like two items (username and
password???), each stored in an atypical base64 (using "." instead of
"+" for the 64th character) and each prefixed with a "$" and then
concatenated. Unfortunately, this makes it difficult to know what the
hash "should" be.  Each of these could also be salted.  Browsing the
vpopmail source code would likely clear this up. Unsure when I'll have
time for that.

I was testing passwords using Squirrelmail, which goes through IMAP,
which means that Dovecot does the authentication (I believe).  It is
possible that dovecot (Centos7) is authenticating differently than did
courier-IMAP (Centos5).  There are two places in
/etc/dovecot/toaster.conf which specify "driver = vpopmail".  I have no
idea what the detailed implications of that setting are.

It would be interesting to see if the 16 or 17 character passwords work
for qmail-smtp.  Could try to telnet to port 25 and see if qmail accepts
the 16 or 17 character password for relay.  If qmail takes the 17
character password and not the 16, it would indicate a different
authentication method than via IMAP.  This would mean that the database
is not the problem.

Unfortunately, and not somewhere that allows me to try this right now.

-Andy



On 10/2/2018 6:47 PM, Eric Broch wrote:
> Okay,
> 
> Set user's password to 17 x's, eg: x
> 
> I could not log in with 17x password but I could with 16x password.
> 
> Not sure what this means, I'm open to enlightenment. Could it be the hash?
> 
> 
> 
> On 10/2/2018 8:41 PM, Eric Broch wrote:
>> Will do.
>>
>>
>> On 10/2/2018 8:40 PM, Andrew Swartz wrote:
>>> Eric,
>>>
>>> Before I do that, can you see if you can replicate the problem: On
>>> Centos7, create an account with a long password and see if you can then
>>> log in with the long password.  If that fails, then try with the first
>>> 16 characters of that password.
>>>
>>> -Andy
>>>
>>>
>>> On 10/2/2018 6:28 PM, Eric Broch wrote:
>>>> Andrew,
>>>>
>>>>
>>>> On 10/2/2018 7:34 PM, Andrew Swartz wrote:
>>>>> 1.  vpopmail (or something else) is NOW authenticating against the
>>>>> cleartext password instead of the hash.
>>>> I don't think so, or I hope not. I've done nothing except compile
>>>> vpopmail on CentOS 7 back in 2015 no patches.
>>>> The only change, if I remember correctly, is MariaDB requirements
>>>> rather
>>>> the MySQL.
>>>>> 2.  vpopmail (or something else) is NOW truncating the password at 16
>>>>> characters when it is set (i.e. hashed), but not during subsequent
>>>>> authentication.
>>>> I hope it's something else.
>>>>> 3.  mysql was storing something in the cleartext password field
>>>>> which it
>>>>> did not export.  This seems unlikely, as I can see 16 characters
>>>>> and the
>>>>> field type is "char(16)".  I went through the database export file,
>>>>> and
>>>>> its contents appear the same as those of the running mysql database on
>>>>> Centos5, which is the same as the running mariadb database on
>>>>> Centos7 (I
>>>>> view the contents with WebMin).  Therefore it appears that the
>>>>> backup/restore worked properly.
>>>> Maybe something worth my time: Bring up two qmail (w/vpopmail) VM's on
>>>> COS5 and COS7.
>>>> Next, Create a domain and user entry on COS5 with >16 length password.
>>>> Dump the vpopmail db on COS5 (vpopmail-cos5db), and import it on COS7.
>>>> Dump the vpopmail db on COS7 (vpopmail-cos7db), and compare (diff) the
>>>> two dumps.
>>>> If they're the same it could possibly be an issue with the vpopmail
>>>> program.
>>>>
>>>> If you were up to it, you could also create a database called vpopmail1
>>>> on your COS7 machine,
>>>> and import the COS5 vpopmail db into it (that way it doesn't mess with
>>>> your regular vpopmail db), and
>>>> dump it and compare the two (COS5/COS7) dumps.
>>>>> Does anyone know the details of how vpopmail interacts with the
>>>>> database
>>>>> server?  Or if any authentication is done by some means other than
>>>>> through vpopmail?
>>>> Interaction with db by vpopmail is done at compile time.
>>>>
>>
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Eric,

Before I do that, can you see if you can replicate the problem: On
Centos7, create an account with a long password and see if you can then
log in with the long password.  If that fails, then try with the first
16 characters of that password.

-Andy


On 10/2/2018 6:28 PM, Eric Broch wrote:
> Andrew,
> 
> 
> On 10/2/2018 7:34 PM, Andrew Swartz wrote:
>> 1.  vpopmail (or something else) is NOW authenticating against the
>> cleartext password instead of the hash.
> I don't think so, or I hope not. I've done nothing except compile
> vpopmail on CentOS 7 back in 2015 no patches.
> The only change, if I remember correctly, is MariaDB requirements rather
> the MySQL.
>>
>> 2.  vpopmail (or something else) is NOW truncating the password at 16
>> characters when it is set (i.e. hashed), but not during subsequent
>> authentication.
> I hope it's something else.
>>
>> 3.  mysql was storing something in the cleartext password field which it
>> did not export.  This seems unlikely, as I can see 16 characters and the
>> field type is "char(16)".  I went through the database export file, and
>> its contents appear the same as those of the running mysql database on
>> Centos5, which is the same as the running mariadb database on Centos7 (I
>> view the contents with WebMin).  Therefore it appears that the
>> backup/restore worked properly.
> Maybe something worth my time: Bring up two qmail (w/vpopmail) VM's on
> COS5 and COS7.
> Next, Create a domain and user entry on COS5 with >16 length password.
> Dump the vpopmail db on COS5 (vpopmail-cos5db), and import it on COS7.
> Dump the vpopmail db on COS7 (vpopmail-cos7db), and compare (diff) the
> two dumps.
> If they're the same it could possibly be an issue with the vpopmail
> program.
> 
> If you were up to it, you could also create a database called vpopmail1
> on your COS7 machine,
> and import the COS5 vpopmail db into it (that way it doesn't mess with
> your regular vpopmail db), and
> dump it and compare the two (COS5/COS7) dumps.
>>
>> Does anyone know the details of how vpopmail interacts with the database
>> server?  Or if any authentication is done by some means other than
>> through vpopmail?
> Interaction with db by vpopmail is done at compile time.
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

Has vpopmail changed?

Among the numerous possible explanations of this behavior:

1.  vpopmail (or something else) is NOW authenticating against the
cleartext password instead of the hash.

2.  vpopmail (or something else) is NOW truncating the password at 16
characters when it is set (i.e. hashed), but not during subsequent
authentication.

3.  mysql was storing something in the cleartext password field which it
did not export.  This seems unlikely, as I can see 16 characters and the
field type is "char(16)".  I went through the database export file, and
its contents appear the same as those of the running mysql database on
Centos5, which is the same as the running mariadb database on Centos7 (I
view the contents with WebMin).  Therefore it appears that the
backup/restore worked properly.

Does anyone know the details of how vpopmail interacts with the database
server?  Or if any authentication is done by some means other than
through vpopmail?

-Andy



On 10/2/2018 4:02 PM, Eric Broch wrote:
> This might be worthy of a note to the MariaDB folks.
> 
> 
> On 10/2/2018 5:59 PM, Andrew Swartz wrote:
>> I felt a new subject appropriate.
>>
>> Current setup is QMT on Centos7 (set up last month).  I did a
>> backup/restore (of accounts only) from a Centos5 QMT.
>>
>> NEW INFORMATION:
>> I just dug through a few automated accounts which still have the long
>> passwords which I've not updated since the backup/restore.  I tried
>> logging in via Squirelmail.
>>
>> - I cannot authenticate with the long password.
>> - I CAN authenticate with the first 16 characters of the password.
>> - The hashes in the old (Centos5) and new (Centos7) vpopmail databases
>> are identical.  Therefore it Eric seems correct that the restore did not
>> regenerate the hashes.
>>
>> HOWEVER:
>> I just tried the same account/password on the old Centos5 QMT, and
>> successfully logged in with the long password (via squirrelmail).
>>
>> NEXT:
>> I just took a test account with a short password on the Centos7 QMT, and
>>   I reset it to a long.
>> - I cannot authenticate with the long password.
>> - I CAN authenticate with the first 16 characters of the password.
>>
>>
>> The only thing I can say conclusively is that this is different behavior
>> than on my Centos5 QMT where I was authenticating with long passwords
>> and never had any such problems.
>>
>> It seems that the different before/after behavior is not due to the
>> backup/restore scripts, but rather to some sort of different
>> functionality of the Centos7 setup.  It may take a lot of digging and
>> expert knowledge to sort this out.
>>
>> Curious to hear if others can replicate this behavior.
>>
>>
>> -Andy
>>
>>
>>
>>
>>
>>
>> On 10/2/2018 3:19 PM, Andrew Swartz wrote:
>>> I had the issue.
>>>
>>> I merely fixed it rather than fully investigating it.
>>>
>>> I had some accounts where, after the backup/restore, the passwords
>>> worked fine.  Yet other where the passwords failed.  When I looked at
>>> the database, the ones where the passwords failed had a long cleartext
>>> password which was chopped off at 16 characters.  All the accounts with
>>> short passwords worked fine.  I looked at the database schema, and saw
>>> that the cleartext password field is 16 characters.  So I tried
>>> authenticating with the shortened version of the password, and I
>>> ~believe~ that it worked.  However, I figured that there was now a
>>> discrepancy between the cleartext and the hash, so I reset the passwords
>>> for all the affected accounts.
>>>
>>> In retrospect, I wish I had investigated further; however, I was in the
>>> mode of fixing the problem as rapidly as possible.  I apologize for not
>>> digging further so that I could pass the info along to others.
>>>
>>> I do not remember if I visually compared the hashes.  I probably did,
>>> and they were probably the same.  That is probably why I got worried
>>> about a cleartext versus hash discrepancy.
>>>
>>> This much I can say with 100% confidence:
>>> The accounts with passwords >16 characters would not authenticate after
>>> the backup/restore procedure.  Resetting those passwords fixed the
>>> problem.
>>>
>>>
>>> -Andy
>>>
>>>
>>>
>>> On 10/2/2018 2:49 PM, Tony White wrote:
>>>> Hi Eric,
>>>>    Sorry, I made it sound like you had the issue. I know it was not
>>>> you.
>>>>
>&

[qmailtoaster] Passwords after backup/restore

[Andrew Swartz]

I felt a new subject appropriate.

Current setup is QMT on Centos7 (set up last month).  I did a
backup/restore (of accounts only) from a Centos5 QMT.

NEW INFORMATION:
I just dug through a few automated accounts which still have the long
passwords which I've not updated since the backup/restore.  I tried
logging in via Squirelmail.

- I cannot authenticate with the long password.
- I CAN authenticate with the first 16 characters of the password.
- The hashes in the old (Centos5) and new (Centos7) vpopmail databases
are identical.  Therefore it Eric seems correct that the restore did not
regenerate the hashes.

HOWEVER:
I just tried the same account/password on the old Centos5 QMT, and
successfully logged in with the long password (via squirrelmail).

NEXT:
I just took a test account with a short password on the Centos7 QMT, and
 I reset it to a long.
- I cannot authenticate with the long password.
- I CAN authenticate with the first 16 characters of the password.


The only thing I can say conclusively is that this is different behavior
than on my Centos5 QMT where I was authenticating with long passwords
and never had any such problems.

It seems that the different before/after behavior is not due to the
backup/restore scripts, but rather to some sort of different
functionality of the Centos7 setup.  It may take a lot of digging and
expert knowledge to sort this out.

Curious to hear if others can replicate this behavior.


-Andy






On 10/2/2018 3:19 PM, Andrew Swartz wrote:
> I had the issue.
> 
> I merely fixed it rather than fully investigating it.
> 
> I had some accounts where, after the backup/restore, the passwords
> worked fine.  Yet other where the passwords failed.  When I looked at
> the database, the ones where the passwords failed had a long cleartext
> password which was chopped off at 16 characters.  All the accounts with
> short passwords worked fine.  I looked at the database schema, and saw
> that the cleartext password field is 16 characters.  So I tried
> authenticating with the shortened version of the password, and I
> ~believe~ that it worked.  However, I figured that there was now a
> discrepancy between the cleartext and the hash, so I reset the passwords
> for all the affected accounts.
> 
> In retrospect, I wish I had investigated further; however, I was in the
> mode of fixing the problem as rapidly as possible.  I apologize for not
> digging further so that I could pass the info along to others.
> 
> I do not remember if I visually compared the hashes.  I probably did,
> and they were probably the same.  That is probably why I got worried
> about a cleartext versus hash discrepancy.
> 
> This much I can say with 100% confidence:
> The accounts with passwords >16 characters would not authenticate after
> the backup/restore procedure.  Resetting those passwords fixed the problem.
> 
> 
> -Andy
> 
> 
> 
> On 10/2/2018 2:49 PM, Tony White wrote:
>> Hi Eric,
>>   Sorry, I made it sound like you had the issue. I know it was not you.
>>
>> best wishes
>>   Tony White
>>
>> On 03/10/18 07:50, Eric Broch wrote:
>>
>>> Okay,
>>>
>>> It seems odd, to me at least, that using the mysql/mariadb commands
>>> 'mysqldump' to backup the vpopmail database and to restore it again
>>> with 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How
>>> is this possible? Certainly a backup/restore doesn't rehash passwords
>>> using the clear text field. It should simply restore exactly what's
>>> backed up. Is this thinking erroneous???
>>>
>>> Eric
>>>
>>>
>>> On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote:
>>>> I hear ya Andrew! I have a very large QMT that hosts hundreds of
>>>> domains. One of those tenants knows that this is a QMT install, and
>>>> wanted to have access to the vqadmin program -- which WOULD have
>>>> given them visibility to other domains' passwords -- but I deny
>>>> access to that tool to anyone (I don't even use it)... they CAN use
>>>> the admin role with the standard qmailadmin interface, because that
>>>> is limited to one domain at a time.
>>>>
>>>> I have a list of "superadmins" for that system that have access to
>>>> the user passwords through the shell "vuserinfo" command -- and you
>>>> have to be elevated (root) to run that, so anyone breaking in
>>>> (hacking) the website (apache user), or qmail (qmail, qmaill, or
>>>> qmailq users) or even vpopmail (vpopmail user) will NOT be able to
>>>> run that command.
>>>>
>>>> I also CHANGE the default passwords for the MySQL 

Re: Fwd: Re: [qmailtoaster] centos 6

[Andrew Swartz]

I had the issue.

I merely fixed it rather than fully investigating it.

I had some accounts where, after the backup/restore, the passwords
worked fine.  Yet other where the passwords failed.  When I looked at
the database, the ones where the passwords failed had a long cleartext
password which was chopped off at 16 characters.  All the accounts with
short passwords worked fine.  I looked at the database schema, and saw
that the cleartext password field is 16 characters.  So I tried
authenticating with the shortened version of the password, and I
~believe~ that it worked.  However, I figured that there was now a
discrepancy between the cleartext and the hash, so I reset the passwords
for all the affected accounts.

In retrospect, I wish I had investigated further; however, I was in the
mode of fixing the problem as rapidly as possible.  I apologize for not
digging further so that I could pass the info along to others.

I do not remember if I visually compared the hashes.  I probably did,
and they were probably the same.  That is probably why I got worried
about a cleartext versus hash discrepancy.

This much I can say with 100% confidence:
The accounts with passwords >16 characters would not authenticate after
the backup/restore procedure.  Resetting those passwords fixed the problem.


-Andy



On 10/2/2018 2:49 PM, Tony White wrote:
> Hi Eric,
>   Sorry, I made it sound like you had the issue. I know it was not you.
> 
> best wishes
>   Tony White
> 
> On 03/10/18 07:50, Eric Broch wrote:
> 
>> Okay,
>>
>> It seems odd, to me at least, that using the mysql/mariadb commands
>> 'mysqldump' to backup the vpopmail database and to restore it again
>> with 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How
>> is this possible? Certainly a backup/restore doesn't rehash passwords
>> using the clear text field. It should simply restore exactly what's
>> backed up. Is this thinking erroneous???
>>
>> Eric
>>
>>
>> On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote:
>>> I hear ya Andrew! I have a very large QMT that hosts hundreds of
>>> domains. One of those tenants knows that this is a QMT install, and
>>> wanted to have access to the vqadmin program -- which WOULD have
>>> given them visibility to other domains' passwords -- but I deny
>>> access to that tool to anyone (I don't even use it)... they CAN use
>>> the admin role with the standard qmailadmin interface, because that
>>> is limited to one domain at a time.
>>>
>>> I have a list of "superadmins" for that system that have access to
>>> the user passwords through the shell "vuserinfo" command -- and you
>>> have to be elevated (root) to run that, so anyone breaking in
>>> (hacking) the website (apache user), or qmail (qmail, qmaill, or
>>> qmailq users) or even vpopmail (vpopmail user) will NOT be able to
>>> run that command.
>>>
>>> I also CHANGE the default passwords for the MySQL database... so if
>>> you CAN break in, you CANNOT just query the database (because the
>>> vpopmail password is well known).
>>>
>>> So that's been my way to deal with it... your mileage may vary 
>>>
>>> Dan
>>>
>>>
>>> -Original Message-
>>> From: Andrew Swartz 
>>> Sent: Tuesday, October 2, 2018 11:24 AM
>>> To: qmailtoaster-list@qmailtoaster.com
>>> Subject: Re: Fwd: Re: [qmailtoaster] centos 6
>>>
>>> Dan,
>>>
>>> Excellent explanation. Thank you.
>>>
>>> It explains something which I did not report in my email:  I solved this
>>> by trying only the first 16 characters of the long passwords, and sure
>>> enough they validated.  I did not put enough thought into it to realize
>>> that the hashes had been regenerated from the shortened passwords.
>>>
>>> This explanation implies that the problem is that the restore script
>>> generates new hashes from the [stored] cleartext passwords.  Seems like
>>> an easy fix would be to just backup/restore the hashes instead of
>>> generating new hashes.
>>>
>>> QUESTIONS:
>>> 1. What is the format of the stored hash?  Looks like concatenation of
>>> two [atypical] base64 fields.
>>>
>>> 2. How difficult would it be to remove the cleartext passwords from
>>> vpopmail?  I see the logic of storing the "hint".  But it means that for
>>> systems with multiple admins, all of the admins can view (and therefore
>>> use) most users' passwords.  That is problematic even without
>>> considering the foreign i

Re: Fwd: Re: [qmailtoaster] centos 6

[Andrew Swartz]

Dan,

Excellent explanation. Thank you.

It explains something which I did not report in my email:  I solved this
by trying only the first 16 characters of the long passwords, and sure
enough they validated.  I did not put enough thought into it to realize
that the hashes had been regenerated from the shortened passwords.

This explanation implies that the problem is that the restore script
generates new hashes from the [stored] cleartext passwords.  Seems like
an easy fix would be to just backup/restore the hashes instead of
generating new hashes.

QUESTIONS:
1. What is the format of the stored hash?  Looks like concatenation of
two [atypical] base64 fields.

2. How difficult would it be to remove the cleartext passwords from
vpopmail?  I see the logic of storing the "hint".  But it means that for
systems with multiple admins, all of the admins can view (and therefore
use) most users' passwords.  That is problematic even without
considering the foreign intruder risk.

My security concern for QMT has always been that I've never trusted the
qmail accessories as much as qmail itself.  I remain fairly confident
that an intruder will not enter via port 25 (i.e. through qmail).  But
running the web server (for webmail) markedly increases the risk.

QUESTION: could a webserver SQL-injection retrieve the cleartext passwords?

-Andy



On 10/2/2018 5:02 AM, Dan McAllister - QMT DNS wrote:
> I know I'm "Johnny-come-lately" on this topic, but I can explain the results 
> you're seeing and have seen the same myself:
> 
> The QMT vpopmail default setup saves the hashed password, as well as the 
> first 16-characters of the clear-text password, in the MySQL database. That 
> has already been established. What you probably don't know (or didn't think 
> of) is how those fields are used!
> 
> Consider the following:
>  - First, the length of the hashing algorithm is a fixed length. Different 
> hashes, different lengths (for example: MD5 hashes are always 32 characters, 
> SHA1 hashes have 40 characters, sha512 hashes 128, and so on...)
>  - Second, ONLY the hashed password is used for validation. There is no NEED 
> for the cleartext password in the database, it's there simply because the 
> MySQL database was considered somewhat secure, and the original developers of 
> the QMT realized that about 40% of user problems are caused by NOT KNOWING 
> THEIR PASSWORDS, and being able to GIVE them their existing password was 
> generally easier than resetting it (and hearing complaints that, although you 
> "fixed" their desktop mail, now their phone's weren't getting email!)
>  - Finally, the original designers of QMT assumed people would use long 
> passwords -- it was suggested in the original documentation. Thus, saving 
> only the first 16 characters of the password in cleartext meant you were only 
> REALLY saving a "password hint" vs. the entire password.
> 
> So - when you enter a 75 character password (only slightly absurd these 
> days), and if we assume a sha1 password hash, then the "set password" 
> function hashes your 75 characters into a 40-character SHA1 hash and saves it 
> into the database field that stores up to (magically) 40 characters. (FWIW: 
> when you enter your 2-character password of "ok", the sha1 algorithm ALSO 
> generates a 40 character output!). After is stores the hashed password, it 
> ALSO stores the first 16 characters of the cleartext password -- because 
> that's the length of the field in the database.
> 
> When you try to authenticate, the password you provided is re-hashed 
> (regardless of its length -- although usually those fields have 64, 72, or 
> 128 character field limits - depending on the web-page designer/programmer), 
> and those 40 characters (the output of the sha1 hash) are compared to your 
> stored hash... there is no query of the cleartext password.
> 
> Unfortunately, when you attempt to restore your passwords using just the 
> stored cleartext passwords, you will find (not surprisingly) that passwords 
> that were longer than the 16 chars generate a totally different hash result! 
> (Interesting side-note: you could have told your users that their passwords 
> were unchanged, but that they had to stop after the 16th character -- and it 
> would have worked!)
> 
> I hope this explains a few things!!
> 
> Dan
> 
> 
> IT4SOHO, LLC
> 33 4th St N; STE 211
> St. Petersburg, FL 33701
> +1-877-IT4SOHO
> +1-877-484-7646
> For service requests, direct your email to serv...@it4soho.com
> 
> 
> 
> -Original Message-
> From: Eric Broch  
> Sent: Friday, September 28, 2018 1:35 AM
> To: qmailtoaster-list@qmailtoaster.com
> Subject: Re: Fwd: Re: [qmailtoaster] centos 6
> 
> Thanks, Andy. Plain text password hav

Re: Fwd: Re: [qmailtoaster] centos 6

[Andrew Swartz]

I recently did the backup/restore and I have one hiccup to report.

A few of the account passwords did not work after backup from centos5
and restore to centos7.

Took some time to troubleshoot, but I poked around in the vpopmail
database and figured it out.  It was due to the vpopmail database
schema, which stores a 16 character password AND its hash.  It allowed
[and worked with] passwords longer than 16 characters (I'm unsure how).
But after the backup/restore, all passwords longer than 16 characters
failed.  Problem was fixed by resetting all of these passwords to new
ones with the proper length.  Luckily there were not many like this.
But for a large system, this could be a major pain.

This seems like a bug.  If the max password length is 16 characters,
then the set-password webpage should reject passwords that are too long.

Also, I'm not sure why it stores a plaintext password in addition to its
hash.  The modern standard is to store only the hash.  This is
potentially a major security problem.

-Andy


On 9/27/2018 8:57 PM, Tony White wrote:
> Eric,
>   I now have a working v6 COS qmt, thank you for you help an patience.
> Now the backup and restore...
> 
> best wishes
>   Tony White
> 
> On 28/09/18 14:43, Eric Broch wrote:
> 
>> changed now
>>
>>
>> On 9/27/2018 10:41 PM, Tony White wrote:
>>> Eric,
>>>   Yes I did run that command.
>>>
>>>   At stage 3 after manually starting qmail at the end of qt-install.
>>>
>>> Stage 3
>>>
>>> rpm -Uvh
>>> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/6/current/x86_64/qmt-release-1-5.qt.el6.noarch.rpm
>>> needs to be
>>>
>>> rpm -Uvh
>>> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/6/current/x86_64/qmt-release-1-6.qt.el6.noarch.rpm
>>>
>>>
>>> best wishes
>>>   Tony White
>>>
>>>  ..  ..  .. 
>>> | .--. || .--. || .--. |
>>> | |      | || | __   | || |___   | |
>>> | | |_  _||_  _| | || |   .' ___  |  | || |   /  ___  |  | |
>>> | |   \ \  / /   | || |  / .'   \_|  | || |  |  (__ \_|  | |
>>> | |\ \/ /| || |  | | | || |   '.___`-.   | |
>>> | |_|  |_| || |  \ `.___.'\  | || |  |`\) |  | |
>>> | |   |__|   | || |   `._.'  | || |  |___.'  | |
>>> | |  | || |  | || |  | |
>>> | '--' || '--' || '--' |
>>>  ''  ''  '' 
>>>
>>> http://www.ycs.com.au
>>> 4 The Crescent
>>> Yea
>>> Victoria
>>> Australia 3717
>>>
>>> Telephone No's
>>> VIC : 0418 515 717
>>>
>>> Please note: YCS records all calls to better serve you.
>>>
>>> IMPORTANT NOTICE
>>>
>>> This communication including any file attachments is intended solely for
>>> the use of the individual or entity to whom it is addressed. If you are
>>> not the intended recipient, or the person responsible for delivering
>>> this communication to the intended recipient, please immediately notify
>>> the sender by email and delete the original transmission and its
>>> contents. Any unauthorised use, dissemination, forwarding, printing or
>>> copying of this communication including file attachments is prohibited.
>>> It is your responsibility to scan this communication including any file
>>> attachments for viruses and other defects. To the extent permitted by
>>> law, Yea Computing Services and its associates will not be liable for 
>>> any loss or damage arising in any way from this communication including
>>> any file attachments.
>>> You may not disclose this information to a third party without written
>>> permission from the Author.
>>> On 28/09/18 14:14, Eric Broch wrote:

 Excellent!!! Glad to hear it.


 On 9/27/2018 10:03 PM, Tony White wrote:
> Eric,
>   Sorry I did not intend to email offlist.
> I did a reply to sender not the list.
> Apologies.
>
> I have reset the VM to give me a blank minimal install again.
> It has just finished qt-bootstrp-2 without error.
> So far so good.
>
> cheers.
>
>
> On 28/09/18 13:53, Eric Broch wrote:
>>
>> Tony, If you communicate off list you must whitelist my address
>>
>>
>> Tony,
>>
>> I think (not sure why) you're still using the wrong bootstrap
>> scripts, my bootstrap's (below in red and green) do not use
>> 'mirrors.qmailtoaster.com' but 'mirror2.qmailtoaster.com'
>>
>> Irritatingly, this is because all the mirror maintainers dropped
>> the ball and didn't bother to let anyone know that they weren't
>> supporting QMT anymore. If this is a pre-existing machine disable
>> the qmailtoaster-current repo:
>>
>> # yum install yum-utils && yum-config-manager --disable
>> qmailtoaster-current qmailtoaster-current-nodist
>>
>> 
>>
>> #!/bin/bash
>>
>> # Copyright (C) Eric Shubert 
>> #
>> # script to do initial bootstrap processing (disable 

Re: [qmailtoaster] Allowing percent sign in email addresses

[Andrew Swartz]

Consider the possibility that this could be a spamdyke option/issue. I
mention this because with my centos5 toaster I had to manually install
spamdyke but it installed automatically with my recent centos7 toaster.
Also, the spamdyke version has upgraded from 4.x to 5.x which was a
fairly significant change.

You could test this easily by commenting out the spamdyke line in
/var/qmail/supervise/smtpd and then restarting qmail.  If that solves
the problem, then spamdyke is the culprit and you should then scour the
spamdyke docs for the appropriate setting to change.

-Andy



On 9/11/2018 6:51 AM, Jeff Koch wrote:
> Hi Eric:
> 
> This was an old Bill's Toaster and for reasons I can't remember (going
> back to 1999) user's couldn't put '@' asteriks in their usernames so we
> had them use percent signs which Bill's toaster accepted.
> 
> Jeff
> 
> On 9/11/2018 10:23 AM, Eric Broch wrote:
>>
>> Hi Jeff,
>>
>> How old was the toaster? What metamorphosis of qmail were you running.
>>
>> In all the maintenance I've done nothing has been modified to the
>> qmail packages concerning the % character.
>>
>>
>> On 9/11/2018 7:54 AM, Jeff Koch wrote:
>>> Hi:
>>>
>>> We just upgraded a mailserver to the new qmail toaster and ran into a
>>> problem. The old mailserver allowed usernames with percent signs such
>>> as sam%domain.com. The new toaster rejects that form of username. Is
>>> there any quick fix that would allow the percent sign to be used?
>>> Otherwise we have hundreds of customers that won't be able to connect
>>> to their email accounts.
>>>
>>> Regards, Jeff
>>
>> -- 
>> Eric Broch
>> White Horse Technical Consulting (WHTC)
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] clamav-toaster 0.100

[Andrew Swartz]

I notice that these clamav rpm's are still in the "testing" directory of
the repo.

Can anyone report success or problems with the centos-7 verions?

-Andy



On 6/11/2018 9:45 AM, Eric Broch wrote:
> Hi Jason,
> 
> CentOS 6 & 7 clamav-0.100.0 source RPMS
> 
> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/7/testing/SRPMS/clamav-0.100.0-4.qt.el7.src.rpm
> 
> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/6/testing/SRPMS/clamav-0.100.0-4.qt.el6.src.rpm
> 
> and
> 
> Binaries
> 
> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/7/testing/x86_64/clamav-0.100.0-4.qt.el7.x86_64.rpm
> 
> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/6/testing/x86_64/clamav-0.100.0-4.qt.el6.x86_64.rpm
> 
> Eric
> 
> 
> On 6/11/2018 11:19 AM, Jason Westbrook wrote:
>>
>> Hi All
>>
>> I was wondering if/when the source rpms that I believe Eric posts on
>> whitehorsetc.com  will be updated to include
>> clamav 0.100 ?
>>
>>
>> Thanks! 
>>
>>
>> Jason Westbrook |T: 313-799-3770| jwestbr...@gmail.com
>>  
> 
> -- 
> Eric Broch
> White Horse Technical Consulting (WHTC)
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] /ect/crontab

[Andrew Swartz]

Thank you!


On 8/20/2018 5:52 PM, Remo Mattei wrote:
> # cat /etc/crontab
> SHELL=/bin/bash
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
> MAILTO=postmas...@italy1.com
> 
> # For details see man 4 crontabs
> 
> # Example of job definition:
> # . minute (0 - 59)
> # |  .- hour (0 - 23)
> # |  |  .-- day of month (1 - 31)
> # |  |  |  .--- month (1 - 12) OR jan,feb,mar,apr ...
> # |  |  |  |  . day of week (0 - 6) (Sunday=0 or 7) OR 
> sun,mon,tue,wed,thu,fri,sat
> # |  |  |  |  |
> # *  *  *  *  * user-name  command to be executed
> 
> 
> 01 01 * * * root /var/qmail/bin/dh_key 2>&1 > /dev/null
> 
> 0-59/5 * * * * root env LANG=C /usr/bin/mrtg 
> /usr/share/toaster/mrtg/qmailmrtg.cfg > /dev/null 2>&1
> 
> 58 * * * * root /usr/share/toaster/isoqlog/bin/cron.sh 2>&1 > /dev/null
> 03 2 * * *  root /etc/rc.d/daily-backup
> 01 8 * * *  root /etc/rc.d/mysql-sync.sh
> 
> 
> 
> 
>> On Aug 20, 2018, at 18:34, Andrew Swartz  wrote:
>>
>> I accidentally overwrote /etc/crontab on my centos-7 toaster.
>>
>> Can someone please post theirs so I can recreate it.
>>
>> Thanks,
>> -Andy
>>
> 



smime.p7s
Description: S/MIME Cryptographic Signature

[qmailtoaster] /ect/crontab

[Andrew Swartz]

I accidentally overwrote /etc/crontab on my centos-7 toaster.

Can someone please post theirs so I can recreate it.

Thanks,
-Andy



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] How to turn of DKIM check?

[Andrew Swartz]

It worked for me.

-Andy


On 8/18/2018 10:52 AM, Jaime Lerner wrote:
> So I received a bounce notice from the list (ezmlm) with the following
> error, and since domain keys aren't really being used anymore, I'd like
> to turn off the DK check of incoming mail so my server won't bounce them
> if nothing is there.
> 
> Remote host said: 554 DomainKeys verify status: no key   (#5.3.0)
> 
> I just saw a thread between Andrew and Eric talking about removing
> domain keys entirely (so I would also no longer sign with them). Is that
> what I should do? Or is there a way to just stop the incoming check? 



smime.p7s
Description: S/MIME Cryptographic Signature

[qmailtoaster] Removing domain keys

[Andrew Swartz]

Eric,

After a little research, I've come up with this plan to remove domainkeys:

1. Removed from each tcprules file:

DKQUEUE="/var/qmail/bin/qmail-queue.orig"
DKVERIFY="DEGIJKfh",
DKSIGN="/var/qmail/control/domainkeys/%/private"


2. Reinstate the original qmail-queue:

rm /var/qmail/bin/qmail-dk
rm /var/qmail/bin/qmail-queue
mv /var/qmail/bin/qmail-queue.orig /var/qmail/bin/qmail-queue


3. rm /var/qmail/control/domainkeys


4. qmailctl cdb


Does this seem adequate?


Thanks,

-Andy





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

[Andrew Swartz]

Eric,

That's interesting.  Those tcprules are that which was present after the
upgrade.  I do not know if it changed them or left them default from
qt-install.  I only copied tcp.smtp to tcp.smtps and changed the ciphers
at the end of the line.  I definitely did not add domain keys to it.

Also, there is still a control/domainkeys directory.  It is empty.  It
must have been created by qt-install because I did not create it.  I do
plan on adding dkim, but I've not gotten to it yet.

-Andy


On 8/16/2018 3:49 PM, Eric Broch wrote:
> Andy,
> 
> I noticed your tcprules include domain keys, be aware that if you
> upgrade to qmail-1.03-3.1 domainkeys have been removed.
> 
> Eric
> 
> 
> On 8/16/2018 5:25 PM, Andrew Swartz wrote:
>> Eric,
>>
>> Your request prompted me to look more closely at these files.
>>
>> I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
>> /var/qmail/supervise/smtps/run with a new one which is missing the
>> 'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
>> SMTPS=1'.  The new supervise/smtps/log/run names the log file
>> "smtp-ssl", whereas I have named it "smtps".  I would argue it should be
>> the latter for consistency, but it is clearly noncritical.
>>
>>
>> Here is my /etc/tcprules.d/tcp.smtp:
>>
>> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"
>>
>>
>>
>>
>> Here is my /etc/tcprules.d/tcp.smtps:
>>
>> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"
>>
>>
>>
>> They are identical except that the smtp one does not have a TLSCIPHERS
>> setting.  This is for two reasons:
>> 1.  per my read of the TLS patch, if not present, it defaults to using
>> qmail/control/tlsserverciphers. This would make qmail-smtpd and
>> qmail-remote use the same ciphers (because tlsclientciphers is just a
>> link to tlsserverciphers).  Since both of those are doing relay, that
>> would seem appropriate for most setups.  Except...
>> 2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
>> specifying a cipher for port 25 is useless.
>>
>> If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
>> then I would have the supervise/submission/run script specify
>> tcp.smtps.cdb so that the cipher rules are the same for these two ports
>> because they are both handling submission and both not going through
>> spamdyke.
>>
>>
>> Here is my /var/qmail/supervise/smtps/run:
>> #!/bin/sh
>> QMAILDUID=`id -u vpopmail`
>> NOFILESGID=`id -g vpopmail`
>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>> SMTPD="/var/qmail/bin/qmail-smtpd"
>> TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
>> HOSTNAME=`hostname`
>> VCHKPW="/home/vpopmail/bin/vchkpw"
>> export REQUIRE_AUTH=1
>> export SMTPS=1
>>
>> exec /usr/bin/softlimit -m 12800 \
>>  /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c
>> "$MAXSMTPD" \
>>  -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
>>  $SMTPD $VCHKPW /bin/true 2>&1
>>
>>
>> A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
>> 83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
>> compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.
>>
>> -Andy
>>
>>
>> On 8/16/2018 1:33 PM, Eric Broch wrote:
>>> Andy,
>>>
>>> Would you mind sharing your tcprules files and smtp/smtps run scripts?
>>>
>>> Eric
>>>
>>>
>>> On 8/16/2018 3:03 PM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> I already had smtps installed.  The new package seems to have
>>>> overwritten the prior files.
>>>>
>>>> However, that was minimally problematic because I have smtps configured
>>>> a little differently than standard.  I have supervise/smtps/run specify
>>>> a separate tcprules.d file for smtps. Th

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

[Andrew Swartz]

Eric,

Your request prompted me to look more closely at these files.

I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
/var/qmail/supervise/smtps/run with a new one which is missing the
'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
SMTPS=1'.  The new supervise/smtps/log/run names the log file
"smtp-ssl", whereas I have named it "smtps".  I would argue it should be
the latter for consistency, but it is clearly noncritical.


Here is my /etc/tcprules.d/tcp.smtp:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"



Here is my /etc/tcprules.d/tcp.smtps:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"


They are identical except that the smtp one does not have a TLSCIPHERS
setting.  This is for two reasons:
1.  per my read of the TLS patch, if not present, it defaults to using
qmail/control/tlsserverciphers. This would make qmail-smtpd and
qmail-remote use the same ciphers (because tlsclientciphers is just a
link to tlsserverciphers).  Since both of those are doing relay, that
would seem appropriate for most setups.  Except...
2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
specifying a cipher for port 25 is useless.

If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
then I would have the supervise/submission/run script specify
tcp.smtps.cdb so that the cipher rules are the same for these two ports
because they are both handling submission and both not going through
spamdyke.


Here is my /var/qmail/supervise/smtps/run:
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export REQUIRE_AUTH=1
export SMTPS=1

exec /usr/bin/softlimit -m 12800 \
    /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
    -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
    $SMTPD $VCHKPW /bin/true 2>&1


A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.

-Andy


On 8/16/2018 1:33 PM, Eric Broch wrote:
> Andy,
>
> Would you mind sharing your tcprules files and smtp/smtps run scripts?
>
> Eric
>
>
> On 8/16/2018 3:03 PM, Andrew Swartz wrote:
>> Eric,
>>
>> I already had smtps installed.  The new package seems to have
>> overwritten the prior files.
>>
>> However, that was minimally problematic because I have smtps configured
>> a little differently than standard.  I have supervise/smtps/run specify
>> a separate tcprules.d file for smtps. This allows me to have a much
>> stricter cipherlist for mail submission than for relay.  The rationale
>> being that I can mandate that submission clients are up to date and
>> using TLSv1.2.  But for relay, I have to support all the old servers
>> (like qmail on centos-5) having an inability to do anything better than
>> SSLv3.
>>
>> I'm not wild about the cipherlist which installed, but that was easy to
>> change.  My understanding is that the order of the ciphers in the list
>> is important in that openssl interprets the list in a most-preferred to
>> least-preferred order.  The list which installed has several SSLv3
>> ciphers very early in the list.
>>
>> While one can specify exact ciphers, openssl also allows specifying the
>> cipher "suites" instead
>> (https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
>> this is much more intuitive. I'm currently playing around with 'openssl
>> cipherlist' to get my preferred content and order correct.  I'm
>> currently leaning toward:
>>
>> 'TLSv1.2:SSLv3:!eNULL:!aNULL'    for smtp
>>
>> and
>>
>> 'TLSv1.2:!eNULL:!aNULL'    for smtps
>>
>> The important effect of my smtp list is that all of the TLSv1.2 ciphers
>> are preferred/attempted before reverting to SSLv3 ciphers.
>>
>> Here is a paste-able command with human read

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

[Andrew Swartz]

Eric,

I already had smtps installed.  The new package seems to have
overwritten the prior files.

However, that was minimally problematic because I have smtps configured
a little differently than standard.  I have supervise/smtps/run specify
a separate tcprules.d file for smtps. This allows me to have a much
stricter cipherlist for mail submission than for relay.  The rationale
being that I can mandate that submission clients are up to date and
using TLSv1.2.  But for relay, I have to support all the old servers
(like qmail on centos-5) having an inability to do anything better than
SSLv3.

I'm not wild about the cipherlist which installed, but that was easy to
change.  My understanding is that the order of the ciphers in the list
is important in that openssl interprets the list in a most-preferred to
least-preferred order.  The list which installed has several SSLv3
ciphers very early in the list.

While one can specify exact ciphers, openssl also allows specifying the
cipher "suites" instead
(https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
this is much more intuitive. I'm currently playing around with 'openssl
cipherlist' to get my preferred content and order correct.  I'm
currently leaning toward:

'TLSv1.2:SSLv3:!eNULL:!aNULL'   for smtp

and

'TLSv1.2:!eNULL:!aNULL' for smtps

The important effect of my smtp list is that all of the TLSv1.2 ciphers
are preferred/attempted before reverting to SSLv3 ciphers.

Here is a paste-able command with human readable output to see the
content and order of the results (you will need to widen the terminal
window to see it correctly):

openssl ciphers -v 'TLSv1.2:SSLv3:!eNULL:!aNULL' | awk '{ printf "%-29s
%-9s  %-13s  %-10s  %-17s  %-s\n",$1,$2,$3,$4,$5,$6 }'

Playing with this has taught me some interesting things (which I do
vaguely remember reading elsewhere at some point).  First, there are no
TLSv1.1 ciphers.  Also, the TLSv1 ciphers are the same ciphers as SSLv3.
 Therefore listing 'TLSv1:!SSLv3' yields no ciphers. The take-home
message is that you either get TLSv1.2 or SSLv3; there is no in-between
for the ciphers.  That's why my above lists omit TLSv1.1 and TLSv1. My
understanding is that TLSv1 and TLSv1.1 had improvements in the protocol
but not the ciphers.

I refuse to use ALL, LOW, etc for creating the cipher list because they
are extremely opaque.  If a notice comes out saying "no one should use
SSLv3", these vague terms do not tell me if I'm using that.  I see no
downside to explicitly specifying the cipher suites.  If you want to be
insecure, you could specify SSLv2.  When the new openssl 1.1.1 comes out
and supports TLSv1.3 (which should happen any day), then I'll explicitly
add that to my cipherlist. If nothing else, it will prompt me to review
the list occasionally.

That merely addresses the ciphers.  There is also significance to the
SSL and TLS protocols, but there appears to be no qmail setting for
those.  It would be far better to use TLSv1 protocol than SSLv3 protocol
even though the ciphers are identical.  I'm gonna do some testing with
changing my qmail cipherlist and connecting via s_client with explicit
protocols and see how much effect the specified cipherlist has upon the
protocol.

This was intended to be a short email.  Sorry.  "I'm sorry this letter
is so long, I didn't have time to compose a short one."

I've had a lot of time this last week to work on this, but I now have
very little time until next week.  I'll consider testing 1.03-3.1 when I
get another chunk of time.

-Andy



On 8/16/2018 9:35 AM, Eric Broch wrote:
> Thanks, Andy.
> 
> It installed SMTPS, correct?
> 
> If you felt bold, I needed some folks to test 1.03-3.1. ;-)
> 
> Eric
> 
> 
> On 8/16/2018 11:28 AM, Andrew Swartz wrote:
>> Eric,
>>
>> Thanks for the help.  I installed qmail-1.03-3.qt.el7.x86_64.rpm without
>> difficulty and it seems to be fully functional.
>>
>> -Andy
>>
>>
>> On 8/15/2018 9:01 AM, Eric Broch wrote:
>>> I ran this 1.03-3 version for several months with no issues, and haven't
>>> heard anything from the community on it.
>>>
>>> I personally upgraded to 1.03-3.1 (in the development tree) now on my
>>> own production machine. In this version I take all the patches (below),
>>> carrying over some, updating some and adding extras, and apply them in
>>> an orderly fashion instead of using one big patch because IMHO opinion
>>> patching will be easier to maintain this way. I'm going to create
>>> 1.03-3.2 in which I'll add to qmail-smtpd more extensive logging mainly
>>> to indicate a message's having been queued. And, I'd also like to
>>> possibly add logging to qmail-remote.
>>>
>>> I was motivated to update/add patches by the work of
>>>
>>> Rob

Re: [qmailtoaster] Asking the password frequently

[Andrew Swartz]

Dan,

I too noticed your mention of selinux.  Do you have qmail running with
selinux?  If so, I'd love to know how.  I have stumbled across some
selinux contexts for qmail components, but I've never seen any clear
explanation or script for configuration.

-Andy


On 8/16/2018 7:42 AM, Remo Mattei wrote:
> Not sure about this but qmail does not have selinux enabled. So your
> steps there may need to be reviewed. 
> 
> 
> 
>> On Aug 16, 2018, at 08:21, Dan McAllister - QMT DNS > > wrote:
>>
>> So let’s explain the steps – some of which you may have already done:
>> a.  ## 1. Generate an RSA key with keylength of 2K (2048) – this is
>> used to PROVE authorship
>> b.  ## The output file is x.key
>> c.  openssl genrsa -out x.key 2048
>> d.   
>> e.  ## 2. Generate a Certificate Request – needed to create a
>> certificate later
>> f.  ## The output file is x.csr
>> g.  openssl req -new -key x.key -out x.csr
>> h.   
>> i.  ## 3. Create a self-signed certificate, using the KEY and REQUEST
>> you created above (a 10-year certificate in this case)
>> j.  ## The output file is x.crt
>> k.  openssl x509 -req -days 3650 -in x.csr -signkey x.key -out x.crt
>> l.   
>> m.  ## So now you have 3 files: the REQUEST file COULD have been sent
>> to a signing authority for them to create a CERTIFICATE for you that
>> is signed by them – thus, making it “valid” for anyone else who trusts
>> that signing authority – but in this case, you used it to create your
>> OWN (self-signed) certificate… no one will trust it, unless they trust
>> EVERYONE.
>> n.   
>> o.  ## 4. Next, you create the PEM file, which stores the KEY and the
>> CERTIFICATE in a single file
>> p.  ## In the general case, this isn’t a good idea, but it’ll suffice
>> in this case
>> q.  cat x.crt x.key > servercert.pem
>> r.   
>> s.  ## 5. Next you make the combined file readable by all (be careful
>> with ACLs and SE-Linux)
>> t.  chmod 644 servercert.pem
>> u.   
>> v.  ## 6. Then you make the certificate (and key – combined file)
>> owned by root (the only user who can change it) and belong to the
>> qmail group – which doesn’t REALLY matter
>> w.  chown root:qmail servercert.pem
>> x.   
>> y.  ## 7. Finally you copy (with permissions) the combined file into
>> your Qmail config folder
>> z.  cp -p servercert.pem /var/qmail/control
>>  
>> If you were to get a REAL certificate, you would replace Step 3 above
>> with the submission of your CSR file, along with the FQDNs you are
>> proposing to certify, to the chosen agency. THEY will return to you a
>> CRT file, along with an INTERMEDIATE certificate file. (DO NOT EVER
>> SEND THEM YOUR KEY FILE!)
>> Then, in Step 4, you would ADD their intermediate certificate to the
>> PEM file (just stick the filename in between your key filename and
>> your certificate filename).
>>  
>> Once you think you have it, test it with the tools at
>>  https://www.sslshopper.com/ssl-checker.html
>> To check your mail server, specify the mail server with the SSL
>> enabled port number, e.g.: mail.x.com:465
>>  or mail.x.com:993
>>  for your imaps server
>>  
>> One last comment – your instructions show you doing this as root –
>> only steps 6 & 7 require elevation: 6 to chown to root, and 7 to write
>> into the Qmail control folder. YOU REALLY SHOULDN’T PLAY IN YOUR
>> SYSTEMS (or work, if you must) AS THE ROOT USER!
>>  
>> I hope this helps….
>>  
>> Dan
>>  
>>  
>>  
>>  
>> *From:* ChandranManikandan mailto:kand...@gmail.com>> 
>> *Sent:* Thursday, August 16, 2018 3:54 AM
>> *To:* qmailtoaster-list@qmailtoaster.com
>> 
>> *Subject:* Re: [qmailtoaster] Asking the password frequently
>>  
>> Hi Eric,
>>  
>> I have one doubt regard the create certificate.
>>  
>> I have gone through this link https://www.qmailtoaster.org/ssl.html
>>  
>> It was showing the six steps.
>> Do i need to complete all the six steps or just use only the below
>> second steps only for my server COS 6 & 7 32 and 64 bit.
>> Please help me.
>>  
>>
>>  1. Application: Self-Signed Certificate
>>
>> a.  # openssl genrsa -out x.key 2048
>> b.  # openssl req -new -key x.key -out x.csr
>> c.  # openssl x509 -req -days 3650 -in x.csr -signkey x.key -out x.crt
>> d.  # cat x.crt x.key > servercert.pem
>> e.  # chmod 644 servercert.pem
>> f.  # chown root:qmail servercert.pem
>> g.  # cp -p servercert.pem /var/qmail/control
>>
>>  
>>
>>  
>> On Tue, Aug 14, 2018 at 11:03 AM, ChandranManikandan
>> mailto:kand...@gmail.com>> wrote:
>>> Hi Eric,
>>>  
>>> Thank you, Let me try it and update here.
>>>  
>>> On Tue, Aug 14, 2018 at 10:54 AM, Eric Broch >> > wrote:
 I've installed certificates on both CentOS 6 & 7 using GoDaddy and
 LetsEncrypt.
  
 On 8/12/2018 9:12 PM, ChandranManikandan wrote:
> Hi Eric, 
>  
> I think i already installed the certificate which was 512 and got
> expired 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

[Andrew Swartz]

Eric,

Thanks.

What is the proper destination folder for the rpm (to allow the 'yum
localupdate' command)?

-Andy


On 8/15/2018 7:25 AM, Eric Broch wrote:
> wget https://www.qmailtoaster.org/qmail-1.03-3.qt.el7.x86_64.rpm
> 
> yum localupdate qmail-1.03-3.qt.el7.x86_64.rpm
> 
> 
> On 8/15/2018 9:22 AM, Andrew Swartz wrote:
>> I just realized that the qt-install script did not install qmail-1.03-3
>> on my new centos-7 toaster.
>>
>> Does anyone have experience with the qmail-1.03-3 update?
>>
>> -Andy
>>
> 





smime.p7s
Description: S/MIME Cryptographic Signature

[qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

[Andrew Swartz]

I just realized that the qt-install script did not install qmail-1.03-3
on my new centos-7 toaster.

Does anyone have experience with the qmail-1.03-3 update?

-Andy



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] status of qt-backup and qt-restore?

[Andrew Swartz]

I looked through the qt-backup and qt-restore scripts on github.

They seem intended for backup and restore to the same model toaster
where EVERYTHING is essentially identical. That seems less applicable
when upgrading by two centos versions which is accompanied by newer
versions of the adjunct software packages (i.e. spamassassin,
squirrelmail, etc).

In my case, I just want to transfer the mail and the login credentials.
I'm fine with squirrelmail, spamassassin, etc. reverting to installation
defaults. Also, I've mostly configured the stuff in qmail/control; the
only thing I need to transfer there is the dkim stuff, which should not
be very labor intensive to do manually.

Eric,

Does this seem like a reasonable plan to transfer the mail and the login
credentials:

1. use a subset of the qt-backup and qt-restore code for backing up and
restoring JUST the MYSQL data (i.e. the vpopmail database). I would just
cut and paste the segment of code into two very small new scripts.

2. rsync /home/vpopmail/domains

Would there be anything else necessary to move the accounts to the new
server?

-Andy



On 8/14/2018 6:30 PM, Remo Mattei wrote:
> I would like to check that out too since I need to move some accounts
> from a 5x box. I just moved one domain and the steps I had to do is add
> the domain / users on the new server and then I did an rsync 
> 
>  I wish I did not have to create an account but then it means I have to
> copy the db over. I guess it’s a catch 22.
> 
>  *dal mio iPhone X*
> 
> Il giorno 14 ago 2018, alle ore 19:19, Eric Broch
> mailto:ebr...@whitehorsetc.com>> ha scritto:
> 
>> I went through the qt-backup and rsync'd the necessary directories and
>> dumped the vpopmail database and restored it on the new machine. Let
>> me take a look at my replicate script and I'll get it to you.
>>
>>
>> On 8/14/2018 7:17 PM, Andrew Swartz wrote:
>>> Do I just rsync the /home/vpopmail directories?  Or is there
>>> data/settings elsewhere also?
>>>
>>> -Andy
>>>
>>>
>>>
>>> On 8/14/2018 4:40 PM, Eric Broch wrote:
>>>> Maria and MySQL have the same commands you should be okay with a
>>>> restore.
>>>>
>>>> Other things are different like spamassassin /etc/mail/spamassassin vs
>>>> /etc/spamassassin.
>>>>
>>>> If I had the servers side by side I wouldn't use backup and restore, I'd
>>>> use rsync.
>>>>
>>>>
>>>> On 8/14/2018 11:09 AM, Andrew Swartz wrote:
>>>>> Does anyone know if these will do a backup of a centos-5 toaster and
>>>>> restore to a centos-7 toaster?
>>>>>
>>>>> vpopmail seems unchanged, but mysql has changed to mariadb and courier
>>>>> has changed to dovecot.
>>>>>
>>>>> I have very little database knowledge.  I'm fearful of the restore
>>>>> causing disaster on the new toaster.
>>>>>
>>>>> -Andy
>>>>>
>>>>>
>>>>>
>>
>> -- 
>> Eric Broch
>> White Horse Technical Consulting (WHTC)
>>
>>
>> -
>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
>> <mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
>> For additional commands, e-mail:
>> qmailtoaster-list-h...@qmailtoaster.com
>> <mailto:qmailtoaster-list-h...@qmailtoaster.com>
>>

-- 
Andrew W. Swartz, MD
Departments of Emergency Medicine, Family Medicine, and Surgery
Yukon-Kuskokwim Delta Regional Hospital
Bethel, Alaska



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] status of qt-backup and qt-restore?

[Andrew Swartz]

Do I just rsync the /home/vpopmail directories?  Or is there
data/settings elsewhere also?

-Andy



On 8/14/2018 4:40 PM, Eric Broch wrote:
> Maria and MySQL have the same commands you should be okay with a restore.
> 
> Other things are different like spamassassin /etc/mail/spamassassin vs
> /etc/spamassassin.
> 
> If I had the servers side by side I wouldn't use backup and restore, I'd
> use rsync.
> 
> 
> On 8/14/2018 11:09 AM, Andrew Swartz wrote:
>> Does anyone know if these will do a backup of a centos-5 toaster and
>> restore to a centos-7 toaster?
>>
>> vpopmail seems unchanged, but mysql has changed to mariadb and courier
>> has changed to dovecot.
>>
>> I have very little database knowledge.  I'm fearful of the restore
>> causing disaster on the new toaster.
>>
>> -Andy
>>
>>
>>
> 



smime.p7s
Description: S/MIME Cryptographic Signature

[qmailtoaster] status of qt-backup and qt-restore?

[Andrew Swartz]

Does anyone know if these will do a backup of a centos-5 toaster and
restore to a centos-7 toaster?

vpopmail seems unchanged, but mysql has changed to mariadb and courier
has changed to dovecot.

I have very little database knowledge.  I'm fearful of the restore
causing disaster on the new toaster.

-Andy





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Requested DIGEST-MD5 scheme, but we have only SHA1

[Andrew Swartz]

My understanding is that RFC compliance is highly variable in email
client-server relationships.  This is because servers tend to have
preexisting relationships with clients such that servers can dictate
configurations.  Therefore RFC compliance isn't important for
interoperability.

Using STARTTLS over port 143 is perfectly secure if it is "required."

The pertinent RFC's is 2595 (June 1999), which I just reviewed.  It
specifies (and favors) STARTTLS on port 143 and frowns upon the
dedication of port 993 for TLS. The exact wording is: '/Separate ports
imply a model of either "secure" or "not secure."/'  It is interesting
that that concept was frowned upon back then because it has definitely
become favored today.  Being in a nebulous/unknown security state leads
to false assumptions which lead to security failure.

So per the RFC, I stand corrected: port 143 is the designated STARTTLS
port.  That makes logical since because the initial handshakes of TLS
and STARTTLS are incompatible, whereas plain-text and STARTTLS both
start out the same.  However, going as far back as using Eudora in the
late 90's, I've seen massive variability in IMAP/POP configurations. 
When the server gets to dictate configuration to the client in advance,
anything goes.

For example, here is Thunderbird's port 993 options:





Note that STARTTLS is an option on 993 (along with "none") and that
there is no setting for "required" versus "optional".  I've been using
Thunderbird for about 10 years, and I'm pretty sure that prior versions
had a setting for "required" or "optional" for STARTTLS.  Eudora
definitely had it.  There is a reasonable chance that the Thunderbird
developers removed the setting and that it silently uses "required". 
But if so, the end result is an ambiguous security setting from the
perspective of admins/users.  That is currently unacceptable.  The
IMAP/POP server might be configured for required STARTTLS, but how would
the user know that?  Transparency = good, ambiguity = bad.


That being said, here is Thunderbird's setting for submission on port 465:



Clearly "None" and "STARTTLS" are not supposed to be supported on port
465.  I imagine they include those options because enough server admins
want them. Again, the clients simply do as their server admins dictate.

Good question because it prompted me to review the RFC's.

The password encryption schemes (like digest-md5) are a concept which
predates authentication over an encrypted channel. The problem with
digest-md5 is that the md5 hash is considered broken and completely
insecure for such purposes.  The new mantra is to be explicitly secure
or insecure; therefore use of weak security to achieve a nebulous
security situation is slowly becoming outlawed.  Here is the wikipedia
article about digest-md5: 
https://en.wikipedia.org/wiki/Digest_access_authentication

If you can guarantee an encrypted session (which is always the case with
TLS), then just use PLAIN auth and ignore the password encryption
schemes all together.  The advantage of this is that PLAIN will never
require reconfiguration because it has become "broken".

Again, I hope with is helpful (and accurate).

-Andy









On 8/14/2018 1:10 AM, Peter Peltonen wrote:
> Thanks Andy. Just to be sure on this: I had the impression that
> STARTTLS could be used also with port 143? At least reading
> https://wiki.dovecot.org/SSL indicates so:
>
> "Clients using STARTTLS work by connecting to the regular unencrypted
> port and immediately issue a STARTTLS command, after which the session
> is encrypted."
>
> So it shouldn't matter if I use 143 or 993 as a port?
>
> My users should all use TLS (configured to their clients). I'm still
> wondering about the DIGEST-MD5: what is that auth mechanism for and
> why did my toaster conf use it? Anything bad that can happen by
> removing it? And what is the difference between PLAIN and LOGIN auth
> mechanisms? Are there client configs For Outlook / Thunderbird / Apple
> Mail that could be broken by this?
>
> Best,
> Peter
>
>
>
> On Tue, Aug 14, 2018 at 11:25 AM, Andrew Swartz  
> wrote:
>> Peter,
>>
>> If you are using ports 110/143, which are clear-text, then you should
>> switch to 993/995 (if possible, of course).
>>
>> Ports 993/995 are never intentionally clear-text; they are either TLS or
>> STARTTLS. Many servers/clients can be configured for either, but they
>> cannot be configured for both because the initial protocol sequences are
>> incompatible.
>>
>> If 993/995 are configured for TLS, you can use PLAIN auth method and not
>> give it another thought.
>>
>> But if configured for STARTTLS, it must be set to "require" STARTTLS
>> rather than just "if 

Re: [qmailtoaster] Requested DIGEST-MD5 scheme, but we have only SHA1

[Andrew Swartz]

Peter,

If you are using ports 110/143, which are clear-text, then you should
switch to 993/995 (if possible, of course).

Ports 993/995 are never intentionally clear-text; they are either TLS or
STARTTLS. Many servers/clients can be configured for either, but they
cannot be configured for both because the initial protocol sequences are
incompatible.

If 993/995 are configured for TLS, you can use PLAIN auth method and not
give it another thought.

But if configured for STARTTLS, it must be set to "require" STARTTLS
rather than just "if available".  If you can "require" STARTTLS, then
PLAIN auth is secure because the login cannot not be sent unencrpyted.

But if the connection is configured as "STARTTLS if available", then
failure to initiate the STARTTLS will result in continuing with a clear
text session.  In this scenario, a PLAIN auth would be very dangerous.

Hope this helps.

-Andy


On 8/13/2018 11:43 PM, Peter Peltonen wrote:
> Thanks for the suggestions!
> 
> So if I have only plain and login auth mechanisms enabled, what does
> that mean in practice security wise?
> 
> Any ideas why the error is happening sometimes but not always and why
> aut_cache settings would fix the problem? Is it related to caching
> credentials for different devices / clients for same account?
> 
> Best,
> Peter
> 
> On Tue, Aug 14, 2018 at 5:52 AM, Eric Broch  wrote:
>> I'd remove DIGEST-MD5 from 'auth_mechanisms'.
>>
>>
>>
>> On 8/13/2018 3:01 PM, Peter Peltonen wrote:
>>>
>>> I have a user with Outlook 2016 having this error appearing in the
>>> Dovecot logs and not being able to login when it occurs
>>>
>>> The strange thing is that if I restart dovecot then the Outlook can
>>> login and no error:
>>>
>>> method=DIGEST-MD5, rip=xxx, lip=yyy, mpid=23280, TLS
>>>
>>> What I have for auth mechanisms in toaster.conf is:
>>>
>>> auth_mechanisms = plain login digest-md5
>>>
>>> I thought it was a dovecot cache issue and I changed
>>>
>>>cache_key=%u
>>>
>>> to
>>>
>>>cache_key=%u%r
>>>
>>> but the problem reappeared after a week.
>>>
>>> This is an old QMT installation on COS5.
>>>
>>> Best,
>>> Peter
>>>
>>> -
>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>>>
>>
>> --
>> Eric Broch
>> White Horse Technical Consulting (WHTC)
>>
>>
>>
>> -
>> 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
> 
> 

-- 
Andrew W. Swartz, MD
Departments of Emergency Medicine, Family Medicine, and Surgery
Yukon-Kuskokwim Delta Regional Hospital
Bethel, Alaska



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

This is copied out of qmail/bin/dh_key:

openssl dhparam -2 -out /var/qmail/control/dh1024.new 2048 2>&1 > /dev/null
chmod 644 /var/qmail/control/dh1024.new 2>&1 > /dev/null
chown root:qmail /var/qmail/control/dh1024.new 2>&1 > /dev/null
mv -f /var/qmail/control/dh1024.new /var/qmail/control/dh1024.pem 2>&1 >
/dev/null

I've changed to "2048" (from 1024) toward the end of the first line. 

-Andy


On 8/13/2018 10:39 PM, Remo Mattei wrote:
> How did y-I gen the dh1024?
>
> Thanks 
>
> Sent from my iPad
>
> On Aug 13, 2018, at 11:34 PM, Andrew Swartz  <mailto:awswa...@acsalaska.net>> wrote:
>
>> I just went through the qmail-tls patch
>> (http://inoa.net/qmail-tls/netqmail-1.05-tls-20060104.patch).
>>
>> Lines 65-68  explain that if TLSCIPHERS is not present (in tcp.smtp)
>> then qmail-smtpd uses the ones in
>> /var/qmail/control/tlsclientciphers.  I interpret that as it not
>> being necessary.
>>
>> Over the last couple days I've discovered a couple things which might
>> interest you:
>>
>> 1. you can put any size dhparams into /var/qmail/control/dh1024.pem. 
>> I'm currently using 2048 bit dhparams in that file, and I proved it
>> to work with 4096 bit (just for fun).  I went through the patch and
>> confirmed that it does not check the size of the dhparams in the
>> file; if the file is present, qmail-smtpd passes it to openssl
>> without any checks. I mention this because 1024 bits is currently
>> considered insecure, and experts now recommend a minimum of 2048 bits.
>>
>> 2. The same goes for /var/qmail/control/rsa.512.pem. I've put a 2048
>> bit key in the file but cannot detect any change in behavior (i.e.
>> connecting with s_client and using -debug).  I have NO IDEA what that
>> file is used for.  It is hardly used in the patch and it is gone from
>> the newer version of the patch.  I've searched the file contents of
>> qmail/control and qmail/bin, and the only mention is in
>> qmail/bin/dh_key, which is a very short bash script for cron which
>> regenerates a new dh512.pem, dh1024.pem, and rsa512.pem daily. 
>> Therefore it is a RSA private key with no associated public key or
>> cert.  Qmail uses the contents of servercert.pem for all connections,
>> at least as far as I can ascertain. I've sent an email to the patch
>> author, but I've not heard back.
>>
>> If you want larger dhparams/keys, the easiest way is to edit the
>> sizes in /var/qmail/bin/dh_key and just wait for the daily cron job
>> to generate new files.
>>
>> -Andy
>>
>>
>>
>>
>> On 8/13/2018 10:03 PM, Remo Mattei wrote:
>>> I have the default one here it is.. should I add the TLS one like
>>> you mention below?
>>>
>>> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private”
>>>
>>>
>>>> On Aug 13, 2018, at 22:43, Andrew Swartz >>> <mailto:awswa...@acsalaska.net>> wrote:
>>>>
>>>> Remo,
>>>>
>>>> I don't think the order matters in tlsserverciphers.  I cat'd the
>>>> cert, the key, and the chain into my file, in that order, and it
>>>> works fine.
>>>>
>>>> Nice bug catch on the cipher list.  I made the script on the latest
>>>> centos-7 toaster which installs with a cipher list of
>>>> "DH:!LOW:!MEDIUM" in tcp.smtp.  The sed command merely replaces
>>>> it.  If it's not present, or different, nothing happens (i.e. it
>>>> fails gracefully).  It did not seem to affect your connection, as
>>>> that was just a cert verify problem.
>>>>
>>>> Do you have a TLSCIPHERS environ. variable in tcp.smtp?  In my
>>>> file, the line for remote mail ends with:
>>>> TLSCIPHERS="ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3"
>>>>
>>>> I just checked a centos-5 installation, and there is no TLSCIPHERS
>>>> variable in tcp.smtp.  I just connected to that machine with
>>>> s_client and it established a TLSv1.0 connection, so apparently
>>>> there is a default cipher list present in qmail-smtpd (I confirmed
>>>> that port 587 does not go through spamdyke).
>>>>
>>>> Specifying ciphers is merely due to my over paranoia.  99.999% of
>>>>

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

I just went through the qmail-tls patch
(http://inoa.net/qmail-tls/netqmail-1.05-tls-20060104.patch).

Lines 65-68  explain that if TLSCIPHERS is not present (in tcp.smtp)
then qmail-smtpd uses the ones in /var/qmail/control/tlsclientciphers. 
I interpret that as it not being necessary.

Over the last couple days I've discovered a couple things which might
interest you:

1. you can put any size dhparams into /var/qmail/control/dh1024.pem. 
I'm currently using 2048 bit dhparams in that file, and I proved it to
work with 4096 bit (just for fun).  I went through the patch and
confirmed that it does not check the size of the dhparams in the file;
if the file is present, qmail-smtpd passes it to openssl without any
checks. I mention this because 1024 bits is currently considered
insecure, and experts now recommend a minimum of 2048 bits.

2. The same goes for /var/qmail/control/rsa.512.pem. I've put a 2048 bit
key in the file but cannot detect any change in behavior (i.e.
connecting with s_client and using -debug).  I have NO IDEA what that
file is used for.  It is hardly used in the patch and it is gone from
the newer version of the patch.  I've searched the file contents of
qmail/control and qmail/bin, and the only mention is in
qmail/bin/dh_key, which is a very short bash script for cron which
regenerates a new dh512.pem, dh1024.pem, and rsa512.pem daily. 
Therefore it is a RSA private key with no associated public key or
cert.  Qmail uses the contents of servercert.pem for all connections, at
least as far as I can ascertain. I've sent an email to the patch author,
but I've not heard back.

If you want larger dhparams/keys, the easiest way is to edit the sizes
in /var/qmail/bin/dh_key and just wait for the daily cron job to
generate new files.

-Andy




On 8/13/2018 10:03 PM, Remo Mattei wrote:
> I have the default one here it is.. should I add the TLS one like you
> mention below?
>
> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private”
>
>
>> On Aug 13, 2018, at 22:43, Andrew Swartz > <mailto:awswa...@acsalaska.net>> wrote:
>>
>> Remo,
>>
>> I don't think the order matters in tlsserverciphers.  I cat'd the
>> cert, the key, and the chain into my file, in that order, and it
>> works fine.
>>
>> Nice bug catch on the cipher list.  I made the script on the latest
>> centos-7 toaster which installs with a cipher list of
>> "DH:!LOW:!MEDIUM" in tcp.smtp.  The sed command merely replaces it. 
>> If it's not present, or different, nothing happens (i.e. it fails
>> gracefully).  It did not seem to affect your connection, as that was
>> just a cert verify problem.
>>
>> Do you have a TLSCIPHERS environ. variable in tcp.smtp?  In my file,
>> the line for remote mail ends with:
>> TLSCIPHERS="ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3"
>>
>> I just checked a centos-5 installation, and there is no TLSCIPHERS
>> variable in tcp.smtp.  I just connected to that machine with s_client
>> and it established a TLSv1.0 connection, so apparently there is a
>> default cipher list present in qmail-smtpd (I confirmed that port 587
>> does not go through spamdyke).
>>
>> Specifying ciphers is merely due to my over paranoia.  99.999% of
>> people will likely be happy with the defaults.
>>
>> -Andy
>>
>>
>>
>> On 8/13/2018 9:25 PM, Remo Mattei wrote:
>>> I think I need to add the intermediary cert. looks like.. trying to
>>> figure that out now.. not sure which order they go. 
>>>
>>> Andrew Swartz wrote on 8/13/18 22:24:
>>>> Remo,
>>>>
>>>> I just did this:
>>>>
>>>> openssl s_client -starttls smtp -crlf -connect qmail.rm.ht:587
>>>>
>>>> and got the same result.
>>>>
>>>> Therefore you've probably had this problem for a while.
>>>>
>>>> Are you using the cert with the "full chain"?  Apparently bare certs
>>>> rarely verify, and I've read several recommendations to provide the
>>>> server with the pem file containing the full chain.
>>>>
>>>> If you read the stuff at the "STARTTLS Everywhere" site, they state that
>>>> most mail servers to not require (or even attempt) cert verification,
>>>> and changing this is one of their goals.
>>>>
>>>> -Andy
>>>>
>>>>
>>>>
>>>> On 8/13/2018 8:56

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

I meant "servercert.pem" and NOT "tlsserverciphers".


-Andy




On 8/13/2018 9:43 PM, Andrew Swartz wrote:
>
> Remo,
>
> I don't think the order matters in tlsserverciphers.  I cat'd the
> cert, the key, and the chain into my file, in that order, and it works
> fine.
>
> Nice bug catch on the cipher list.  I made the script on the latest
> centos-7 toaster which installs with a cipher list of
> "DH:!LOW:!MEDIUM" in tcp.smtp.  The sed command merely replaces it. 
> If it's not present, or different, nothing happens (i.e. it fails
> gracefully).  It did not seem to affect your connection, as that was
> just a cert verify problem.
>
> Do you have a TLSCIPHERS environ. variable in tcp.smtp?  In my file,
> the line for remote mail ends with:
> TLSCIPHERS="ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3"
>
> I just checked a centos-5 installation, and there is no TLSCIPHERS
> variable in tcp.smtp.  I just connected to that machine with s_client
> and it established a TLSv1.0 connection, so apparently there is a
> default cipher list present in qmail-smtpd (I confirmed that port 587
> does not go through spamdyke).
>
> Specifying ciphers is merely due to my over paranoia.  99.999% of
> people will likely be happy with the defaults.
>
> -Andy
>
>
>
> On 8/13/2018 9:25 PM, Remo Mattei wrote:
>> I think I need to add the intermediary cert. looks like.. trying to
>> figure that out now.. not sure which order they go.
>>
>> Andrew Swartz wrote on 8/13/18 22:24:
>>> Remo,
>>>
>>> I just did this:
>>>
>>> openssl s_client -starttls smtp -crlf -connect qmail.rm.ht:587
>>>
>>> and got the same result.
>>>
>>> Therefore you've probably had this problem for a while.
>>>
>>> Are you using the cert with the "full chain"?  Apparently bare certs
>>> rarely verify, and I've read several recommendations to provide the
>>> server with the pem file containing the full chain.
>>>
>>> If you read the stuff at the "STARTTLS Everywhere" site, they state that
>>> most mail servers to not require (or even attempt) cert verification,
>>> and changing this is one of their goals.
>>>
>>> -Andy
>>>
>>>
>>>
>>> On 8/13/2018 8:56 PM, Remo Mattei wrote:
>>>> Any suggestions on this Andy?
>>>>
>>>> openssl s_client -crlf -connect qmail.rm.ht:465
>>>> CONNECTED(0005)
>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>>> verify error:num=20:unable to get local issuer certificate
>>>> verify return:1
>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>>> verify error:num=27:certificate not trusted
>>>> verify return:1
>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>>> verify error:num=21:unable to verify the first certificate
>>>> verify return:1
>>>> ---
>>>> Certificate chain
>>>>  0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=qmail.rm.ht
>>>>    i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
>>>> RSA Domain Validation Secure Server CA
>>>> ---
>>>>
>>>>
>>>> I do have a valid cert as you can see it’s from COMODO. But not sure
>>>> about the first few lines
>>>>
>>>> Remo 
>>>>
>>>>> On Aug 13, 2018, at 21:42, Andrew Swartz >>>> <mailto:awswa...@acsalaska.net>> wrote:
>>>>>
>>>>> I just realized that the plain text line-wrapped the script, so here
>>>>> is an unwrapped version in case anyone else wants to use it. Also, I
>>>>> made it multiline so you can cut and paste it into a terminal and
>>>>> accomplish this in about 3 seconds with netstat confirming success (it
>>>>> should print a single line showing tcpserver listening on 465).
>>>>>
>>>>> rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year
>>>>> reinstates port 465/tls because starttls (port 587) is broken beyond
>>>>> repair (from a security perspective). So eventually everyone may
>>>>> eventually need to go back to port 465.  But since servers get to
>>>>> dictate setting to their clients without creating interoperability
>>>>> issues, it will likely be many years before this occurs.
>>>>>
>>>>> The crit

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

Remo,

I don't think the order matters in tlsserverciphers.  I cat'd the cert,
the key, and the chain into my file, in that order, and it works fine.

Nice bug catch on the cipher list.  I made the script on the latest
centos-7 toaster which installs with a cipher list of "DH:!LOW:!MEDIUM"
in tcp.smtp.  The sed command merely replaces it.  If it's not present,
or different, nothing happens (i.e. it fails gracefully).  It did not
seem to affect your connection, as that was just a cert verify problem.

Do you have a TLSCIPHERS environ. variable in tcp.smtp?  In my file, the
line for remote mail ends with:
TLSCIPHERS="ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3"

I just checked a centos-5 installation, and there is no TLSCIPHERS
variable in tcp.smtp.  I just connected to that machine with s_client
and it established a TLSv1.0 connection, so apparently there is a
default cipher list present in qmail-smtpd (I confirmed that port 587
does not go through spamdyke).

Specifying ciphers is merely due to my over paranoia.  99.999% of people
will likely be happy with the defaults.

-Andy



On 8/13/2018 9:25 PM, Remo Mattei wrote:
> I think I need to add the intermediary cert. looks like.. trying to
> figure that out now.. not sure which order they go.
>
> Andrew Swartz wrote on 8/13/18 22:24:
>> Remo,
>>
>> I just did this:
>>
>> openssl s_client -starttls smtp -crlf -connect qmail.rm.ht:587
>>
>> and got the same result.
>>
>> Therefore you've probably had this problem for a while.
>>
>> Are you using the cert with the "full chain"?  Apparently bare certs
>> rarely verify, and I've read several recommendations to provide the
>> server with the pem file containing the full chain.
>>
>> If you read the stuff at the "STARTTLS Everywhere" site, they state that
>> most mail servers to not require (or even attempt) cert verification,
>> and changing this is one of their goals.
>>
>> -Andy
>>
>>
>>
>> On 8/13/2018 8:56 PM, Remo Mattei wrote:
>>> Any suggestions on this Andy?
>>>
>>> openssl s_client -crlf -connect qmail.rm.ht:465
>>> CONNECTED(0005)
>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>> verify error:num=20:unable to get local issuer certificate
>>> verify return:1
>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>> verify error:num=27:certificate not trusted
>>> verify return:1
>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>> verify error:num=21:unable to verify the first certificate
>>> verify return:1
>>> ---
>>> Certificate chain
>>>  0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=qmail.rm.ht
>>>    i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
>>> RSA Domain Validation Secure Server CA
>>> ---
>>>
>>>
>>> I do have a valid cert as you can see it’s from COMODO. But not sure
>>> about the first few lines
>>>
>>> Remo 
>>>
>>>> On Aug 13, 2018, at 21:42, Andrew Swartz >>> <mailto:awswa...@acsalaska.net>> wrote:
>>>>
>>>> I just realized that the plain text line-wrapped the script, so here
>>>> is an unwrapped version in case anyone else wants to use it. Also, I
>>>> made it multiline so you can cut and paste it into a terminal and
>>>> accomplish this in about 3 seconds with netstat confirming success (it
>>>> should print a single line showing tcpserver listening on 465).
>>>>
>>>> rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year
>>>> reinstates port 465/tls because starttls (port 587) is broken beyond
>>>> repair (from a security perspective). So eventually everyone may
>>>> eventually need to go back to port 465.  But since servers get to
>>>> dictate setting to their clients without creating interoperability
>>>> issues, it will likely be many years before this occurs.
>>>>
>>>> The critical flaw in starttls is that some ISP's and/or governments
>>>> have been caught filtering out the STARTTLS packet and thus preventing
>>>> the initiation of encryption (a "starttls downgrade attack").  In that
>>>> case, the client's username and password are sent in the clear.  And
>>>> if an eavesdropper gets those, they can wreak havoc on your your life
>>>> (i.e. by resetting the password for your bank or other online
>>>> accounts, etc).  With port 465/tls, the clie

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

Remo,

I just did this:

openssl s_client -starttls smtp -crlf -connect qmail.rm.ht:587

and got the same result.

Therefore you've probably had this problem for a while.

Are you using the cert with the "full chain"?  Apparently bare certs
rarely verify, and I've read several recommendations to provide the
server with the pem file containing the full chain.

If you read the stuff at the "STARTTLS Everywhere" site, they state that
most mail servers to not require (or even attempt) cert verification,
and changing this is one of their goals.

-Andy



On 8/13/2018 8:56 PM, Remo Mattei wrote:
> Any suggestions on this Andy?
> 
> openssl s_client -crlf -connect qmail.rm.ht:465
> CONNECTED(0005)
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
> verify error:num=27:certificate not trusted
> verify return:1
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
> verify error:num=21:unable to verify the first certificate
> verify return:1
> ---
> Certificate chain
>  0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=qmail.rm.ht
>    i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
> RSA Domain Validation Secure Server CA
> ---
> 
> 
> I do have a valid cert as you can see it’s from COMODO. But not sure
> about the first few lines
> 
> Remo 
> 
>> On Aug 13, 2018, at 21:42, Andrew Swartz > <mailto:awswa...@acsalaska.net>> wrote:
>>
>> I just realized that the plain text line-wrapped the script, so here
>> is an unwrapped version in case anyone else wants to use it. Also, I
>> made it multiline so you can cut and paste it into a terminal and
>> accomplish this in about 3 seconds with netstat confirming success (it
>> should print a single line showing tcpserver listening on 465).
>>
>> rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year
>> reinstates port 465/tls because starttls (port 587) is broken beyond
>> repair (from a security perspective). So eventually everyone may
>> eventually need to go back to port 465.  But since servers get to
>> dictate setting to their clients without creating interoperability
>> issues, it will likely be many years before this occurs.
>>
>> The critical flaw in starttls is that some ISP's and/or governments
>> have been caught filtering out the STARTTLS packet and thus preventing
>> the initiation of encryption (a "starttls downgrade attack").  In that
>> case, the client's username and password are sent in the clear.  And
>> if an eavesdropper gets those, they can wreak havoc on your your life
>> (i.e. by resetting the password for your bank or other online
>> accounts, etc).  With port 465/tls, the client connection either
>> establishes encryption or fails; it cannot be tricked into using
>> clear-text.
>>
>> Anyway, here is the paste-able script:
>>
>> qmailctl stop; \
>> cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps; \
>> chown -R qmaill:qmail /var/qmail/supervise/smtps; \
>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
>> /var/qmail/supervise/smtps/run; \
>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run; \
>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run; \
>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2:!SSLv3/'
>> /etc/tcprules.d/tcp.smtp; \
>> qmailctl cdb; \
>> qmailctl start; \
>> netstat -lnp | grep 465
>>
>>
>> -Andy
>>
>> PS: If old clients cannot connect, then remove the "!SSLv3" from the
>> cipher list in tcp.smtp
>>
>>
>>
>>
>>
>>
>> On 8/13/2018 7:32 PM, Remo Mattei wrote:
>>> Cool! I remember I did it like Eric described but the bottom line is
>>> it works either way. I do not offer 465 any longer :) 
>>>
>>>  *dal mio iPhone X*
>>>
>>> Il giorno 13 ago 2018, alle ore 20:25, Andrew Swartz
>>> mailto:awswa...@acsalaska.net>> ha scritto:
>>>
>>>> I eventually figured this out, and accomplished the same result though I
>>>> went about it slightly differently.  It is now fully functional.  Below
>>>> is the script which I created and accomplishes this in very few lines.
>>>> It copies the supervise/smtp directory to supervise/smtps and it then
>>>> edits a few values in two files files (plus editing the cipher list in
>>>> tcp.smtp).
>>>>
>>>&g

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

Does it verify with on port 587:

openssl s_client -starttls smtp -crlf -connect localhost:587


-Andy


On 8/13/2018 8:56 PM, Remo Mattei wrote:
> Any suggestions on this Andy?
> 
> openssl s_client -crlf -connect qmail.rm.ht:465
> CONNECTED(0005)
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
> verify error:num=27:certificate not trusted
> verify return:1
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
> verify error:num=21:unable to verify the first certificate
> verify return:1
> ---
> Certificate chain
>  0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=qmail.rm.ht
>    i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
> RSA Domain Validation Secure Server CA
> ---
> 
> 
> I do have a valid cert as you can see it’s from COMODO. But not sure
> about the first few lines
> 
> Remo 
> 
>> On Aug 13, 2018, at 21:42, Andrew Swartz > <mailto:awswa...@acsalaska.net>> wrote:
>>
>> I just realized that the plain text line-wrapped the script, so here
>> is an unwrapped version in case anyone else wants to use it. Also, I
>> made it multiline so you can cut and paste it into a terminal and
>> accomplish this in about 3 seconds with netstat confirming success (it
>> should print a single line showing tcpserver listening on 465).
>>
>> rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year
>> reinstates port 465/tls because starttls (port 587) is broken beyond
>> repair (from a security perspective). So eventually everyone may
>> eventually need to go back to port 465.  But since servers get to
>> dictate setting to their clients without creating interoperability
>> issues, it will likely be many years before this occurs.
>>
>> The critical flaw in starttls is that some ISP's and/or governments
>> have been caught filtering out the STARTTLS packet and thus preventing
>> the initiation of encryption (a "starttls downgrade attack").  In that
>> case, the client's username and password are sent in the clear.  And
>> if an eavesdropper gets those, they can wreak havoc on your your life
>> (i.e. by resetting the password for your bank or other online
>> accounts, etc).  With port 465/tls, the client connection either
>> establishes encryption or fails; it cannot be tricked into using
>> clear-text.
>>
>> Anyway, here is the paste-able script:
>>
>> qmailctl stop; \
>> cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps; \
>> chown -R qmaill:qmail /var/qmail/supervise/smtps; \
>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
>> /var/qmail/supervise/smtps/run; \
>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run; \
>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run; \
>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2:!SSLv3/'
>> /etc/tcprules.d/tcp.smtp; \
>> qmailctl cdb; \
>> qmailctl start; \
>> netstat -lnp | grep 465
>>
>>
>> -Andy
>>
>> PS: If old clients cannot connect, then remove the "!SSLv3" from the
>> cipher list in tcp.smtp
>>
>>
>>
>>
>>
>>
>> On 8/13/2018 7:32 PM, Remo Mattei wrote:
>>> Cool! I remember I did it like Eric described but the bottom line is
>>> it works either way. I do not offer 465 any longer :) 
>>>
>>>  *dal mio iPhone X*
>>>
>>> Il giorno 13 ago 2018, alle ore 20:25, Andrew Swartz
>>> mailto:awswa...@acsalaska.net>> ha scritto:
>>>
>>>> I eventually figured this out, and accomplished the same result though I
>>>> went about it slightly differently.  It is now fully functional.  Below
>>>> is the script which I created and accomplishes this in very few lines.
>>>> It copies the supervise/smtp directory to supervise/smtps and it then
>>>> edits a few values in two files files (plus editing the cipher list in
>>>> tcp.smtp).
>>>>
>>>>
>>>> qmailctl stop
>>>> cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps
>>>> chown -R qmaill:qmail /var/qmail/supervise/smtps
>>>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
>>>> /var/qmail/supervise/smtps/run
>>>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run
>>>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run
>>>> sed -i

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

I just realized that the plain text line-wrapped the script, so here is
an unwrapped version in case anyone else wants to use it. Also, I made
it multiline so you can cut and paste it into a terminal and accomplish
this in about 3 seconds with netstat confirming success (it should print
a single line showing tcpserver listening on 465).

rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year
reinstates port 465/tls because starttls (port 587) is broken beyond
repair (from a security perspective). So eventually everyone may
eventually need to go back to port 465.  But since servers get to
dictate setting to their clients without creating interoperability
issues, it will likely be many years before this occurs.

The critical flaw in starttls is that some ISP's and/or governments have
been caught filtering out the STARTTLS packet and thus preventing the
initiation of encryption (a "starttls downgrade attack").  In that case,
the client's username and password are sent in the clear.  And if an
eavesdropper gets those, they can wreak havoc on your your life (i.e. by
resetting the password for your bank or other online accounts, etc). 
With port 465/tls, the client connection either establishes encryption
or fails; it cannot be tricked into using clear-text.

Anyway, here is the paste-able script:

qmailctl stop; \
cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps; \
chown -R qmaill:qmail /var/qmail/supervise/smtps; \
sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
/var/qmail/supervise/smtps/run; \
sed -i 's/587/465/' /var/qmail/supervise/smtps/run; \
sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run; \
sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2:!SSLv3/'
/etc/tcprules.d/tcp.smtp; \
qmailctl cdb; \
qmailctl start; \
netstat -lnp | grep 465


-Andy

PS: If old clients cannot connect, then remove the "!SSLv3" from the
cipher list in tcp.smtp






On 8/13/2018 7:32 PM, Remo Mattei wrote:
> Cool! I remember I did it like Eric described but the bottom line is
> it works either way. I do not offer 465 any longer :) 
>
>  *dal mio iPhone X*
>
> Il giorno 13 ago 2018, alle ore 20:25, Andrew Swartz
> mailto:awswa...@acsalaska.net>> ha scritto:
>
>> I eventually figured this out, and accomplished the same result though I
>> went about it slightly differently.  It is now fully functional.  Below
>> is the script which I created and accomplishes this in very few lines.
>> It copies the supervise/smtp directory to supervise/smtps and it then
>> edits a few values in two files files (plus editing the cipher list in
>> tcp.smtp).
>>
>>
>> qmailctl stop
>> cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps
>> chown -R qmaill:qmail /var/qmail/supervise/smtps
>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
>> /var/qmail/supervise/smtps/run
>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run
>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run
>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2/'
>> /etc/tcprules.d/tcp.smtp
>> qmailctl cdb
>> qmailctl start
>>
>>
>> Thanks for confirming that I did it right,
>> Andy
>>
>>
>> On 8/13/2018 7:06 PM, Eric Broch wrote:
>>> Stock CentOS 7 does not have SMTPS standard. You must create the
>>> supervise scripts.
>>>
>>> You could stop qmail
>>>
>>> # qmailctl stop
>>>
>>> and copy smtp supervise scripts to smtps (make sure qmail is stopped or
>>> else you'll have a mess):
>>>
>>> # cp -Rp /var/qmail/supervise/smtp /var/qmail/supervise/smtps
>>>
>>> Then change two files:
>>>
>>> /var/qmail/supervise/smtps/run
>>>
>>> 
>>>
>>> #!/bin/sh
>>> QMAILDUID=`id -u vpopmail`
>>> NOFILESGID=`id -g vpopmail`
>>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>>> SMTPD="/var/qmail/bin/qmail-smtpd"
>>> TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
>>> HOSTNAME=`hostname`
>>> VCHKPW="/home/vpopmail/bin/vchkpw"
>>> export SMTPS=1
>>>
>>> exec /usr/bin/softlimit -m 12800 \
>>>     /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c
>>> "$MAXSMTPD" \
>>>     -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
>>>     $SMTPD $VCHKPW /bin/true 2>&1
>>>
>>> 
>>>
>>> &
>>>
>>> /var/qmail/supervise/smtps/log/run
>>>
>>> 
>>>
>>> #!/bin/sh
>>> LOGSIZE=`cat /var/qmail/control/logsize`
>>> LOGCOUNT=`cat /var/qmail/control/logco

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

I just realized that the plain text line-wrapped the script, so here is
an unwrapped version in case anyone else wants to use it. Also, I made
it multiline so you can cut and paste it into a terminal and accomplish
this in about 3 seconds with netstat confirming success (it should print
a single line showing tcpserver listening on 465).

rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year
reinstates port 465/tls because starttls (port 587) is broken beyond
repair (from a security perspective). So eventually everyone may
eventually need to go back to port 465.  But since servers get to
dictate setting to their clients without creating interoperability
issues, it will likely be many years before this occurs.

The critical flaw in starttls is that some ISP's and/or governments have
been caught filtering out the STARTTLS packet and thus preventing the
initiation of encryption (a "starttls downgrade attack").  In that case,
the client's username and password are sent in the clear.  And if an
eavesdropper gets those, they can wreak havoc on your your life (i.e. by
resetting the password for your bank or other online accounts, etc). 
With port 465/tls, the client connection either establishes encryption
or fails; it cannot be tricked into using clear-text.

Anyway, here is the paste-able script:

qmailctl stop; \
cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps; \
chown -R qmaill:qmail /var/qmail/supervise/smtps; \
sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
/var/qmail/supervise/smtps/run; \
sed -i 's/587/465/' /var/qmail/supervise/smtps/run; \
sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run; \
sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3/'
/etc/tcprules.d/tcp.smtp; \
qmailctl cdb; \
qmailctl start; \
netstat -lnp | grep 465


-Andy







On 8/13/2018 7:32 PM, Remo Mattei wrote:
> Cool! I remember I did it like Eric described but the bottom line is
> it works either way. I do not offer 465 any longer :) 
>
>  *dal mio iPhone X*
>
> Il giorno 13 ago 2018, alle ore 20:25, Andrew Swartz
> mailto:awswa...@acsalaska.net>> ha scritto:
>
>> I eventually figured this out, and accomplished the same result though I
>> went about it slightly differently.  It is now fully functional.  Below
>> is the script which I created and accomplishes this in very few lines.
>> It copies the supervise/smtp directory to supervise/smtps and it then
>> edits a few values in two files files (plus editing the cipher list in
>> tcp.smtp).
>>
>>
>> qmailctl stop
>> cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps
>> chown -R qmaill:qmail /var/qmail/supervise/smtps
>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
>> /var/qmail/supervise/smtps/run
>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run
>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run
>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2/'
>> /etc/tcprules.d/tcp.smtp
>> qmailctl cdb
>> qmailctl start
>>
>>
>> Thanks for confirming that I did it right,
>> Andy
>>
>>
>> On 8/13/2018 7:06 PM, Eric Broch wrote:
>>> Stock CentOS 7 does not have SMTPS standard. You must create the
>>> supervise scripts.
>>>
>>> You could stop qmail
>>>
>>> # qmailctl stop
>>>
>>> and copy smtp supervise scripts to smtps (make sure qmail is stopped or
>>> else you'll have a mess):
>>>
>>> # cp -Rp /var/qmail/supervise/smtp /var/qmail/supervise/smtps
>>>
>>> Then change two files:
>>>
>>> /var/qmail/supervise/smtps/run
>>>
>>> 
>>>
>>> #!/bin/sh
>>> QMAILDUID=`id -u vpopmail`
>>> NOFILESGID=`id -g vpopmail`
>>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>>> SMTPD="/var/qmail/bin/qmail-smtpd"
>>> TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
>>> HOSTNAME=`hostname`
>>> VCHKPW="/home/vpopmail/bin/vchkpw"
>>> export SMTPS=1
>>>
>>> exec /usr/bin/softlimit -m 12800 \
>>>     /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c
>>> "$MAXSMTPD" \
>>>     -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
>>>     $SMTPD $VCHKPW /bin/true 2>&1
>>>
>>> 
>>>
>>> &
>>>
>>> /var/qmail/supervise/smtps/log/run
>>>
>>> 
>>>
>>> #!/bin/sh
>>> LOGSIZE=`cat /var/qmail/control/logsize`
>>> LOGCOUNT=`cat /var/qmail/control/logcount`
>>> exec /usr/bin/setuidgid qmaill /usr/bin/multilog \
>>>     t s$LOGSIZE n$LOGC

Re: [qmailtoaster] setting up port 465 listening

[Andrew Swartz]

I eventually figured this out, and accomplished the same result though I
went about it slightly differently.  It is now fully functional.  Below
is the script which I created and accomplishes this in very few lines.
It copies the supervise/smtp directory to supervise/smtps and it then
edits a few values in two files files (plus editing the cipher list in
tcp.smtp).


qmailctl stop
cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps
chown -R qmaill:qmail /var/qmail/supervise/smtps
sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
/var/qmail/supervise/smtps/run
sed -i 's/587/465/' /var/qmail/supervise/smtps/run
sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run
sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2/'
/etc/tcprules.d/tcp.smtp
qmailctl cdb
qmailctl start


Thanks for confirming that I did it right,
Andy


On 8/13/2018 7:06 PM, Eric Broch wrote:
> Stock CentOS 7 does not have SMTPS standard. You must create the
> supervise scripts.
> 
> You could stop qmail
> 
> # qmailctl stop
> 
> and copy smtp supervise scripts to smtps (make sure qmail is stopped or
> else you'll have a mess):
> 
> # cp -Rp /var/qmail/supervise/smtp /var/qmail/supervise/smtps
> 
> Then change two files:
> 
> /var/qmail/supervise/smtps/run
> 
> 
> 
> #!/bin/sh
> QMAILDUID=`id -u vpopmail`
> NOFILESGID=`id -g vpopmail`
> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
> SMTPD="/var/qmail/bin/qmail-smtpd"
> TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
> HOSTNAME=`hostname`
> VCHKPW="/home/vpopmail/bin/vchkpw"
> export SMTPS=1
> 
> exec /usr/bin/softlimit -m 12800 \
>     /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
>     -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
>     $SMTPD $VCHKPW /bin/true 2>&1
> 
> 
> 
> &
> 
> /var/qmail/supervise/smtps/log/run
> 
> 
> 
> #!/bin/sh
> LOGSIZE=`cat /var/qmail/control/logsize`
> LOGCOUNT=`cat /var/qmail/control/logcount`
> exec /usr/bin/setuidgid qmaill /usr/bin/multilog \
>     t s$LOGSIZE n$LOGCOUNT /var/log/qmail/smtps 2>&1
> 
> 
> 
> Start qmail (# qmailctl start)
> 
> 
> On 8/11/2018 6:36 PM, Andrew Swartz wrote:
>> I just installed qmailtoaster onto CentOS-7.  The qt_install script
>> opened port 465 on the firewall.  However, s_client cannot connect to
>> port 465 and netstat shows that nothing is listening on port 465.
>>
>> Can anyone point me at appropriate instructions for setting up listening
>> on port 465 which are specific (or applicable) to qmailtoaster?  I
>> searched wiki.qmailtoaster.com and found nothing. I did some general
>> googling and found several somewhat conflicting descriptions but I'm
>> unsure which apply to the configuration used in qmailtoaster.
>>
>> My interest is because 465 has been reinstated (in Jan 2018) as the
>> preferred submission port due to security problems with STARTTLS
>> (https://tools.ietf.org/html/rfc8314).
>>
>> Thanks,
>> -Andy
>>
>>
> 

-- 
Andrew W. Swartz, MD
Departments of Emergency Medicine, Family Medicine, and Surgery
Yukon-Kuskokwim Delta Regional Hospital
Bethel, Alaska



smime.p7s
Description: S/MIME Cryptographic Signature

[qmailtoaster] setting up port 465 listening

[Andrew Swartz]

I just installed qmailtoaster onto CentOS-7.  The qt_install script
opened port 465 on the firewall.  However, s_client cannot connect to
port 465 and netstat shows that nothing is listening on port 465.

Can anyone point me at appropriate instructions for setting up listening
on port 465 which are specific (or applicable) to qmailtoaster?  I
searched wiki.qmailtoaster.com and found nothing. I did some general
googling and found several somewhat conflicting descriptions but I'm
unsure which apply to the configuration used in qmailtoaster.

My interest is because 465 has been reinstated (in Jan 2018) as the
preferred submission port due to security problems with STARTTLS
(https://tools.ietf.org/html/rfc8314).

Thanks,
-Andy




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Dkim headache

[Andrew Swartz]

FYI... your messages which I am receiving from this list have a bad DKIM
signature, while messages from other gmail.com posters have good DKIM
signatures.

I'm attaching a snapshot of what "DKIM verifier" displays in Thunderbird.

Some listserves do modify the messages in such a way that all mail comes
through like this.  But yours are the only messages from this list that
do not verify (if they have a signature, that is).

-Andy


On 2/3/2017 7:01 AM, ktf4...@gmail.com wrote:
> I've try to contact one of the customer using my Gmail account and this
> mail was also rejected with the same 550 Error.  I start to think that
> they have big problems on their server and that my server is ok.
> 
> 
> Fabio
> 
> 
> In data 03 febbraio 2017 04:46:21 PM  ha scritto:
> 
>> I can ask,  for now all I know is that the server rejected our mail
>> with a
>> "550 Administrative Proibition" error.
>>
>> Fabio
>>
>>
>> In data 03 febbraio 2017 04:34:25 PM Eric Broch 
>> ha scritto:
>>
>>> Can you have the failing customers test the DKIM record for your domain
>>> from their mail servers with something like the following:
>>>
>>> # host -t txt private._domainkey.yourdomain.tld
>>>
>>>
>>> On 2/3/2017 7:54 AM, Fabio Mecchia wrote:
 DKIM-Result: fail (bad signature)
>>>
>>> -- 
>>> Eric Broch, IMSO, DAM, NGOO, DITH, URTS
>>> White Horse Technical Consulting (WHTC)
>>> 406.214.6802
>>>
>>>
>>> -
>>> 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
> 
> 

-- 
Andrew W. Swartz, MD
Departments of Emergency Medicine, Family Medicine, and Surgery
Yukon-Kuskokwim Delta Regional Hospital
Bethel, Alaska


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] oh oh I got blacklisted

[Andrew Swartz]

Some other thoughts:

1.  Consider how secure your router/firewall is.  There are lots of
DefCon talks on Youtube where they hack into routers running linux
firmware and install malware.  Therefore don't overlook the possibility
that your router is the culprit.

2.  Tighten up your firewall rules as much as possible, especially for
ports 25 and 587.  Default rules can block all connections for ports 25,
465, 110, 143, 993, and 995.  Then go back and write rules to allow ONLY
the IP's which should be using these ports.  Allow the mail server
outgoing port 25.  Allow ports 587, 993, 995 only on the internal
clients which should be allowed to send/check mail.  You should probably
never allow ports 110 and 143 because they are plain-text and
usernames/passwords can easily be sniffed. Also consider if you are
allowing non-TLS logins on port 587 as the usernames/passwords would be
sent in plain-text and thus at risk of being sniffed.

This basically boils down to distrusting EVERY device on the internal
network, and then explicitly deciding which devices to trust.  The
degree this can be done will vary for different networks, but it should
be the guiding philosophy.  But remember that this is why QMail itself
is so secure... each component distrusts every other component.  :)

-Andy

PS:  don't forget about the router!  If it is insecure, all else is for
naught.



On 1/15/2016 2:13 PM, Jim Shupert wrote:
> i will try the
> 
> check the qmail queue
> 
> monitor the send log or use tcpdump to check connections to the server.
> 
> I am now Off the blacklist so it is not such a Bright red matter ...
> 
> I also am going to be vigelant to dlt unused accounts
> ( personnel changes  and there ya go unattended  account of
> m...@mydomain.com , password=found_in_dictionary ! opps )
> I have dlted those sorts
> 
> I ... am reluctant to block all SMTP ( port 110 ?? ) out going.
> I have some ...machines on the network that send an email ( via their
> own sendmail or other mta )
> these have a cronned script that looks how full a local drive is and
> sends an email to folks here so that they can keep track ...cause
> they never actually LOOK..
> 
> these are sent from a machine (root) w a gmail account . gmail server
> 
> but it STill leaves via my firewall ... so that would stop it yes?
> 
> thanks
> 
> jshupert
> 
> On 1/14/2016 9:44 PM, Eric wrote:
>> Hi Jim,
>>
>> You can do several things. First, on your internet firewall block all
>> outgoing SMTP traffic not originating from your email server. This
>> will prevent PC's from sending spam directly out the firewall. Two,
>> check the qmail queue for the possibility of a hacked password.
>> Usually when someone is using a hacked account the queue fills up
>> quickly. Looking at the queue it will be obvious which email account
>> has been hacked. I've had 11 thousand emails in the queue, over the
>> period of just a few hours, from a hacked password. Three, an email
>> account on a local PC spurred by a virus could be using your email
>> server as a relay. You could monitor the send log or use tcpdump to
>> check connections to the server.
>>
>> Eric
>>
>> On 1/14/2016 4:12 PM, Jim Shupert wrote:
>>> it seems that my mail server does appear on a blacklist .
>>> spamcop
>>>
>>> If I use mxtoolkit
>>>
>>> https://mxtoolbox.com
>>>
>>> under "more information" it says
>>> The SpamCop Blocking List lists IP Addresses which have sent
>>> unsolicited email to SpamCop users. This is often an indication of a
>>> Virus or Botnet from a Malware infection contracted inside your network.
>>>
>>> So , i am wondering what might be happening
>>>
>>> Might I have a bot somewhere
>>> such as
>>> an account has been compromised ? a bad guy has the login & psswd and
>>> is now spamming?
>>>
>>> how could/can i tell?
>>> a look at the logs?
>>> where ? how?
>>>
>>> would i monitor port 25 on my network?
>>>
>>> any wisdom is welcomed.
>>>
>>> to be clear. I am not a spammer - just a small bussiness with a
>>> qmailtoster and ... now I have this matter
>>>
>>>
>>> any wisdom is welcomed.
>>>
>>> thanks in advance
>>
> 
> 


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

Re: [qmailtoaster] Qmaintoaster-plus error

[Andrew Swartz]

Eric,

Those commands worked to get past the prior errors.

Then came another, which I worked my way through:

qt-install rewrites the firewall rules and restarts iptables.
This cuts off SSH access (took a while to diagnose the problem;
I had to switch to using the console).
Then it started trying to download packages which resulted in an endless
scrolling of:

PYCURL ERROR 6 - Couldn't resolve host 'xxx.yyy.zzz'

I did some quick troubleshooting to confirm that this was a firewall issue.

I turned the firewall off with service iptables stop
I edited qt-install: I commented out the qt-firewall-setup line.

Then qt-install ran and completed successfully.

qmailctl start was successful
qmailctl stat shows it is running.

I'll fix the firewall later (this is a vm behind a host NAT for now).
Besides, I prefer to hand-code my iptables file.

It will be a while before I do any testing.

Thanks for your help Eric.

-Andy


On 6/24/2015 10:58 AM, Eric Broch wrote:
 Andy,
 
 To install EPEL
 # yum install epel-release
 
 To install repoforge (x86_64)
 # rpm -Uvh
 http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
 
 Eric
 
 On 6/24/2015 12:42 PM, Andrew Swartz wrote:
 Eric,

 Thanks for your help.  Here is what I get:

 [root@centos6 install_toaster]# qt-install-epel
 qt-install-epel v1.0 - getting version of the latest epel-release ...
 qt-install-epel - epel-release not installed, installing ...
 error: open of !DOCTYPE failed: No such file or directory
 error: open of HTML failed: No such file or directory
 error: open of PUBLIC failed: No such file or directory
 error: open of -//IETF//DTD HTML 2.0//EN failed: No such file or directory
 error: open of htmlhead failed: No such file or directory
 error: open of title404 failed: No such file or directory
 error: open of Not failed: No such file or directory
 error: open of Found/title failed: No such file or directory
 error: open of /headbody failed: No such file or directory
 error: open of h1Not failed: No such file or directory
 error: open of Found/h1 failed: No such file or directory
 error: open of pThe failed: No such file or directory
 error: open of requested failed: No such file or directory
 error: open of URL failed: No such file or directory
 error: open of /pub/epel/6/x86_64//icons/unknown.gifquot; failed: No
 such file or directory
 error: open of was failed: No such file or directory
 error: open of not failed: No such file or directory
 error: open of found failed: No such file or directory
 error: open of on failed: No such file or directory
 error: open of this failed: No such file or directory
 error: open of server./p failed: No such file or directory
 error: open of /body/html failed: No such file or directory
 qt-install-epel - install failed, rc=22. Exiting.




 [root@centos6 install_toaster]# ls /etc/yum.repos.d
 CentOS-Base.repo   CentOS-Media.repo   qmailtoaster-nodist.repo
 CentOS-Debuginfo.repo  CentOS-Vault.repo
 CentOS-fasttrack.repo  qmailtoaster-dist.repo



 -Andy










 On 6/24/2015 10:09 AM, Eric Broch wrote:
 Hey Andy,

 It looks like some repo and/or packages failed to install, probably EPEL
 or RepoForge (repos) and MySQL (package). Try running the following

 qt-install-epel
 qt-install-repoforge

 What is the listing of /etc/yum.repos.d?

 Eric

 On 6/24/2015 10:53 AM, Andrew Swartz wrote:
 I installed CentOS-6 from: CentOS-6.6-x86_64-minimal.iso

 I followed the below instructions. qt-install ends with numerous
 dependency errors:

 -
 -- Finished Dependency Resolution
 Error: Package: 1:dovecot-2.2.7-8.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(JSON::XS)
 Error: Package: vpopmail-5.4.33-8.qt.el6.x86_64 (qmailtoaster-current)
 Requires: libev.so.4()(64bit)
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: peri-Razor-Agent
 Error: Package: vpopmail-5.4.33-8.qt.el6.x86_64 (qmailtoaster-current)
 Requires: libev
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(Mail::DomainKeys)
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(Geo::JP)
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(Mail::SPF::Query)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
 qt-mysql-secure-vpopmail vl.B
 error reading information on service mysqld: No such file or directory
 /usr/bin/qt-mysql-secure-vpopmail: line 21: mysql_secure_installation:
 command n
 ot found
 qt-mysql-secure-vpopmail -unsuccessful mysql_secure_installation
 -terminating
 error reading information on service httpd: No such file or directory
 httpd: unrecognized service
 [root@centos6 install_toaster]#
 -

 I've repeated the process several times, same result

Re: [qmailtoaster] Qmaintoaster-plus error

[Andrew Swartz]

I installed CentOS-6 from: CentOS-6.6-x86_64-minimal.iso

I followed the below instructions. qt-install ends with numerous
dependency errors:

-
-- Finished Dependency Resolution
Error: Package: 1:dovecot-2.2.7-8.qt.el6.x86_64 (qmailtoaster-current)
Requires: perl(JSON::XS)
Error: Package: vpopmail-5.4.33-8.qt.el6.x86_64 (qmailtoaster-current)
Requires: libev.so.4()(64bit)
Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
Requires: peri-Razor-Agent
Error: Package: vpopmail-5.4.33-8.qt.el6.x86_64 (qmailtoaster-current)
Requires: libev
Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
Requires: perl(Mail::DomainKeys)
Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
Requires: perl(Geo::JP)
Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
Requires: perl(Mail::SPF::Query)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
qt-mysql-secure-vpopmail vl.B
error reading information on service mysqld: No such file or directory
/usr/bin/qt-mysql-secure-vpopmail: line 21: mysql_secure_installation:
command n
ot found
qt-mysql-secure-vpopmail -unsuccessful mysql_secure_installation
-terminating
error reading information on service httpd: No such file or directory
httpd: unrecognized service
[root@centos6 install_toaster]#
-

I've repeated the process several times, same result each time.
Do I need to manually install these, or have I missed something?

-Andy






On 6/23/2015 4:41 AM, Eric Broch wrote:
 
 
 The qmailtoaster-plus is no longer maintained. If this is a fresh
 install move to CentOS 6 and install as follows:
 
 Installation Instructions (pre-wiki)
 .) install CentOS minimal
 # curl
 https://raw.githubusercontent.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-1
 qt-bootstrap-1
 # sh qt-bootstrap-1
 (system will reboot)
 # curl
 https://raw.githubusercontent.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-2
 qt-bootstrap-2
 # sh qt-bootstrap-2
 # qt-install
 (script will complete the installation)
 
 If you want updates for CentOS 5, I have them here:
 ftp://ftp.whitehorsetc.com/pub/qmail/CentOS5/qmt/rpms/x86_64/
 
 Be mindful that I haven't installed the latest Dovecot on a production
 machine, but I have installed the latest Spamassassin (3.4.1) and ClamAV
 in (98.7) in a production environment.
 
 EricB.
 
 
 
 On 6/23/2015 2:53 AM, Biju Jose wrote:

 Hi

  

 I was trying to install QTP repository, I am getting the following
 error in Cent OS 64 5.10

 # rpm -Uvh http://qtp.qmailtoaster.com/trac/downloads/1

 Retrieving http://qtp.qmailtoaster.com/trac/downloads/1

 error: skipping http://qtp.qmailtoaster.com/trac/downloads/1 -
 transfer failed - Unknown or unexpected error

 warning: u 0x25824b0 ctrl 0x2583850 nrefs != 0 (qtp.qmailtoaster.com http)

 Is there any workaround or should I wait till someone fixes the error?

  

 TIA

 * *

 *Biju Jose*

 *Mobile # 9895990272*

  

 
 


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

Re: [qmailtoaster] Qmaintoaster-plus error

[Andrew Swartz]

Eric,

Thanks for your help.  Here is what I get:

[root@centos6 install_toaster]# qt-install-epel
qt-install-epel v1.0 - getting version of the latest epel-release ...
qt-install-epel - epel-release not installed, installing ...
error: open of !DOCTYPE failed: No such file or directory
error: open of HTML failed: No such file or directory
error: open of PUBLIC failed: No such file or directory
error: open of -//IETF//DTD HTML 2.0//EN failed: No such file or directory
error: open of htmlhead failed: No such file or directory
error: open of title404 failed: No such file or directory
error: open of Not failed: No such file or directory
error: open of Found/title failed: No such file or directory
error: open of /headbody failed: No such file or directory
error: open of h1Not failed: No such file or directory
error: open of Found/h1 failed: No such file or directory
error: open of pThe failed: No such file or directory
error: open of requested failed: No such file or directory
error: open of URL failed: No such file or directory
error: open of /pub/epel/6/x86_64//icons/unknown.gifquot; failed: No
such file or directory
error: open of was failed: No such file or directory
error: open of not failed: No such file or directory
error: open of found failed: No such file or directory
error: open of on failed: No such file or directory
error: open of this failed: No such file or directory
error: open of server./p failed: No such file or directory
error: open of /body/html failed: No such file or directory
qt-install-epel - install failed, rc=22. Exiting.




[root@centos6 install_toaster]# ls /etc/yum.repos.d
CentOS-Base.repo   CentOS-Media.repo   qmailtoaster-nodist.repo
CentOS-Debuginfo.repo  CentOS-Vault.repo
CentOS-fasttrack.repo  qmailtoaster-dist.repo



-Andy










On 6/24/2015 10:09 AM, Eric Broch wrote:
 Hey Andy,
 
 It looks like some repo and/or packages failed to install, probably EPEL
 or RepoForge (repos) and MySQL (package). Try running the following
 
 qt-install-epel
 qt-install-repoforge
 
 What is the listing of /etc/yum.repos.d?
 
 Eric
 
 On 6/24/2015 10:53 AM, Andrew Swartz wrote:
 I installed CentOS-6 from: CentOS-6.6-x86_64-minimal.iso

 I followed the below instructions. qt-install ends with numerous
 dependency errors:

 -
 -- Finished Dependency Resolution
 Error: Package: 1:dovecot-2.2.7-8.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(JSON::XS)
 Error: Package: vpopmail-5.4.33-8.qt.el6.x86_64 (qmailtoaster-current)
 Requires: libev.so.4()(64bit)
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: peri-Razor-Agent
 Error: Package: vpopmail-5.4.33-8.qt.el6.x86_64 (qmailtoaster-current)
 Requires: libev
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(Mail::DomainKeys)
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(Geo::JP)
 Error: Package: spamassassin-3.4.8-2.qt.el6.x86_64 (qmailtoaster-current)
 Requires: perl(Mail::SPF::Query)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
 qt-mysql-secure-vpopmail vl.B
 error reading information on service mysqld: No such file or directory
 /usr/bin/qt-mysql-secure-vpopmail: line 21: mysql_secure_installation:
 command n
 ot found
 qt-mysql-secure-vpopmail -unsuccessful mysql_secure_installation
 -terminating
 error reading information on service httpd: No such file or directory
 httpd: unrecognized service
 [root@centos6 install_toaster]#
 -

 I've repeated the process several times, same result each time.
 Do I need to manually install these, or have I missed something?

 -Andy






 On 6/23/2015 4:41 AM, Eric Broch wrote:

 The qmailtoaster-plus is no longer maintained. If this is a fresh
 install move to CentOS 6 and install as follows:

 Installation Instructions (pre-wiki)
 .) install CentOS minimal
 # curl
 https://raw.githubusercontent.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-1
 qt-bootstrap-1
 # sh qt-bootstrap-1
 (system will reboot)
 # curl
 https://raw.githubusercontent.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-2
 qt-bootstrap-2
 # sh qt-bootstrap-2
 # qt-install
 (script will complete the installation)

 If you want updates for CentOS 5, I have them here:
 ftp://ftp.whitehorsetc.com/pub/qmail/CentOS5/qmt/rpms/x86_64/

 Be mindful that I haven't installed the latest Dovecot on a production
 machine, but I have installed the latest Spamassassin (3.4.1) and ClamAV
 in (98.7) in a production environment.

 EricB.



 On 6/23/2015 2:53 AM, Biju Jose wrote:
 Hi

  

 I was trying to install QTP repository, I am getting the following
 error in Cent OS 64 5.10

 # rpm -Uvh http://qtp.qmailtoaster.com/trac/downloads/1

 Retrieving http://qtp.qmailtoaster.com/trac/downloads/1

 error

[qmailtoaster] SMTP and SSLv3

[Andrew Swartz]

Has anyone come up with a way to disable SSLv3 PROTOCOL in qmail-smtp 
and qmail-remote?


I have done a fair amount of searching on this topic, both here and 
elsewhere, and I've found no solution.  I will share what I have found.


Disabling SSLv2 and SSLv3 was easy for IMAP/POP3 by setting 
TLS_PROTOCOL=TLS1 in /etc/courier/imap-ssl and /etc/courier/pop3-ssl. 
 Dovecot reportedly works similarly.


But the smtp ports (25 and 587) are another story.  One post on this 
maillist stated that port 587 will only accept TLS, so we should not 
worry about it.  That is not the case on my machine (yum updated 
qmailtoaster on Cent5).  As installed, I could connect both SSLv2 and 
SSLv3 to ports 25 and 587 (via: openssl s_client -starttls smtp -crlf 
-connect localhost:587 -ssl2).  I found this unsettling.  I like qmail 
for its security-focused design and track record.  Yet the toaster 
accepts SSLv2 depsite the entire internet proclaiming that it is 
outdated, broken, and should simply not be used by anyone for anything 
(except maybe political aids who want to deniably leak stories).


SSLv2 was easily disabled with !SSLv2 in 
/var/qmail/control/tlsserverciphers, but that is not the case with 
SSLv3.  Since the SSLv3, TLSv1, and TLSv1.1 protocols share the same 
ciphers, putting !SSLv3 in /var/qmail/control/tlsserverciphers 
disables all three of these protocols and thus disables STARTTLS 
altogether (unless you have a version of openssl which supports TLSv1.2, 
which qmailtoaster on Cent5 does not).  I tested this, and it was indeed 
the case.


Though qmailtoaster has /var/qmail/control/tlsserverciphers for 
specification of TLS ciphers, it seems to have no corresponding way to 
specify the TLS protocols.


The next logical step would be to disable SSLv3 is OpenSSL. 
Unfortunately, I have found no way to do this via openssl.cnf, neither 
by going through the file or by extensive searches on this question. 
Several posts have explicitly stated it is not possible, and that is 
consistent with the man page.


It is possible to compile openssl with the no-SSL3 option 
(http://wiki.openssl.org/index.php/Compilation_and_Installation). 
Though I am comfortable compiling my own small programs, or things I 
download which do not have things which depend on them, I am not 
comfortable trying to figure out how to do it for a RPM/Yum managed 
package with many dependencies.


Unfortunately, waiting for QmailToaster to migrate to Cent6 is not the 
answer.  Cent6 can update to OpenSSL 1.0.1 which has TLSv1.2 support, 
but without a patch to qmail or a no-ssl3 built openssl RPM, one must 
fall back to !SSLv3 in /var/qmail/control/tlsserverciphers.  Doing 
that would leave ONLY the TLSv1.2 protocol, which would severely 
restrict compatability with existing infrastructure.


So it seems that for now I just sit and wait for a patch.

In the mean time, my choices seem to be:

(plaintext) OR (encrypted AND POODLE-vulnerable)

The latter seems less risky than the former, so that is what I'm going 
with for now.  For me, it's not just SMTP-AUTH password protection.  I 
think ALL MTA-to-MTA traffic should be encrypted.  If anyone is going to 
read/scan all our mails, then they should at least have to work hard to 
do so.


I'd be curious to hear others' thoughts on this.

I'd love for someone to point out a simple solution which I've 
overlooked.  :)


-Andy




smime.p7s
Description: S/MIME Cryptographic Signature