Re: [Assp-test] Inbound TLS from gmail.com addresses / servers
It doesn't seem to be linear. Here's how I tested that theory. First I did 4 tests from gmail with TLS disabled for the google IP's: 100KB file, 1.1MB file, five 1.1MB files in one email, and ten 1.1MB files in one email. Then I did those same 4 tests with TLS enabled for the google ip's. 100KB NO TLS received DATA size: 142.81 kByte - sent DATA size: 143.44 kByte processing time 2 seconds 1.1MB NO TLS received DATA size: 1.50 MByte - sent DATA size: 1.50 MByte processing time 6 seconds 5.5MB NO TLS received DATA size: 7.49 MByte - sent DATA size: 7.49 MByte processing time 13 seconds 11MB NO TLS received DATA size: 14.97 MByte - sent DATA size: 14.97 MByte processing time 19 seconds Same files attached, now with TLS ON for the google ip addresses 100KB With TLS received DATA size: 142.87 kByte - sent DATA size: 143.54 kByte processing time 3 seconds (1 second longer, but still totally acceptable) 1.1MB With TLS received DATA size: 1.50 MByte - sent DATA size: 1.50 MByte processing time 27 seconds about *4.5x *loger than without TLS, only 27 seconds, but that's a pretty long time for a 1.5mb email 5.5MB TLS received DATA size: 7.49 MByte - sent DATA size: 7.49 MByte processing time 318 seconds about *24x *longer than without TLS and nearly 1/3 the speed of the 1MB tls version 11.0MB received DATA size: 14.97 MByte - sent DATA size: 14.97 MByte processing time 772 seconds about *40x *longer than without TLS almost 13 minutes instead of just 19 seconds about 2.5x the time of the 5.5MB with tls, expected 2x I can't test larger emails with google, Google will timeout after 15 minutes. I had debugging on for the gmail address I was sending from and got a huge debug log as expected. However, there's nothing useful in there. I don't see anything about speed, SSL renegotiation, or anything. For reference, sending that same 11.0MB email from a test *Outlook.com* account (whihch uses TLS) gets me: received DATA size: 14.98 MByte - sent DATA size: 14.98 MByte processing time 76 seconds (reasonable in my book for a TLS session) I also watched other traffic after the tests were done.I happened to see messages 5MB, 12MB, 17MB all came through quickly from non-Google sources with TLS on, but other gmail emails with attachments were slow slow. I haven't seen any mails be slow over TLS except for google, but that doesn't mean that there aren't others. Whatever the case, Gmail is too big of a player in this game to ignore the problem IMO. THANKS SO MUCH On Thu, Sep 22, 2016 at 5:58 AM, Thomas Eckardt wrote: > Ken, please check the following. > > Investigate a relatve small (eg 100KB), a middle size (1MB) and one mail > that takes very long. > > Is the processing time in a nearly linear relation to the message size? > > like: > > 100KB - six seconds > 1MB - one minute > 2MB - two minutes > 3MB - three minutes > > > Or grows the time required for one MB, if the message size grows? > > Thomas > > > > > > Von:K Post > An: ASSP development mailing list > Datum: 03.08.2016 03:37 > Betreff:Re: [Assp-test] Inbound TLS from gmail.com addresses / > servers > > > > Thanks Thomas, but what OpenSSL should I be using? I really don't think > this is the problem, but I might as well eliminate it. I've got > activestate's perl 5.20 installed and net::ssleay from the activestate > ppm. However,the OpenSSL binaries that I have (I'm talking about the FULL > openssl installation in c:\openssl) not the dll files that net::ssleay > >might< have, is 1.0.2h from Shiining LIght ( > slproweb.com/products/Win32OpenSSL.html) > > ASSP says net::ssleay is OpenSSL 1.0.2g - apparently it hasn't been > compiled using 1.0.2h yet. That the readme from net::ssleay talks > specifically about shining light and that it's best to roll your own > worries me. > > And Bob, > Thanks for testing this out. 3MB in 25 seconds is about what I'm > generally > seeing now that I've tweaked the performance settings of ASSP, but without > TLS, we can receive a 10mb attachment in just a few seconds thanks to a > fast line. Curious, if you disable TLS temporarily and send yourself that > same 3mb attachment from gmail, how long does it take? > > > > On Tue, Aug 2, 2016 at 2:04 PM, Thomas Eckardt > > wrote: > > > >Having looked through the Net:SSLEAY readme, there's a bunch that > > suggests > > >that it's best to compile your own net:ssleay and OpenSSL on the same > > >machine with the same settings. > > > > This will be the case, if you use the PPM from ActiveState. Perl and all > > modules are compiled with the same compiler and header files. > Net::SSLeay > > is compiled static, means it contains all required openssl code. > > > > >I'd love to find the time to give this a go, > > You'll find something better to do, than to compile this module on > > windows. > > > > > > Thomas > > > > > > > > > > Von:K Post > > An: ASSP development mailing list > > Datum: 02.08.2016 19:42 > > Betreff:Re
Re: [Assp-test] Feature request
+1 __.https://eXtremeSHOK.com .__ On 22-Sep-16 4:59 PM, Gooegg wrote: > Hi all, > > I would like to know if it could be possible to have and separate Msg/IP > scorring for messages with non printable characters in > undecoded subject (RFC2047) or have a way to disable just that that check? > I'am asking this because I have a rather large user base > of mostly french speaking people, and a lot of HAM messages, mostly coming > from MFC printers, FAX Machines and B2B Portals are > triggering the bombSubjectRE and then get blocked by ASSP. I don't want to > have to disable doBombHeaderRe or lower bombValencePB > here because I use bombSubjectRE extensively to trap scams and spear-phishing > emails and it work's great. It's just that RFC2047 > check that is giving me some troubles... and apparently I can't rely on > Canon, Xerox or HP to fix there buggy cr*p. > > Thanks guys and keep up the good work, > -- ___ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
[Assp-test] Logging enhancement. Minor request
In doing a bit of testing for another issue, I noticed that these lines could use more information IMO. Sep-22-16 08:17:10 Finished message - received DATA size: 142.81 kByte - sent DATA size: 143.44 kByte Sep-22-16 08:17:10 Disconnected: session:11C314CC 209.85.161.170 - processing time 2 seconds For the first line, it would be terrific to have the message ID like we see in most of the other lines for a message. That would help us identify which message this is talking about and also show when we search by message id. For the second line, would it be possible to list all of the message ID's that were sent during that session? That's less important, but would be useful. And last, any chance that you could add 25 for the number of results to show? We have 1, 10, and 100 now, but 25 would be helpful when you want a single message and you have lots of logging features on. Would just speed up the search a bit. Thanks -- ___ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
[Assp-test] Feature request
Hi all, I would like to know if it could be possible to have and separate Msg/IP scorring for messages with non printable characters in undecoded subject (RFC2047) or have a way to disable just that that check? I'am asking this because I have a rather large user base of mostly french speaking people, and a lot of HAM messages, mostly coming from MFC printers, FAX Machines and B2B Portals are triggering the bombSubjectRE and then get blocked by ASSP. I don't want to have to disable doBombHeaderRe or lower bombValencePB here because I use bombSubjectRE extensively to trap scams and spear-phishing emails and it work's great. It's just that RFC2047 check that is giving me some troubles... and apparently I can't rely on Canon, Xerox or HP to fix there buggy cr*p. Thanks guys and keep up the good work, -- Gooegg -- ___ 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
Ken, please check the following. Investigate a relatve small (eg 100KB), a middle size (1MB) and one mail that takes very long. Is the processing time in a nearly linear relation to the message size? like: 100KB - six seconds 1MB - one minute 2MB - two minutes 3MB - three minutes Or grows the time required for one MB, if the message size grows? Thomas Von:K Post An: ASSP development mailing list Datum: 03.08.2016 03:37 Betreff:Re: [Assp-test] Inbound TLS from gmail.com addresses / servers Thanks Thomas, but what OpenSSL should I be using? I really don't think this is the problem, but I might as well eliminate it. I've got activestate's perl 5.20 installed and net::ssleay from the activestate ppm. However,the OpenSSL binaries that I have (I'm talking about the FULL openssl installation in c:\openssl) not the dll files that net::ssleay >might< have, is 1.0.2h from Shiining LIght ( slproweb.com/products/Win32OpenSSL.html) ASSP says net::ssleay is OpenSSL 1.0.2g - apparently it hasn't been compiled using 1.0.2h yet. That the readme from net::ssleay talks specifically about shining light and that it's best to roll your own worries me. And Bob, Thanks for testing this out. 3MB in 25 seconds is about what I'm generally seeing now that I've tweaked the performance settings of ASSP, but without TLS, we can receive a 10mb attachment in just a few seconds thanks to a fast line. Curious, if you disable TLS temporarily and send yourself that same 3mb attachment from gmail, how long does it take? On Tue, Aug 2, 2016 at 2:04 PM, Thomas Eckardt wrote: > >Having looked through the Net:SSLEAY readme, there's a bunch that > suggests > >that it's best to compile your own net:ssleay and OpenSSL on the same > >machine with the same settings. > > This will be the case, if you use the PPM from ActiveState. Perl and all > modules are compiled with the same compiler and header files. Net::SSLeay > is compiled static, means it contains all required openssl code. > > >I'd love to find the time to give this a go, > You'll find something better to do, than to compile this module on > windows. > > > Thomas > > > > > Von:K Post > An: ASSP development mailing list > Datum: 02.08.2016 19:42 > Betreff:Re: [Assp-test] Inbound TLS from gmail.com addresses / > servers > > > > Having looked through the Net:SSLEAY readme, there's a bunch that suggests > that it's best to compile your own net:ssleay and OpenSSL on the same > machine with the same settings. I've not done that, and never have (nor do > I have the skillset to do much more than run a simple make command). I'd > love to find the time to give this a go, but what do you all think - could > this be it? Why would gmail.com always be bad, but others not (that I've > seen)? > > On Tue, Aug 2, 2016 at 1:22 PM, Thomas Eckardt > > wrote: > > > >How do you know the type of encryption that gmail is using? > > > > You'll find it in the Received header line written by assp. > > > > >I have SSLDebug set to level 3, > > > > This helps not much. Most of the SSL-debug output goes to NUL. > > But if there were errors in SSL - you would see them in the maillog. > > > > >I changed EnableHighPerformace to "very high," > > I don't recommend to do this. This cuts the cycle time (poll/select wait > > time) in the workers to a minmum. Even if assp is idle - if this is set, > > it will permanently poll the sockets and will produce unwanted CPU > > workload. I know 'EnableHighPerformace' sounds magic, but it is more > > implemented to tweak exceptional environments. > > How ever, if your host accepts this workload - it is fine. > > > > >Anything else I should try tweaking? > > > > Don't try to much. Tweak (if) one by one step. Use the > > 'notes/confighistory.txt' - the old and new values are recoded there. > > > > I have an idea about the gmail problem. It may be the case, that they > > request SSL rehandshakes more or less often depending on the used > > certificate and/or cipher to raise the security of the connection. Such > a > > behavior would slow down the SSL speed - BUT, now the bad news, this is > a > > client request (made my gmail). Perl's Net::SSLeay has no easy way to > > ignore these requests. The only way would be to pipe all SSL packest > > through an assp routine (this is possible), which would drop the > > renegotiation requests. Such a code will slow down ALL SSL traffic > > dramaticaly, if written in pure perl. > > > > >We are using a 2048bit certificate. It's a wildcard (*.ourcharity.org) > > >cert, but I don't think that has anything to do with it. > > > > Who knows? But to exclude this, you may use an innocent selfcert > > certificate and key - create it with openssl - for a while. > > BTW. assp will create such certificate and keys, if the 'assp/certs' > > folder is empty at startup. :):) > > > > Thomas > > > > > > > > > > Von:K Post > > An: ASSP development mailing list > > Datum: 02.08.
