Facebook
Twitter-
Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
To continue sharing your ideas and feedback, please visit features.plesk.com
"Backscattering" prevention is broke
- Thread starter qnet
- Start date
This doesn't appear to have corrected the problem:
Here is what I have installed:
/usr/lib/plesk-9.0/
-r-xr-s--- 1 postfix popuser 64600 2012-02-29 05:34 psa-pc-remote*
/usr/local/psa/handlers/hooks/
-r-sr-sr-x 1 popuser postfix 31392 2012-02-29 05:34 check-quota*
After installing the new files I ran "/etc/init.d/pc-remote restart".
Actually, now that I look at this, it appears that "/etc/init.d/pc-remote restart" isn't really stopping and restarting the service. Will take a look at that further and get back to you.
Here is what I have installed:
/usr/lib/plesk-9.0/
-r-xr-s--- 1 postfix popuser 64600 2012-02-29 05:34 psa-pc-remote*
/usr/local/psa/handlers/hooks/
-r-sr-sr-x 1 popuser postfix 31392 2012-02-29 05:34 check-quota*
After installing the new files I ran "/etc/init.d/pc-remote restart".
Actually, now that I look at this, it appears that "/etc/init.d/pc-remote restart" isn't really stopping and restarting the service. Will take a look at that further and get back to you.
Last edited:
After restarting psa-pc-remote by hand (not sure why /etc/init.d/pc-remote isn't working), it appears to have changed the behavior of over-quota condition:
Unless there are some unintended consequences, this patch appears to have worked.
Will update after running it during the day.
Igor, thank you.
Unless there are some unintended consequences, this patch appears to have worked.
Will update after running it during the day.
Igor, thank you.
burnleyvic
Regular Pleskian
The two binaries for CentOS 5 seem to work on CentOS 6, they are binary compatible. More testing is needed, though.
When copying the files from the patch to replace the old ones, be careful and restore the proper ownership and permissions, otherwise check-quota won't be able to access the maildir under /var/qmail/mailnames/. You'd see a log entry like this:
check-quota filter[9413]: stat('/var/qmail/mailnames/example.com.au/adi/Maildir') failed. Permission denied: 13
When this happens, instead of "571 5.7.1 Mailbox full" Postfix returns "250 2.0.0 Ok" and accepts the message, then generates a "mailbox full" bounce back to the sender, which is the perfect backscatter example.
So perhaps Parallels should add some notes for this hotfix, otherwise your patched server might become a spam relaying machine.
* Later edit: I've just learned that Plesk is in breach of RFC 1893 - http://www.faqs.org/rfcs/rfc1893.html - when deciding to return permanent failure for "Mailbox full" status instead of temporary failure. Currently the SMTP error is "571 5.7.1 Mailbox full" but it should probably be "450 4.2.2 Mailbox full"
When copying the files from the patch to replace the old ones, be careful and restore the proper ownership and permissions, otherwise check-quota won't be able to access the maildir under /var/qmail/mailnames/. You'd see a log entry like this:
check-quota filter[9413]: stat('/var/qmail/mailnames/example.com.au/adi/Maildir') failed. Permission denied: 13
When this happens, instead of "571 5.7.1 Mailbox full" Postfix returns "250 2.0.0 Ok" and accepts the message, then generates a "mailbox full" bounce back to the sender, which is the perfect backscatter example.
So perhaps Parallels should add some notes for this hotfix, otherwise your patched server might become a spam relaying machine.
* Later edit: I've just learned that Plesk is in breach of RFC 1893 - http://www.faqs.org/rfcs/rfc1893.html - when deciding to return permanent failure for "Mailbox full" status instead of temporary failure. Currently the SMTP error is "571 5.7.1 Mailbox full" but it should probably be "450 4.2.2 Mailbox full"
Last edited:
Parallels Plesk Panel 10.4.4 MU #23 [23-Mar-2012]
This MU #23 says "Postfix milter (mail filter) crashes while processing the e-mail". I assume this MU will install an updated milter.
Igor, do you know if this updated milter contains the changes that fix the over-quota backscattering problem talked about in this thread?
In other words, if I install this MU, is my milter going to stop sending "Mailbox over quota" messages again?
Thank you.
This MU #23 says "Postfix milter (mail filter) crashes while processing the e-mail". I assume this MU will install an updated milter.
Igor, do you know if this updated milter contains the changes that fix the over-quota backscattering problem talked about in this thread?
In other words, if I install this MU, is my milter going to stop sending "Mailbox over quota" messages again?
Thank you.
Burnleyvic, I brought this up to. It should really return a 4xx transient error for a mailbox full condition and let the sending server deal with it based on their policy.
At a minimum, there should be an option in the Mail configuration to specify whether you want to respond with 5xx for 4xx on mailbox full conditions. Again, this whole thing came up because of the ghost called "backscatter" and broken spam filters paying attention to "backscatter lists". I don't have a lot of hope for the future of the internet when a properly-functioning mail server delivering a valid message is considered "spam" because some phantom somewhere thinks it's bad and other people blindly follow.
We need to change how customers look at their email. The blame needs to be put on the recipient's mail provider, not the sender's. If your mail provider chooses to honor a backscatter list, it's in your best interest to change mail providers. Unfortunately, it's always the sender's mail provider that gets blamed for the recipient's broken mail provider.
At a minimum, there should be an option in the Mail configuration to specify whether you want to respond with 5xx for 4xx on mailbox full conditions. Again, this whole thing came up because of the ghost called "backscatter" and broken spam filters paying attention to "backscatter lists". I don't have a lot of hope for the future of the internet when a properly-functioning mail server delivering a valid message is considered "spam" because some phantom somewhere thinks it's bad and other people blindly follow.
We need to change how customers look at their email. The blame needs to be put on the recipient's mail provider, not the sender's. If your mail provider chooses to honor a backscatter list, it's in your best interest to change mail providers. Unfortunately, it's always the sender's mail provider that gets blamed for the recipient's broken mail provider.
same issue here:
Apr 5 08:36:08 web01 postfix/cleanup[28596]: 4308CC5A002: milter-reject: END-OF-MESSAGE from ********[*.*.*.*]: 5.7.1 Command rejected; from=<******@******.**t> to=<******@*******.*> proto=ESMTP helo=<***********>
Plesk Version: 10.4.4 Update #24
OS: Debian GNU/Linux 6.0 2.6.32-5-amd64
unfortunately, this is causing a lot of support requests, therefore it needs to be fixed.
regards
juergen
Apr 5 08:36:08 web01 postfix/cleanup[28596]: 4308CC5A002: milter-reject: END-OF-MESSAGE from ********[*.*.*.*]: 5.7.1 Command rejected; from=<******@******.**t> to=<******@*******.*> proto=ESMTP helo=<***********>
Plesk Version: 10.4.4 Update #24
OS: Debian GNU/Linux 6.0 2.6.32-5-amd64
unfortunately, this is causing a lot of support requests, therefore it needs to be fixed.
regards
juergen
tkalfaoglu
Silver Pleskian
Same problem for multiple recipients?
I had people alert me that when they sent mail to many recips, if one of them is local and has a mailbox full, none of the mails are delivered. Is backscatter prevention the cause of this problem?
I had people alert me that when they sent mail to many recips, if one of them is local and has a mailbox full, none of the mails are delivered. Is backscatter prevention the cause of this problem?
Similar threads
