Anti-Spam SMTP Proxy Server

ASSP will not call clamd if it is not working, but..
when  ASSP is calling clamd and clamd does not give back control, ASSP
will hang. There is no timeout mechanism to get control back. clamd
must be supervised by other means - watchdog etc. every 5 minutes or
so.

fritz

Fritz Borgstedt wrote:
> ASSP will not call clamd if it is not working, but..
> when  ASSP is calling clamd and clamd does not give back control, ASSP
> will hang. There is no timeout mechanism to get control back. clamd
> must be supervised by other means - watchdog etc. every 5 minutes or
> so.

Ah, good to know.  This explains a lot!  Would it be possible/viable to
have an internal timer?  Perhaps if clamd doesn't return control in a
certain amount of time (5 or 10 minutes?), ASSP will disable clamd
support [, send a warning to the postmaster] and continue?

Watch dog scripts are a feasible work-around, but it seems like a
programmatic control issue exists with ASSP. In the meantime, 1.3.5
seems to run fine with clamd disabled.

On a side note:  This seems to be the issue I was experiencing in our
previously off-line communication.  I wasn't  aware that clamd
*required* a watchdog script like this.  And it wasn't until I allowed
ASSP to stay "hung" for an extended period of time that I noticed that
the clamd.exe process in memory grew to (3) times its normal size in memory!

But, also to note, this clamd issue has only appeared in my environment
since ~1.3.3.8.  I have no way of knowing if its a coincidence or not -
but I do no believe I had a clamd issue before.  So, I'm going to still
see if I can figure out what may have changed - but in the meantime a
watchdog script will get he job done.

Thanks,

assp-test@... schreibt:
>Ah, good to know.  This explains a lot!  Would it be possible/viable
>to
>have an internal timer?  Perhaps if clamd doesn't return control in a
>certain amount of time (5 or 10 minutes?), ASSP will disable clamd
>support [, send a warning to the postmaster] and continue?

 ASSP cannot look at an internal timer and disable clamd if it does
not get back control.

Fritz Borgstedt wrote:
> ASSP will not call clamd if it is not working, but..
> when  ASSP is calling clamd and clamd does not give back control, ASSP
> will hang. There is no timeout mechanism to get control back. clamd
> must be supervised by other means - watchdog etc. every 5 minutes or
> so.

Downside to being single threaded, i looked into this but it is a huge 
pain to do without re-writing the File-Scan-ClamAV module to handle a 
hang after the initial "ping".

Kevin

Kevin wrote:
> Downside to being single threaded, i looked into this but it is a huge 
> pain to do without re-writing the File-Scan-ClamAV module to handle a 
> hang after the initial "ping".
>   
I'm sure this is either going to get me virtually hit - or just ignored 
- but I'll ask anyway.

The brief - I emphasize BRIEF - look I took at File-Scan-ClamAV did not 
impress me.  At the very least, the fact that it only communicates with 
clamd using files instead of streams is a major limiting factor - since 
it precludes the use of clamd on a remote machine (note: since I haven't 
played with this, I have no idea if using streams instead of files is A 
Bad Idea...).  If the TCP socket/stream communication with clamd is as 
good as anything else - I'm sure many people would like to hand that 
processing to a separate server from their mail gateway.  Apart from the 
value of the developers' time - which I heartily appreciate - why NOT 
rewrite this module?  If I had a better working grasp of perl I'd do it 
myself - but I haven't been active in any development in some time - I'm 
just a crummy end-user now.
-- 
Daniel

Jean-Pierre van Melis wrote:
> Although Mr. Espinola puts it rather harsh, I partially agree that
> question are never answered directly. Fritz likes a bit of sarcasm
> (nothing wrong with that), but due to the language barrier this
> doesn't really come off as he intends to.
> 
> I'm in this mailing-list with the best intentions and I assume most
> of us. Fritz could take this a bit more in consideration....

I believe it was answered already.
This is from an email Fritz send on 10/26/2007 at 1:22 PM

Fritz Borgstedt wrote:
> 
> Defaults are kicking in only when ASSP is setup anew. Nothing changes
>  for anybody who do not want to change the serviceproviders.
> 
> This is not the first time it was mentioned, I tested it some months 
> ago for the blacklist, it was excellent. I was planning to add a perl
>  module for queries and forgot it. After  I found out, that it was
> also providing rwl I put in  into my production mix. It was excellent
>  again, which I can see by the way in 10 minutes.
> 
> fritz


Kevin

Lorian Development wrote:
> Am using an LDAP search filter in ASSP of (email=EMAILADDRESS).
>
> What am I missing here? Any of you have any hints / clues / advice /
> guesses?

Use the defaults first.    If that doesn't work, then you have an
authentication or communications problem.

Fritz Borgstedt wrote:
> As usual you do not get me. I did not  test it for 10 minutes. I saw
> after 10 minutes it was excellent.
> I appreciate your scientific approach. Go on with it, I will go with
> mine approach. It is really time  to fork away for me. 

I honestly don't understand why a few simple questions have to devolve
into such petty bickering.  A straight-forward answer would have
terminated the thread immediately.  My questions and concerns were and
still are sincere.

Veiled threats are reprehensible.  You get great/free beta testing for a
product you are making a profit from, with no complaints from us.

> A straight-forward answer 

You consider your initial question a straight-forward question? I do
not.

