I.v.m vakantie, zijn wij tot 24 oktober niet in staat uw mail te beantwoorden.
Vanaf de 24e, nemen wij contact met u op.
Met vriendelijke groet,
Marco Asbreuk
ITS Asbreuk
--
The demand for IT networking professionals
It's in "all test mode".
The Spoofing check is scipped in "all test mode".
Thomas
Von:Ricardo Campos Passanezi
An: assp-test@lists.sourceforge.net
Datum: 17.10.2011 16:13
Betreff:[Assp-test] DoNoSpoofing question
Hello guys.
I've recently installed assp. It's in "all t
AH woops, not got the correct version *embarrassed face* will download
later versions.
Sorry and thanks
Paul
On Fri, 21 Oct 2011 18:22:36 +0200, Thomas Eckardt wrote:
> the error message should be:
>
> "relay attempt blocked for non local BCC
> recipient -
> $addr";
>
> see
the error message should be:
"relay attempt blocked for non local BCC recipient -
$addr";
seems your version is a bit too old
check the output of an interactive start - is there a line ?
info: internal variable 'removeForeignBCC' was set to '1'
or anything like
warning: u
Hi Thomas
I did what you said about the startup configuration and it still
appears to be happening.
Here is my daemon process.
nobody 12951 1 0 Oct20 ?00:01:37 /usr/bin/perl --
/usr/local/ASSP_V2/assp.pl /usr/local/ASSP_V2 --removeForeignBCC:=1
and here is the log of the order
On 2011-10-21 9:24 AM, Thomas Eckardt wrote:
> I'll change the behavior of assp for SSL-failed privat IP's and
> 'acceptAllMail' IP's - by giving them one more chance to correct there
> mistake.
Thanks Thomas!!
--
Best regards,
Charles
> >(as happens when Thunderbird prompts the user to accept a
>>self-signed cert) is not best practice.
>
> This is done by Net::SSLeay (OpenSSL) - not by assp and it works perfect
> with other clients. ASSP simply detects that an unrecoverable (one more
> retry attempt for each connection) error o
>(as happens when Thunderbird prompts the user to accept a
>self-signed cert) is not best practice.
This is done by Net::SSLeay (OpenSSL) - not by assp and it works perfect
with other clients. ASSP simply detects that an unrecoverable (one more
retry attempt for each connection) error occurs.
On 2011-10-21 9:25 AM, Peter W Bowey wrote:
> The challenge is in the ASSP verification for 'self-signed certs'.
> It is a bummer for Thomas...:-)
+1
I'm not suggesting it is easy to do (I don't know as ianap)... and if
Thomas' answer is 'it is desirable, but hard to do', then that is a
perfec
> Wasn't suggesting it should be disabled, I was suggesting that maybe
> refusing to continue to offer STARTTLS/SSL because of one, temporary
> 'failure' (as happens when Thunderbird prompts the user to accept a
> self-signed cert) is not best practice.
>
> Postfix, Exchange Server, web server
On 2011-10-21 9:18 AM, Peter W Bowey wrote:
> I see that you have 'possibly' not aswered the orig. query?
>
> "Is it possible for ASSP to use "self-signed certs"?"
>
> I suspect the real answer is 'no'. [sorry Charles].
I hope that is not the (permanent) case... it would be sad for assp to
n
>>There is absolutely nothing wrong with a smaller company using
>>self-signed certs, so ASSP should allow for this to work... period...
>Using SSL in a bigger company is more than doing some clicks.
>- create CA and keys
>- cert server
>- key and or certificate deployment
>- centralized ce
On 2011-10-21 8:53 AM, Thomas Eckardt wrote:
> The SSLFailed cache in assp is a DoS prevention - there is no good reason
> to disable it - even not for privat IP's.
Wasn't suggesting it should be disabled, I was suggesting that maybe
refusing to continue to offer STARTTLS/SSL because of one, tem
>wrong with a smaller company using
>>with hundreds or
>> even thousands of clients...
Using SSL in a bigger company is more than doing some clicks.
- create CA and keys
- cert server
- key and or certificate deployment
- centralized cert verification
- centralized directoy servic
On 2011-10-21 7:18 AM, Thomas Eckardt wrote:
>> This is not a reasonable suggestion... think of someone with hundreds or
>> even thousands of clients...
> An more reasonable suggestion for even thousands of clients is to use a
> verificable cert.
Good point, but still only a workaround...
Ther
>This is not a reasonable suggestion... think of someone with hundreds or
>even thousands of clients...
An more reasonable suggestion for even thousands of clients is to use a
verificable cert.
Thomas
Von:Charles Marcus
An: assp-test@lists.sourceforge.net
Datum: 21.10.2011 13:01
B
On 2011-10-21 5:29 AM, Thomas Eckardt wrote:
> Just import your self cert used by assp for SSL to all clients prior to
> connect them via SSL.
This is not a reasonable suggestion... think of someone with hundreds or
even thousands of clients...
--
Best regards,
Charles
-
For testing I use 'jbmail' - same popup - but no timeout or discard by
assp ?
Just import your self cert used by assp for SSL to all clients prior to
connect them via SSL.
Thomas
Von:Doug Lytle
An: ASSP development mailing list
Datum: 21.10.2011 11:24
Betreff:Re: [Assp-te
Thomas Eckardt wrote:
> No , because this does not make sense. If a client make mistakes in SSL ,
> this could lead into stucking workers.
Thanks for pointing out where to clear the cache. The below is what
usually triggers our issue.
The scenario:
Setup Seamonkey/Thunderbird for TLS, send a
In case you're running ASSP on windows and using
the ClamAV scanner, you may be interested in this
update to the ClamAV since it fixes a vulnerability
in the scanning engine; this vulnerability is described
here http://www.securityfocus.com/bid/50183/discuss
The binaries for 32 and 64 bits platfor
Image::OCR::Tesseract is doing the following
BEGIN {
use File::Which 'which';
$WHICH_TESSERACT = which('tesseract');
$WHICH_CONVERT = which('convert');
$WHICH_TESSERACT or die("Is tesseract installed? Cannot find bin path
to tesseract.");
$WHICH_CONVERT or die("Is convert instal
21 matches
Mail list logo
