Documents stuck in queues - please help!

[Spudley]

Hi.

I have a B3 box which I'm generally very happy with.

However, I have a couple of issues that are causing me problems. I wonder if you can help.

Firstly, email: I have had a few emails sent to me that have been bounced by the B3 box because they exceed the maximum file size allowed. I have plenty of disk space so I would prefer not to have the file size limit at all, but I don't know how to adjust it. Could you tell me how?

However, that's not the real problem. The real problem is that the B3 box is sending repeated bounce messages for the same message -- thirty or forty of them over night, and continuing. It seems like the message is stuck in the B3 inbox and keeps getting rejected over and over and over. Please help me clear this out from the queue -- the people who sent me the original emails are starting to get annoyed.

Secondly, printing: I have a USB printer plugged into the B3 box, so it can be shared between computers on my network. This was working well until a particular print job. I was printing several copies of a google map. I asked for 10 copies, but the job seems to have got stuck in the queue, because every time I switch the printer on now, it immediately starts printing more and more copies of the same map. No other jobs are getting to the printer.

Please help me clear the printer queue.

I couldn't find any way to fix these issues via the B3 control panel; restarting the mail and print servers does not seem to have worked, nor does rebooting the box.

Thanks for any help.

[Spudley]

I found some solutions for myself.

1. The print problem.

I discovered that there is a printer admin interface located at b3.local:631/ (change 'b3.local' whatever your B3 box is named, or its IP address)

This is the standard interface provided by the CUPS printer system, and allowed me to clear the printer queue.

This does not explain how the print job got so messed up in the first place -- there were fifty copies of the job in the queue (not counting the ones that had already printed) -- but it has allowed me to tidy up the mess.

2. The email problem.

I was helped with this by an article in the B3 Wiki, which explains how to remove the size limit on mail items. Once I had done this, several emails sent from various people that had been blocked previously all arrived in my inbox at once.

I know that at least two of these people had been getting repeated rejection messages for these emails ever since they'd been sent (a period of several months in both cases).

Hopefully, clearing the size limit will mean that I don't get this problem any more, but again I don't understand what caused this issue in the first place. Once the message had been rejected, it should not have carried on trying to deliver it. I'm happy to work without a size limit, but other people may want one, so this answer would not solve the problem for everyone.

TL;DR -- I've got around the problems, but I still don't understand how they happened in the first place. Can anyone with a bit more knowledge of these things explain it to me?

[Gordon]

TL;DR -- I've got around the problems, but I still don't understand how they happened in the first place. Can anyone with a bit more knowledge of these things explain it to me?

The default message size limit on the internet is 4Mb and any MTA that an email passes between sender and recipient can bounce larger messages. Now the problem with bouncing is that you actually send the message back to whom it appears to originate from and I specifically say "appears" here. Spammers will always provide false email addresses that may or may not actually exist and yes that may clog up your server and by bouncing a message that is larger than 4Mb you are in danger of getting it bounced back again.

You might want to take a look at the ASSP project on sourceforge. It's a spam filter that actually sits in front of your local MTA (i.e. Postfix) and blocks offending emails while they are being delivered. Therefore no bouncing to unsuspecting email users anywhere else on the internet, which may in fact cause people to identify YOU as a spammer.

[Ubi]

before you implement this, please read the discussions on the postfix mailing list that discuss pre-queue filtering. There are SMTP session timeouts if the filter takes too long, resulting in an easy DOS attack.

[Gordon]

Not sure if that fully applies... ASSP is itself a SMTP proxy and I've never used it in between two Postfix instances. Don't really see any reason why you'd want to do this anyway, as documentation I found states that the filter should accept SMTP style messaging in a non batch method.

Edit: I guess that if all your emails arrive from the same server, a.k.a. bSMTP, then the Postfix Before-Queue Content Filter might make some sense. That is because ASSP will shut the door on a SMTP client trying to deliver what is identified as spam. If the provider has configured his servers with a large retry interval, this can cause all your emails (including the good ones) to be stuck on your provider's server if you receive a good amount of spam - with an interval of 30 minutes and 100 spam emails per day that would most likely cause you to not receive any emails at all!

[Ubi]

It's an interesting academic discussion, but I think we disgress from the original question, which was that the B3 was repeatedly sending bounce messages for the same incoming messages. This should not occur, as the bounce comes from mailer-daemon (<>), and if rejected goes into double-bounce and is discarded. If the B3 sends something repeatedly, this can only occur if the bounce message is rejected with a 4XX error (please try again later). If the message is too big, it should yield a 5XX error, and postfix will not try again. But then again, the message is actually delivered, so how can there be an error?

The only scenario I can think of is that the bounce goes to a address that splits to multiple different addresses. If one of those addresses rejects with a 4XX, then postfix will resend and the addresses that accepted the original will get a repeat.

OT: placing ASPP as a front-end is IMO not a good idea, because the postfix SMTP-checks are capable of rejecting 90% of spam with much less effort. On a low-performance machine it is not good practice to place a resource- expensive filter as the primary filter.

[Gordon]

It's an interesting academic discussion, but I think we disgress from the original question, which was that the B3 was repeatedly sending bounce messages for the same incoming messages. This should not occur, as the bounce comes from mailer-daemon (<>), and if rejected goes into double-bounce and is discarded. If the B3 sends something repeatedly, this can only occur if the bounce message is rejected with a 4XX error (please try again later). If the message is too big, it should yield a 5XX error, and postfix will not try again. But then again, the message is actually delivered, so how can there be an error?

I'd need to look into this, but I don't think mailer-daemon should use an envelope with sender <> - this is the most certain way to prompt the receiving MTA to bounce the message. And that would also explain messages bouncing back and forth, since bouncing after having accepted the email is simply an email response to it - it is NOT a reject by definition of the SMTP protocol!

[Ubi]

Sorry Gordon, but that last message was really nonsense. Bounce messages must per definition be from <> precisely because they would result in endless bounce loops otherwise. Bounding messages because they are from <> are a violation of RFC and only deliberately misconfigured MTAs do this. And no, the whole SMTP philosophy is that you EITHER accept or reject, never both.

http://en.wikipedia.org/wiki/Bounce_message

Bounce messages in SMTP are sent with the envelope sender address <>, known as the null sender address. They are frequently sent with a From: header address of MAILER-DAEMON at the recipient site.

Please, have a better look at inner workings of mails servers. You know more than anyone I know on network routing and firewalls, but mail administration is a little lacking

[Gordon]

Bounce messages must per definition be from <> precisely because they would result in endless bounce loops otherwise. Bounding messages because they are from <> are a violation of RFC and only deliberately misconfigured MTAs do this.

Hadn't come around to that, but it appears that this is correct. Been put on the wrong track because ASSP has a setting to deny messages that originate from <> but I do receive bounce messages once in a while - never on a message that I didn't send myself though, so that's quite amazing.

However what I stated about bouncing versus rejecting is in fact correct. Bouncing occurs after the MTA has originally accepted the message, rejecting informs the sending MTA that it should bounce the message. In any case the weird thing here is that the receiving MTA, of which we know nothing about, seems to think all went well and delivers the message, while postfix on the B3 thinks something went wrong and reattempts. Let's assume that the MTA on the other side is not deliberately misconfigured to return any type of 4xx error, what if it doesn't give a response at all after having received the email body?

[Ubi]

if the receiving MTA does not return a 200 OK message postfix will consider the message as not successfully delivered. This is logged in the sending MTA logs (i.e. the B3).
I vaguely remember seeing behaviour like this in an old exchange MTA once.