Small anomaly in web interface, plus kicking MySQL

First, while testing for banned attachments I'm sending a
zip file via blat
to my new box, and all is well, but it seems to me that the
wording, etc.,
to release the mail with the banned attachment is quite
congruous with the
type of operation.

The first interface
(http://mx1.zetron.com/maia-mailguard/li
st-cache.php?cache_type=attachment)
says Banned File Attachments, but the radio buttons refer to
spam, which
isn't quite the situation.

It's similar for the web page that you get when you click on
the message
title to view it
(http://mx1.zetron.com/maia-mailguar
d/view.php?id=54&cache_type=attachment)
- the icons also refer to spam.

In both cases, perhaps the number of choices could (should?)
be reduced to
two, and relabeled - something like "delete this
mail" and "release this
mail", and if wanted, the bayes engine could then be
trained based on those
choices.

Very minor really, but thought it worth pointing out.



Second, I ran into a problem today while doing the testing
above - got log
messages about 'MySQL server has gone away'. I STFW, and
found
http://www.maiamailguard.com/maia/wiki/MySQLServerH
asGoneAway, and it looks
like the level of my testing activity wasn't sufficient to
keep MySQL from
timing out. What's a better way of waking up mysqld (better
than, say
rebooting, I blush to confess) if/when this happens again?
Sending more
messages didn't seem to do it. Would 'killall -HUP mysqld'
be appropriate?



Thanks,


Kurt Buff
Lead Network Administrator
Zetron, Inc.
425.820.6363 x463
kbuffzetron.com
PO Box 97004
Redmond, WA 98073


  

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 18, 2007, at 7:48 PM, Kurt Buff wrote:

> First, while testing for banned attachments I'm sending
a zip file  
> via blat
> to my new box, and all is well, but it seems to me that
the  
> wording, etc.,
> to release the mail with the banned attachment is quite
congruous  
> with the
> type of operation.
>
> The first interface
> (
http://mx1.zetron.com/maia-mailguard/list-cache.php? 
> cache_type=attachment)
> says Banned File Attachments, but the radio buttons
refer to spam,  
> which
> isn't quite the situation.
>
> It's similar for the web page that you get when you
click on the  
> message
> title to view it
> (http:/
/mx1.zetron.com/maia-mailguard/view.php? 
> id=54&cache_type=attachment)
> - the icons also refer to spam.
>
> In both cases, perhaps the number of choices could
(should?) be  
> reduced to
> two, and relabeled - something like "delete this
mail" and "release  
> this
> mail", and if wanted, the bayes engine could then
be trained based  
> on those
> choices.

They have very different purposes though.   A separate
delete is  
needed to indicate to maia *not* to learn or report from
this  
message.   As for the other, even if it has a banned
attachment, it  
is still spam isn't it? 



> timing out. What's a better way of waking up mysqld
(better than, say
> rebooting, I blush to confess) if/when this happens
again? Sending  
> more
> messages didn't seem to do it. Would 'killall -HUP
mysqld' be  
> appropriate?

It's not that mysql has gone to sleep so much as it has
dropped the  
connection.  restart amavisd-maia:

amavisd-maia reload


David Morton
Maia Mailguard http://www.maiamailguard
.com
mortondadgrmm.net



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGJsVTUy30ODPkzl0RApZ/AJ9cH/gnz1sbjJJ4VaAv03YL1ELK5ACg
yTWW
3RUEmlIxqvmkdlRvKhBSGAc=
=8d6+
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kurt Buff wrote:
> First, while testing for banned attachments I'm sending
a zip file via blat
> to my new box, and all is well, but it seems to me that
the wording, etc.,
> to release the mail with the banned attachment is quite
congruous with the
> type of operation.
> 
> The first interface
> (http://mx1.zetron.com/maia-mailguard/li
st-cache.php?cache_type=attachment)
> says Banned File Attachments, but the radio buttons
refer to spam, which
> isn't quite the situation.
> 
> It's similar for the web page that you get when you
click on the message
> title to view it
> (http://mx1.zetron.com/maia-mailguar
d/view.php?id=54&cache_type=attachment)
> - the icons also refer to spam.
> 
> In both cases, perhaps the number of choices could
(should?) be reduced to
> two, and relabeled - something like "delete this
mail" and "release this
> mail", and if wanted, the bayes engine could then
be trained based on those
> choices.

