v5: cannot delete from Proxy Content Manager

Just tested this. No problems over here.

Could it be a question of load? I have a few hundred emails a minute, and my queue is building up frozen messages (SPAM bounces and other undeliverables) at the rate of 1-2K per hour. Right now, I'm upwards of 10K frozen messages for half a day, and I can't delete them. I did find that I could delete/refresh messages that weren't deferred or frozen, one by one in the delete specific message section on the bottom. But the top select of delete type of message isn't working at all.

I could be a question of load. There are some discussions on this board about the slow webadmin interface. When I delete messages it's about 20 messages at once. That amount is no problem.

Hi there, 

just want to add, that you need to reload (refresh) the proxy content in order to see the changes.

Regards
Gert

Well, I just have too many frozen. Whenever I go to see all in one page, the system spikes in load and never returns a page. The interface can't seem to manage the 10K per 6 hours of frozen messages that I see. I've been logging into the system and deleting Finput/Fmsglog directory entries. Hell, rm can't even deal with the number, and I need to run a scipt off of the ls command to delete them one by one. Otherwise, with over 300 "pages" of results, the interface shows only 5-7 messages in the permenently frozen queue at a time. That's not too useful. Hell, just looking at the proxy content manager page when logging in takes about a minute on high end hardware. This interface blows!  [:(] Can we have the old one back?

To give an example, I have just over 10K entries right now. I don't want to delete all non-deferred content since that would also delete some potentially in process messages, right? Regardless, when I do select that, it fails (with refreshing proxy content I never see the message count drop at all, it just increases). I can click the filter, and select permanent delivery errors, and I still end up with 391 pages and 8K of messages. How does one delete them without going through 391 pages, or using the command line interefaces? Also, does deleting all non-deferred cover too many messages (quarantine, undeliverable, etc). I'd like just a "delete all permanent delivery error" category, and make sure it works.

Sounds like there should be an option to not keep those messags to begin with (once it's determined they are permanently undeliverable).

BTW, have you turned on the sender address verification, and maybe an RBL? Each of those features should drastically reduce the amount of incoming spam.

Barry

First, to answer the above post: yes, I have RBLs and sender address verification. I also have some blacklists. The problem is when you are a smarthost... If you aren't handling incoming mail, but are routing it as an outbound SMTP server, the sender address verification doesn't help. Similarly with blacklists. A lot of my problems are bounces to spam that fall at this server's floor as the authoritative smarthost for this part of the domain.

I'm on to something though. I had the system crash (with the failover not working since the primary nics stayed up.. god knows why). When I brought the primary system back on as a master, I had 24K of messages. I did the usual trick of clearing out Finput/Fmsglog. I found out the delete messages from the interface seemingly works when there are few enough messages. Perhaps when you go beyond rm's limit on shell expanded file names, it just stops working (rm * reports that there are too many items). I think Astaro's deletion code needs to handle it differently. Also, it seems that if you try and display all messages in one page to delete them, and have over 1500 messages to be displayed, the interface times out, the system spikes, and you'll need to log back in. Basically, the code in question cannot handle displaying or operating on any > 1500 message grouping. Enterprise ready this is not [:(]

I do agree the suggestion of admin control of the frozen messages. Either not keeping them or the ability to set the days to keep them around (1 day or such) instead of the non-editable 7 days, which I never get that far to see if it actually even removes them then.

I haven't looked at ASL's mail spool in a long time, but one way to get around the 1500 file limit would be to use find.

e.g. 
find /path-to-queue -name 'whatever*' -exec rm {} \;

TEST THIS without the -exec first!
note that it will also search and delete files in subdirectories.

Unfortunately, this would delete everything in the queue unless you can figure out how to distinguish frozen bounces from the rest by filename.
Find will take some time parameters, so you could look only for messages older than a certain # of days.

There was a perl script for ASL 2 or 3 to help with this kind of thing, but I don't know if it still works, nor do I know if it's still available. I don't see it on the docs site.

I also have one for my sendmail server, but it barely works (usually only deletes 1 of the 2 files for each message).

Barry

My solution was similar (just a for loop), but the point is one should not have to manually clean it out. It should be handled by ASL, and furthermore the interface should offer the ability to tweak such settings.

im not sure this applies to your issue, as you have said that you can't delete using any of the functions, but i ran into nearly the same issue just yesterday on one of our clients firewalls.  selecting the message and using the trashcan did nothing, finally just used the drop down to tell it to delete all messages in the content manager, and that did the trick.  im sure there is something going wrong with it, and i hope i don't end up with your issue and not being able to remove it no matter what...