You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Tom Hendrikx <to...@whyscream.net> on 2013/01/10 12:41:06 UTC
spamc exit code for exceeding max size
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 (where nothing is actually
listing on that port).
However, checking for maxsize issues does not work:
$ spamc --full --no-safe-fallback --max-size=10 < message.eml; echo $?
This reports an exit code of 0. Checking the source code [1] tells me
that the exit code is suppressed on purpose, but the bugreport
referenced in the source code [2] doesn't explain why EX_TOOBIG should
be suppressed.
So either the code has an issue, or the man page (as EX_TOOBIG can never
happen but it is documented). I'd rather see the code fixed, unless
there is a compelling reason not too which I failed to understand.
Kind regards,
Tom
[1]
http://svn.apache.org/viewvc/spamassassin/trunk/spamc/spamc.c?view=markup (line
1050)
[2] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5412
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 the conditions/patch that
work for you. Then open a ticket with the issue and the patch and it
has a chance of getting into the code. I can't promise it will be
accepted but at the very worst it will give you the framework to
maintain your own local patch.
Regards,
KAM
Re: spamc exit code for exceeding max size
Posted by Martin Gregorie <ma...@gregorie.org>.
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 look and here's what I've found. Consider the following to be
my "Usage scenario"
As a low volume user, I get incoming mail from my ISP's mail server with
getmail, which pipes it through spamc and then spamkiller, a locally
written program. Spamkiller looks at the X-Spam-Flag header and
quarantines messages with "YES" in this header. All other messages are
passed to postfix.sendmail for delivery to the Postfix MTA.
Outbound mail is sent via the local Postfix, which delivers it to my
ISP's MTA via SMTP. It also sends a copy to my mail archive, which acts
as a whitelisting database (any address I've sent mail to gets
whitelisted).
I've been running spamc with all options defaulted. I notice that when
spamc is run this way all messages passed to it are always written out
on stdout regardless of the exit status. The MDA script used by getmail
ignores the spamc exit codes: as a result all non-spam messages are sent
to Postfix, even those that exceed the size limit or are received when
the whitelisting DB is offline to be backed up. This is exactly what I
need.
Nonetheless, I've just added the --exitcode option to spamc. I don't
expect it to have any effect: rather, its a reminder to me to look at
spamc exit code handling if I ever need to change the MDA script.
> Or perhaps spamc needs a configuration file to set any and all of the
> possible exit levels which would alleviate the need for all these
> switches perhaps?
>
It already has a config file, though this is just another place to put
the various option settings.
> Unfortunately, the current way spamc exits meets all of my needs so I'm
> not sure of the scenarios otherwise needed.
>
Same here.
Martin
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 don't understand this as I use MD to call spamc. Why can't you just
>> check the file size prior to calling sa?
> Because I don't want to maintain the maxsize in two places? Because I
> still want to catch the error when someone lowers only the maxsize
> settings because he did not RTFM?
In my code, I maintain one variable for the maxsize. Here's pseudo code:
$params{'max_size_email_for_scanning'} = 512KB;
if (-s $file <= $params{'max_size_email_for_scanning'}) {
spamc -s $params{'max_size_email_for_scanning'}
}
In short, I've never needed or even seen the EX_TOOBIG error because
I've never called spamc with a file bigger than the scansize.
> So I'd be happy to contribute a patch that contains an elegant
> solution, but not another kludge that fixes only my stupid little
> issue but makes matters worse in the long run. As said, creating a
> kludge in the surrounding code is just as ugly, but much faster. -- Tom
Either way, your time is running out. I hope to build pre2 if I can get
all the xt test errors fixed tonight. After 3.4.0 is pushed out, the
ability to majorly revamp params for anything is much limited because
3.4.0 is a major release so there can be changes to parameters, APIs, etc.
Regards,
KAM
Re: spamc exit code for exceeding max size
Posted by Martin Gregorie <ma...@gregorie.org>.
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 that contains an elegant solution, but not another
> kludge that fixes only my stupid little issue but makes matters worse in
> the long run. As said, creating a kludge in the surrounding code is just
> as ugly, but much faster.
>
I don't think its as bad as you think. The major problem is that, not
only is the set of the set of exit codes to be used configurable, but
there is also a mandatory link to to some of the processing options. To
me that's icky. However, I can't see why the processing options can't be
entirely separated from the exit code set selection. Apart from making
the code cleaner, it should also add flexibility.
The set of processing options with hard wired exit code linkages are
--check -d and --learntype
There only two sets of exit codes, which are directly controlled by
--exitcode and --no-safe-fallback. I can see a good reason for keeping
these, but having two options seems unnecessary. Besides, --exitcode is
a horrible option name since it tells us very little. You could make the
set controlled by --exitcode the default, remove the option and retain
--no-safe-fallback to select fine-grained exit codes.
I haven't looked at the spamc code since 3.2.25, but IIRC it was pretty
straight-forward. I don't recall any show-stopping reasons why the
hard-wired exit code linkages shouldn't be broken.
Martin
Re: spamc exit code for exceeding max size
Posted by Tom Hendrikx <to...@whyscream.net>.
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_errors 5,18,21,2,6
>>>> ignore_errors 23,3,19
>>>
>>> Spamc currently has no options file currently so this is a big change
>>> that someone will need to open a bug and likely spearhead with some
>>> draft patches. Otherwise, I haven't yet seen the value of this overhaul.
>>
>> how about:
>>
>> spamc --pass_errors "5,18,21,2,6" -ignore_errors "23,3,19" ...
>>
>> ?
>>
>>
> Perhaps but shouldn't it tie into EX_TOOBIG and not a number?
>
> I think this has merit especially if we can say:
>
> used to use -x? Use --pass_errors="EX_.., EX_..." and give examples of
> old to new.
While this allows for maximum flexibility (great), I'd still nitpick on
the fact that anyone technically advanced enough to know which errors
can be safely configured to be passed to the caller (and handle them
there), would also be capable to write a simple shell wrapper doing the
same. Ergo, a simple option that passes everything would do the same.
Risking the option I'm sounding a bit like a broken record, I'm just
trying to advocate the KISS principle here: all the extra options look
like feature creep to me when a clean -x implementation is available.
I started on a patch for trunk yesterday, but it's not working yet. As
my C skills are not very good, adding something like the --pass-errors=
would be out of my league.
--
Tom
Re: spamc exit code for exceeding max size
Posted by jdow <jd...@earthlink.net>.
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_errors 5,18,21,2,6
>>>> ignore_errors 23,3,19
>>>
>>> Spamc currently has no options file currently so this is a big change that
>>> someone will need to open a bug and likely spearhead with some draft patches.
>>> Otherwise, I haven't yet seen the value of this overhaul.
>>
>> how about:
>>
>> spamc --pass_errors "5,18,21,2,6" -ignore_errors "23,3,19" ...
>>
>> ?
>>
>>
> Perhaps but shouldn't it tie into EX_TOOBIG and not a number?
>
> I think this has merit especially if we can say:
>
> used to use -x? Use --pass_errors="EX_.., EX_..." and give examples of old to
> new.
>
> regards,
> KAM
Just off hand I figure it ought to take both so you don't need to
carry a translation table in your head. The "kill" command is a good
model for this.
{^_^}
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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_errors 5,18,21,2,6
>>> ignore_errors 23,3,19
>>
>> Spamc currently has no options file currently so this is a big change
>> that someone will need to open a bug and likely spearhead with some
>> draft patches. Otherwise, I haven't yet seen the value of this overhaul.
>
> how about:
>
> spamc --pass_errors "5,18,21,2,6" -ignore_errors "23,3,19" ...
>
> ?
>
>
Perhaps but shouldn't it tie into EX_TOOBIG and not a number?
I think this has merit especially if we can say:
used to use -x? Use --pass_errors="EX_.., EX_..." and give examples of
old to new.
regards,
KAM
Re: spamc exit code for exceeding max size
Posted by John Hardin <jh...@impsec.org>.
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_errors 5,18,21,2,6
>> > ignore_errors 23,3,19
>>
>> Spamc currently has no options file currently so this is a big change that
>> someone will need to open a bug and likely spearhead with some draft
>> patches. Otherwise, I haven't yet seen the value of this overhaul.
>
> how about:
>
> spamc --pass_errors "5,18,21,2,6" -ignore_errors "23,3,19" ...
Oops:
spamc --pass_errors "5,18,21,2,6" --ignore_errors "23,3,19" ...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Maxim IV: Close air support covereth a multitude of sins.
-----------------------------------------------------------------------
6 days until Benjamin Franklin's 307th Birthday
Re: spamc exit code for exceeding max size
Posted by John Hardin <jh...@impsec.org>.
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_errors 5,18,21,2,6
>> ignore_errors 23,3,19
>
> Spamc currently has no options file currently so this is a big change that
> someone will need to open a bug and likely spearhead with some draft patches.
> Otherwise, I haven't yet seen the value of this overhaul.
how about:
spamc --pass_errors "5,18,21,2,6" -ignore_errors "23,3,19" ...
?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Maxim IV: Close air support covereth a multitude of sins.
-----------------------------------------------------------------------
6 days until Benjamin Franklin's 307th Birthday
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 1/10/2013 8:46 PM, jdow wrote:
> I'd suggest an option similar to the header option.
>
> pass_errors 5,18,21,2,6
> ignore_errors 23,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 lines are not in any config file then today's current behavior
> would be exhibited.
>
> It is simply expandable into the future if there is some interesting
> reason for having to pass or ignore errors in a different manner than
> the default manner.
Spamc currently has no options file currently so this is a big change
that someone will need to open a bug and likely spearhead with some
draft patches. Otherwise, I haven't yet seen the value of this overhaul.
Re: spamc exit code for exceeding max size
Posted by jdow <jd...@earthlink.net>.
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 don't understand this as I use MD to call spamc. Why can't you just
>> check the file size prior to calling sa?
>
> Because I don't want to maintain the maxsize in two places? Because I
> still want to catch the error when someone lowers only the maxsize
> settings because he did not RTFM?
>
> I want to handle the error as spamc throws it at me, implementing a
> second safety net is a waste. Given enough development time and cpu
> cycles, I could safeguard against all possible errors that spamc is able
> to return before I actually execute it, but it would be easier to just
> build a new version of spamc in stead.
>
>>
>> Otherwise, like I said, now's the time to open a bug and work on a patch
>> if you are interested in this.
>
> 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 that contains an elegant solution, but not another
> kludge that fixes only my stupid little issue but makes matters worse in
> the long run. As said, creating a kludge in the surrounding code is just
> as ugly, but much faster.
>
> --
> Tom
I'd suggest an option similar to the header option.
pass_errors 5,18,21,2,6
ignore_errors 23,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 lines are not in any config file then today's current behavior
would be exhibited.
It is simply expandable into the future if there is some interesting
reason for having to pass or ignore errors in a different manner than
the default manner.
{^_^}
Re: spamc exit code for exceeding max size
Posted by Tom Hendrikx <to...@whyscream.net>.
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 MD to call spamc. Why can't you just
> check the file size prior to calling sa?
Because I don't want to maintain the maxsize in two places? Because I
still want to catch the error when someone lowers only the maxsize
settings because he did not RTFM?
I want to handle the error as spamc throws it at me, implementing a
second safety net is a waste. Given enough development time and cpu
cycles, I could safeguard against all possible errors that spamc is able
to return before I actually execute it, but it would be easier to just
build a new version of spamc in stead.
>
> Otherwise, like I said, now's the time to open a bug and work on a patch
> if you are interested in this.
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 that contains an elegant solution, but not another
kludge that fixes only my stupid little issue but makes matters worse in
the long run. As said, creating a kludge in the surrounding code is just
as ugly, but much faster.
--
Tom
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 size prior to calling sa?
Otherwise, like I said, now's the time to open a bug and work on a patch
if you are interested in this.
Regards,
KAM
Re: spamc exit code for exceeding max size
Posted by Tom Hendrikx <to...@whyscream.net>.
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.
>>>
>>> I'm thinking that it might be better to have a switch with the semantics
>>> 'Change all temporary errors to EX_TEMPFAIL' which would change most of
>>> the named exit codes in the man page into EX_TEMPFAIL, except when the
>>> message should be simply passed through (effectively only EX_TOOBIG).
>>>
>>> This would do for integration as documented in the bug:
>>> - spamc without special switch: exitcode indicates succes (0) or
>>> failure (1)
>>> - spamc -<new>: exitcode indicates succes (0), failure (1) or retry (75)
>>> - spamc -x: always raw exitcode
>>>
>>> But I guess it depends largely on the setup and the sysadmins opinion
>>> whether 'addressee unknown' is a temporary condition, so there is
>>> another exception to be handled...
>>>
>> It seems to me that the set of replies as currently linked to spamc
>> options would do a near-prefect job with two minor tweaks:
>>
>> (1) remove the EX_TOOBIG kludge from --no-safe-fallback so it does
>> what it says on ythe tin
>>
>> (2) use the --exitcode behavior as the default in place of
>> --no-safe-fallback
>>
>> The manpage needs to say that --no-safe-fallback should be used during
>> testing and explain that, although it catches more errors, it should
>> not be used for production because it treats EX_TOOBIG as an error
>> rather than a warning.
>>
>> Personal opinion: the best approach would be to stick with
>> --no-safe-fallback after removing the EX_TOOBIG kludge and for the
>> calling script/code to make more detailed exit code checks. However, I
>> also realise this change would break a lot of installations, which is
>> why I'm suggesting making --exitcode the default in place of
>> --no-safe-fallback.
> Ignore breaking things because with a major version like 3.4.0, if this
> is the "right" thing to do, it's completely feasible and best to do
> right now with no delay.
>
> Overall, what we almost need is "Usage scenarios" and appropriate
> parameters. Then we can identify scenarios with missing parameters to
> support.
>
> Or perhaps spamc needs a configuration file to set any and all of the
> possible exit levels which would alleviate the need for all these
> switches perhaps?
The reason why I proposed a new blanket option was because there are
already too many exit code switches to my liking, so I'd rather not
introduce a new single use option: my proposal would fit most
implementations and would be extensible when new errors should be added
(but I did not spend hours to get all usage scenarios imagined). I know
see that I already missed the default 'always exit with EX_OK' scenario...
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. For a short term solution I added my own kludge to
fix the existing EX_TOOBIG kludge in spamc: I added '-l' to my spamc
arguments, and apply regexp on stderr to catch the 'size exceeded'
condition now. This is my usage scenario: if someone wants all error
conditions, give him the tools without kludges (and the ability to shoot
himself in the foot if he screws up :>).
--
Tom
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 with the semantics
>> 'Change all temporary errors to EX_TEMPFAIL' which would change most of
>> the named exit codes in the man page into EX_TEMPFAIL, except when the
>> message should be simply passed through (effectively only EX_TOOBIG).
>>
>> This would do for integration as documented in the bug:
>> - spamc without special switch: exitcode indicates succes (0) or failure (1)
>> - spamc -<new>: exitcode indicates succes (0), failure (1) or retry (75)
>> - spamc -x: always raw exitcode
>>
>> But I guess it depends largely on the setup and the sysadmins opinion
>> whether 'addressee unknown' is a temporary condition, so there is
>> another exception to be handled...
>>
> It seems to me that the set of replies as currently linked to spamc
> options would do a near-prefect job with two minor tweaks:
>
> (1) remove the EX_TOOBIG kludge from --no-safe-fallback so it does
> what it says on ythe tin
>
> (2) use the --exitcode behavior as the default in place of
> --no-safe-fallback
>
> The manpage needs to say that --no-safe-fallback should be used during
> testing and explain that, although it catches more errors, it should
> not be used for production because it treats EX_TOOBIG as an error
> rather than a warning.
>
> Personal opinion: the best approach would be to stick with
> --no-safe-fallback after removing the EX_TOOBIG kludge and for the
> calling script/code to make more detailed exit code checks. However, I
> also realise this change would break a lot of installations, which is
> why I'm suggesting making --exitcode the default in place of
> --no-safe-fallback.
Ignore breaking things because with a major version like 3.4.0, if this
is the "right" thing to do, it's completely feasible and best to do
right now with no delay.
Overall, what we almost need is "Usage scenarios" and appropriate
parameters. Then we can identify scenarios with missing parameters to
support.
Or perhaps spamc needs a configuration file to set any and all of the
possible exit levels which would alleviate the need for all these
switches perhaps?
Unfortunately, the current way spamc exits meets all of my needs so I'm
not sure of the scenarios otherwise needed.
regards,
KAM
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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, and certain error conditions related to communication
between spamc and spamd will result in an error code.
In other words, the error codes are limited...
> Could I also suggest that the error codes used by -c, -C, -E and -L be
> added to the "Error Codes" section. Its incomplete otherwise.
I think there could be more detail here, yes but it's not a hold up for
3.4.0
>>> echo "junk line"| spamc -E -x; echo $? 64 1
>> Possibly but I don't see a check for it in the code.
>>
> Seems like a bug to me unless -E and -x are additive, in which case it
> should be documented.
Could be right but unless someone's actually having a problem, it's
REALLY low priority to me.
> What is this -X of which you speak? '-x' is documented but there is no
> mention of -X anywhere in either manpage or help display.
It was added to trunk.
> BTW, there is a configuration file documented as being already
> available: see the -F --config option and the "CONFIGURATION FILE"
> section in the spamc manpage.
Neat. Never used that feature! Looks like it just an alternate way not
to define everything on the command line.
Regards,
KAM
Re: spamc exit code for exceeding max size
Posted by Martin Gregorie <ma...@gregorie.org>.
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 scan/couldn't scan.
>
Not according to the manpage: -x and --no-safe-fallback are the same and
can use error codes on the range 64-98
> Add -c to get the
> error level you are expecting, I beleive.
>
According to the manpage: -c and -E should use the same exit codes.
> I've added a return to the spamc.pod to clarify this with error levels
> because the sentence " If one of the "-x", "-L" or "-C" options are
> specified, 'safe fallback' will be disabled, and certain error
> conditions related to communication between spamc and spamd will result
> in an error code. " should end that paragraph and the "The exit codes
> used..." applies to all of the options.
>
Could I also suggest that the error codes used by -c, -C, -E and -L be
added to the "Error Codes" section. Its incomplete otherwise.
> > echo "junk line"| spamc -E -x; echo $? 64 1
> Possibly but I don't see a check for it in the code.
>
Seems like a bug to me unless -E and -x are additive, in which case it
should be documented.
> They set different
> options so it likely can work together albeit perhaps not that useful.
> I added code for -X to make sure that -x was set first because -x -X is
> handled differently than -X -x. Perhaps something is needed for this
> but overall we don't have many complaints this is a real world issue.
>
What is this -X of which you speak? '-x' is documented but there is no
mention of -X anywhere in either manpage or help display.
BTW, there is a configuration file documented as being already
available: see the -F --config option and the "CONFIGURATION FILE"
section in the spamc manpage.
> > If you want this bugged, can I have bugzilla access, please?
> >
> You simply need to open your own account. Nothing should stop you from
> signing up at https://issues.apache.org/SpamAssassin/createaccount.cgi
>
Noted. Thanks.
Martin
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 codes to be used (1=spam, 0=everything else) it isn't
> needed.
>
> ======
> As a quick check, I ran the following set of tests with spamd running:
>
> Test Exit expected Exit seen
> ===================================== ============= =========
> echo "junk line"| spamc; echo $? 1 0
As noted, the default is that 0 is the exit code for everything. So you
should expect 0.
echo "junk line"| spamc; echo $?
> echo "junk line"| spamc -x; echo $? 1 0
The error level with -x is could scan/couldn't scan. Add -c to get the
error level you are expecting, I beleive.
I've added a return to the spamc.pod to clarify this with error levels
because the sentence " If one of the "-x", "-L" or "-C" options are
specified, 'safe fallback' will be disabled, and certain error
conditions related to communication between spamc and spamd will result
in an error code. " should end that paragraph and the "The exit codes
used..." applies to all of the options.
> echo "junk line"| spamc -E -x; echo $? 64 1
Possibly but I don't see a check for it in the code. They set different
options so it likely can work together albeit perhaps not that useful.
I added code for -X to make sure that -x was set first because -x -X is
handled differently than -X -x. Perhaps something is needed for this
but overall we don't have many complaints this is a real world issue.
> If you want this bugged, can I have bugzilla access, please?
>
You simply need to open your own account. Nothing should stop you from
signing up at https://issues.apache.org/SpamAssassin/createaccount.cgi
regards,
KAM<
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 understand that but realize that this makes taking any overarching
input from you fairly difficult to accept.
> Specifically things like MTAs that integrate spam checking especially
> midstream and use these various exit levels?
>
> Now for my suggested option changes: these were written on the
> assumption that, with the exception of the EX-TOOBIG kludge when -x is
> in force and which is now known to be undocumented,
I've addded to the docs that * The EX_TOOBIG error level is never used.
If spamc receives a message that is
too big, the exit code will be 0.
> the spamc manpage is
> a true description of the effect of the various options. I haven't
> attempted to compare the current code with the current manpage. If there
> are discrepancies, then the code and manpage should be synchronised
> before 3.4.0 is released.
I'm not aware of any problems but happy to fix them if you note any
other issues.
> Another deficiency is that the manpage doesn't say whether -E or -x is
> the default though it is implied by the -x option description.
It uses neither: By default, spamc will use the 'safe fallback' error
recovery method.
See the first section under EXIT CODES.
>
>> If we add flexibility that covers more scenarios, great but to me this
>> looks like you are talking about removing options that i can only
>> assume are used. Am i wrong?
>>
> With all due respect, yes. I'm suggesting that the default set of exit
> codes for all processing options should be what -E --exitcode currently
> defines and that -x (possibly renamed) overrides that just as it does at
> present. Taking this view makes the -E --exitcode option redundant and,
> indeed, confusing so its would be better to document this as the default
> set of exit codes and remove the -E --exitcode option. This does not
> constrain spamc flexibility or remove any current functionality.
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.
Regards,
KAM
Re: spamc exit code for exceeding max size
Posted by Martin Gregorie <ma...@gregorie.org>.
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 spam checking especially
> midstream and use these various exit levels?
>
Now for my suggested option changes: these were written on the
assumption that, with the exception of the EX-TOOBIG kludge when -x is
in force and which is now known to be undocumented, the spamc manpage is
a true description of the effect of the various options. I haven't
attempted to compare the current code with the current manpage. If there
are discrepancies, then the code and manpage should be synchronised
before 3.4.0 is released.
That said, the manpage says there are only two ways in which exit codes
are generated:
-x --no-safe-fallback which should, were the kludge to be removed,
output the complete set of exit codes and which will return the
EX-TOOBIG code (98)
-E --exitcode causes only two exit codes to be returned: 1 for spam and
0 for all other conditions. As a side effect, -c --check implies -E
A further side effect, which I mis-described earlier, is that if the -x
--no-safe-fallback option is in force, and the -d option's host resolves
to multiple IPs, only the first address will be tried because -x
prevents the fail-over from being tried.
Another deficiency is that the manpage doesn't say whether -E or -x is
the default though it is implied by the -x option description.
> If we add flexibility that covers more scenarios, great but to me this
> looks like you are talking about removing options that i can only
> assume are used. Am i wrong?
>
With all due respect, yes. I'm suggesting that the default set of exit
codes for all processing options should be what -E --exitcode currently
defines and that -x (possibly renamed) overrides that just as it does at
present. Taking this view makes the -E --exitcode option redundant and,
indeed, confusing so its would be better to document this as the default
set of exit codes and remove the -E --exitcode option. This does not
constrain spamc flexibility or remove any current functionality.
HTH
Martin
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 removing options that i can only assume are used. Am i wrong?
Regards,
KAM
Martin Gregorie <ma...@gregorie.org> wrote:
>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 or
>> errors (current default behaviour)
>>
>> 2) indicate ham/spam difference with EX_OK/EX_FAILURE (current
>> --exitcode behaviour)
>>
>> 3) all power (and responsibility) to the user (current
>> --no-safe-fallback behaviour, but with kludges removed)
>>
>Yes, that sounds like something I'd do.
>
>> The recently added -X switch would also be too exotic for me, and be
>> removed again.
>>
>I'd go with 1=SPAM, 0=HAM plus checks skipped all reasons (i.e.
>--exitcode) for the default because it seems to work well in practice
>for production running and --no-fail-fallback (renamed to something
>like
>--extended-exit-codes / -x for testing as opposed to production
>operation).
>
>> Final result: simple, no
>> unexpected kludges, common scenarios facilitated out of the box, all
>> exotic scenarios available to the brave.
>>
>I think we're in agreement - see my last on the subject. As KAM says
>there's a window for changing options and option names in preparation
>for 3.4.0 I say have at it and good luck.
>
>
>Cheers,
>Martin
Re: spamc exit code for exceeding max size
Posted by Martin Gregorie <ma...@gregorie.org>.
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 or
> errors (current default behaviour)
>
> 2) indicate ham/spam difference with EX_OK/EX_FAILURE (current
> --exitcode behaviour)
>
> 3) all power (and responsibility) to the user (current
> --no-safe-fallback behaviour, but with kludges removed)
>
Yes, that sounds like something I'd do.
> The recently added -X switch would also be too exotic for me, and be
> removed again.
>
I'd go with 1=SPAM, 0=HAM plus checks skipped all reasons (i.e.
--exitcode) for the default because it seems to work well in practice
for production running and --no-fail-fallback (renamed to something like
--extended-exit-codes / -x for testing as opposed to production
operation).
> Final result: simple, no
> unexpected kludges, common scenarios facilitated out of the box, all
> exotic scenarios available to the brave.
>
I think we're in agreement - see my last on the subject. As KAM says
there's a window for changing options and option names in preparation
for 3.4.0 I say have at it and good luck.
Cheers,
Martin
Re: spamc exit code for exceeding max size
Posted by Tom Hendrikx <to...@whyscream.net>.
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 switch with the semantics
>> 'Change all temporary errors to EX_TEMPFAIL' which would change most of
>> the named exit codes in the man page into EX_TEMPFAIL, except when the
>> message should be simply passed through (effectively only EX_TOOBIG).
>>
>> This would do for integration as documented in the bug:
>> - spamc without special switch: exitcode indicates succes (0) or failure (1)
>> - spamc -<new>: exitcode indicates succes (0), failure (1) or retry (75)
>> - spamc -x: always raw exitcode
>>
>> But I guess it depends largely on the setup and the sysadmins opinion
>> whether 'addressee unknown' is a temporary condition, so there is
>> another exception to be handled...
>>
> It seems to me that the set of replies as currently linked to spamc
> options would do a near-prefect job with two minor tweaks:
>
> (1) remove the EX_TOOBIG kludge from --no-safe-fallback so it does
> what it says on ythe tin
>
> (2) use the --exitcode behavior as the default in place of
> --no-safe-fallback
>
> The manpage needs to say that --no-safe-fallback should be used during
> testing and explain that, although it catches more errors, it should
> not be used for production because it treats EX_TOOBIG as an error
> rather than a warning.
>
> Personal opinion: the best approach would be to stick with
> --no-safe-fallback after removing the EX_TOOBIG kludge and for the
> calling script/code to make more detailed exit code checks. However, I
> also realise this change would break a lot of installations, which is
> why I'm suggesting making --exitcode the default in place of
> --no-safe-fallback.
>
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 or
errors (current default behaviour)
2) indicate ham/spam difference with EX_OK/EX_FAILURE (current
--exitcode behaviour)
3) all power (and responsibility) to the user (current
--no-safe-fallback behaviour, but with kludges removed)
In my original proposal:
4) indicate ham/spam/failure with EX_OK/EX_FAILURE/EX_TEMPFAIL, use case
based on introduction of the -X switch, but generalised for all other
tempfail-alike exit codes too (i.e. nearly all error conditions except
EX_TOOBIG).
The first 3 seem very common, the last one is a more exotic scenario.
The question is: where is the line you draw between common and exotic,
and do you introduce extra complexity for that? In fact all exotic
scenarios could be implemented easily by wrapping 'spamc
--no-safe-fallback' with a 4-line shell script that evaluates and
manipulates the exitcode, but only if spamc would consistently expose
all exit codes.
Exit code manipulation for -c should ultimately be removed for
simplicity: the user can easily combine it with -E (as documented in the
man page), and exit code manipulation is then separated from presented
output (i.e. you can easily make all of the above switches
non-combinable, avoiding the crap from
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5412).
The recently added -X switch would also be too exotic for me, and be
removed again. I would also not implement a variant as described in 4)
above, also discarding as too exotic. Final result: simple, no
unexpected kludges, common scenarios facilitated out of the box, all
exotic scenarios available to the brave.
Kind regards,
Tom
Re: spamc exit code for exceeding max size
Posted by Martin Gregorie <ma...@gregorie.org>.
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 temporary errors to EX_TEMPFAIL' which would change most of
> the named exit codes in the man page into EX_TEMPFAIL, except when the
> message should be simply passed through (effectively only EX_TOOBIG).
>
> This would do for integration as documented in the bug:
> - spamc without special switch: exitcode indicates succes (0) or failure (1)
> - spamc -<new>: exitcode indicates succes (0), failure (1) or retry (75)
> - spamc -x: always raw exitcode
>
> But I guess it depends largely on the setup and the sysadmins opinion
> whether 'addressee unknown' is a temporary condition, so there is
> another exception to be handled...
>
It seems to me that the set of replies as currently linked to spamc
options would do a near-prefect job with two minor tweaks:
(1) remove the EX_TOOBIG kludge from --no-safe-fallback so it does
what it says on ythe tin
(2) use the --exitcode behavior as the default in place of
--no-safe-fallback
The manpage needs to say that --no-safe-fallback should be used during
testing and explain that, although it catches more errors, it should
not be used for production because it treats EX_TOOBIG as an error
rather than a warning.
Personal opinion: the best approach would be to stick with
--no-safe-fallback after removing the EX_TOOBIG kludge and for the
calling script/code to make more detailed exit code checks. However, I
also realise this change would break a lot of installations, which is
why I'm suggesting making --exitcode the default in place of
--no-safe-fallback.
Martin
Re: spamc exit code for exceeding max size
Posted by Tom Hendrikx <to...@whyscream.net>.
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.
>>
>> $ spamc --full -no-safe-fallback --port=12345 < message.eml; echo $?
>>
>> This nicely reports an exit code of 69 (where nothing is actually
>> listing on that port).
>>
>> However, checking for maxsize issues does not work:
>>
>> $ spamc --full --no-safe-fallback --max-size=10 < message.eml; echo $?
>>
>> This reports an exit code of 0. Checking the source code [1] tells me
>> that the exit code is suppressed on purpose, but the bugreport
>> referenced in the source code [2] doesn't explain why EX_TOOBIG should
>> be suppressed.
>>
>> So either the code has an issue, or the man page (as EX_TOOBIG can never
>> happen but it is documented). I'd rather see the code fixed, unless
>> there is a compelling reason not too which I failed to understand.
>>
>> Kind regards,
>> Tom
>>
>> [1]
>> http://svn.apache.org/viewvc/spamassassin/trunk/spamc/spamc.c?view=markup
>> (line
>> 1050)
>> [2] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5412
> My best guess, it exits that way so that the mail that is larger than
> the scan limit is still accepted by MTAs and continues along the process.
>
> Suggest you look at bug 6717 perhaps and see if you can work up a patch
> to give the behavior you would like.
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 temporary errors to EX_TEMPFAIL' which would change most of
the named exit codes in the man page into EX_TEMPFAIL, except when the
message should be simply passed through (effectively only EX_TOOBIG).
This would do for integration as documented in the bug:
- spamc without special switch: exitcode indicates succes (0) or failure (1)
- spamc -<new>: exitcode indicates succes (0), failure (1) or retry (75)
- spamc -x: always raw exitcode
But I guess it depends largely on the setup and the sysadmins opinion
whether 'addressee unknown' is a temporary condition, so there is
another exception to be handled...
--
Tom
Re: spamc exit code for exceeding max size
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 $?
>
> This nicely reports an exit code of 69 (where nothing is actually
> listing on that port).
>
> However, checking for maxsize issues does not work:
>
> $ spamc --full --no-safe-fallback --max-size=10 < message.eml; echo $?
>
> This reports an exit code of 0. Checking the source code [1] tells me
> that the exit code is suppressed on purpose, but the bugreport
> referenced in the source code [2] doesn't explain why EX_TOOBIG should
> be suppressed.
>
> So either the code has an issue, or the man page (as EX_TOOBIG can never
> happen but it is documented). I'd rather see the code fixed, unless
> there is a compelling reason not too which I failed to understand.
>
> Kind regards,
> Tom
>
> [1]
> http://svn.apache.org/viewvc/spamassassin/trunk/spamc/spamc.c?view=markup (line
> 1050)
> [2] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5412
My best guess, it exits that way so that the mail that is larger than
the scan limit is still accepted by MTAs and continues along the process.
Suggest you look at bug 6717 perhaps and see if you can work up a patch
to give the behavior you would like.
Regards,
KAM