On 2013/01/11 10:45, Kevin A. McGrail wrote:
On 1/11/2013 1:10 PM, John Hardin wrote:
On Fri, 11 Jan 2013, Kevin A. McGrail wrote:
On 1/10/2013 8:46 PM, jdow wrote:
I'd suggest an option similar to the header option.
pass_errors5,18,21,2,6
ignore_errors23,3,19
Spamc currently ha
On 1/11/2013 5:30 PM, Martin Gregorie wrote:
Not according to the manpage: -x and --no-safe-fallback are the same
and can use error codes on the range 64-98
I think that's an error. Read it like this:
If one of the "-x", "-L" or "-C" options are specified, 'safe fallback'
will be disabled, a
On Fri, 2013-01-11 at 16:35 -0500, Kevin A. McGrail wrote:
> As noted, the default is that 0 is the exit code for everything. So you
> should expect 0.
>
OK
> echo "junk line"| spamc; echo $?
>
>
> > echo "junk line"| spamc -x; echo $?1 0
> The error level with -x is could s
On 1/11/2013 4:06 PM, Martin Gregorie wrote:
These options were added through real-world usage scenarios. Removing
them is not something I can support without more study that we aren't
breaking things for people.
All I'm saying is that, because the -E --exitcodes option causes the
default exit
On 11-01-13 19:45, Kevin A. McGrail wrote:
> On 1/11/2013 1:10 PM, John Hardin wrote:
>> On Fri, 11 Jan 2013, Kevin A. McGrail wrote:
>>
>>> On 1/10/2013 8:46 PM, jdow wrote:
I'd suggest an option similar to the header option.
pass_errors5,18,21,2,6
ignore_errors23,3,
On 1/11/2013 1:10 PM, John Hardin wrote:
On Fri, 11 Jan 2013, Kevin A. McGrail wrote:
On 1/10/2013 8:46 PM, jdow wrote:
I'd suggest an option similar to the header option.
pass_errors5,18,21,2,6
ignore_errors23,3,19
Spamc currently has no options file currently so this is a big c
On Fri, 11 Jan 2013, John Hardin wrote:
On Fri, 11 Jan 2013, Kevin A. McGrail wrote:
On 1/10/2013 8:46 PM, jdow wrote:
> I'd suggest an option similar to the header option.
>
> pass_errors5,18,21,2,6
> ignore_errors23,3,19
Spamc currently has no options file currently so thi
On Fri, 11 Jan 2013, Kevin A. McGrail wrote:
On 1/10/2013 8:46 PM, jdow wrote:
I'd suggest an option similar to the header option.
pass_errors5,18,21,2,6
ignore_errors23,3,19
Spamc currently has no options file currently so this is a big change that
someone will need to open a bu
On 1/10/2013 8:46 PM, jdow wrote:
I'd suggest an option similar to the header option.
pass_errors5,18,21,2,6
ignore_errors23,3,19
Those example lines would guarantee errors 5 ,18 ,21 ,2, and 6 would pass
through to the consumer and suppress error notification for 23, 3, and
19.
If the
On 1/11/2013 7:52 AM, Martin Gregorie wrote:
On Thu, 2013-01-10 at 19:49 -0500, Kevin A. McGrail wrote:
Do the scenarios you have identified cover all current usage of spamd?
The only use scenario I mentioned is entirely my own: I make no claims
that anybody else uses spamc in the same way.
I
On Thu, 2013-01-10 at 19:49 -0500, Kevin A. McGrail wrote:
> Do the scenarios you have identified cover all current usage of spamd?
>
The only use scenario I mentioned is entirely my own: I make no claims
that anybody else uses spamc in the same way.
> Specifically things like MTAs that integrate
On 2013/01/10 14:16, Tom Hendrikx wrote:
On 10-01-13 22:43, Kevin A. McGrail wrote:
On 1/10/2013 3:16 PM, Tom Hendrikx wrote:
Since I wrap spamc with a different programming language, I have all
the tools available to handle any error condition: detecting EX_TOOBIG
is however not possible.
I
Do the scenarios you have identified cover all current usage of spamd?
Specifically things like MTAs that integrate spam checking especially midstream
and use these various exit levels?
If we add flexibility that covers more scenarios, great but to me this looks
like you are talking about remo
On Fri, 2013-01-11 at 00:20 +0100, Tom Hendrikx wrote:
> Reviewing my previous suggestion, I mostly agree with the above, and
> meant this too (but with wrong words). I meant to provide the user with
> consistent behaviour for:
>
> 1) always exit with EX_OK, disregarding actual processing outcome
On 10-01-13 17:26, Martin Gregorie wrote:
> On Thu, 2013-01-10 at 15:59 +0100, Tom Hendrikx wrote:
>
>> Since EX_TOOBIG is not really a temporary condition, I'm not sure if
>> that condition and the semantics of -X from the patch actually helps.
>>
>> I'm thinking that it might be better to have a
On Thu, 2013-01-10 at 23:16 +0100, Tom Hendrikx wrote:
> Yes, that is why I was discussing the different options available.
> Adding another 17 switches for different scenarios is ugly, the existing
> 6(!) already look disappointingly overcomplicated to me. So I'd be happy
> to contribute a patch t
On 1/10/2013 5:16 PM, Tom Hendrikx wrote:
On 10-01-13 22:43, Kevin A. McGrail wrote:
On 1/10/2013 3:16 PM, Tom Hendrikx wrote:
Since I wrap spamc with a different programming language, I have all
the tools available to handle any error condition: detecting EX_TOOBIG
is however not possible.
I
On 10-01-13 22:43, Kevin A. McGrail wrote:
> On 1/10/2013 3:16 PM, Tom Hendrikx wrote:
>> Since I wrap spamc with a different programming language, I have all
>> the tools available to handle any error condition: detecting EX_TOOBIG
>> is however not possible.
>
> I don't understand this as I use
On 1/10/2013 3:16 PM, Tom Hendrikx wrote:
Since I wrap spamc with a different programming language, I have all
the tools available to handle any error condition: detecting EX_TOOBIG
is however not possible.
I don't understand this as I use MD to call spamc. Why can't you just
check the file
On 10-01-13 17:51, Kevin A. McGrail wrote:
> On 1/10/2013 11:26 AM, Martin Gregorie wrote:
>> On Thu, 2013-01-10 at 15:59 +0100, Tom Hendrikx wrote:
>>
>>> Since EX_TOOBIG is not really a temporary condition, I'm not sure if
>>> that condition and the semantics of -X from the patch actually helps.
On Thu, 2013-01-10 at 11:51 -0500, Kevin A. McGrail wrote:
> Overall, what we almost need is "Usage scenarios" and appropriate
> parameters. Then we can identify scenarios with missing parameters to
> support.
>
Its been a while since I had to go near my spamc configuration, so I've
just had a
On 1/10/2013 11:26 AM, Martin Gregorie wrote:
On Thu, 2013-01-10 at 15:59 +0100, Tom Hendrikx wrote:
Since EX_TOOBIG is not really a temporary condition, I'm not sure if
that condition and the semantics of -X from the patch actually helps.
I'm thinking that it might be better to have a switch
On Thu, 2013-01-10 at 15:59 +0100, Tom Hendrikx wrote:
> Since EX_TOOBIG is not really a temporary condition, I'm not sure if
> that condition and the semantics of -X from the patch actually helps.
>
> I'm thinking that it might be better to have a switch with the semantics
> 'Change all temporar
On 1/10/2013 9:59 AM, Tom Hendrikx wrote:
Since EX_TOOBIG is not really a temporary condition, I'm not sure if
that condition and the semantics of -X from the patch actually helps.
Overall, I'm not suggesting -X works for you. I'm suggestion you might
need a new switch and you need to figure out
On 1/10/13 2:49 PM, Kevin A. McGrail wrote:
> On 1/10/2013 6:41 AM, Tom Hendrikx wrote:
>> Hi,
>>
>> I was trying to detect various error conditions during spamc execution
>> based on its exit code, which, according to its manpage, should be easy
>> using something -x / --no-safe-fallback.
>>
>> $
On 1/10/2013 6:41 AM, Tom Hendrikx wrote:
Hi,
I was trying to detect various error conditions during spamc execution
based on its exit code, which, according to its manpage, should be easy
using something -x / --no-safe-fallback.
$ spamc --full -no-safe-fallback --port=12345 < message.eml; echo
Hi,
I was trying to detect various error conditions during spamc execution
based on its exit code, which, according to its manpage, should be easy
using something -x / --no-safe-fallback.
$ spamc --full -no-safe-fallback --port=12345 < message.eml; echo $?
This nicely reports an exit code of 69
27 matches
Mail list logo
