New options

[Valentin Chopov]

Dan,

thanks for the explanation.
I'm running access.db, DNSBL ant 2 more milters before spamass-milter and
maybe this is why this happen. I'll wait for the fix and try again.
I have a questions regarding the new options -i & -b
-i is very useful and I'm going to use for our block of networks. My
question is, is it safe to add 127.0.0.1 (localhost) into this list. My
understanding is that this will be safe but I need to be sure. The reason
I'm asking this, is because of some .forward scripts in wich case the last
hub is the  localhost.
My 2-nd question is about the option "-b" and how it cooperates with the
"-r". Which mail is forwarded to the bucket - the mail tagged as a spam
from the SpamAssassin or the mail rejected with "-r" ? I personaly preffer
the 2-nd one ;)

Thanks again,
Val



On Thu, 12 Jun 2003, Dan Nelson wrote:

> In the last episode (Jun 12), Valentin Chopov said:
> > today I tried the latest spamass-milter from the CVS and I got a lot
> > of spamd "bad protocol: header error:..." (see below) in the maillog
> > file. What does this mean?
> >
> > Jun 12 15:38:30 milter spamd[68946]: bad protocol: header error: (closed 
> > before headers)
> > Jun 12 15:38:30 milter spamd[14625]: connection from localhost [127.0.0.1] 
> > at port 1625
> > Jun 12 15:38:30 milter spamd[68950]: processing message <address@hidden> 
> > for spamass:1003.
> > Jun 12 15:38:30 milter spamd[14625]: connection from localhost [127.0.0.1] 
> > at port 1626
> > Jun 12 15:38:30 milter spamd[68951]: bad protocol: header error: (closed 
> > before headers)
> > Jun 12 15:38:30 milter spamd[68950]: identified spam (6.0/5.0) for 
> > spamass:1003 in 0.3 seconds, 10774 bytes.
> > Jun 12 15:38:31 milter spamd[14625]: connection from localhost [127.0.0.1] 
> > at port 1627
> > Jun 12 15:38:31 milter spamd[68957]: bad protocol: header error: (closed 
> > before headers)
> > Jun 12 15:38:31 milter spamd[14625]: connection from localhost [127.0.0.1]
>
> That could be due to a modification I did to the milter; it launches
> spamc at MAIL FROM instead of at the first message header.  This means
> that if a client connects and you have an access.db entry or DNSBL
> check that blocks the message, spamc will get started then killed
> before the message gets sent.  I did this so that the milter could send
> the envelope data to spamc (greatly increasing its accuracy).  It looks
> like I'll have to simply store this info temporarily, move the launch
> of spamc back to where it was, and send those lines then.
>
> It shouldn't affect processing of regular email.  I'm not sure why I'm
> not seeing similar entries myself, though.
>
> --
>       Dan Nelson
>       address@hidden
>
>

==
Valentin S. Chopov, CC[ND]P
Sys/Net Admin
SEI Data Inc.
E-Mail: address@hidden
==