• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Qmail gives 451 temp error when mailbox full

M

mooiesite

Basic Pleskian
Situation

plesk 10.4.4 with all latest micrupdates
qmail
greylisting turned off, no spamfiltering, no spf, etc
mailbox with for example 100mb quota and 102mb data.
Overusage not allowed.

When this mailbox receives an email i expect it to return sender with error stating the mailbox is full.

What does it returns a 451 qq trouble in home directory (#4.3.0) error.
So mailservers keeps on trying to deliver.

I tried /usr/local/psa/admin/sbin/mchk --without-spam with no luck
I found this url ( http://www.sxg.com/qq-trouble-in-home-directory-4-3-0-plesk-10/ ) which looks like describing the same problem, but i cannot change to postfix right now.

Some loginfo

[maillog]
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: Handlers Filter before-queue for qmail started ...
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: from=*removed*
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: to=*removed*@*removed*
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: handlers_stderr: DATA Mailbox full
DEFER
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: DEFER during call 'check-quota' handler

(what is that newline with DEFER doing there??)

[returned mail message]
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue on *removed*.

The message identifier is: 1ShbD3-0004Xo-HC
The date of the message is: Thu, 21 Jun 2012 08:49:38 +0200
The subject of the message is: RE: *removed*

The address to which the message has not yet been delivered is:

*removed*@*removed*
Delay reason: SMTP error from remote mail server after end of data:
host XXXX-05.*removed* [*removedIP*]: 451 qq trouble in home directory (#4.3.0)

No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you.

I tried adding/removing mailboxes but no luck. Problem persists.
Any idea?
 
Yeah, I see this behaviour too. It appears to be normal for 10.4.4, at least under Centos 6 and whatever os you are using.

On the one hand a temporary refusal can be more useful than a hard bounce, because the mailbox may get emptied a little later on. On the other hand this is different to how it was in 8.6 and earlier under Centos 4 at least, and it might cause problems if the sender's mailserver tries for several days before giving up - the sender won't know that the recipient isn't going to get their email until too late.

I need to investigate this a bit more because I'm sure I've seen a hard bounce in the logs ... but we have a mix of versions and that could have been from an 8.6 system.
 
I checked 4 boxes and it looks like postfix is also affected!

Parallels Plesk Panel 10.4.4 on Centos 5.8 with Qmail: Problem exists
Parallels Plesk Panel 10.4.4 on Centos 6 with Qmail: Problem exist
Parallels Plesk Panel 10.4.4 on Centos 5.8 with Postfix: Problem exists
Parallels Plesk Panel 9.5.4 on Centos 5.8 with Qmail: Problem does NOT exist

A 451 on mailbox full is strange, also when looking at the codes defined in RFC 3463 (or 1893) the RFC says that a full mailbox should be considered a "persistent transient error" (550 error) communicates "mailbox full".

Any official statement from Parallels??
 
Last edited:
Excellent debugging there. Thanks.

Hopefully Igor will tell if the devs are aware of this issue. If they are not, we'll need to prepare a bug report in the following format:

---------------------------------------------------------------
PRODUCT, VERSION, MICROUPDATE, OPERATING SYSTEM, ARCHITECTURE

PROBLEM DESCRIPTION

STEPS TO REPRODUCE

ACTUAL RESULT

EXPECTED RESULT

ANY ADDITIONAL INFORMATION
--------------------------------------------------------------

Alternatively, there's a bug report form on the parallels website. If I get a moment I'll use it to report the issue -- the more people who report it, the better.

Of course it is *almost* a "cosmetic bug" so I can't see it being high on the fix list. But it would be nice to see this changed back to the way we think it should be, and as you point out also how it should be according to the RFCs :)
 
PRODUCT, VERSION, MICROUPDATE, OPERATING SYSTEM, ARCHITECTURE
at least in:
Full (micro)updated Parallels Plesk Panel 10.4.4 on 64 bit Centos 5.8 with Qmail
Full (micro)updated Parallels Plesk Panel 10.4.4 on 64 bit Centos 6 with Qmail
Full (micro)updated Parallels Plesk Panel 10.4.4 on 64 bit Centos 5.8 with Postfix

PROBLEM DESCRIPTION
On full mailbox qmail or postfix returns a "451 qq trouble in home directory (#4.3.0) error" instead of a "550 mailbox full".
This means a sending mailserver will try to send the message for a few days, because it gets this temporary error. Normal behaviour is an immediate bounce (550 error) stating mailbox is full.

STEPS TO REPRODUCE
Create mailbox with 100kb storage
send email to mailbox with 200kb attachment

ACTUAL RESULT
after a few days returned mail:
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue on *removed*.

The message identifier is: 1ShbD3-0004Xo-HC
The date of the message is: Thu, 21 Jun 2012 08:49:38 +0200
The subject of the message is: RE: *removed*

The address to which the message has not yet been delivered is:

*removed*@*removed*
Delay reason: SMTP error from remote mail server after end of data:
host XXXX-05.*removed* [*removedIP*]: 451 qq trouble in home directory (#4.3.0)

No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you.

logs plesk server:
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: Handlers Filter before-queue for qmail started ...
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: from=*removed*
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: to=*removed*@*removed*
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: handlers_stderr: DATA Mailbox full
DEFER
Jun 22 07:15:01 XXXX-05 qmail-queue-handlers[25080]: DEFER during call 'check-quota' handler

EXPECTED RESULT
Immediate bounce of email with an error stating 550 mailbox full

ANY ADDITIONAL INFORMATION
Something changed in one of the last plesk (micro)updates. Because it used to sent the 550.

As defined in RFC 3463 (or 1893): a full mailbox should be considered a "persistent transient error" (550 error) with a "mailbox full" description.

Problem does not exist in plesk 9.5.4 on 32 bit centos 5.8 with qmail
 
now waiting for Igor or another official Parallels' reaction :)

(and can someone change the topic title? It's not just qmail which is affected)
 
I have forwarded tour report to developers. I will update thread with results of investigation.
 
any update?

(i know i'm bumping this thread.. But come on, this is not a small or minor bug.. You're breaking RFC's!)
 
Same Error here

I got my all microupdates done and getting the same error.
Any update on this from parallel?

THis is my panel version :-
10.4.4 Update #39, last updated at July 18, 2012 11:05 PM
 
hi igor,

i don't think it has anything todo with the problem described in this thread.
In the kb and the refered wiki article they are talking about a 5xx error at the connectionstage when there are multiple recipients so messages are bounced at a 'user/local' level.
This bug is about giving a 4xx error (temp failure) where there should be a 5xx error.
This problem also exist where there is a single recipient.

Will try it anyway, but i don't think it solves this bug.
I will also test today if this bug is also present in Plesk 11.
 
Last edited:
That seems to do the trick.. very strange. After applying this 'patch', it gives a correct 5xx error.
But this is strange cause the kb article is talking about multiple recipients. And my testing was a single recipient. So there's definitely something wrong in this 'feature'.

Besides that,
Don't you think it's a bit weird that we have to apply a patch to comply with the RFC's??
It should be the other way around.
 
problem also exists in plesk 11.

Concluding:

Your antispam solution as described in the kb article gives the wrong error (4xx instead of 5xx).
If you change this to a 5xx error it should solve the problem.
 
mooiesite - I'm a bit confused. What you say "That seems to do the trick.. very strange. After applying this 'patch', it gives a correct 5xx error." do you mean then by following the suggestion in the KBs:

Code: 
# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "REPLACE INTO misc VALUES ('reject_mail_when_overquota', 'false')"
# /usr/lib/plesk-9.0/mail_mailbox_restore --handlers-only

i.e. by setting reject_mail_whenoverquota to FALSE, the 4xx become 5xx?

Or is it that when it is FALSE the email is not rejected at the SMTP stage but instead a bounce message is generated by the Plesk server? The example maillogs in the KB seem to indicate that's what happens.

In which case absolutely -- when set to TRUE the SMTP reject reason still needs to be 5xx not 4xx.

@Igor ... can you look into this for us please?
 
To clarify, yes by setting it to FALSE the email is not rejected at the SMTP stage but instead a bounce message is generated by the Plesk server. So the bug does not occur.

But when setting is to TRUE (or actually leaving it at TRUE, because it's default), the message is bounced at SMTP stage with the _wrong_ error code (4xx instead of 5xx).

I think plesk chose a 451 because it's an 'anti-spam feature'. But it should be a RFC compliant 5xx error when the mailbox is full.
 
Last edited:
According to developers this problem has been fixed for Postfix in 10.4.4 MU#27. It is not so easy fix it for Qmail and developers are working on it. As possible workaround we can recommend switching to Postfix MTA.
 
IIRC, MU#27 fixed only harmless warning messages in mail log from check-quota handler. And it also made check-quota defer messages instead of rejecting them (and return error code 4.5.1 if on Postfix). Then there were a couple of MUs that fixed havoc that this change brought on some machines (think QMail, SELinux), but the core behavior was not changed after that.

[-] Check-quota filter errors.

[-] Wrong error message returned by postfix.
Click to expand...

So no, the problem was not fixed in MU#27. Currently there is no way to make Plesk (10 or 11 for that matter) return permanent error instead of a temporary one for overquota cases.
 
It is not so easy fix it for Qmail and developers are working on it.
Click to expand...

it IS easy to fix!
Focus on your core product instead of developping strange antispam features and force clients to use them!
 
You must log in or register to reply here.

Similar threads

J
Issue Notifications Email and 550 error
Replies
1
Views
3K
mariano_loo
M
J
Resolved Can't login at Plesk admin panel (Plesk Onyx 17.0.17)
Replies
6
Views
10K
JVG
J
intradesign
Question SMTP error Service unavailable
Replies
3
Views
2K
Kaspar
K
Azurel
Forwarded to devs mail() not working, if called php script on command-line
Replies
3
Views
3K
Azurel
Azurel
R
Issue Plesk repair -all error
Replies
4
Views
2K
MARS_NETWORKS
M
Back
Top