view release on metacpan or  search on metacpan

share/SpamAssassin/easy_ham_2/00627.31852759f370656c49f987fd28fed691  view on Meta::CPAN

some 1700 times today (between 2 clustered servers) representing a little
over 1% failure rate. In an enterprise level I was hoping for more along the
lines of maybe one-tenth that .....
>
>   It's a network error - That string is not created by
>   Razor Agents.  Its trying to connect and having trouble.
>   1700 times seems abnormally high.  How many successful
>   connections were there in the same timespan?
>

Today was not as bad ... apt.cloudmark was the server du jour and
experienced about 800 "Unable to connect .... Reason: Operation now in
progress" out of some 189,000 "bootup[1]"  or roughly 0.5% -- better than
the 1% before but still a bit higher than I would like. I suspect it is
because a previous timeout from razor-agents has a process id that is being
held by an open milter socket. The process id's cycle, the number comes up
again and the error occurs as a duplicate pid occurs. I will tweak my milter
settings to shorten the total time to allow the socket to live per connect.

>
> ) 2) Related somewhat to question 1: is there (or will there be if
currently not) a way of adjusting the timeout the setting for the
razor-check to await a response from the server it queries? I am running
this as a sendmail milter and adjusting the milter timeouts won't help if
the razor-check script times out first anyway ....
>
>   The timeout is hardcoded to 15 secs.
>   No plans right now to make that an option.
>   You can always edit the source - Core.pm.  :)

In looking at Core.pm I find a couple possible places where that code might
be. Is it:
    my $select = new IO::Select ($sock);
    my @handles = $select->can_read (15);
    if ($handles[0]) {
        $self->log (8,"Connection established");
        my $greeting = <$sock>;
        # $sock->autoflush; # this is on by default as of IO::Socket 1.18
        $self->{sock} = $sock;
        $self->{connected_to} = $server;
        $self->{select} = $select;
        $self->log(4,"$server >> ". length($greeting) ." server greeting:
$greeting");

        return 1 if $params{discovery_server};
        unless ($self->parse_greeting($greeting) ) {
            $self->nextserver or return $self->errprefix("connect2");
            return $self->connect;
        }
        return 1;
    } else {
        $self->log (3, "Timed out (15 sec) while reading from
$self->{s}->{ip}.");
??????
or
    unless ($sock) {
        $sock = IO::Socket::INET->new(
                            PeerAddr => $server,
                            PeerPort => $port,
                            Proto    => 'tcp',
                            Timeout  => 20,
                     );
        unless ( $sock ) {
            $self->log (3,"Unable to connect to $server:$port; Reason:
$!.");
            return if $params{discovery_server};
            $self->nextserver or return $self->errprefix("connect1");
            return $self->connect;
        }
    }
??????
[of course the latter reflects a differenct timeout setting altogether - one
part for proxy, the other for non-proxy]

>
>
> ) 3) What are the plans for fire.cloudmark, apt.cloudmark, ubik.cloudmark?
It seems that we have all these catalogue servers yet a good portion of the
time, only one is available or the last discovery ends up only listing one
(currently honor.cloudmark) in the cataloge.lst file.
>
>   The system is designed so servers can be added and
>   subtracted without the clients caring - if the razor
>   client can't connect to a server, it re-discovers, getting
>   all currently available servers and stores results locally.
>

I changed the default discovery period to every 12 hours in order to
compensate for the recent sporadic nature of the servers' availability (I
realize that the issue was related to syncing and server upgrades .... but I
might as well play it safe for a while).

>
> ) 4) What would be the implications/requirements/caveats of hosting a
catalogue server or, at the minimum, a caching server (similar to the way
mail-abuse.org, for example, does dns zone transfers of its rbl list -- I
realize that this is a completely different mechanism, but you get the point
I am driving at here). I realize that there is an issue of polluting the
catalogue but perhpas there could be some way of certifying a catalogue
server? What type of bandwidth considerations are we looking at here? (It is
just the signatures that are actually transferred across the pipes, is it
not?)
>
>   We are looking into releasing caching catalogue servers
>   for those besides us to use.

If I can be of help or if you have details about to participate in this
portion (caching or catalogueing), please let me know.

>
>
> ) It really looks like there is a great potential here for a very workable
tool and if I can get some of these issues addressed or can even be of some
assistance, all the better .....
> )
> ) Sven Willenberger
> ) Systems Administration
> ) Delmarva Online, Inc.
>
>
>   Thanks!