Facebook
Twitter-
The BIND DNS server has already been deprecated and removed from Plesk for Windows.
If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release. -
The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.
A
alexhubner
Guest
Thanks, I'm aware of this. Actually the Plesk support say that I need to contact my ISP (ThePlanet) which is the owner of the Plesk lisence installed on my box. The Planet support says they can't do anything and insist that this is a "expected" behaviour. I agree, it can be a "expected" behaviour, but it's definetively not a desired and a good behaviour.
Still looking for a way to workaround this in Plesk. Again: if others are doing (and protecting their clients), why it can't be done in Plesk?
Still looking for a way to workaround this in Plesk. Again: if others are doing (and protecting their clients), why it can't be done in Plesk?
W
wagnerch
Guest
I think you already answered your question, it can. You just need to own the license with SWsoft so you can start a ticket, or find out about how to request a feature. Have you asked the question on the Qmail mailing lists yet? I don't think your going to get your answer here.
B
Bast
Guest
Any update on this?
I'm having the same problem under Windows.
I'm having the same problem under Windows.
T
thomdf
Guest
I agree, its a problem
I think the example given several posts ago, where an ISP limits which SMTP server a person can talk to, is a minor problem compared to anyone being able to spoof internal users to blast internal domains with garbage e-mail that can get around spam filters because of the source address. I think thats a minor problem because the percentage of ISPs that actually do that is probably very low and certainly none of my users have that issue. My users do have the issue of e-mails being sent in with spoofed internal addresses.
So that brings about this valid scenario, when you use auto-whitelist with spamassassin, and an e-mail gets spoofed with an internal address but the content is spam? Auto-whitelist automatically whitelists it because its an internal address of the sender. That stinks. Either you live with it or shut off auto-whitelisting in spamassassin all because of this Qmail issue.
I think at a minimum it should be an option that should be allowed via a checkbox in Plesk so the administrator has the ability to stop that if they want to.
Also someone else mentioned that they thought version 8 had this same behavior, I have confirmed it on version 7.5.3 and version 8.x.
I did a quick check though that seems to support this as normal behavior by all the major free email players:
yahoo = allows unauthed joe@yahoo.com to joe@yahoo.com
aol = inconclusive
google = allows unauthed joe@google.com to joe@google.com
hotmail = allows unauthed fred@hotmail.com to fred@hotmail.com
I still wish I had the ability to stop this normal behavior.
qmail-spp doesn't seem to help by the way, I have tried and it never "sees" any auth information from plesk even when sending from an e-mail client that is definately authing (tcpdump confirmed). The environment variables for auth never get set. If qmail-spp actually did see the authing a person could have a plugin check if its authed when the rcpt and mail addresses match.
I just did some further checking, qmail-spp never seems to invoke auth plugins. Looking at the qmail-spp page I see that there are several versions of an auth patch for it based on which version of the qmail auth patch was implemented for qmail. They probably have patched qmail with qmail-spp only and not the qmail-spp-auth patch. If I had this, it would be easy to write a plugin that checked the sender, receiver--if both are local, make sure that the user auth'd. This is true for 7.5.3 I have not tested it on 8.0.1 yet.
I think the example given several posts ago, where an ISP limits which SMTP server a person can talk to, is a minor problem compared to anyone being able to spoof internal users to blast internal domains with garbage e-mail that can get around spam filters because of the source address. I think thats a minor problem because the percentage of ISPs that actually do that is probably very low and certainly none of my users have that issue. My users do have the issue of e-mails being sent in with spoofed internal addresses.
So that brings about this valid scenario, when you use auto-whitelist with spamassassin, and an e-mail gets spoofed with an internal address but the content is spam? Auto-whitelist automatically whitelists it because its an internal address of the sender. That stinks. Either you live with it or shut off auto-whitelisting in spamassassin all because of this Qmail issue.
I think at a minimum it should be an option that should be allowed via a checkbox in Plesk so the administrator has the ability to stop that if they want to.
Also someone else mentioned that they thought version 8 had this same behavior, I have confirmed it on version 7.5.3 and version 8.x.
I did a quick check though that seems to support this as normal behavior by all the major free email players:
yahoo = allows unauthed joe@yahoo.com to joe@yahoo.com
aol = inconclusive
google = allows unauthed joe@google.com to joe@google.com
hotmail = allows unauthed fred@hotmail.com to fred@hotmail.com
I still wish I had the ability to stop this normal behavior.
qmail-spp doesn't seem to help by the way, I have tried and it never "sees" any auth information from plesk even when sending from an e-mail client that is definately authing (tcpdump confirmed). The environment variables for auth never get set. If qmail-spp actually did see the authing a person could have a plugin check if its authed when the rcpt and mail addresses match.
I just did some further checking, qmail-spp never seems to invoke auth plugins. Looking at the qmail-spp page I see that there are several versions of an auth patch for it based on which version of the qmail auth patch was implemented for qmail. They probably have patched qmail with qmail-spp only and not the qmail-spp-auth patch. If I had this, it would be easy to write a plugin that checked the sender, receiver--if both are local, make sure that the user auth'd. This is true for 7.5.3 I have not tested it on 8.0.1 yet.
B
Bast
Guest
Thanks for your reply.
It would indeed be nice it there would be an option to dis-allow outsiders to use the our server to mail inside.
I started to use MAPS spam protection, works pretty good. Spam reduced a lot.
Didn't try Spamassassin yet, because it doesn't seem to work on aliases.
It would indeed be nice it there would be an option to dis-allow outsiders to use the our server to mail inside.
I started to use MAPS spam protection, works pretty good. Spam reduced a lot.
Didn't try Spamassassin yet, because it doesn't seem to work on aliases.
Maybe edit the rcpthosts file?
So I noticed I could send bogus email to domains managed by my plesk front end without authentication so long as I used the server the domain resides on as my SMTP server.
I wanted to fix this, but know nothing about qmail authentication or the like.
I'm not sure if this was a good idea or not but if fixed my issue. Qmail uses an rcpthosts file to define its local domains. Well if you remove the local domains from that file then voila I can't send email TO my local domain, FROM my local domain, WITHOUT authenticating. I get an error about "that is not in my list of allowed rcpthosts".
This link should help... http://qmail-support.blogspot.com/2005/05/what-is-qmail-rcpthosts.html
So I noticed I could send bogus email to domains managed by my plesk front end without authentication so long as I used the server the domain resides on as my SMTP server.
I wanted to fix this, but know nothing about qmail authentication or the like.
I'm not sure if this was a good idea or not but if fixed my issue. Qmail uses an rcpthosts file to define its local domains. Well if you remove the local domains from that file then voila I can't send email TO my local domain, FROM my local domain, WITHOUT authenticating. I get an error about "that is not in my list of allowed rcpthosts".
This link should help... http://qmail-support.blogspot.com/2005/05/what-is-qmail-rcpthosts.html
Similar threads
