From john.thurston at alaska.gov Tue Nov 3 17:38:31 2020 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 3 Nov 2020 08:38:31 -0900 Subject: [ZendTo] Occasional longer retention period? References: <372316a7-1d66-e4d2-5297-e749626f9dfe@alaska.gov> Message-ID: We have a fairly short retention-period in ZendTo. Occasionally, we have need for a "drop" to be be available longer. There does not seem to be any way for this availability to be any longer than "numberOfDaysToRetain", and that limit is the same for all users. It does appear, however, that the lifetime is an attribute of each "drop", and it is computed and stored at creation. Would extending the lifetime of a specific "drop" be as simple as reaching into the database and adjusting the value of "lifeseconds" on the specified "drop"? (Why not just increase the value of "numberOfDaysToRetain"? Because the occasional increased duration may need to be 10x or 20x the normal duration. And that would be way too long to have available for everything.) -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska From Jules at Zend.To Wed Nov 4 11:25:06 2020 From: Jules at Zend.To (Jules) Date: Wed, 4 Nov 2020 11:25:06 +0000 Subject: [ZendTo] Occasional longer retention period? In-Reply-To: References: <372316a7-1d66-e4d2-5297-e749626f9dfe@alaska.gov> Message-ID: <6669767e-3374-e199-1361-f9546b62b9b4@Zend.To> Hi John, My "official" solution to this is to use the new setting ??? 'defaultNumberOfDaysToRetain' and set this to your normal short lifetime. Set ??? 'numberOfDaysToRetain' to the much longer time you occasionally need. Most people won't bother changing the life time on the "new drop-off" form from the default value it gives them (the short one). But if they need to, they can increase it up to the maximum you've set (the long one). But yes, you're quite right, just tweaking the "lifeseconds" value in the relevant record in the "dropoff" table should do the trick for you. The instance of ZendTo I run for the University of Southampton (my employer) has recently been getting a bit big. We had to increase its drop-off space from 3 TB to 4 TB the other week. To help rein this in, we've just dropped the default lifetime from 32 days to 22, while leaving the maximum lifetime still at 32 days. Hopefully in a month's time, we'll start to see average disk usage drop a bit. Cheers, Jules. On 03/11/2020 17:38, John Thurston via ZendTo wrote: > We have a fairly short retention-period in ZendTo. Occasionally, we > have need for a "drop" to be be available longer. There does not seem > to be any way for this availability to be any longer than > "numberOfDaysToRetain", and that limit is the same for all users. > > It does appear, however, that the lifetime is an attribute of each > "drop", and it is computed and stored at creation. Would extending the > lifetime of a specific "drop" be as simple as reaching into the > database and adjusting the value of "lifeseconds" on the specified > "drop"? > > > > (Why not just increase the value of "numberOfDaysToRetain"? Because > the occasional increased duration may need to be 10x or 20x the normal > duration. And that would be way too long to have available for > everything.) > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebbernardi at gmail.com Thu Nov 5 13:31:17 2020 From: ebbernardi at gmail.com (Everton Bruno Bernardi) Date: Thu, 5 Nov 2020 10:31:17 -0300 Subject: [ZendTo] Invalid JSON error - reCAPTCHA References: Message-ID: Hi there, Recently we've been facing the following issue with ZendTo (version 5.03 - a lot old, I know): [image: image.png] I've confirmed the reCAPTCHA keys and everything seems to be correct. What could I do in order to know what's really happening? Thanks in advance. Regards -- *Everton Bruno Bernardi * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165079 bytes Desc: not available URL: From Jules at Zend.To Thu Nov 5 13:36:23 2020 From: Jules at Zend.To (Jules) Date: Thu, 5 Nov 2020 13:36:23 +0000 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: Message-ID: <7684cc1b-30fa-98e0-5c67-b6b4a4aa22e5@Zend.To> Everton, Please can you try a couple of things: 1. Close all your browser tabs except 1 showing something like Google's home page. Clear your browser cache completely, then quit and restart your browser. Does the problem still occur? 2. Try from an incognito/private browser window. Does that make it behave? If number 2 makes it behave, then the browser cache isn't being fully cleared, as that's the only important difference as far as a new tab is concerned. Anyone else seeing this problem? Cheers, Jules. On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo wrote: > Hi there, > > Recently we've been facing the following issue with ZendTo (version > 5.03 - a lot old, I know): > > image.png > > I've confirmed the reCAPTCHA keys and everything seems to be correct. > What could I do in order to know what's really happening? > > > Thanks in advance. > > Regards > > -- > /Everton Bruno Bernardi / > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165079 bytes Desc: not available URL: From zend.to at neilzone.co.uk Thu Nov 5 14:32:32 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Thu, 5 Nov 2020 14:32:32 +0000 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <7684cc1b-30fa-98e0-5c67-b6b4a4aa22e5@Zend.To> <9FD49E1F-1467-47CA-9148-441D915C9BFF@neilzone.co.uk> Message-ID: > On 5 Nov 2020, at 13:36, Jules via ZendTo wrote: > > Anyone else seeing this problem? No Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Nov 5 15:10:48 2020 From: Jules at Zend.To (Jules) Date: Thu, 5 Nov 2020 15:10:48 +0000 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <7684cc1b-30fa-98e0-5c67-b6b4a4aa22e5@Zend.To> Message-ID: <4d9acd8d-7917-e7eb-807c-0c3434e3cc8d@Zend.To> Hi Everton, I've just compared the code from 5.03 to the latest, for this specific problem. Try applying this patch (manually with a text editor is just fine!) to /opt/zendto/www/verify.php: 97,101c110,111 ???????????? $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >??????????????????????????? new \ReCaptcha\RequestMethod\CurlPost()); If that helps, apply this (very similar) patch to /opt/zendto/www/pickup.php as that's the other place this call appears: 130c143,144 ?????????? $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >???????????? new \ReCaptcha\RequestMethod\CurlPost()); I've never managed to figure out why sites which have been working perfectly well on the default suddenly stop doing so, with apparently no changes anywhere (except at Google?). But using the CurlPost() technique seems to work well for everyone. Let me know how you get on. Cheers, Jules. On 05/11/2020 14:54, Everton Bruno Bernardi wrote: > Hi Jules, > > Thanks for your considerations. > Unfortunately this is happening to all of our users (including external). > > I've already tried on other browsers and the same happens. > > > > Em qui, 5 de nov de 2020 11:18, Jules > escreveu: > > Everton, > > Please can you try a couple of things: > 1. Close all your browser tabs except 1 showing something like > Google's home page. Clear your browser cache completely, then quit > and restart your browser. Does the problem still occur? > 2. Try from an incognito/private browser window. Does that make it > behave? > > If number 2 makes it behave, then the browser cache isn't being > fully cleared, as that's the only important difference as far as a > new tab is concerned. > > Anyone else seeing this problem? > > Cheers, > Jules. > > On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo wrote: >> Hi there, >> >> Recently we've been facing the following issue with ZendTo >> (version 5.03 - a lot old, I know): >> >> image.png >> >> I've confirmed the reCAPTCHA keys and everything seems to be correct. >> What could I do in order to know what's really happening? >> >> >> Thanks in advance. >> >> Regards >> >> -- >> /Everton Bruno Bernardi / >> >> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > www.Zend.To > Twitter: @JulesFM > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebbernardi at gmail.com Thu Nov 5 17:09:49 2020 From: ebbernardi at gmail.com (Everton Bruno Bernardi) Date: Thu, 5 Nov 2020 14:09:49 -0300 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <7684cc1b-30fa-98e0-5c67-b6b4a4aa22e5@Zend.To> <4d9acd8d-7917-e7eb-807c-0c3434e3cc8d@Zend.To> Message-ID: Jules, Thanks for that. I changed the code you sent me but it had no effect. The same error occurs. Am I able to send any debug information to help you out? If so, please tell me how can I get it. Regards, Everton On Thu, Nov 5, 2020 at 12:10 PM Jules wrote: > Hi Everton, > > I've just compared the code from 5.03 to the latest, for this specific > problem. > > Try applying this patch (manually with a text editor is just fine!) to > /opt/zendto/www/verify.php: > > 97,101c110,111 > < // Old version 1 code. > < // $resp = recaptcha_check_answer($reCaptchaPrivateKey, > < // getClientIP(), > < // > $_POST["g-recaptcha-response"]); > < $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); > --- > > $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, > > new \ReCaptcha\RequestMethod\CurlPost()); > > If that helps, apply this (very similar) patch to > /opt/zendto/www/pickup.php as that's the other place this call appears: > > 130c143,144 > < $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); > --- > > $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, > > new \ReCaptcha\RequestMethod\CurlPost()); > > I've never managed to figure out why sites which have been working > perfectly well on the default suddenly stop doing so, with apparently no > changes anywhere (except at Google?). But using the CurlPost() technique > seems to work well for everyone. > > Let me know how you get on. > > Cheers, > Jules. > > On 05/11/2020 14:54, Everton Bruno Bernardi wrote: > > Hi Jules, > > Thanks for your considerations. > Unfortunately this is happening to all of our users (including external). > > I've already tried on other browsers and the same happens. > > > > Em qui, 5 de nov de 2020 11:18, Jules escreveu: > >> Everton, >> >> Please can you try a couple of things: >> 1. Close all your browser tabs except 1 showing something like Google's >> home page. Clear your browser cache completely, then quit and restart your >> browser. Does the problem still occur? >> 2. Try from an incognito/private browser window. Does that make it behave? >> >> If number 2 makes it behave, then the browser cache isn't being fully >> cleared, as that's the only important difference as far as a new tab is >> concerned. >> >> Anyone else seeing this problem? >> >> Cheers, >> Jules. >> >> On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo wrote: >> >> Hi there, >> >> Recently we've been facing the following issue with ZendTo (version 5.03 >> - a lot old, I know): >> >> [image: image.png] >> >> I've confirmed the reCAPTCHA keys and everything seems to be correct. >> What could I do in order to know what's really happening? >> >> >> Thanks in advance. >> >> Regards >> >> -- >> *Everton Bruno Bernardi * >> >> >> >> _______________________________________________ >> ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto >> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> www.Zend.To >> Twitter: @JulesFM >> >> > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > www.Zend.To > Twitter: @JulesFM > > -- *Everton Bruno Bernardi * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Nov 5 17:19:42 2020 From: Jules at Zend.To (Jules) Date: Thu, 5 Nov 2020 17:19:42 +0000 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <7684cc1b-30fa-98e0-5c67-b6b4a4aa22e5@Zend.To> <4d9acd8d-7917-e7eb-807c-0c3434e3cc8d@Zend.To> Message-ID: Everton, I've just had a dig through my mail archives. Some folks at Brunel University in the UK had the same problem. Here is their comment on the problem and how they fixed it: Reason for reCAPTCHA problem we understood relates to the firewall and IPV6 settings. Recently we had firewall and network changes implemented to our data centre which had impact on IPV6 related connectivity in Linux environment. We have disabled IPV6 on dropoff server and it worked fine without any issues. Hope that helps, Jules. On 05/11/2020 17:09, Everton Bruno Bernardi wrote: > Jules, > > Thanks for that. I changed the code you sent me but it had no effect. > The same error occurs. > Am I able to send any debug information to help you out? If so, please > tell me how can I get it. > > > Regards, > > Everton > > On Thu, Nov 5, 2020 at 12:10 PM Jules > wrote: > > Hi Everton, > > I've just compared the code from 5.03 to the latest, for this > specific problem. > > Try applying this patch (manually with a text editor is just > fine!) to /opt/zendto/www/verify.php: > > 97,101c110,111 > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); > --- > >???????????? $recaptcha = new > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, > >??????????????????????????? new \ReCaptcha\RequestMethod\CurlPost()); > > If that helps, apply this (very similar) patch to > /opt/zendto/www/pickup.php as that's the other place this call > appears: > > 130c143,144 > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); > --- > >?????????? $recaptcha = new > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, > >???????????? new \ReCaptcha\RequestMethod\CurlPost()); > > I've never managed to figure out why sites which have been working > perfectly well on the default suddenly stop doing so, with > apparently no changes anywhere (except at Google?). But using the > CurlPost() technique seems to work well for everyone. > > Let me know how you get on. > > Cheers, > Jules. > > On 05/11/2020 14:54, Everton Bruno Bernardi wrote: >> Hi Jules, >> >> Thanks for your considerations. >> Unfortunately this is happening to all of our users (including >> external). >> >> I've already tried on other browsers and the same happens. >> >> >> >> Em qui, 5 de nov de 2020 11:18, Jules > > escreveu: >> >> Everton, >> >> Please can you try a couple of things: >> 1. Close all your browser tabs except 1 showing something >> like Google's home page. Clear your browser cache completely, >> then quit and restart your browser. Does the problem still occur? >> 2. Try from an incognito/private browser window. Does that >> make it behave? >> >> If number 2 makes it behave, then the browser cache isn't >> being fully cleared, as that's the only important difference >> as far as a new tab is concerned. >> >> Anyone else seeing this problem? >> >> Cheers, >> Jules. >> >> On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo wrote: >>> Hi there, >>> >>> Recently we've been facing the following issue with ZendTo >>> (version 5.03 - a lot old, I know): >>> >>> image.png >>> >>> I've confirmed the reCAPTCHA keys and everything seems to be >>> correct. >>> What could I do in order to know what's really happening? >>> >>> >>> Thanks in advance. >>> >>> Regards >>> >>> -- >>> /Everton Bruno Bernardi >>> / >>> >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> >> www.Zend.To >> Twitter: @JulesFM >> > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > www.Zend.To > Twitter: @JulesFM > > > > -- > /Everton Bruno Bernardi / > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebbernardi at gmail.com Thu Nov 5 18:53:48 2020 From: ebbernardi at gmail.com (Everton Bruno Bernardi) Date: Thu, 5 Nov 2020 15:53:48 -0300 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <7684cc1b-30fa-98e0-5c67-b6b4a4aa22e5@Zend.To> <4d9acd8d-7917-e7eb-807c-0c3434e3cc8d@Zend.To> Message-ID: Jules, IPV6 was enabled. Disabled IPV6 and rebooted the box but the issue persists. :/ On Thu, Nov 5, 2020 at 3:18 PM Jules wrote: > Everton, > > I've just had a dig through my mail archives. > > Some folks at Brunel University in the UK had the same problem. Here is > their comment on the problem and how they fixed it: > > Reason for reCAPTCHA problem we understood relates to the firewall and > IPV6 settings. > Recently we had firewall and network changes implemented to our data > centre which had impact on IPV6 related connectivity in Linux environment. > We have disabled IPV6 on dropoff server and it worked fine without any > issues. > > Hope that helps, > Jules. > > On 05/11/2020 17:09, Everton Bruno Bernardi wrote: > > Jules, > > Thanks for that. I changed the code you sent me but it had no effect. The > same error occurs. > Am I able to send any debug information to help you out? If so, please > tell me how can I get it. > > > Regards, > > Everton > > On Thu, Nov 5, 2020 at 12:10 PM Jules wrote: > >> Hi Everton, >> >> I've just compared the code from 5.03 to the latest, for this specific >> problem. >> >> Try applying this patch (manually with a text editor is just fine!) to >> /opt/zendto/www/verify.php: >> >> 97,101c110,111 >> < // Old version 1 code. >> < // $resp = recaptcha_check_answer($reCaptchaPrivateKey, >> < // getClientIP(), >> < // >> $_POST["g-recaptcha-response"]); >> < $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >> --- >> > $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >> > new \ReCaptcha\RequestMethod\CurlPost()); >> >> If that helps, apply this (very similar) patch to >> /opt/zendto/www/pickup.php as that's the other place this call appears: >> >> 130c143,144 >> < $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >> --- >> > $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >> > new \ReCaptcha\RequestMethod\CurlPost()); >> >> I've never managed to figure out why sites which have been working >> perfectly well on the default suddenly stop doing so, with apparently no >> changes anywhere (except at Google?). But using the CurlPost() technique >> seems to work well for everyone. >> >> Let me know how you get on. >> >> Cheers, >> Jules. >> >> On 05/11/2020 14:54, Everton Bruno Bernardi wrote: >> >> Hi Jules, >> >> Thanks for your considerations. >> Unfortunately this is happening to all of our users (including external). >> >> I've already tried on other browsers and the same happens. >> >> >> >> Em qui, 5 de nov de 2020 11:18, Jules escreveu: >> >>> Everton, >>> >>> Please can you try a couple of things: >>> 1. Close all your browser tabs except 1 showing something like Google's >>> home page. Clear your browser cache completely, then quit and restart your >>> browser. Does the problem still occur? >>> 2. Try from an incognito/private browser window. Does that make it >>> behave? >>> >>> If number 2 makes it behave, then the browser cache isn't being fully >>> cleared, as that's the only important difference as far as a new tab is >>> concerned. >>> >>> Anyone else seeing this problem? >>> >>> Cheers, >>> Jules. >>> >>> On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo wrote: >>> >>> Hi there, >>> >>> Recently we've been facing the following issue with ZendTo (version 5.03 >>> - a lot old, I know): >>> >>> [image: image.png] >>> >>> I've confirmed the reCAPTCHA keys and everything seems to be correct. >>> What could I do in order to know what's really happening? >>> >>> >>> Thanks in advance. >>> >>> Regards >>> >>> -- >>> *Everton Bruno Bernardi * >>> >>> >>> >>> _______________________________________________ >>> ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto >>> >>> >>> Jules >>> >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> www.Zend.To >>> Twitter: @JulesFM >>> >>> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> www.Zend.To >> Twitter: @JulesFM >> >> > > -- > *Everton Bruno Bernardi * > > > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > www.Zend.To > Twitter: @JulesFM > > -- *Everton Bruno Bernardi * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Nov 6 10:27:10 2020 From: Jules at Zend.To (Jules) Date: Fri, 6 Nov 2020 10:27:10 +0000 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <4d9acd8d-7917-e7eb-807c-0c3434e3cc8d@Zend.To> Message-ID: Okay, 3 more ideas: 1. In your php.ini set "allow_url_fopen" to true. Then restart Apache (and php-fpm if you're using that). 2. Switch on php error display in your php.ini. 3. https://github.com/google/recaptcha/issues/359 I'll continue hunting as well... Cheers, Jules. On 05/11/2020 18:53, Everton Bruno Bernardi wrote: > Jules, > > IPV6 was enabled. Disabled IPV6 and rebooted the box but the issue > persists. > :/ > > > > On Thu, Nov 5, 2020 at 3:18 PM Jules > wrote: > > Everton, > > I've just had a dig through my mail archives. > > Some folks at Brunel University in the UK had the same problem. > Here is their comment on the problem and how they fixed it: > > Reason for reCAPTCHA problem we understood relates to the firewall > and IPV6 settings. > Recently we had firewall and network changes implemented to our > data centre which had impact on IPV6 related connectivity in Linux > environment. > We have disabled IPV6 on dropoff server and it worked fine without > any issues. > > Hope that helps, > Jules. > > On 05/11/2020 17:09, Everton Bruno Bernardi wrote: >> Jules, >> >> Thanks for that. I changed the code you sent me but it had no >> effect. The same error occurs. >> Am I able to send any debug information to help you out? If so, >> please tell me how can I get it. >> >> >> Regards, >> >> Everton >> >> On Thu, Nov 5, 2020 at 12:10 PM Jules > > wrote: >> >> Hi Everton, >> >> I've just compared the code from 5.03 to the latest, for this >> specific problem. >> >> Try applying this patch (manually with a text editor is just >> fine!) to /opt/zendto/www/verify.php: >> >> 97,101c110,111 >> > > recaptcha_check_answer($reCaptchaPrivateKey, >> < //??????????????????????????????? getClientIP(), >> < // $_POST["g-recaptcha-response"]); >> > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >> --- >> >???????????? $recaptcha = new >> \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >> >??????????????????????????? new >> \ReCaptcha\RequestMethod\CurlPost()); >> >> If that helps, apply this (very similar) patch to >> /opt/zendto/www/pickup.php as that's the other place this >> call appears: >> >> 130c143,144 >> > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >> --- >> >?????????? $recaptcha = new >> \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >> >???????????? new \ReCaptcha\RequestMethod\CurlPost()); >> >> I've never managed to figure out why sites which have been >> working perfectly well on the default suddenly stop doing so, >> with apparently no changes anywhere (except at Google?). But >> using the CurlPost() technique seems to work well for everyone. >> >> Let me know how you get on. >> >> Cheers, >> Jules. >> >> On 05/11/2020 14:54, Everton Bruno Bernardi wrote: >>> Hi Jules, >>> >>> Thanks for your considerations. >>> Unfortunately this is happening to all of our users >>> (including external). >>> >>> I've already tried on other browsers and the same happens. >>> >>> >>> >>> Em qui, 5 de nov de 2020 11:18, Jules >> > escreveu: >>> >>> Everton, >>> >>> Please can you try a couple of things: >>> 1. Close all your browser tabs except 1 showing >>> something like Google's home page. Clear your browser >>> cache completely, then quit and restart your browser. >>> Does the problem still occur? >>> 2. Try from an incognito/private browser window. Does >>> that make it behave? >>> >>> If number 2 makes it behave, then the browser cache >>> isn't being fully cleared, as that's the only important >>> difference as far as a new tab is concerned. >>> >>> Anyone else seeing this problem? >>> >>> Cheers, >>> Jules. >>> >>> On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo >>> wrote: >>>> Hi there, >>>> >>>> Recently we've been facing the following issue with >>>> ZendTo (version 5.03 - a lot old, I know): >>>> >>>> image.png >>>> >>>> I've confirmed the reCAPTCHA keys and everything seems >>>> to be correct. >>>> What could I do in order to know what's really happening? >>>> >>>> >>>> Thanks in advance. >>>> >>>> Regards >>>> >>>> -- >>>> /Everton Bruno Bernardi >>>> / >>>> >>>> >>>> >>>> _______________________________________________ >>>> ZendTo mailing list >>>> ZendTo at zend.to >>>> http://jul.es/mailman/listinfo/zendto >>> >>> Jules >>> >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> www.Zend.To >>> Twitter: @JulesFM >>> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> >> www.Zend.To >> Twitter: @JulesFM >> >> >> >> -- >> /Everton Bruno Bernardi / >> >> > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > www.Zend.To > Twitter: @JulesFM > > > > -- > /Everton Bruno Bernardi / > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sun Nov 8 11:54:25 2020 From: Jules at Zend.To (Jules) Date: Sun, 8 Nov 2020 11:54:25 +0000 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <4d9acd8d-7917-e7eb-807c-0c3434e3cc8d@Zend.To> Message-ID: <523cd0d8-f96a-0092-3842-c72e788158e2@Zend.To> Everton, What exact variant and version of Linux are you using? Please send me the output of these: ??? ifconfig -a ??? ip addr list ??? sysctl -a | egrep -i 'ipv?6' ??? lsmod Thanks! Jules. On 05/11/2020 18:53, Everton Bruno Bernardi wrote: > Jules, > > IPV6 was enabled. Disabled IPV6 and rebooted the box but the issue > persists. > :/ > > > > On Thu, Nov 5, 2020 at 3:18 PM Jules > wrote: > > Everton, > > I've just had a dig through my mail archives. > > Some folks at Brunel University in the UK had the same problem. > Here is their comment on the problem and how they fixed it: > > Reason for reCAPTCHA problem we understood relates to the firewall > and IPV6 settings. > Recently we had firewall and network changes implemented to our > data centre which had impact on IPV6 related connectivity in Linux > environment. > We have disabled IPV6 on dropoff server and it worked fine without > any issues. > > Hope that helps, > Jules. > > On 05/11/2020 17:09, Everton Bruno Bernardi wrote: >> Jules, >> >> Thanks for that. I changed the code you sent me but it had no >> effect. The same error occurs. >> Am I able to send any debug information to help you out? If so, >> please tell me how can I get it. >> >> >> Regards, >> >> Everton >> >> On Thu, Nov 5, 2020 at 12:10 PM Jules > > wrote: >> >> Hi Everton, >> >> I've just compared the code from 5.03 to the latest, for this >> specific problem. >> >> Try applying this patch (manually with a text editor is just >> fine!) to /opt/zendto/www/verify.php: >> >> 97,101c110,111 >> > > recaptcha_check_answer($reCaptchaPrivateKey, >> < //??????????????????????????????? getClientIP(), >> < // $_POST["g-recaptcha-response"]); >> > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >> --- >> >???????????? $recaptcha = new >> \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >> >??????????????????????????? new >> \ReCaptcha\RequestMethod\CurlPost()); >> >> If that helps, apply this (very similar) patch to >> /opt/zendto/www/pickup.php as that's the other place this >> call appears: >> >> 130c143,144 >> > \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >> --- >> >?????????? $recaptcha = new >> \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >> >???????????? new \ReCaptcha\RequestMethod\CurlPost()); >> >> I've never managed to figure out why sites which have been >> working perfectly well on the default suddenly stop doing so, >> with apparently no changes anywhere (except at Google?). But >> using the CurlPost() technique seems to work well for everyone. >> >> Let me know how you get on. >> >> Cheers, >> Jules. >> >> On 05/11/2020 14:54, Everton Bruno Bernardi wrote: >>> Hi Jules, >>> >>> Thanks for your considerations. >>> Unfortunately this is happening to all of our users >>> (including external). >>> >>> I've already tried on other browsers and the same happens. >>> >>> >>> >>> Em qui, 5 de nov de 2020 11:18, Jules >> > escreveu: >>> >>> Everton, >>> >>> Please can you try a couple of things: >>> 1. Close all your browser tabs except 1 showing >>> something like Google's home page. Clear your browser >>> cache completely, then quit and restart your browser. >>> Does the problem still occur? >>> 2. Try from an incognito/private browser window. Does >>> that make it behave? >>> >>> If number 2 makes it behave, then the browser cache >>> isn't being fully cleared, as that's the only important >>> difference as far as a new tab is concerned. >>> >>> Anyone else seeing this problem? >>> >>> Cheers, >>> Jules. >>> >>> On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo >>> wrote: >>>> Hi there, >>>> >>>> Recently we've been facing the following issue with >>>> ZendTo (version 5.03 - a lot old, I know): >>>> >>>> image.png >>>> >>>> I've confirmed the reCAPTCHA keys and everything seems >>>> to be correct. >>>> What could I do in order to know what's really happening? >>>> >>>> >>>> Thanks in advance. >>>> >>>> Regards >>>> >>>> -- >>>> /Everton Bruno Bernardi >>>> / >>>> >>>> >>>> >>>> _______________________________________________ >>>> ZendTo mailing list >>>> ZendTo at zend.to >>>> http://jul.es/mailman/listinfo/zendto >>> >>> Jules >>> >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> www.Zend.To >>> Twitter: @JulesFM >>> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> >> www.Zend.To >> Twitter: @JulesFM >> >> >> >> -- >> /Everton Bruno Bernardi / >> >> > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > www.Zend.To > Twitter: @JulesFM > > > > -- > /Everton Bruno Bernardi / > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Find a place inside where there's joy, and the joy will burn out the pain.' - Joseph Campbell www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebbernardi at gmail.com Mon Nov 9 13:36:35 2020 From: ebbernardi at gmail.com (Everton Bruno Bernardi) Date: Mon, 9 Nov 2020 10:36:35 -0300 Subject: [ZendTo] Invalid JSON error - reCAPTCHA In-Reply-To: References: <4d9acd8d-7917-e7eb-807c-0c3434e3cc8d@Zend.To> <523cd0d8-f96a-0092-3842-c72e788158e2@Zend.To> Message-ID: Jules, I'm currently on *Ubuntu 16.04.* Please find below the output for the commands you sent. root at hostname:~# ifconfig -a ens160 Link encap:Ethernet HWaddr HIDDEN inet addr:HIDDEN Bcast:HIDDEN.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:19150019 errors:0 dropped:456053 overruns:0 frame:0 TX packets:13861115 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:25447977490 (25.4 GB) TX bytes:49743121905 (49.7 GB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:51898 errors:0 dropped:0 overruns:0 frame:0 TX packets:51898 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:4636581 (4.6 MB) TX bytes:4636581 (4.6 MB) root at hostname:~# ip addr list 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens160: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether HIDDEN brd ff:ff:ff:ff:ff:ff inet HIDDEN/23 brd HIDDEN.255 scope global ens160 valid_lft forever preferred_lft forever root at hostname:~# sysctl -a | egrep -i 'ipv?6' sysctl: reading key "net.ipv6.conf.all.stable_secret" net.ipv6.anycast_src_echo_reply = 0 net.ipv6.auto_flowlabels = 1 net.ipv6.bindv6only = 0 net.ipv6.conf.all.accept_dad = 1 net.ipv6.conf.all.accept_ra = 1 net.ipv6.conf.all.accept_ra_defrtr = 1 net.ipv6.conf.all.accept_ra_from_local = 0 net.ipv6.conf.all.accept_ra_min_hop_limit = 1 net.ipv6.conf.all.accept_ra_mtu = 1 net.ipv6.conf.all.accept_ra_pinfo = 1 net.ipv6.conf.all.accept_ra_rt_info_max_plen = 0 net.ipv6.conf.all.accept_ra_rtr_pref = 1 net.ipv6.conf.all.accept_redirects = 1 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.all.autoconf = 1 net.ipv6.conf.all.dad_transmits = 1 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.all.force_mld_version = 0 net.ipv6.conf.all.force_tllao = 0 net.ipv6.conf.all.forwarding = 0 net.ipv6.conf.all.hop_limit = 64 net.ipv6.conf.all.ignore_routes_with_linkdown = 0 net.ipv6.conf.all.max_addresses = 16 net.ipv6.conf.all.max_desync_factor = 600 net.ipv6.conf.all.mc_forwarding = 0 net.ipv6.conf.all.mldv1_unsolicited_report_interval = 10000 net.ipv6.conf.all.mldv2_unsolicited_report_interval = 1000 net.ipv6.conf.all.mtu = 1280 net.ipv6.conf.all.ndisc_notify = 0 net.ipv6.conf.all.proxy_ndp = 0 net.ipv6.conf.all.regen_max_retry = 3 net.ipv6.conf.all.router_probe_interval = 60 net.ipv6.conf.all.router_solicitation_delay = 1 net.ipv6.conf.all.router_solicitation_interval = 4 net.ipv6.conf.all.router_solicitations = 3 sysctl: reading key "net.ipv6.conf.default.stable_secret" net.ipv6.conf.all.suppress_frag_ndisc = 1 net.ipv6.conf.all.temp_prefered_lft = 86400 net.ipv6.conf.all.temp_valid_lft = 604800 net.ipv6.conf.all.use_oif_addrs_only = 0 net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.accept_dad = 1 net.ipv6.conf.default.accept_ra = 1 net.ipv6.conf.default.accept_ra_defrtr = 1 net.ipv6.conf.default.accept_ra_from_local = 0 net.ipv6.conf.default.accept_ra_min_hop_limit = 1 net.ipv6.conf.default.accept_ra_mtu = 1 net.ipv6.conf.default.accept_ra_pinfo = 1 net.ipv6.conf.default.accept_ra_rt_info_max_plen = 0 net.ipv6.conf.default.accept_ra_rtr_pref = 1 net.ipv6.conf.default.accept_redirects = 1 net.ipv6.conf.default.accept_source_route = 0 net.ipv6.conf.default.autoconf = 1 net.ipv6.conf.default.dad_transmits = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.default.force_mld_version = 0 net.ipv6.conf.default.force_tllao = 0 net.ipv6.conf.default.forwarding = 0 net.ipv6.conf.default.hop_limit = 64 net.ipv6.conf.default.ignore_routes_with_linkdown = 0 net.ipv6.conf.default.max_addresses = 16 net.ipv6.conf.default.max_desync_factor = 600 net.ipv6.conf.default.mc_forwarding = 0 net.ipv6.conf.default.mldv1_unsolicited_report_interval = 10000 net.ipv6.conf.default.mldv2_unsolicited_report_interval = 1000 net.ipv6.conf.default.mtu = 1280 net.ipv6.conf.default.ndisc_notify = 0 net.ipv6.conf.default.proxy_ndp = 0 net.ipv6.conf.default.regen_max_retry = 3 net.ipv6.conf.default.router_probe_interval = 60 net.ipv6.conf.default.router_solicitation_delay = 1 net.ipv6.conf.default.router_solicitation_interval = 4 net.ipv6.conf.default.router_solicitations = 3 sysctl: reading key "net.ipv6.conf.ens160.stable_secret" net.ipv6.conf.default.suppress_frag_ndisc = 1 net.ipv6.conf.default.temp_prefered_lft = 86400 net.ipv6.conf.default.temp_valid_lft = 604800 net.ipv6.conf.default.use_oif_addrs_only = 0 net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.ens160.accept_dad = 1 net.ipv6.conf.ens160.accept_ra = 1 net.ipv6.conf.ens160.accept_ra_defrtr = 1 net.ipv6.conf.ens160.accept_ra_from_local = 0 net.ipv6.conf.ens160.accept_ra_min_hop_limit = 1 net.ipv6.conf.ens160.accept_ra_mtu = 1 net.ipv6.conf.ens160.accept_ra_pinfo = 1 net.ipv6.conf.ens160.accept_ra_rt_info_max_plen = 0 net.ipv6.conf.ens160.accept_ra_rtr_pref = 1 net.ipv6.conf.ens160.accept_redirects = 1 net.ipv6.conf.ens160.accept_source_route = 0 net.ipv6.conf.ens160.autoconf = 1 net.ipv6.conf.ens160.dad_transmits = 1 net.ipv6.conf.ens160.disable_ipv6 = 1 net.ipv6.conf.ens160.force_mld_version = 0 net.ipv6.conf.ens160.force_tllao = 0 net.ipv6.conf.ens160.forwarding = 0 net.ipv6.conf.ens160.hop_limit = 64 net.ipv6.conf.ens160.ignore_routes_with_linkdown = 0 net.ipv6.conf.ens160.max_addresses = 16 net.ipv6.conf.ens160.max_desync_factor = 600 net.ipv6.conf.ens160.mc_forwarding = 0 net.ipv6.conf.ens160.mldv1_unsolicited_report_interval = 10000 net.ipv6.conf.ens160.mldv2_unsolicited_report_interval = 1000 net.ipv6.conf.ens160.mtu = 1500 net.ipv6.conf.ens160.ndisc_notify = 0 net.ipv6.conf.ens160.proxy_ndp = 0 net.ipv6.conf.ens160.regen_max_retry = 3 net.ipv6.conf.ens160.router_probe_interval = 60 net.ipv6.conf.ens160.router_solicitation_delay = 1 net.ipv6.conf.ens160.router_solicitation_interval = 4 net.ipv6.conf.ens160.router_solicitations = 3 sysctl: reading key "net.ipv6.conf.lo.stable_secret" net.ipv6.conf.ens160.suppress_frag_ndisc = 1 net.ipv6.conf.ens160.temp_prefered_lft = 86400 net.ipv6.conf.ens160.temp_valid_lft = 604800 net.ipv6.conf.ens160.use_oif_addrs_only = 0 net.ipv6.conf.ens160.use_tempaddr = 0 net.ipv6.conf.lo.accept_dad = -1 net.ipv6.conf.lo.accept_ra = 1 net.ipv6.conf.lo.accept_ra_defrtr = 1 net.ipv6.conf.lo.accept_ra_from_local = 0 net.ipv6.conf.lo.accept_ra_min_hop_limit = 1 net.ipv6.conf.lo.accept_ra_mtu = 1 net.ipv6.conf.lo.accept_ra_pinfo = 1 net.ipv6.conf.lo.accept_ra_rt_info_max_plen = 0 net.ipv6.conf.lo.accept_ra_rtr_pref = 1 net.ipv6.conf.lo.accept_redirects = 1 net.ipv6.conf.lo.accept_source_route = 0 net.ipv6.conf.lo.autoconf = 1 net.ipv6.conf.lo.dad_transmits = 1 net.ipv6.conf.lo.disable_ipv6 = 1 net.ipv6.conf.lo.force_mld_version = 0 net.ipv6.conf.lo.force_tllao = 0 net.ipv6.conf.lo.forwarding = 0 net.ipv6.conf.lo.hop_limit = 64 net.ipv6.conf.lo.ignore_routes_with_linkdown = 0 net.ipv6.conf.lo.max_addresses = 16 net.ipv6.conf.lo.max_desync_factor = 600 net.ipv6.conf.lo.mc_forwarding = 0 net.ipv6.conf.lo.mldv1_unsolicited_report_interval = 10000 net.ipv6.conf.lo.mldv2_unsolicited_report_interval = 1000 net.ipv6.conf.lo.mtu = 65536 net.ipv6.conf.lo.ndisc_notify = 0 net.ipv6.conf.lo.proxy_ndp = 0 net.ipv6.conf.lo.regen_max_retry = 3 net.ipv6.conf.lo.router_probe_interval = 60 net.ipv6.conf.lo.router_solicitation_delay = 1 net.ipv6.conf.lo.router_solicitation_interval = 4 net.ipv6.conf.lo.router_solicitations = 3 net.ipv6.conf.lo.suppress_frag_ndisc = 1 net.ipv6.conf.lo.temp_prefered_lft = 86400 net.ipv6.conf.lo.temp_valid_lft = 604800 net.ipv6.conf.lo.use_oif_addrs_only = 0 net.ipv6.conf.lo.use_tempaddr = -1 net.ipv6.flowlabel_consistency = 1 net.ipv6.flowlabel_state_ranges = 0 net.ipv6.fwmark_reflect = 0 net.ipv6.icmp.ratelimit = 1000 net.ipv6.idgen_delay = 1 net.ipv6.idgen_retries = 3 net.ipv6.ip6frag_high_thresh = 4194304 net.ipv6.ip6frag_low_thresh = 3145728 net.ipv6.ip6frag_secret_interval = 0 net.ipv6.ip6frag_time = 60 net.ipv6.ip_nonlocal_bind = 0 net.ipv6.mld_max_msf = 64 net.ipv6.mld_qrv = 2 net.ipv6.neigh.default.anycast_delay = 100 net.ipv6.neigh.default.app_solicit = 0 net.ipv6.neigh.default.base_reachable_time_ms = 30000 net.ipv6.neigh.default.delay_first_probe_time = 5 net.ipv6.neigh.default.gc_interval = 30 net.ipv6.neigh.default.gc_stale_time = 60 net.ipv6.neigh.default.gc_thresh1 = 128 net.ipv6.neigh.default.gc_thresh2 = 512 net.ipv6.neigh.default.gc_thresh3 = 1024 net.ipv6.neigh.default.locktime = 0 net.ipv6.neigh.default.mcast_resolicit = 0 net.ipv6.neigh.default.mcast_solicit = 3 net.ipv6.neigh.default.proxy_delay = 80 net.ipv6.neigh.default.proxy_qlen = 64 net.ipv6.neigh.default.retrans_time_ms = 1000 net.ipv6.neigh.default.ucast_solicit = 3 net.ipv6.neigh.default.unres_qlen = 31 net.ipv6.neigh.default.unres_qlen_bytes = 65536 net.ipv6.neigh.ens160.anycast_delay = 100 net.ipv6.neigh.ens160.app_solicit = 0 net.ipv6.neigh.ens160.base_reachable_time_ms = 30000 net.ipv6.neigh.ens160.delay_first_probe_time = 5 net.ipv6.neigh.ens160.gc_stale_time = 60 net.ipv6.neigh.ens160.locktime = 0 net.ipv6.neigh.ens160.mcast_resolicit = 0 net.ipv6.neigh.ens160.mcast_solicit = 3 net.ipv6.neigh.ens160.proxy_delay = 80 net.ipv6.neigh.ens160.proxy_qlen = 64 net.ipv6.neigh.ens160.retrans_time_ms = 1000 net.ipv6.neigh.ens160.ucast_solicit = 3 net.ipv6.neigh.ens160.unres_qlen = 31 net.ipv6.neigh.ens160.unres_qlen_bytes = 65536 net.ipv6.neigh.lo.anycast_delay = 100 net.ipv6.neigh.lo.app_solicit = 0 net.ipv6.neigh.lo.base_reachable_time_ms = 30000 net.ipv6.neigh.lo.delay_first_probe_time = 5 net.ipv6.neigh.lo.gc_stale_time = 60 net.ipv6.neigh.lo.locktime = 0 net.ipv6.neigh.lo.mcast_resolicit = 0 net.ipv6.neigh.lo.mcast_solicit = 3 net.ipv6.neigh.lo.proxy_delay = 80 net.ipv6.neigh.lo.proxy_qlen = 64 net.ipv6.neigh.lo.retrans_time_ms = 1000 net.ipv6.neigh.lo.ucast_solicit = 3 net.ipv6.neigh.lo.unres_qlen = 31 net.ipv6.neigh.lo.unres_qlen_bytes = 65536 net.ipv6.route.gc_elasticity = 9 net.ipv6.route.gc_interval = 30 net.ipv6.route.gc_min_interval = 0 net.ipv6.route.gc_min_interval_ms = 500 net.ipv6.route.gc_thresh = 1024 net.ipv6.route.gc_timeout = 60 net.ipv6.route.max_size = 4096 net.ipv6.route.min_adv_mss = 1220 net.ipv6.route.mtu_expires = 600 net.ipv6.xfrm6_gc_thresh = 2147483647 root at hostname:~# lsmod Module Size Used by binfmt_misc 20480 1 vmw_vsock_vmci_transport 28672 1 vsock 36864 2 vmw_vsock_vmci_transport ppdev 20480 0 vmw_balloon 20480 0 joydev 20480 0 input_leds 16384 0 serio_raw 16384 0 nfit 32768 0 parport_pc 32768 0 parport 49152 2 ppdev,parport_pc 8250_fintek 16384 0 vmw_vmci 65536 2 vmw_vsock_vmci_transport,vmw_balloon shpchp 36864 0 i2c_piix4 24576 0 mac_hid 16384 0 ib_iser 49152 0 rdma_cm 49152 1 ib_iser iw_cm 45056 1 rdma_cm ib_cm 45056 1 rdma_cm ib_sa 36864 2 rdma_cm,ib_cm ib_mad 49152 2 ib_cm,ib_sa ib_core 106496 6 rdma_cm,ib_cm,ib_sa,iw_cm,ib_mad,ib_iser ib_addr 20480 2 rdma_cm,ib_core iscsi_tcp 20480 0 libiscsi_tcp 24576 1 iscsi_tcp libiscsi 53248 3 libiscsi_tcp,iscsi_tcp,ib_iser scsi_transport_iscsi 98304 4 iscsi_tcp,ib_iser,libiscsi autofs4 40960 2 btrfs 987136 0 raid10 49152 0 raid456 110592 0 async_raid6_recov 20480 1 raid456 async_memcpy 16384 2 raid456,async_raid6_recov async_pq 16384 2 raid456,async_raid6_recov async_xor 16384 3 async_pq,raid456,async_raid6_recov async_tx 16384 5 async_pq,raid456,async_xor,async_memcpy,async_raid6_recov xor 24576 2 btrfs,async_xor raid6_pq 102400 4 async_pq,raid456,btrfs,async_raid6_recov libcrc32c 16384 1 raid456 raid1 36864 0 raid0 20480 0 multipath 16384 0 linear 16384 0 crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 ghash_clmulni_intel 16384 0 aesni_intel 167936 0 aes_x86_64 20480 1 aesni_intel lrw 16384 1 aesni_intel gf128mul 16384 1 lrw glue_helper 16384 1 aesni_intel ablk_helper 16384 1 aesni_intel cryptd 20480 3 ghash_clmulni_intel,aesni_intel,ablk_helper psmouse 131072 0 vmwgfx 237568 1 ttm 94208 1 vmwgfx drm_kms_helper 155648 1 vmwgfx syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper sysimgblt 16384 1 drm_kms_helper fb_sys_fops 16384 1 drm_kms_helper mptspi 24576 3 mptscsih 40960 1 mptspi drm 364544 4 ttm,drm_kms_helper,vmwgfx vmxnet3 57344 0 mptbase 102400 2 mptspi,mptscsih scsi_transport_spi 32768 1 mptspi pata_acpi 16384 0 floppy 73728 0 fjes 28672 0 On Sun, Nov 8, 2020 at 8:54 AM Jules wrote: > Everton, > > What exact variant and version of Linux are you using? > Please send me the output of these: > ifconfig -a > ip addr list > sysctl -a | egrep -i 'ipv?6' > lsmod > > Thanks! > Jules. > > On 05/11/2020 18:53, Everton Bruno Bernardi wrote: > > Jules, > > IPV6 was enabled. Disabled IPV6 and rebooted the box but the issue > persists. > :/ > > > > On Thu, Nov 5, 2020 at 3:18 PM Jules wrote: > >> Everton, >> >> I've just had a dig through my mail archives. >> >> Some folks at Brunel University in the UK had the same problem. Here is >> their comment on the problem and how they fixed it: >> >> Reason for reCAPTCHA problem we understood relates to the firewall and >> IPV6 settings. >> Recently we had firewall and network changes implemented to our data >> centre which had impact on IPV6 related connectivity in Linux environment. >> We have disabled IPV6 on dropoff server and it worked fine without any >> issues. >> >> Hope that helps, >> Jules. >> >> On 05/11/2020 17:09, Everton Bruno Bernardi wrote: >> >> Jules, >> >> Thanks for that. I changed the code you sent me but it had no effect. The >> same error occurs. >> Am I able to send any debug information to help you out? If so, please >> tell me how can I get it. >> >> >> Regards, >> >> Everton >> >> On Thu, Nov 5, 2020 at 12:10 PM Jules wrote: >> >>> Hi Everton, >>> >>> I've just compared the code from 5.03 to the latest, for this specific >>> problem. >>> >>> Try applying this patch (manually with a text editor is just fine!) to >>> /opt/zendto/www/verify.php: >>> >>> 97,101c110,111 >>> < // Old version 1 code. >>> < // $resp = recaptcha_check_answer($reCaptchaPrivateKey, >>> < // getClientIP(), >>> < // >>> $_POST["g-recaptcha-response"]); >>> < $recaptcha = new >>> \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >>> --- >>> > $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >>> > new \ReCaptcha\RequestMethod\CurlPost()); >>> >>> If that helps, apply this (very similar) patch to >>> /opt/zendto/www/pickup.php as that's the other place this call appears: >>> >>> 130c143,144 >>> < $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); >>> --- >>> > $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey, >>> > new \ReCaptcha\RequestMethod\CurlPost()); >>> >>> I've never managed to figure out why sites which have been working >>> perfectly well on the default suddenly stop doing so, with apparently no >>> changes anywhere (except at Google?). But using the CurlPost() technique >>> seems to work well for everyone. >>> >>> Let me know how you get on. >>> >>> Cheers, >>> Jules. >>> >>> On 05/11/2020 14:54, Everton Bruno Bernardi wrote: >>> >>> Hi Jules, >>> >>> Thanks for your considerations. >>> Unfortunately this is happening to all of our users (including external). >>> >>> I've already tried on other browsers and the same happens. >>> >>> >>> >>> Em qui, 5 de nov de 2020 11:18, Jules escreveu: >>> >>>> Everton, >>>> >>>> Please can you try a couple of things: >>>> 1. Close all your browser tabs except 1 showing something like Google's >>>> home page. Clear your browser cache completely, then quit and restart your >>>> browser. Does the problem still occur? >>>> 2. Try from an incognito/private browser window. Does that make it >>>> behave? >>>> >>>> If number 2 makes it behave, then the browser cache isn't being fully >>>> cleared, as that's the only important difference as far as a new tab is >>>> concerned. >>>> >>>> Anyone else seeing this problem? >>>> >>>> Cheers, >>>> Jules. >>>> >>>> On 05/11/2020 13:31, Everton Bruno Bernardi via ZendTo wrote: >>>> >>>> Hi there, >>>> >>>> Recently we've been facing the following issue with ZendTo (version >>>> 5.03 - a lot old, I know): >>>> >>>> [image: image.png] >>>> >>>> I've confirmed the reCAPTCHA keys and everything seems to be correct. >>>> What could I do in order to know what's really happening? >>>> >>>> >>>> Thanks in advance. >>>> >>>> Regards >>>> >>>> -- >>>> *Everton Bruno Bernardi * >>>> >>>> >>>> >>>> _______________________________________________ >>>> ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto >>>> >>>> >>>> Jules >>>> >>>> -- >>>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>>> >>>> www.Zend.To >>>> Twitter: @JulesFM >>>> >>>> >>> Jules >>> >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> www.Zend.To >>> Twitter: @JulesFM >>> >>> >> >> -- >> *Everton Bruno Bernardi * >> >> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> www.Zend.To >> Twitter: @JulesFM >> >> > > -- > *Everton Bruno Bernardi * > > > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'Find a place inside where there's joy, and the joy will burn out > the pain.' - Joseph Campbell > www.Zend.To > Twitter: @JulesFM > > -- *Everton Bruno Bernardi * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Nov 10 16:23:29 2020 From: Jules at Zend.To (Jules) Date: Tue, 10 Nov 2020 16:23:29 +0000 Subject: [ZendTo] Test posting Message-ID: <41927250-ec53-0c22-1075-fdd77df65654@Zend.To> I upgraded a lot of stuff on my main mail server over the weekend, and want to check this list still works! Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssilva at sgvwater.com Tue Nov 10 17:02:14 2020 From: ssilva at sgvwater.com (Scott Silva) Date: Tue, 10 Nov 2020 17:02:14 +0000 Subject: [ZendTo] Test posting In-Reply-To: References: <41927250-ec53-0c22-1075-fdd77df65654@Zend.To> <54D3F6A07E3F2A4AAD4CBA73922025F4345B9A3D@FONEXCH01.sgvwc.local> Message-ID: Still works? From: ZendTo On Behalf Of Jules via ZendTo Sent: Tuesday, November 10, 2020 8:24 AM To: ZendTo Users Cc: Jules Subject: [ZendTo] Test posting I upgraded a lot of stuff on my main mail server over the weekend, and want to check this list still works! Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From schneiderbw at gmail.com Fri Nov 13 17:54:48 2020 From: schneiderbw at gmail.com (Ben Schneider) Date: Fri, 13 Nov 2020 12:54:48 -0500 Subject: [ZendTo] Error when requesting a drop-off References: Message-ID: Hi All, I'm getting an error on one of my client's ZendTo servers when they request a drop-off. The error message says: Request Error The end time you set has already passed. Use the Back button to go back and fix this error before trying again. This just started happening after upgrading to 6.05-4. Any suggestions? Thanks!! ____________________________________________ *Ben Schneider* schneiderbw at gmail.com Cell: 937-346-7154 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Nov 16 09:36:41 2020 From: Jules at Zend.To (Jules) Date: Mon, 16 Nov 2020 09:36:41 +0000 Subject: [ZendTo] Error when requesting a drop-off In-Reply-To: References: Message-ID: <6861b6af-640e-be8a-1986-87cc25a46c0a@Zend.To> Ben, Did you run /opt/zendto/bin/upgrade after upgrading? There's now the ability to set the start and end times of a request. Make sure they have the updated templates in /opt/zendto/templates. If the request.tpl is not the latest, they would probably see this error. You should check they are using all the latest *.tpl files. Download a copy of the tgz distribution of exactly the same version, unpack it into /tmp and grab a copy of all the files out of the templates directory. Use them to replace whatever is in /opt/zendto/templates. What flavour of Linux are you using? For those on RPM/yum based systems such as RHEL and CentOS, I am going to change the rpm slightly so that any old customised templates are moved to *.rpmsave and new templates take priority. Sadly I can't do that with deb/apt based systems, and the default when it asks you is to leave the old one in place, which is exactly the wrong answer for these template files. If I'm missing anything, so that I could change the default answer, please do let me know! Cheers, Jules. On 13/11/2020 17:54, Ben Schneider via ZendTo wrote: > Hi All, > > I'm getting an error on one of my client's ZendTo servers when they > request a drop-off. > > The error message says: > Request Error > The end time you set has already passed.? Use the Back button to go > back and fix this error before trying again. > > This just started happening after upgrading to 6.05-4. > > Any?suggestions? > > Thanks!! > ____________________________________________ > *Ben Schneider* > schneiderbw at gmail.com > Cell:937-346-7154 > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Find a place inside where there's joy, and the joy will burn out the pain.' - Joseph Campbell www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Tue Nov 17 10:49:28 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Tue, 17 Nov 2020 10:49:28 +0000 Subject: [ZendTo] Multiple recipients of the same "request a drop-off" request receive the same link References: Message-ID: Hello Jules I?ve been experimenting with the ?Request a Drop-off? functionality, and sending the same request to multiple recipients. The tool-tip on the email address field says "Multiple email addresses should be separated with a comma \",\" or semicolon \";\". Each recipient will be sent a different link.? However, when I tested with three different accounts at the same domain (by putting "1 at example.com , 2 at example.com , 3 at example.com ? (without the quotes) into the field), each account received a separate email, but each email had the same link. As such, when one had uploaded a file, the others could not. Best wishes Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Nov 17 11:11:05 2020 From: Jules at Zend.To (Jules) Date: Tue, 17 Nov 2020 11:11:05 +0000 Subject: [ZendTo] Multiple recipients of the same "request a drop-off" request receive the same link In-Reply-To: References: Message-ID: Neil, Aha! I knew someone else would spot that bug eventually. Fortunately it's very easy to fix (and the fix is already in the code, waiting for another release to happen). Edit /opt/zendto/lib/Smartyconf.php Change the last couple of lines of code in the file to this: $smarty->force_compile = false; $smarty->caching = 0; Then delete all the cached templates: rm -f /var/zendto/cache/*php rm -f /var/zendto/templates_c/*php There's no need to restart anything at all, you can safely do this to a live system. Cheers, Jules. On 17/11/2020 10:49, Neil via ZendTo wrote: > Hello Jules > > I?ve been experimenting with the ?Request a Drop-off? functionality, > and sending the same request to multiple recipients. > > The tool-tip on the email address field says "Multiple email addresses > should be separated with a comma \",\" or semicolon \";\". Each > recipient will be sent a different link.? > > However, when I tested with three different accounts at the same > domain (by putting "1 at example.com , > 2 at example.com , 3 at example.com > ? (without the quotes) into the field), each > account received a separate email, but each email had the same link. > As such, when one had uploaded a file, the others could not. > > Best wishes > > Neil > > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Find a place inside where there's joy, and the joy will burn out the pain.' - Joseph Campbell www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Tue Nov 17 11:40:03 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Tue, 17 Nov 2020 11:40:03 +0000 Subject: [ZendTo] Multiple recipients of the same "request a drop-off" request receive the same link In-Reply-To: References: <3E50166B-B37F-41DE-90DE-E6AB487BEE13@neilzone.co.uk> Message-ID: > On 17 Nov 2020, at 11:11, Jules wrote: Hello Jules > > > Edit /opt/zendto/lib/Smartyconf.php > > Change the last couple of lines of code in the file to this: > > $smarty->force_compile = false; > $smarty->caching = 0; > > Then delete all the cached templates: > rm -f /var/zendto/cache/*php > rm -f /var/zendto/templates_c/*php That did the trick. Thank you! Best wishes Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Tue Nov 17 19:13:18 2020 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 17 Nov 2020 10:13:18 -0900 Subject: [ZendTo] Feature request: optional units on some preferences References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> Message-ID: Computers are good at doing math. Can we have the option of including units on some preferences? I'm thinking, particularly, about: maxBytesForDropoff maxBytesForFile maxBytesForChecksum maxBytesForEncryption These are currently specified in bytes. This is generally a long number which is hard to read and easy to stumble over. May we have the default continue to be "number of bytes" but have it accept an optional unit-suffix? For example: 'maxBytesForDropoff' => 25769790582, could be specified as: 'maxBytesForDropoff' => 24G, Old preferences would continue to work, and new preferences would be easier to read. -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska From KLE at msktd.com Tue Nov 17 19:15:57 2020 From: KLE at msktd.com (Ken Etter) Date: Tue, 17 Nov 2020 14:15:57 -0500 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> <5FB4216D020000130014AD60@mail.msktd.com> Message-ID: I'll second that one! >>> John Thurston via ZendTo 11/17/2020 2:13 PM >>> Computers are good at doing math. Can we have the option of including units on some preferences? I'm thinking, particularly, about: maxBytesForDropoff maxBytesForFile maxBytesForChecksum maxBytesForEncryption These are currently specified in bytes. This is generally a long number which is hard to read and easy to stumble over. May we have the default continue to be "number of bytes" but have it accept an optional unit-suffix? For example: 'maxBytesForDropoff' => 25769790582, could be specified as: 'maxBytesForDropoff' => 24G, Old preferences would continue to work, and new preferences would be easier to read. -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Massimo.Forni at turboden.it Tue Nov 17 20:02:21 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Tue, 17 Nov 2020 20:02:21 +0000 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> Message-ID: +1 for me! -----Original Message----- From: ZendTo On Behalf Of John Thurston via ZendTo Sent: marted? 17 novembre 2020 20:13 To: ZendTo List Cc: John Thurston Subject: [ZendTo] Feature request: optional units on some preferences Computers are good at doing math. Can we have the option of including units on some preferences? I'm thinking, particularly, about: maxBytesForDropoff maxBytesForFile maxBytesForChecksum maxBytesForEncryption These are currently specified in bytes. This is generally a long number which is hard to read and easy to stumble over. May we have the default continue to be "number of bytes" but have it accept an optional unit-suffix? For example: 'maxBytesForDropoff' => 25769790582, could be specified as: 'maxBytesForDropoff' => 24G, Old preferences would continue to work, and new preferences would be easier to read. -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska _______________________________________________ ZendTo mailing list ZendTo at zend.to https://urldefense.com/v3/__http://jul.es/mailman/listinfo/zendto__;!!BYEqwblc0Q!i3n9POw7rlJZAjD9qJ2p5AJGysYAUOtjFrVPSKBhrp7-n8lPg4ngEe-YNVtgAfVD1f8RPQ$ -- Massimo Forni ICT Infrastructure Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. From dsolodow at gaylor.com Wed Nov 18 19:35:30 2020 From: dsolodow at gaylor.com (Solodow, Damien) Date: Wed, 18 Nov 2020 19:35:30 +0000 Subject: [ZendTo] Ubuntu 20.04 LTS support? References: Message-ID: I?m currently running ZendTo 6.05 on Ubuntu 18.04 and it?s prompting for an upgrade to 20.04.1. I didn?t see that listed as a supported/tested distribution; any known issues or anyone using it? ? [Gaylor Electric logo] [Gaylor Electric Website] [Facebook] [Twitter] [LinkedIn] Damien Solodow IS System Administrator Gaylor Electric, Inc. 5750 Castle Creek Pkwy N Drive, Suite 400 Indianapolis , IN . 46250 O: 317.815.3103 | M: 317.506.8521 317.759.0077 emergency IS support -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5535 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1014 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 713 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 852 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 774 bytes Desc: image005.png URL: From zend.to at neilzone.co.uk Wed Nov 18 19:37:49 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Wed, 18 Nov 2020 19:37:49 +0000 Subject: [ZendTo] Ubuntu 20.04 LTS support? In-Reply-To: References: <2A746EB0-EB58-48DB-8BD7-879DE2E28072@neilzone.co.uk> Message-ID: > On 18 Nov 2020, at 19:35, Solodow, Damien via ZendTo wrote: > > I didn?t see that listed as a supported/tested distribution; any known issues or anyone using it? I have intentionally held off upgrading up I see confirmation zend.to is supported, in case that helps. Neil __________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Nov 19 19:03:38 2020 From: Jules at Zend.To (Jules) Date: Thu, 19 Nov 2020 19:03:38 +0000 Subject: [ZendTo] Ubuntu 20.04 LTS support? In-Reply-To: References: Message-ID: <422bffa5-97fd-bad1-ef60-66b5abafdf33@Zend.To> Damien, Neil, I do all the development of it on a fully-patched Ubuntu 20.04 box. So it certainly works on that. I'm 99% sure I tested the ZendTo Installer on Ubuntu 20 as well. But the website disagrees (only mentions Ubuntu 19). I'll need to test the Installer on 20.04 and 20.10 to double-chceck. So I can't guarantee the Installer work perfectly on Ubuntu 20, but a working installation works on Ubuntu 20 as I said above. Cheers, Jules. On 18/11/2020 19:35, Solodow, Damien via ZendTo wrote: > > I?m currently running ZendTo 6.05 on Ubuntu 18.04 and it?s prompting > for an upgrade to 20.04.1. > > I didn?t see that listed as a supported/tested distribution; any known > issues or anyone using it? > > ? > > Gaylor Electric logo > > Gaylor Electric Website > > > > Facebook > > > > Twitter > > > > LinkedIn > > > > *Damien?Solodow* > > *IS?System?Administrator* > > Gaylor?Electric,?Inc. > > 5750?Castle?Creek?Pkwy?N?Drive,?Suite?400 > > Indianapolis > > > > , > > > > IN > > > > . > > > > 46250 > > O: 317.815.3103 > > > > | > > > > M: 317.506.8521 > > *317.759.0077 emergency > IS?support * > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng MBCS CITP CEng www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 'A committee is a group of the unwilling, chosen from the unfit, to do the unnecessary.' - Anon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5535 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1014 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 774 bytes Desc: not available URL: