You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by "Malte S. Stretz" <ms...@gmx.net> on 2004/01/14 02:08:12 UTC
Re: svn commit: rev 6157 - incubator/spamassassin/trunk/spamd
On Wednesday 14 January 2004 01:38 CET Justin Mason wrote:
> mss@apache.org writes:
> > logmsg(
> > ($method eq 'PROCESS' ? "processing" : "checking") .
> >- " message $msgid for $current_user:$>."
> >+ " message $msgid" .
> >+ ($rmsgid ? " ($rmsgid)" : "" ) .
> >+ " for ${current_user}:$>."
> > );
>
> OK -- one problem here -- we shouldn't make that conditional if possible,
> as it will confuse log parsers. Is there a way we can avoid that?
Hmmm... changing the log format will probably break the log parsers anyway,
I should have thoought about that. Maybe that's why I chose to put the
stuff inside brackets intuitively ;-) But it just came into my mind that
the MID is replaced with "(unknown)" if none was given... Hm.
The "problem" is that of course not every mail has a Resent-Message-Id. The
possible solutions I could think of are:
1. The one above ;-)
2. Always write out the (square?) brackets, "unknown" if the message had no
RMID. But that will in 90% of all cases give messages like
processing message <fo...@example.net> [unknown] for you:42.
while only relatively rare cases will look like
processing message <fo...@example.net> [<ba...@example.com>] for you:42.
This might also occur
processing message (unknown) [<fo...@example.com>] for you:42.
While the following message should never happen
processing message (unknown) [unknown] for you:42.
3. Do it like sendmail, log the RMID instead of the MID if one exists. I
don't like that solution because I tend to grep for ^Message-Id: ;-)
4. Don't log the RMID (so don't change anything). But IMO the RMID is
valuable information, especially as sendmail logs only that one (as bug
2900 states.)
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: svn commit: rev 6157 - incubator/spamassassin/trunk/spamd
Posted by "Malte S. Stretz" <ms...@gmx.net>.
On Friday 16 January 2004 01:56 CET Duncan Findlay wrote:
> On Fri, Jan 16, 2004 at 01:46:11AM +0100, Malte S. Stretz wrote:
> > So parsing the log line is more or less like the trace headers: You've
> > got a keyword (currently "message", "aka" (anybody got a better name
> > for this?) and "for") followed by a space and the value. The value is
> > either anything between a matching pair of brackets ("<...>", "(...)",
> > "[...]"), a quoted string or some chars (without a space of course).
> > That should be enough forward-compatible for any reasonable parser. I
> > think I'll put a note about this into some doc.
>
> Someone should update sa-stats.pl accordingly. Malte, would you like
> to? I can do it if you don't want to.
Looks like this is not necessary. sa-stats.pl looks only at the "result"
line, I changed the "announcement" line.
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Re: svn commit: rev 6157 - incubator/spamassassin/trunk/spamd
Posted by Duncan Findlay <du...@debian.org>.
On Fri, Jan 16, 2004 at 01:46:11AM +0100, Malte S. Stretz wrote:
> On Wednesday 14 January 2004 02:08 CET Malte S. Stretz wrote:
> > On Wednesday 14 January 2004 01:38 CET Justin Mason wrote:
> > > OK -- one problem here -- we shouldn't make that conditional if
> > > possible, as it will confuse log parsers. Is there a way we can avoid
> > > that?
> >
> > Hmmm... changing the log format will probably break the log parsers
> > anyway, I should have thoought about that. Maybe that's why I chose to
> > put the stuff inside brackets intuitively ;-) But it just came into my
> > mind that the MID is replaced with "(unknown)" if none was given... Hm.
>
> Ok, I changed this (r6171), it's now
> logmsg = ("processing" | "checking")
> WSP "message" WSP (("<" msgid ">") | "(unknown)")
> [ WSP "aka" WSP "<" resent-msgid ">" ]
> WSP "for" WSP (uname | "(unknown)") ":" uid
> "."
>
> So parsing the log line is more or less like the trace headers: You've got a
> keyword (currently "message", "aka" (anybody got a better name for this?)
> and "for") followed by a space and the value. The value is either anything
> between a matching pair of brackets ("<...>", "(...)", "[...]"), a quoted
> string or some chars (without a space of course). That should be enough
> forward-compatible for any reasonable parser. I think I'll put a note about
> this into some doc.
Someone should update sa-stats.pl accordingly. Malte, would you like
to? I can do it if you don't want to.
--
Duncan Findlay
Re: svn commit: rev 6157 - incubator/spamassassin/trunk/spamd
Posted by "Malte S. Stretz" <ms...@gmx.net>.
On Wednesday 14 January 2004 02:08 CET Malte S. Stretz wrote:
> On Wednesday 14 January 2004 01:38 CET Justin Mason wrote:
> > OK -- one problem here -- we shouldn't make that conditional if
> > possible, as it will confuse log parsers. Is there a way we can avoid
> > that?
>
> Hmmm... changing the log format will probably break the log parsers
> anyway, I should have thoought about that. Maybe that's why I chose to
> put the stuff inside brackets intuitively ;-) But it just came into my
> mind that the MID is replaced with "(unknown)" if none was given... Hm.
Ok, I changed this (r6171), it's now
logmsg = ("processing" | "checking")
WSP "message" WSP (("<" msgid ">") | "(unknown)")
[ WSP "aka" WSP "<" resent-msgid ">" ]
WSP "for" WSP (uname | "(unknown)") ":" uid
"."
So parsing the log line is more or less like the trace headers: You've got a
keyword (currently "message", "aka" (anybody got a better name for this?)
and "for") followed by a space and the value. The value is either anything
between a matching pair of brackets ("<...>", "(...)", "[...]"), a quoted
string or some chars (without a space of course). That should be enough
forward-compatible for any reasonable parser. I think I'll put a note about
this into some doc.
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>