The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Disk Quota Delivery Failure Response

Discussion in 'E-mail Discussions' started by mtindor, Sep 7, 2016.

Tags:
  1. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,279
    Likes Received:
    36
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    Hello,

    I upgraded all of my machines to WHM 58. Under Mailserver Configuration I have the following option checked:

    Disk Quota Delivery Failure Response
    - Defer Delivery Temporarily

    I have a problem with the new way this is handled compared to previous versions of WHM.

    On my systems, with Defer Delivery Temporarily selected, it no longer keeps the message in the queue. Instead it accepts the message and then bounces it back to the sender.

    In the example below, my issue is NOT that AOL is rejecting the bounce. My issue is that the incoming mailbox was full, Defer Delivery Temporarily was set, and instead of the message being held in the queue for retry (to user@recipientdomain.com's mailbox), it instead accepted the message and generated a bounce back to the [AOL] sender in this case.

    Code:
    2016-09-06 17:13:03 [631374] 1bhNfk-002eFS-E3 <= someunknownuser@aol.com H=omr-m020e.mx.aol.com [204.29.186.20]:56589 I=[1.2.3.10]:25 P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256 CV=no S=35179 M8S=8 id=56f6975b-3b9a-978f-b3f1-7be795c2d939@aol.com T="Fwd: I have to fart" from <someunknownuser@aol.com> for user@recipientdomain.com
    2016-09-06 17:13:03 [631485] 1bhNfk-002eFS-E3 ** user@receipientdomain.com F=<someunknownuser@aol.com> R=virtual_user_overquota: Mailbox is full / Blocks limit exceeded / Inode limit exceeded
    2016-09-06 17:13:03 [631489] 1bhNfz-002eHJ-2a <= <> R=1bhNfk-002eFS-E3 U=mailnull P=local S=36436 M8S=0 T="Mail delivery failed: returning message to sender" from <> for someunknownuser@aol.com
    2016-09-06 17:13:04 [631492] 1bhNfz-002eHJ-2a ** someunknownuser@aol.com F=<> P=<> R=dkim_lookuphost T=dkim_remote_smtp H=mailin-01.mx.aol.com [64.12.88.132]:25 I=[1.2.3.4]:48371 X=TLSv1:DHE-RSA-AES256-SHA:256 CV=yes DN="/C=US/ST=Virginia/L=Dulles/O=AOL Inc./OU=AOL Mail/CN=mx.aol.com": SMTP error from remote mail server after end of data: 521 5.2.1 :  AOL will not accept delivery of this message.
    2016-09-07 10:39:05 [960644] 1bhNfz-002eHJ-2a ** someunknownuser@aol.com F=<> P=<> R=dkim_lookuphost T=dkim_remote_smtp H=mailin-01.mx.aol.com [152.163.0.67]:25 I=[1.2.3.4]:46064 X=TLSv1:DHE-RSA-AES256-SHA:256 CV=yes DN="/C=US/ST=Virginia/L=Dulles/O=AOL Inc./OU=AOL Mail/CN=mx.aol.com": SMTP error from remote mail server after end of data: 521 5.2.1 :  AOL will not accept delivery of this message.
    
    A deferral should be a 4.x.x error, and that error should be handed off to the sending server as part of the original SMTP connection/transaction. The mail system should NOT be (a) accepting the mail and then (b) bouncing it if the mailbox is over quota. That's horrendous behavior and is not at all how WHM handled mail in previous versions.

    In previous versions, you could either reject the email (during SMTP) if the local recipient's mailbox was full, or you could have the email queued up in the queue for future delivery attempts to user@recipientdomain.com on the local server.

    Mike

    PS: Yes, I could set Reject the Message Permanently, but I don't feel like trying that without knowing beforehand if it is going to exhibit the same bad behavior (accept / bounce) or if it is going to act properly and send a 5.x.x when someunknownuser@aol.com sends an email to user@recipientdomain.com on the local server.
     
    #1 mtindor, Sep 7, 2016
    Last edited by a moderator: Dec 2, 2016 at 4:33 AM
    sneader likes this.
  2. sneader

    sneader Well-Known Member

    Joined:
    Aug 21, 2003
    Messages:
    1,126
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    La Crosse, WI
    cPanel Access Level:
    Root Administrator
    This has been working perfectly for as long as I can remember. As of v54, we have had the Exim setting "Bounce email for users over quota" set to OFF, which meant that even if the account was over quota, we'd still accept the message normally, and then just keep trying to deliver it, until the queue problem is resolved. This really worked great... if a customer accidentally went over quota, they had some time to delete some emails, up their quota, or ask for help.

    The new functionality is horrible. Is there not any way we can get it to work like it did, before? i.e. accept the message even if the account is over quota, and do NOT send any bounce / deferral to the sending host?

    - Scott
     
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,678
    Likes Received:
    653
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello,

    I've reproduced this behavior, and opened internal case CPANEL-8468 to report the issue. I'll update this thread with more information on the status of this case as it becomes available.

    Thank you.
     
  4. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,279
    Likes Received:
    36
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    Thanks, Michael. I appreciate it.

    - Mike
     
  5. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,279
    Likes Received:
    36
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    Michael,

    It is important to note that I have now tested both options in WHM 58.

    a. reject the message permanently
    b. defer delivery temporarily

    Whether you tell it to "reject the message permanently" OR "defer delivery temporarily", in EITHER case (the only options), it ACCEPTS the email and then BOUNCES it back to sender. So the handling of over-quota accounts is broken in 58 period. Both options do exactly the same thing / generate the same lines in /var/log/exim_mainlog, send the same bounces back to the sender [from my server] instead of rejecting them / deferring them during SMTP.

    "reject the message permanently" should 5.x.x the message during the smtp session with the sending server, so that the burden is on the sending server to notify the sender that the message could not be delivered.

    "defer delivery temporarily" should either 4.x.x the message (so that the sending server queues it for future delivery retries) OR it should behave like "54" does.

    If you disable the quota bounce in 54, the cpanel server accepts the mail into the queue and locally attempts retries to our recipient.

    Mike
     
  6. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,279
    Likes Received:
    36
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    And, it's important to note that AOL will not even accept those quota bounces. They may not be the only provider who won't accept them. But even if they are the only provider that doesn't accept them, that is too hurtful to us hosts because our recipient will never get the message and the AOL sender will never get the notification that it wasn't delivered. Absolutely not good.

    To be clear, in "58", regardless of whether one chooses to "reject the message permanently" or they choose to "defer delivery temporarily", in an overquota condition the cPanel server accepts the message and bounces it back to the sending server. In the case of AOL (and probably others), they won't even accept the bounces that let their sender know that their message to my over-quota recipient can't be delivered. And the message does not queue up on my server for future delivery to my recipient once my recipient's quota issue is resolved.

    What this means is that, in WHM 58, an overquota condition basically disposes the message without locally retrying it, without the local recipient ever receiving it, and in at least some cases [AOL is big] the sender not knowing that it wasn't delivered or why it wasn't delivered.

    Mike
     
  7. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,678
    Likes Received:
    653
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello Mike,

    This is an accurate description of the bug. CPANEL-8468 will ensure emails sent to accounts at their disk quota limit are queued instead of bounced when Dovecot is configured to defer the message. A resolution is now in testing, and I'll update this thread once a new build is published.

    Thank you.
     
  8. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,678
    Likes Received:
    653
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
  9. cbcast

    cbcast Member

    Joined:
    Jun 17, 2005
    Messages:
    12
    Likes Received:
    0
    Trophy Points:
    1
    We're running 60.0.26. I have the Dovecot option "Disk Quota Delivery Failure Response" set to "Reject the message permanently."

    The messages destined for over-quota email accounts are not queued, as expected. However, a separate "Mail delivery failed: returning message to sender" message is generated.

    I do not remember it working like this in previous cPanel/WHM releases. I vaguely remember the old Exim option to reject messages at SMTP time if the mailbox is over quota. I don't recall if a separate failure message was generated. Was the SMTP response simply a reject, connection termination and no further action taken? Perhaps I'm dreaming.

    Why do we need to send a mailer-daemon bounce if we told the sending MTA at SMTP time that the mailbox is over quota and the message cannot be delivered?
    Code:
    2016-12-01 20:56:02 1cCe0z-0007bX-7J H=mxphxpool1010.ebay.com [66.211.184.76]:45141 Warning: "SpamAssassin  detected message as NOT spam (-23.9)"
    2016-12-01 20:56:02 1cCe0z-0007bX-7J <= member@ebay.com H=mxphxpool1010.ebay.com [66.211.184.76]:45141 P=esmtps  T="Re: Other: blah for blah@blah
    2016-12-01 20:56:02 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1cCe0z-0007bX-7J
    2016-12-01 20:56:02 1cCe0z-0007bX-7J ** blah@blah R=virtual_user_overquota: Mailbox is full / Blocks limit exceeded / Inode limit exceeded
    2016-12-01 20:56:02 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1cCe0z-0007bX-7J
    2016-12-01 20:56:02 1cCe14-0007da-IZ <= <> R=1cCe0z-0007bX-7J U=mailnull P=local S=31053 T="Mail delivery failed: returning message to sender" for member@ebay.com
    2016-12-01 20:56:02 1cCe0z-0007bX-7J Completed
    
    
     
    #9 cbcast, Dec 1, 2016 at 9:28 PM
    Last edited by a moderator: Dec 2, 2016 at 4:34 AM
Loading...

Share This Page