Re: [Assp-test] Inbound TLS from gmail.com addresses / servers
Tried again after hours without any better results. Even NON-SSL connections are going idle/damping. Even TINY messages with just text. -- ___ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
Re: [Assp-test] Inbound TLS from gmail.com addresses / servers
very good news, and some not so good news with 16273. I watched this same 11MB attachment come across using the Shutdown_list (about 15,000,000 bytes after all said and done). It transferred in about 40 seconds. As in OUTSTANDING SPEED. As in, whatever you did has made a HUGE HUGE difference. (looking at the code, nice work. clever) HOWEVER, I had to revert as the email never seemed to complete. *It then just sat with the idle / damping time increasing indefinitely. * All SSL connections did this too, fast transfer,then idle forever. I didn't have the time to test non-SSL connections. I tried restarting for safe measure just to be sure. Same problem. Once I went back to 16271, normal behavior resumed. Seems close, but not quite right On Thu, Sep 29, 2016 at 10:25 AM, cw wrote: > Hi Thomas, > I moved up to 16270 following this thread of discussion but then had a day > working away. I've come back to huge issues with delays, mails not going > through and many, many of these in the logs: > > Info: unable to detect any running worker for a new connection - wait (max > 30 seconds) > > When I say many, I have over 21,000 lines in today's log file. I also found > the GUI unresponsive or not connecting at all and ASSP restarting quite > regularly. > > I've dropped back to 16256 and things are instantly better. Do you think > going up to 16273 might improve things over 16270 or am I better holding > off for now? > All the best, > Colin. > > On Thu, Sep 29, 2016 at 3:15 PM, Thomas Eckardt < > thomas.ecka...@thockar.com> > wrote: > > > I just released 2.5.2 build 16273 at CVS test folder > > > > http://assp.cvs.sourceforge.net/viewvc/assp/assp2/test/ > > > > This release should make a very large difference for SSL/TLS mails sent > by > > hosts that uses small SSL-frame size. > > > > Tell me your test results. > > > > > > Thomas > > > > > > > > > > > > Von:K Post > > An: ASSP development mailing list > > Datum: 28.09.2016 19:42 > > Betreff:Re: [Assp-test] Inbound TLS from gmail.com addresses / > > servers > > > > > > > > But I want a postman driving a Ferarri with monster truck tires that can > > roll over the traffic (and if wishes are being granted, I'd prefer the > car > > in a deep blue instead of classic red). > > > > We regularly see people attaching large files or a bunch of smaller ones > > that add up to a big email, I'm talking lots and lots of different people > > from outside the organization sending to us, and this happens on a daily > > basis. It's especially popular with photos and huge scans multi-page > > 600dpi (which people don't understand can be done at low resolution). > > Often it's people sending in scanned official documents for us to review > > an > > help them. They're not our staff, they're the people we help. They have > > a > > tendency of not following any instructions, and ignore the fact that we > > have a web based system for the process. We can't control it and the > > powers that be don't want us lowering the 30 MB threshold across the > > board. Lot of these people use gmail.com addresses and google allows > for > > up to 25 MB - https://support.google.com/mail/answer/6584 > > > > I think it's really interesting that google seems to use this inefficient > > small packet size for SSL, allows for 25MB emails, is a big proponent of > > SSL, and at the same time doesn't allow mails to take more than 15 > minutes > > to transfer. Now that you've made things >much< more efficient on the > > ASSP > > side, I'm hoping that all will be okay. I just get annoyed by > > inefficiency. > > > > > > I'm going to tryrunning with npSize of zero, the no queuing size set very > > high and see how that goes. I want to insure that even the biggest > emails > > are scanned for malware before hitting the inbox. > > > > > > I've never said this before, but it seems like google's doing it wrong. > I > > think we've exhausted our options here. If anyone has a Google > > engineering > > friend, or a friend of a friend, this might be a good time to have a > > little > > chat in an effort to reach someone who can either explain why they're use > > a > > 1.4 kB frame size for ssl packets, but a normal much bigger size for > > non-encrypted traffic or to get them to see an error in their ways and > fix > > this! > > > > Thank you again for all of the discussion and explanation and of course > > the > > code changes which have made a huge difference. > > > > On Wed, Sep 28, 2016 at 12:59 PM, Thomas Eckardt > > > > wrote: > > > > > >I'm still afraid of running into frequent problems with 25mb > > attachments > > > though. > > > > > > 25MB - I don't know anyone who allows this. Sending a link to a > download > > > is much smarter. > > > ASSP_AFC has an option to do this for your outgoing mails! - > > > ASSP_AFCWebScript > > > > > > >Can someone else run a debug test with Gmail and TLS to see if you're > > > seeing these tiny packets too? > > > > > > I've done it - s
Re: [Assp-test] Inbound TLS from gmail.com addresses / servers
Hi Thomas,
I moved up to 16270 following this thread of discussion but then had a day
working away. I've come back to huge issues with delays, mails not going
through and many, many of these in the logs:
Info: unable to detect any running worker for a new connection - wait (max
30 seconds)
When I say many, I have over 21,000 lines in today's log file. I also found
the GUI unresponsive or not connecting at all and ASSP restarting quite
regularly.
I've dropped back to 16256 and things are instantly better. Do you think
going up to 16273 might improve things over 16270 or am I better holding
off for now?
All the best,
Colin.
On Thu, Sep 29, 2016 at 3:15 PM, Thomas Eckardt
wrote:
> I just released 2.5.2 build 16273 at CVS test folder
>
> http://assp.cvs.sourceforge.net/viewvc/assp/assp2/test/
>
> This release should make a very large difference for SSL/TLS mails sent by
> hosts that uses small SSL-frame size.
>
> Tell me your test results.
>
>
> Thomas
>
>
>
>
>
> Von:K Post
> An: ASSP development mailing list
> Datum: 28.09.2016 19:42
> Betreff:Re: [Assp-test] Inbound TLS from gmail.com addresses /
> servers
>
>
>
> But I want a postman driving a Ferarri with monster truck tires that can
> roll over the traffic (and if wishes are being granted, I'd prefer the car
> in a deep blue instead of classic red).
>
> We regularly see people attaching large files or a bunch of smaller ones
> that add up to a big email, I'm talking lots and lots of different people
> from outside the organization sending to us, and this happens on a daily
> basis. It's especially popular with photos and huge scans multi-page
> 600dpi (which people don't understand can be done at low resolution).
> Often it's people sending in scanned official documents for us to review
> an
> help them. They're not our staff, they're the people we help. They have
> a
> tendency of not following any instructions, and ignore the fact that we
> have a web based system for the process. We can't control it and the
> powers that be don't want us lowering the 30 MB threshold across the
> board. Lot of these people use gmail.com addresses and google allows for
> up to 25 MB - https://support.google.com/mail/answer/6584
>
> I think it's really interesting that google seems to use this inefficient
> small packet size for SSL, allows for 25MB emails, is a big proponent of
> SSL, and at the same time doesn't allow mails to take more than 15 minutes
> to transfer. Now that you've made things >much< more efficient on the
> ASSP
> side, I'm hoping that all will be okay. I just get annoyed by
> inefficiency.
>
>
> I'm going to tryrunning with npSize of zero, the no queuing size set very
> high and see how that goes. I want to insure that even the biggest emails
> are scanned for malware before hitting the inbox.
>
>
> I've never said this before, but it seems like google's doing it wrong. I
> think we've exhausted our options here. If anyone has a Google
> engineering
> friend, or a friend of a friend, this might be a good time to have a
> little
> chat in an effort to reach someone who can either explain why they're use
> a
> 1.4 kB frame size for ssl packets, but a normal much bigger size for
> non-encrypted traffic or to get them to see an error in their ways and fix
> this!
>
> Thank you again for all of the discussion and explanation and of course
> the
> code changes which have made a huge difference.
>
> On Wed, Sep 28, 2016 at 12:59 PM, Thomas Eckardt
> > wrote:
>
> > >I'm still afraid of running into frequent problems with 25mb
> attachments
> > though.
> >
> > 25MB - I don't know anyone who allows this. Sending a link to a download
> > is much smarter.
> > ASSP_AFC has an option to do this for your outgoing mails! -
> > ASSP_AFCWebScript
> >
> > >Can someone else run a debug test with Gmail and TLS to see if you're
> > seeing these tiny packets too?
> >
> > I've done it - same behavior - 1400 byte per SSL frame from gmail.
> >
> >
> > >Would it be an easy modification to show the negotiated cipher in the
> >
> > ASSP does this for years now - simply look in to the received header
> line
> > added by assp.
> >
> > -- -- -- Received: from vs10241.internet1.de ([158.181.49.77]
> > helo=vs10241.internet1.de)
> > by xx with SMTPS(TLSv1_2 ECDHE-RSA-AES256-GCM-SHA384)
> (2.5.2);
> > 24 Jul 2016 05:34:12 +0200
> >
> > if you set 'ConnectionLog' at least to verbose, you'll see the
> > SSL-negotiation results in maillog.txt.
> >
> > info: started TLS-SSL session for client $cliIP - using
> > $Con{$ssls}->{sslversion} , $Con{$ssls}->{sslcipher}
> >
> > >what other options are there?
> >
> > Set 'EnableHighPerformance' to very high.
> >
> > >Are you sure that negotiating a lesser cipher with Gmail wouldn't have
> > them switch to sending larger SSL packets?
> >
> > Yes, I'm 100% sure.
> >
> > An SSL peer is free to use any SSL frame size between 1 byte and 16kB.
> > There is no SSL-negotiation parameter for min or max frame
Re: [Assp-test] Inbound TLS from gmail.com addresses / servers
I just released 2.5.2 build 16273 at CVS test folder
http://assp.cvs.sourceforge.net/viewvc/assp/assp2/test/
This release should make a very large difference for SSL/TLS mails sent by
hosts that uses small SSL-frame size.
Tell me your test results.
Thomas
Von:K Post
An: ASSP development mailing list
Datum: 28.09.2016 19:42
Betreff:Re: [Assp-test] Inbound TLS from gmail.com addresses /
servers
But I want a postman driving a Ferarri with monster truck tires that can
roll over the traffic (and if wishes are being granted, I'd prefer the car
in a deep blue instead of classic red).
We regularly see people attaching large files or a bunch of smaller ones
that add up to a big email, I'm talking lots and lots of different people
from outside the organization sending to us, and this happens on a daily
basis. It's especially popular with photos and huge scans multi-page
600dpi (which people don't understand can be done at low resolution).
Often it's people sending in scanned official documents for us to review
an
help them. They're not our staff, they're the people we help. They have
a
tendency of not following any instructions, and ignore the fact that we
have a web based system for the process. We can't control it and the
powers that be don't want us lowering the 30 MB threshold across the
board. Lot of these people use gmail.com addresses and google allows for
up to 25 MB - https://support.google.com/mail/answer/6584
I think it's really interesting that google seems to use this inefficient
small packet size for SSL, allows for 25MB emails, is a big proponent of
SSL, and at the same time doesn't allow mails to take more than 15 minutes
to transfer. Now that you've made things >much< more efficient on the
ASSP
side, I'm hoping that all will be okay. I just get annoyed by
inefficiency.
I'm going to tryrunning with npSize of zero, the no queuing size set very
high and see how that goes. I want to insure that even the biggest emails
are scanned for malware before hitting the inbox.
I've never said this before, but it seems like google's doing it wrong. I
think we've exhausted our options here. If anyone has a Google
engineering
friend, or a friend of a friend, this might be a good time to have a
little
chat in an effort to reach someone who can either explain why they're use
a
1.4 kB frame size for ssl packets, but a normal much bigger size for
non-encrypted traffic or to get them to see an error in their ways and fix
this!
Thank you again for all of the discussion and explanation and of course
the
code changes which have made a huge difference.
On Wed, Sep 28, 2016 at 12:59 PM, Thomas Eckardt
wrote:
> >I'm still afraid of running into frequent problems with 25mb
attachments
> though.
>
> 25MB - I don't know anyone who allows this. Sending a link to a download
> is much smarter.
> ASSP_AFC has an option to do this for your outgoing mails! -
> ASSP_AFCWebScript
>
> >Can someone else run a debug test with Gmail and TLS to see if you're
> seeing these tiny packets too?
>
> I've done it - same behavior - 1400 byte per SSL frame from gmail.
>
>
> >Would it be an easy modification to show the negotiated cipher in the
>
> ASSP does this for years now - simply look in to the received header
line
> added by assp.
>
> -- -- -- Received: from vs10241.internet1.de ([158.181.49.77]
> helo=vs10241.internet1.de)
> by xx with SMTPS(TLSv1_2 ECDHE-RSA-AES256-GCM-SHA384)
(2.5.2);
> 24 Jul 2016 05:34:12 +0200
>
> if you set 'ConnectionLog' at least to verbose, you'll see the
> SSL-negotiation results in maillog.txt.
>
> info: started TLS-SSL session for client $cliIP - using
> $Con{$ssls}->{sslversion} , $Con{$ssls}->{sslcipher}
>
> >what other options are there?
>
> Set 'EnableHighPerformance' to very high.
>
> >Are you sure that negotiating a lesser cipher with Gmail wouldn't have
> them switch to sending larger SSL packets?
>
> Yes, I'm 100% sure.
>
> An SSL peer is free to use any SSL frame size between 1 byte and 16kB.
> There is no SSL-negotiation parameter for min or max frame size.
> If gmail.com sends 1.4kB frames, they are free to do it this way. There
is
> no technical way to force them to send larger frames.
>
> >If neverQueue is set to 12MB, am I correct in saying that we're open to
a
> targeted exploit, say an .exe in a .zip as long as the email is more
than
> 12MB?
>
> Yes, you are correct.
>
> >or is that just after the whole message is received?
>
> Yes, after the complete mail is received.
>
> It is like it is - if the postman with his Ferrari is in a traffic jam,
> you'll have to wait longer for your letter or you'll get it the next
day.
>
>
> Thomas
>
>
>
> Von:K Post
> An: ASSP development mailing list
> Datum: 28.09.2016 17:03
> Betreff:Re: [Assp-test] Inbound TLS from gmail.com addresses /
> servers
>
>
>
> Thanks again for the detailed explanation.
>
> 10% faster is terrific, and it's more than 50% faster since bef
[Assp-test] Ubuntu 16.04 problems with ASSP
Howdy, So I’ve been working on getting ASSP up and running on Ubuntu 16.04. I upgraded one of our servers and have had a few minor issues. By and large it has been fine. For some reason, ASSP is logging “Mail::SPF::Query module is not installed.” at startup when it is (Mail::SPF::Query is up to date (1.999.1).) I also appear to be having problems with Crypt::GOST. When I first fired up ASSP all encrypted variables had changed to display their encrypted version. I’ve found the following so far and corrected them: syncCFGPass adminusersdbpass mydb myuser mypassword SSL_cipher_list SSLCertFile SSLKeyFile SSLCaFile I can’t see any other but was wondering if there is a full list of what may be affected by this? Correcting these makes them all show the correct value and almost everything works except the admin users database. I get this logged: Adminusers database error: ASSP::CRYPT ERROR: DATA and PASSPHRASE are incompatible! at sub ASSP::CryptTie::TIEHASH line 32. Adminusers.right database error: ASSP::CRYPT ERROR: DATA and PASSPHRASE are incompatible! at sub ASSP::CryptTie::TIEHASH line 32. The password is set the same as the live Ubuntu 14.04 servers. I’ve even set a new password on the master server and synced it through with no change. I did some reading on how to test Crypt::GOST but didn’t find anything helpful. Anyone else got ASSP running on 16.04 that might have gone through these same issues? Does 16.04 have some inherent difference in the encryption routines that means it is not compatible? -- ___ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
