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

[David Bray]

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
  - 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  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  > > 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
> > 

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] Re: Login activity report

[ChandranManikandan]

Hi Team,

Thanks for your advise.


On Sat, Apr 18, 2020 at 12:18 AM Craig McLaughlin <
craig.p.mclaugh...@gmail.com> wrote:

>
> Seems this would not be something typically out of box (and I'd advise
> your management that this won't necessarily give them an accurate read of
> people's 'work time' anyway).
>
> That said, the information you want is in /var/log/dovecot.log.  imap
> logins are noted there and you could whip up a script to parse out the data
> you are seeking.
>
> On 4/17/20 2:13 AM, ChandranManikandan wrote:
>
> Hi Eric,
>
> Yes, Am required IMAP only.
> My management request to pull out the report for users email activity with
> timestamp when they login first and last for the day.
>
>
> On Wed, Apr 15, 2020 at 8:20 PM Eric"s mail 
> wrote:
>
>> I don't know if any tool exists for that. Is this for IMAP only?
>>
>> Get Outlook for Android 
>>
>>
>>
>>
>> On Tue, Apr 14, 2020 at 9:58 PM -0600, "ChandranManikandan" <
>> kand...@gmail.com> wrote:
>>
>> Hi Friends,
>>>
>>> I hope you are well
>>>
>>> Now everyone is WFH,
>>> So i would like to know if any way to take report for all the email
>>> accounts login & logout and active hours report.
>>> Anyone using any tool.
>>>
>>> Am using Centos 7 with qmailtoaster.
>>>
>>> Appreciate your help.
>>>
>>> On Thu, Apr 9, 2020 at 12:13 PM ChandranManikandan 
>>> wrote:
>>>
 Hi Friends,

 I hope you are well

 Now everyone is WFH,
 So i would like to know if any way to take report for all the email
 accounts login & logout and active hours report.
 Anyone using any tool.

 Am using Centos 7 with qmailtoaster.

 Appreciate your help.

 --


 *Regards, Manikandan.C *

>>>
>>>
>>> --
>>>
>>>
>>> *Regards, Manikandan.C *
>>>
>>
>
> --
>
>
> *Regards, Manikandan.C *
>
>

-- 


*Regards,Manikandan.C*

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

[remo]

I will give more suggestions in the morning time for bed. 

> Il giorno 19 apr 2020, alle ore 23:13, David Bray  ha 
> scritto:
> 
> 
> 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 
>>   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  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:
>>> User say hey I can't send
>>> 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 05:08:13.601336500 tcpserver: end 29690 status 256
>>> 2020-04-20 05:08:13.601337500 tcpserver: status: 10/60
>>> 
>>> David Bray
>>> 0418 745334
>>> 2 ∞ & <
>>> 
>>> 
 On Sun, 19 Apr 2020 at 10:04, David Bray  wrote:
 Thanks Eric
 
 It's hard to track things but I think I have had success monitoring the 
 /var/log/maillog
 
 I'm not sure why I didn't pick this up earlier, I'm already using the 
 fail2ban suggestion of the older qmailtoaster wiki 
 (http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to 
 process it and have expanded on this now
 
 I've been running email servers most of my working life and still get 
 tripped up by simple stuff
 
 Thank for your efforts in this area, it helps to talk things out
 
 cheers
 
 David Bray
 0418 745334
 2 ∞ & <
 
 
> On Sun, 19 Apr 2020 at 01:12, Eric Broch  wrote:
> It looks like a connect and disconnect. If there was authentication you'd 
> see it. I don't think you have anything to worry about here. I'm not 
> saying there's not some jerk out there messing with your smtps...just 
> saying it may be harmless. That said, do you have a good firewall in 
> place that prevents DOS attacks. I use Sonicwall myself but you can do 
> the same thing as others have shown with iptables.
> 
> Does anyone know how to do the same with the stock firewalld on COS7/8?
> 
> On 4/17/2020 11:49 PM, David Bray wrote:
>> sure - thanks for replying, this comes in waves taking the server to 
>> it's maximum at times

[qmailtoaster] SMTP outgoing error on thunderbird

[ChandranManikandan]

Hi Folks,

I am facing outgoing smtp error issue in thunderbird.

Sending of the message failed.

Peer’s Certificate has been revoked.

The configuration related to smtp.example.com must be corrected

But outlook and webmail is working fine both incoming and outgoing.

Could anyone face the same issue.
Appreciate anyone help me.


-- 


*Regards,Manikandan.C*

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

[David Bray]

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 
>   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  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 05:08:13.601336500 tcpserver: end 29690 status 256
> 2020-04-20 05:08:13.601337500 tcpserver: status: 10/60
>
> David Bray
> 0418 745334
> 2 ∞ & <
>
>
> On Sun, 19 Apr 2020 at 10:04, David Bray  wrote:
>
>> Thanks Eric
>>
>> It's hard to track things but I think I have had success monitoring the
>> /var/log/maillog
>>
>> I'm not sure why I didn't pick this up earlier, I'm already using the
>> fail2ban suggestion of the older qmailtoaster wiki (
>> http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to
>> process it and have expanded on this now
>>
>> I've been running email servers most of my working life and still get
>> tripped up by simple stuff
>>
>> Thank for your efforts in this area, it helps to talk things out
>>
>> cheers
>>
>> David Bray
>> 0418 745334
>> 2 ∞ & <
>>
>>
>> On Sun, 19 Apr 2020 at 01:12, Eric Broch  wrote:
>>
>>> It looks like a connect and disconnect. If there was authentication
>>> you'd see it. I don't think you have anything to worry about here. I'm not
>>> saying there's not some jerk out there messing with your smtps...just
>>> saying it may be harmless. That said, do you have a good firewall in place
>>> that prevents DOS attacks. I use Sonicwall myself but you can do the same
>>> thing as others have shown with iptables.
>>>
>>> Does anyone know how to do the same with the stock firewalld on COS7/8?
>>> On 4/17/2020 11:49 PM, David Bray 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
>>>