You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by martin <ma...@excite.com> on 2006/04/11 11:08:36 UTC
sa missed to scan some of email
using spamassassin-3.0.4-2, spamass-milter-0.3.0, clamav-0.88,
clamav-milter-0.88, sendmail-8.13.1 under FC3. All parts seem work fine, but
found some mails had dropped to mbox directly and seem not scanned by sa (X-Spam
header had not added, spam.log can't found related message). The system (P4,
512M ram) seem not too busy.
another problem is, i found that at spam.log, some message id of message (e.g
"processing message <unknown> for spamass:59") show "unknown" rather than the
related msgid at maillog.
so, how can i sure that message had been scanned by spamassassin and found
related record from spam.log to maillog? thx
Re: sa missed to scan some of email
Posted by martin <ma...@excite.com>.
David B Funk <dbfunk <at> engineering.uiowa.edu> writes:
> Exactly so.
> Usually you can find the related message by matching the time-stamp
> from your maillog to your spamd log. You can also do some detective work,
> eliminate maillog entries that have an incoming msgid (IE one from the
> sending MTA) and just concentrate on those that have a locally added
> msgid.
>
> Dave
>
thx help, it seem ur correct, as based on the timestamp search, most of
unknown msgid at spam.log had a msgid like '200604100343.fsdsrRT3235@myhost.com'
at maillog.
Re: sa missed to scan some of email
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Thu, 13 Apr 2006, martin wrote:
> thx info, that mean that if email don't given msgid when arrived, sendmail
> default will add itself id for this mail and this msgid will not pass to milter?
> So is it no method to find related message from maillog at such case?
Exactly so.
Usually you can find the related message by matching the time-stamp
from your maillog to your spamd log. You can also do some detective work,
eliminate maillog entries that have an incoming msgid (IE one from the
sending MTA) and just concentrate on those that have a locally added
msgid.
Dave
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: sa missed to scan some of email
Posted by martin <ma...@excite.com>.
David B Funk <dbfunk <at> engineering.uiowa.edu> writes:
> Because some messages arrive at your MTA without a msgid to log
> (usually a sign of either a forged message or a brain-damaged
> sending MTA).
>
> The standard sendmail config will add a locally generated msgid to
> such messages but the "milter" interface is handed the message in the
> form that it arrived (IE before any local header adding or modification).
>
> So if the message was sent to you without a msgid, your SA will not log
> any msgid.
>
thx info, that mean that if email don't given msgid when arrived, sendmail
default will add itself id for this mail and this msgid will not pass to milter?
So is it no method to find related message from maillog at such case?
Re: sa missed to scan some of email
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Wed, 12 Apr 2006, martin wrote:
> also, just wonder why at spam.log, some scanned message can't log down msgid
> (which at maillog using)
Because some messages arrive at your MTA without a msgid to log
(usually a sign of either a forged message or a brain-damaged
sending MTA).
The standard sendmail config will add a locally generated msgid to
such messages but the "milter" interface is handed the message in the
form that it arrived (IE before any local header adding or modification).
So if the message was sent to you without a msgid, your SA will not log
any msgid.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: sa missed to scan some of email
Posted by martin <ma...@excite.com>.
Matt Kettler <mkettler_sa <at> comcast.net> writes:
>
> martin wrote:
> > Matt Kettler <mkettler_sa <at> comcast.net> writes:
> >
> >
> >> martin wrote:
> > thx info, that seem the cause, becoz the email att. with a
> >image around 250k in size.
> > just wonder, can this parameter tuneable from config file? And SA had any
> > ruleset to due with a image spamming email?
>
> Normally this is tunable as a parameter to spamc. I'm not sure how this
> works with spamass-milter, but it will be on that end of the system you
> have to tune.
>
just found from man spamc, -s max_size (default: 250k). But will SA spammed by
larger image mail?
also, just wonder why at spam.log, some scanned message can't log down msgid
(which at maillog using)
Re: sa missed to scan some of email
Posted by Matt Kettler <mk...@comcast.net>.
martin wrote:
> Matt Kettler <mkettler_sa <at> comcast.net> writes:
>
>
>> martin wrote:
>>
>>> using spamassassin-3.0.4-2, spamass-milter-0.3.0, clamav-0.88,
>>> clamav-milter-0.88, sendmail-8.13.1 under FC3. All parts seem work fine, but
>>> found some mails had dropped to mbox directly and seem not scanned
>>> by sa (X-Spam header had not added, spam.log can't found related message). >
>>> The system (P4,512M ram) seem not too busy.
>>>
>> How big were the messages? By default most tools bypass scanning of
>> large messages because they bog SA down, and rarely turn out to be spam.
>> By default, spamc does this at 250k, and spamass-milter probably has a
>> similar threshold.
>>
> thx info, that seem the cause, becoz the email att. with a image around 250k
> in size.
> just wonder, can this parameter tuneable from config file? And SA had any
> ruleset to due with a image spamming email?
>
>
Normally this is tunable as a parameter to spamc. I'm not sure how this
works with spamass-milter, but it will be on that end of the system you
have to tune.
Re: sa missed to scan some of email
Posted by martin <ma...@excite.com>.
Matt Kettler <mkettler_sa <at> comcast.net> writes:
>
> martin wrote:
> > using spamassassin-3.0.4-2, spamass-milter-0.3.0, clamav-0.88,
> > clamav-milter-0.88, sendmail-8.13.1 under FC3. All parts seem work fine, but
> > found some mails had dropped to mbox directly and seem not scanned
> > by sa (X-Spam header had not added, spam.log can't found related message). >
> > The system (P4,512M ram) seem not too busy.
> How big were the messages? By default most tools bypass scanning of
> large messages because they bog SA down, and rarely turn out to be spam.
> By default, spamc does this at 250k, and spamass-milter probably has a
> similar threshold.
thx info, that seem the cause, becoz the email att. with a image around 250k
in size.
just wonder, can this parameter tuneable from config file? And SA had any
ruleset to due with a image spamming email?
> > another problem is, i found that at spam.log, some message id of
> > message (e.g "processing message <unknown> for spamass:59") show "unknown"
> > rather than the related msgid at maillog.
> Check the timestamp in the Received: header against the timestamp of the
> log message?
but without the msgid info, how can i related mail at maillog? coz the
spam.log just log spamc its pid, connection and scoring info. I just found the
msgid info related to maillog.
thx again
Re: sa missed to scan some of email
Posted by Matt Kettler <mk...@comcast.net>.
martin wrote:
> using spamassassin-3.0.4-2, spamass-milter-0.3.0, clamav-0.88,
> clamav-milter-0.88, sendmail-8.13.1 under FC3. All parts seem work fine, but
> found some mails had dropped to mbox directly and seem not scanned by sa (X-Spam
> header had not added, spam.log can't found related message). The system (P4,
> 512M ram) seem not too busy.
>
How big were the messages? By default most tools bypass scanning of
large messages because they bog SA down, and rarely turn out to be spam.
By default, spamc does this at 250k, and spamass-milter probably has a
similar threshold.
> another problem is, i found that at spam.log, some message id of message (e.g
> "processing message <unknown> for spamass:59") show "unknown" rather than the
> related msgid at maillog.
> so, how can i sure that message had been scanned by spamassassin and found
> related record from spam.log to maillog? thx
>
Check the timestamp in the Received: header against the timestamp of the
log message?
>
>
>
>