fritz

Fritz Borgstedt wrote:
> You consider your initial question a straight-forward question? I do
> not.

I would love to dissolve the apparent language barrier that you and I
have.  What is it that I wrote that you did not consider a straight
forward question?  I would like to either explain or correct my phrasing.

Lorian Development wrote:
> Am using ASSP 1.3.5b2 on a test machine to test an alternate email server.
> 
> Trying to do LDAP lookups of email address to have ASSP check for valid 
> recipients.
> 
> Doing an "ldapsearch" in the terminal works fine. Shows this (actual 
> addresses changed):
> 
> test:~ user$ ldapsearch -U postmaster@... -w thepass 
> "(email=person@...)"
> SASL/DIGEST-MD5 authentication started
> SASL username: postmaster@...
> SASL SSF: 0
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope subtree
> # filter: (email=person@...)
> # requesting: ALL
> #
> 
> # person@...
> dn: email=person@...
> email: person@...
> 
> # search result
> search: 5
> result: 0 Success
> text: 1
> 
> # numResponses: 2
> # numEntries: 1
> 
> However, supplying the same parameters to ASSP to do an LDAP lookup 
> fails. The ASSP log shows:
> 
> LDAP search error: 84 -- check ignored
> 

Error 84 LDAP_DECODING_ERROR

ASSP LDAP doesn't support SSL I believe.
Could be wrong, but if it did it would need the SSL modules installed also.

What LDAP server are you querying against?

Kevin

Katip wrote:
> who cares about this ever suckin' blackholes.five-ten-sg.com or 
> bl.csma.biz (never heard before, never tried and never will)? they 
> also stay as defaults on GUI. that's ok for me.

Descriptions and info here:
http://www.asspsmtp.org/wiki/Dnsbl

Kevin

Micheal Espinola Jr wrote:
> I honestly don't understand why a few simple questions have to devolve
> into such petty bickering. 

Welcome to the Internet. :)

Kevin

>Fritz , are you sure of this step  "if you want to use it you must 
>establish an account there" ?
http://my.karmasphere.com/help/faq/queryauthentication
Network queries require authentication. What's that about?
For business and security reasons, Karmasphere prohibits anonymous
queries. Consequently, all network queries are authenticated either
with IP address or username/password credentials.
Which credentials can be used with which query protocols?
	•	IP address authentication: DNS, BQuery, XML/RPC
	•	Username/password authentication: BQuery, XML/RPC
IP address authentication works with every query protocol. In some
cases, where you don't know the IP address of the source of a
reputation query, it may be preferable to use username/password
authentication.
What's IP authentication?
That's when we guess who you are based on the IP address sending the
query. You tell us which IP addresses you query from, and we figure
that any queries from those IP addresses come from you.
IP authentication is the only form of authentication available for DNS
queries. It is also supported for BQueries and XML/RPC queries.
What's username/password authentication?
That's when you encode your assigned username and password into the
BQuery packet itself, in the "auth" field.
When a BQuery shows up with the "auth" field, we don't bother looking
at the IP address.
Some client libraries and plugins use slightly different terminology.
Where they say "Principal", read "username". Where they say
"Credentials", read "password".
Where do I find my credentials?
At the page called [ http://my.karmasphere.com/app/account/auth ]My
IPs and Credentials.
The password is different from the password you use to sign in. It is
a randomly generated string. When you query the system, and use
username/password authentication, you want to use this string, not the
password for signing in.
Why do you require authentication?
In a DDOS scenario, we would be unable to distinguish legitimate
queries from an attack. Also, certain data sources restrict access to
licensed users; authentication allows us to implement access control
accordingly.

Fritz Borgstedt wrote:
>> I would really advise you to make use of the watchdog scripts I wrote
>> for both Clamav as ASSP.
> 
> I put in the GUI a warning: 
> Attention: You must run a watchdog script for ClamAV if you use it
> with ASSP. ASSP will hang, if ClamAV hangs.
> 
> I think we should put your script into the distribution, I overlooked
> it, can you send it to me?

FYI the issue is most likely caused by the setting 'MailFollowURLs' 
being enabled in the clamd.conf file. ( as it was in Michaels case)

Disabling this setting causes clamd to not lockup and hopefully prevents 
this issue.


@ Jean-Pierre: Please either send me your scripts or post them to the 
wiki so we can easily reference them.

@ Fritz: I have a 'watchdog' script that is (somewhat) cross platform 
that I'm prepping for addition to the wiki along with a slight overhaul 
of the ClamAV documentation.

Kevin

assp-test@... schreibt:
>@ Fritz: I have a 'watchdog' script that is (somewhat) cross platform 
>that I'm prepping for addition to the wiki along with a slight
>overhaul 
>of the ClamAV documentation.

Put it in the distribution too. 

fritz

Jean-Pierre van Melis wrote:
> I would really advise you to make use of the watchdog scripts I wrote for both Clamav as ASSP....

Thanks, but I'm on Windows and I'm already watching it by other means.

>I would really advise you to make use of the watchdog scripts I wrote
>for both Clamav as ASSP.

I put in the GUI a warning: 
Attention: You must run a watchdog script for ClamAV if you use it
with ASSP. ASSP will hang, if ClamAV hangs.

I think we should put your script into the distribution, I overlooked
it, can you send it to me?