#43 No action when replying to ASK queue report

[Pizzagod]

I just upgraded from 2.5.0 to 2.5.2. Everything seems
to be working well, except when I reply to the 'ASK
queue report' I receive when I send an 'ask process
queue' e-mail.

Here is what I get in my ask.log:

2005/11/17 14:03:59 [20021]:
2005/11/17 14:03:59 [20021]: ----- ASK v2.5.2 Started -----
2005/11/17 14:03:59 [20021]: Message from: Test User
<e-mail address hidden>
2005/11/17 14:03:59 [20021]: Message to: Another
Test User <e-mail address hidden>
2005/11/17 14:03:59 [20021]: Message Subject: Re: ASK
queue report
2005/11/17 14:03:59 [20021]:
is_confirmation_return(): Didn't find conf#MD5 tag on
subject
2005/11/17 14:03:59 [20021]: is_remote_command():
Verifying the subject...
2005/11/17 14:03:59 [20021]:
process_remote_commands(): Found subject="Re: ASK queue
report"
2005/11/17 14:03:59 [20021]:
process_remote_commands(): Checking only. Returning true
2005/11/17 14:03:59 [20021]: Not matched in the whitelist
2005/11/17 14:03:59 [20021]: Sender is not mailer-daemon
2005/11/17 14:03:59 [20021]: __get_auth_tokens(): No
X-ASK-Auth SMTP header found
2005/11/17 14:03:59 [20021]: validate_auth_md5():
Cannot read authorization tokens. Authentication Failed.
2005/11/17 14:03:59 [20021]: Checking for remote commands
2005/11/17 14:03:59 [20021]:
process_remote_commands(): Found subject="Re: ASK queue
report"
2005/11/17 14:03:59 [20021]:
process_textmode_commands(): Action [R], MD5
[67c3773226a7917621667de82dd670da]

Any ideas? All I'm trying to do is remove an item from
my queue. I change the N to an R in my reply, and
send. For some reason, it's saying "Cannot read
authorization tokens. Authentication Failed". Why
would it say that? I'm only replying to the e-mail
(with codes that ASK generated).

Thanks in advance...

[Nobody/Anonymous]

Logged In: NO

Glad to hear it, thought it was just me :)
I have the same problem - last line in my logs is always the
Action [R] line. With the previous version the next line
was always something about 'confirmation_msg_queued' and the
delete command stuff, but this one isn't getting that far.
(yes, the correct message is in the queue)
gotta be a simple fix here someplace...

[Nobody/Anonymous]

Logged In: NO

Same bug. Debian system with exim4
These files (ASK-FATAL-ERROR.xxxx) xxxx is number
are appearing in my home directory, they all have this content:

Traceback (most recent call last):
File "/usr/bin/askfilter", line 66, in ?
rc = ask.filter(sys.stdin)
File "/usr/share/ask/askmain.py", line 168, in filter
if self.rmt.process_remote_commands():
File "/usr/share/ask/askremote.py", line 216, in
process_remote_commands
method() ## Execute method
File "/usr/share/ask/askremote.py", line 291, in
process_textmode_commands
self.askmsg.set_user_args(md5)
AttributeError: AskMessage instance has no attribute
'set_user_args'

------- same as pizzagod, I can ask process queue and get a
list of queue contents, but won't process my
delete/deliver/etc/ response.

[Dave]

Logged In: YES
user_id=1410238

Using 2.5.2 on a Slackware system with sendmail
same bug
same log entries
same traceback message
NO ASK-FATAL... files
no queue processing - deletes or delivers, but at least the
queue reporting is accurate and lets me know when I should
log into the server and manually delete spamturds. :)

[Dave]

Logged In: YES
user_id=1410238

OK, couldn't resist trying again -
Just installed 2.5.2 on a Debian system with exim
No previous ASK installation here (maybe that has something
to do with it?)
Same bug, same non-functional queue processing.
There ARE however ASK-FATAL error files in my home directory
now, and they all contain:

File "/usr/bin/askfilter", line 66, in ?
rc = ask.filter(sys.stdin)
File "/usr/share/ask/askmain.py", line 168, in filter
if self.rmt.process_remote_commands():
File "/usr/share/ask/askremote.py", line 216, in
process_remote_commands
method() ## Execute method
File "/usr/share/ask/askremote.py", line 291, in
process_textmode_commands
self.askmsg.set_user_args(md5)
AttributeError: AskMessage instance has no attribute
'set_user_args'

I wonder if those of us experiencing this are a vanishingly
small minority or something... it seems a bug like this
(system basically unusable by ordinary users) would have a
higher priority <wink>
Cheers-