That's the way it used to be in earlier versions of
Maia--the only
classification options for banned attachments (and bad
headers) were
effectively "I want this, deliver it" and "I
don't want this, delete
it".  The problem was that many times the items that
fell into the
banned attachment and bad header quarantines were in fact
spam that just
happened to fall into these other bins first (spam-checking
is the most
resource-intensive process, so it gets tested for last), and
people
started asking for a way to reclassify those items as spam
rather than
just delete them.

The "delete" option does just that--it deletes the
item, and that's the
end of it.  No Bayes training gets done, no spam reporting
gets
performed.  That's a safe and reasonable option if you're
not sure what
else to do with it, but in many cases the items with banned
attachments
that you don't want to release are also spam (or worm-spew).
 If you
want to report these items and/or use them for Bayes
training, you need
to reclassify them as "spam", and that's what the
new option allows.

More generally, the question of "what is spam"
becomes relevant in this
discussion.  While Maia tries to distinguish between
"non-spam", "spam",
"viruses/malware", "banned attachments",
and "invalid mail headers", the
fact is these categories are not mutually exclusive.  Maia
tries to save
resources, first of all, by testing the mail first for the
most
dangerous content (i.e. viruses/malware), and from there it
prefers to
order its tests from least to most resource-intensive.  The
first bin
the mail falls into becomes its classification, but that's
by no means
the /only/ category it may belong in.

For instance, it's common for spam to contain broken mail
headers, but
since we test for bad headers before we test for spam, an
item like this
ends up in the bad header quarantine rather than the spam
quarantine.
By providing a "Spam?" option, Maia lets the
recipient reclassify those
items as "spam" when that happens, so that the
item can be properly
processed for Bayes training and spam reporting rather than
just being
deleted.

Likewise, in many cases the banned attachment quarantine
serves as a
second line of defense against new viruses/malware that your
virus
scanners don't yet have signatures to recognize.  Those
zero-day and
zero-hour exploits often slip past the virus scan, but
because they're
typically executable files they get snagged by the banned
attachment
quarantine.  It could be argued, then, that many of those
items should
be reclassified as "viruses".

But stepping back a bit further, even viruses/malware can be
viewed as
forms of spam, in the sense that they're unsolicited bulk
email.  If you
set up a spam-trap account with a brand-new, unadvertised
address (e.g.
dsfkesghdjexample.com), it's only a matter of time before
dictionary-attack probing by harvesting bots finds that
address and adds
it to a list that begins receiving every kind of spam and
virus
imaginable.  Anything and everything that address receives
can be safely
described as spam, regardless of the nature of its content. 
Saying that
something is a "virus", or contains a "banned
attachment", or has
"invalid mail headers" describes characteristics
of the mail's
/content/, whereas calling it "spam" speaks to
whether it was
/solicited/.  Some solicited mail may contain banned
attachments or bad
headers--or even viruses, if you're in the VX business;
that's why we
have quarantine release mechanisms, and why we bother to
categorize the
mail by content type.  But /unsolicited/, bulk
mail--regardless of
content--is spam.


> Second, I ran into a problem today while doing the
testing above - got log
> messages about 'MySQL server has gone away'. I STFW,
and found
> http://www.maiamailguard.com/maia/wiki/MySQLServerH
asGoneAway, and it looks
> like the level of my testing activity wasn't sufficient
to keep MySQL from
> timing out. What's a better way of waking up mysqld
(better than, say
> rebooting, I blush to confess) if/when this happens
again? Sending more
> messages didn't seem to do it. Would 'killall -HUP
mysqld' be appropriate?

As David pointed out, it's not MySQL that needs restarting
in that
instance, it's amavisd-maia.  However, this sort of problem
usually
sorts itself out on its own when the child process suffers
its fatal
error and it gets replaced with a new process (which
establishes a fresh
database connection).  The mail is not lost, it just remains
queued
upstream until the new child spawns, at which point the mail
gets
processed properly.

- --
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGJwjLGmqOER2NHewRAhyJAJ9fCNr3cHRa0R3CP2L46D5mv4pkyACd
Hdjg
1hIv5LZaIZDoG5fb+iYXKNo=
=0Jsg
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users