1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

Qmail gives 451 temp error when mailbox full

Discussion in 'Plesk 10.x for Linux Issues, Fixes, How-To' started by mooiesite, Jun 22, 2012.

  1. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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?
     
  2. Faris Raouf

    Faris Raouf Silver Pleskian Plesk Guru

    31
    30%
    Joined:
    Mar 15, 2009
    Messages:
    667
    Likes Received:
    17
    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.
     
  3. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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: Jun 25, 2012
  4. Faris Raouf

    Faris Raouf Silver Pleskian Plesk Guru

    31
    30%
    Joined:
    Mar 15, 2009
    Messages:
    667
    Likes Received:
    17
    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 :)
     
  5. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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
     
  6. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    now waiting for Igor or another official Parallels' reaction :)

    (and can someone change the topic title? It's not just qmail which is affected)
     
  7. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,536
    Likes Received:
    1,239
    Location:
    Novosibirsk, Russia
    Affiliate:
    https://plesk.com/?a_aid=59ae552b0731c
    I have forwarded tour report to developers. I will update thread with results of investigation.
     
  8. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    Update?

    any update?
     
  9. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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!)
     
  10. CooL LeO

    CooL LeO New Pleskian

    10
    30%
    Joined:
    Jul 12, 2012
    Messages:
    5
    Likes Received:
    0
    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
     
  11. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,536
    Likes Received:
    1,239
    Location:
    Novosibirsk, Russia
    Affiliate:
    https://plesk.com/?a_aid=59ae552b0731c
  12. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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: Jul 19, 2012
  13. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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.
     
  14. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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.
     
  15. Faris Raouf

    Faris Raouf Silver Pleskian Plesk Guru

    31
    30%
    Joined:
    Mar 15, 2009
    Messages:
    667
    Likes Received:
    17
    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?
     
  16. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    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: Jul 22, 2012
  17. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    any update?
     
  18. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,536
    Likes Received:
    1,239
    Location:
    Novosibirsk, Russia
    Affiliate:
    https://plesk.com/?a_aid=59ae552b0731c
    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.
     
  19. Nikolay.

    Nikolay. Silver Pleskian

    17
    35%
    Joined:
    Jul 1, 2012
    Messages:
    844
    Likes Received:
    2
    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.

    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.
     
  20. mooiesite

    mooiesite Basic Pleskian

    24
    23%
    Joined:
    Jun 17, 2006
    Messages:
    66
    Likes Received:
    0
    it IS easy to fix!
    Focus on your core product instead of developping strange antispam features and force clients to use them!
     
Loading...