Disk Quota Delivery Failure Response
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[/EMAIL]'s mailbox), it instead accepted the message and generated a bounce back to the [AOL] sender in this case.
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[/EMAIL] 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[/EMAIL] sends an email to user@recipientdomain.com[/EMAIL] on the local server.
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 for user@recipientdomain.com
2016-09-06 17:13:03 [631485] 1bhNfk-002eFS-E3 ** user@receipientdomain.com F= 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[/EMAIL] 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[/EMAIL] sends an email to user@recipientdomain.com[/EMAIL] on the local server.
-
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.
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? - Scott0 -
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. 0 -
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.
Thanks, Michael. I appreciate it. - Mike0 -
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 0 -
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 0 -
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.
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.0 -
Hello, To update, the resolution is included with cPanel version 58.0.30: Fixed case CPANEL-8468: Disable overquota reject at SMTP if dovecot is set to defer. You can review the full change log, information on updating cPanel/WHM, and information on the build/release process at:
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
0 -
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?
"Reject the message permanently" should reject during SMTP (no bounces). Based upon what people have said, even with WHM 60 this is still broken. However, since I updated to the latest WHM 58 (and now to WHM 60), I have not had any issues with the deferral option. The deferral option queues up mail like it is supposed to and doesn't generate any crazy bounces. Mike0 -
Hello, cPanel & WHM version 58 and later uses Dovecot as the local mail delivery agent. Earlier versions of cPanel & WHM used Exim as both the mail transfer agent and the local delivery agent. Per Dovecot's documentation, here's a description of the "quota_full_tempfail" value (This is what's changed when modifying "Disk Quota Delivery Failure Response" in "WHM >> Mailserver Configuration"): quota_full_tempfail = no If user is over quota, return with temporary failure instead of bouncing the mail.
Thus, if it's set to "No", the message is temporarily deferred and queued for another delivery attempt. If it's set to "Yes", the message is bounced to the sender. Thank you.0 -
Michael, Thank you for the explanation as to why it is behaving like that. Have you ever heard the saying "two wrongs don't make a right" ? Well, in this case, just because Dovecot's option to permanently reject is via a bounce, that doesn't mean that bouncing things is good [or more importantly, proper]. It's been at least 10 years now since bouncing mail has been unacceptable practice. The old system handled both queuing and 5.5.x rejection during SMTP (or was it a 4.5.x deferral - I don't remember) just fine. That either needs to be duplicated in cPanel, or the option to reject permanently via a bounce needs to be removed. Since I use the deferral method, I don't personally have a horse in the game. But the product [WHM] shouldn't even have a setting exist that allows for bouncing [purposeful or otherwise], since there is just no scenario where the bouncing of quota emails is / should be an acceptable practice. If this isn't something that cPanel cannot work around in an ACL, I'd recommend omitting the option altogether and stating in the documentation that Dovecot handles overquotas by accepting / queueing email for accounts over quota. I'm going to have to put some accounts into an overquota state and test. The only options that should ever [be allowed to] happen are: 1. 4.5.x deferral -- tell the sending server to try again later because recipient mailbox is in an overquota condition 2. 5.5.x rejection during SMTP -- tell sending server it's undeliverable due to quota 3. accept and queue My personal feeling that a 5.5.x rejection is too brutal for an overquota condition, and that a 4.5.x deferral is an issue in cases where the sending mechanism is a PHP script bypassing an MTA and doing a direct delivery. So I set my servers to accept / queue the mail (which I think is what the quota_full_tempfail = yes does). The bottom line is that anybody who sets up any mailserver to accept/bounce mail rather than reject/defer via SMTP (or accept/queue until time in queue expires or overquota condition is relieved) is setting themselves up for problems. Mike 0 -
Michael, Thank you for the explanation as to why it is behaving like that. Have you ever heard the saying "two wrongs don't make a right" ? Well, in this case, just because Dovecot's option to permanently reject is via a bounce, that doesn't mean that bouncing things is good [or more importantly, proper]. It's been at least 10 years now since bouncing mail has been unacceptable practice. The old system handled both queuing and 5.5.x rejection during SMTP (or was it a 4.5.x deferral - I don't remember) just fine. That either needs to be duplicated in cPanel, or the option to reject permanently via a bounce needs to be removed. Since I use the deferral method, I don't personally have a horse in the game. But the product [WHM] shouldn't even have a setting exist that allows for bouncing [purposeful or otherwise], since there is just no scenario where the bouncing of quota emails is / should be an acceptable practice. If this isn't something that cPanel cannot work around in an ACL, I'd recommend omitting the option altogether and stating in the documentation that Dovecot handles overquotas by accepting / queueing email for accounts over quota. I'm going to have to put some accounts into an overquota state and test. The only options that should ever [be allowed to] happen are: 1. 4.5.x deferral -- tell the sending server to try again later because recipient mailbox is in an overquota condition 2. 5.5.x rejection during SMTP -- tell sending server it's undeliverable due to quota 3. accept and queue My personal feeling that a 5.5.x rejection is too brutal for an overquota condition, and that a 4.5.x deferral is an issue in cases where the sending mechanism is a PHP script bypassing an MTA and doing a direct delivery. So I set my servers to accept / queue the mail (which I think is what the quota_full_tempfail = yes does). The bottom line is that anybody who sets up any mailserver to accept/bounce mail rather than reject/defer via SMTP (or accept/queue until time in queue expires or overquota condition is relieved) is setting themselves up for problems. Mike
I don't really see this as a major issue, just an annoyance. If Exim rejects at SMTP time for over-quota, the remote MTA should then bounce to the original sender. But it now sounds like Dovecot LMTP is also generating a bounce, which I would agree is improper. The original sender doesn't need two bounces. Or do I have that wrong?0 -
The best course of action here is a feature request for a third-option, the ability to reject the message at SMTP time. You can open a request via our feature request system: Submit A Feature Request I don't really see this as a major issue, just an annoyance. If Exim rejects at SMTP time for over-quota, the remote MTA should then bounce to the original sender. But it now sounds like Dovecot LMTP is also generating a bounce, which I would agree is improper. The original sender doesn't need two bounces. Or do I have that wrong?
There's only one bounce. Exim no longer handles the bounce, as it's handled by Dovecot. Thank you.0 -
The reject option was intended to reject the messages at SMTP time. I've opened case CPANEL-11493 to have the bug in the exim router construction corrected. 0 -
Hello, To update, CPANEL-11493 is included with Thank you. 0
Please sign in to leave a comment.
Comments
15 comments