G'day All,
Over the years, cPanel has patched backscatter and delayed bounce bugs each time they're reported, but the logic problems seem to keep coming back again silently with updates.
Now that Exim is offloading some bounces to Dovecot, it's very easy for a cPanel box to be caused to spam and become listed on a backscatter or honeypot type of RBL.
Currently, on stable 68.0.21, cPanel routinely sends delayed bounces for several not so edge-case situations.
If the incoming email is spam with a spoofed From: header, then the cPanel box will be effectively spamming when it sends the bounce back to an innocent party.
Just two examples of fairly common situations which result in delayed soft bounces, and which can be reproduced very easily, are...
1. Sending an email too large for the remaining quota of a mailbox not yet over quota.
2. Sending an email smaller than the remaining quota of a mailbox, but where the total hosting account is already over disk quota.
In these situations, the incoming item is accepted at SMTP-time, and then subsequently bounced by Dovecot after a delay. That outgoing email has the headers of the cPanel box, and if deemed to be spam, the IP of the cPanel box is the one which will appear on any related RBL.
On the other hand, where it works correctly is in situations where an email is sent to a mailbox which is *already* over quota. In that situation, an SMTP-time hard rejection is correctly communicated directly to the sending server. This leaves the responsibility for the sending server to notify the sending client of the failure. This is the correct handling of email rejections and should be used for all situations including the examples above.
Setting the "Disk Quota Delivery Failure Response" to "Defer delivery temporarily" doesn't fix the incorrect handling demonstrated above. It can delay the backscatter for a period in hope of the message becoming deliverable, but ultimately, if the quota situation is not fixed before the defer period expires, the backscatter is still generated.
Rather than raising a cPanel support ticket which doesn't seem to be the way to go on something like this, is there a contact address at cPanel where something like this can be raised for proper discussion?
It's been a very long time since backscatter generating email systems have been regarded as acceptable.
Best regards,
LBJ
Over the years, cPanel has patched backscatter and delayed bounce bugs each time they're reported, but the logic problems seem to keep coming back again silently with updates.
Now that Exim is offloading some bounces to Dovecot, it's very easy for a cPanel box to be caused to spam and become listed on a backscatter or honeypot type of RBL.
Currently, on stable 68.0.21, cPanel routinely sends delayed bounces for several not so edge-case situations.
If the incoming email is spam with a spoofed From: header, then the cPanel box will be effectively spamming when it sends the bounce back to an innocent party.
Just two examples of fairly common situations which result in delayed soft bounces, and which can be reproduced very easily, are...
1. Sending an email too large for the remaining quota of a mailbox not yet over quota.
2. Sending an email smaller than the remaining quota of a mailbox, but where the total hosting account is already over disk quota.
In these situations, the incoming item is accepted at SMTP-time, and then subsequently bounced by Dovecot after a delay. That outgoing email has the headers of the cPanel box, and if deemed to be spam, the IP of the cPanel box is the one which will appear on any related RBL.
On the other hand, where it works correctly is in situations where an email is sent to a mailbox which is *already* over quota. In that situation, an SMTP-time hard rejection is correctly communicated directly to the sending server. This leaves the responsibility for the sending server to notify the sending client of the failure. This is the correct handling of email rejections and should be used for all situations including the examples above.
Setting the "Disk Quota Delivery Failure Response" to "Defer delivery temporarily" doesn't fix the incorrect handling demonstrated above. It can delay the backscatter for a period in hope of the message becoming deliverable, but ultimately, if the quota situation is not fixed before the defer period expires, the backscatter is still generated.
Rather than raising a cPanel support ticket which doesn't seem to be the way to go on something like this, is there a contact address at cPanel where something like this can be raised for proper discussion?
It's been a very long time since backscatter generating email systems have been regarded as acceptable.
Best regards,
LBJ
