• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

SMTP Authentication no more?

S

Swakoo

Guest
Guys, I just realise I can send email even without SMTP authentication... and even without userid!

Relaying:
SMTP is ticked. I have even ticked POP3 but to no avail.

is there any reason why so?

And I see alot of emails being send to netzero. Compromise probably? But how do I switch it on manually first?

Maybe related to my this problem?
http://forum.swsoft.com/showthread.php?s=&threadid=26767
 
a check with /var/log/secure

shows alot of connections!

for example:

Jun 11 05:00:43 ns3 xinetd[3531]: START: smtp pid=28943 from=151.47.238.225
Jun 11 05:00:43 ns3 xinetd[3531]: START: smtp pid=28947 from=87.3.233.50
Jun 11 05:00:43 ns3 xinetd[3531]: START: smtp pid=28958 from=83.165.156.87
Jun 11 05:00:44 ns3 xinetd[3531]: START: smtp pid=28962 from=151.37.157.107
Jun 11 05:00:44 ns3 xinetd[3531]: START: smtp pid=28987 from=88.16.193.174
Jun 11 05:00:45 ns3 xinetd[3531]: START: smtp pid=29016 from=82.61.190.204
Jun 11 05:00:45 ns3 xinetd[3531]: START: smtp pid=29022 from=70.136.114.166
Jun 11 05:00:46 ns3 xinetd[3531]: START: smtp pid=29036 from=125.135.65.190

something to do with xinetd?
even when i remove -Rt0 mails still get send out very fast... as if it is skipping it!

Update:
ok duh me...

without smtp authentication, i can send locally (same box email addresses) but i can't send out.

But interestingly enough, people can just connect to this PLESK box and send to any of the local domain without authentication.. and from http://forums.ev1servers.net/showthread.php?t=62149 it seems to be a "feature"

But its dangerous isn't it...? anyone?
 
people can just connect to this PLESK box and send to any of the local domain without authentication
Well, of course the other side would not need to authenticate to deliver email to your users.... otherwise you would have a 'closed' email server.

The authentication is only needed for email which is to be sent out from your server to other servers.
 
wouldn't it be possible that this becomes an exploit by people to spam my local domains?
 
But what is the primary purpose for an email server? To accept incoming email for it's users, and to allow it's users to send outbound email. It is not an exploit, it is the normal function of an email server.

Limiting incoming spam is dependent upon how strict or loose you set things up. I don't know of any email server which can honestly claim to be 100% spam free, unless it's out of service...

With a Plesk server running Qmail, it is just a matter of what protection measures you put on your server, and of course, what settings you have in place for Spamassassin.

There are other methods for reducing spam you can implement on your server, but if you have shared hosting or are running on a VPS type service then your choices become more limited.
(stop me if I'm rambling on too much)
 
nah you aren't rambling, please don think this way. your words of wisdom always is appreciated :)

I get your point now.. heh.. silly me

but yeah.. spam is a big headache and i am thinking of how to counter it... other than buying the control panel for SA from plesk. your take?
 
I refuse to pay SWSoft for their SA GUI, I use ART's qmail-scanner instead. It's not a GUI, but it coordinates the AV and SA on the server and is quite effective.

It is compatible with many AV packages, but not Dr Web (dump DrWeb, remove it! )
 
Not normal!

James, I have to disagree with you. Sending (not to be confused with *receiving* from another MTA/SMTP) without authentication is a seriuos flaw, even if it's limited to local domains. In fact, being a local domain is worst, since any message sent *to the local domain and using an 'authorized' SMTP server* will bypass SPF records.

I'm almost convinced that this is not the normal function. The majority of SMTP servers I've know *do not* allow you to send messages without proper authentication, even if the destination is a local domain. AFAIK, only SMTP servers in Plesk box does that. This is definetively a flaw.

I'm constantly receiving spam and virus because of this problem in my Plesk boxes.
 
Re: Not normal!

This is definetively a flaw.

I disagree. SMTP has been around for atleast 20 years, back then this stuff never existed. If anything Qmail is compliant to earlier standards, not a flaw. It lacks a feature, not a flaw. A flaw (specifically a security flaw) is typically defined as a software defect that allows protection mechanisms to be bypassed. If the protection mechanism doesn't exist, it's not a flaw.

I know I have discussed this problem back and forth in another thread with you, but I can see it Qmail's way. Think about the scenario where I have my own ISP, they don't allow me talk SMTP to any server but theirs -- but I want to send an email as [email protected] to my support staff at [email protected]. If Qmail forces authentication then this breaks (which traditionally has ALWAYS worked!), and potentially violates the SMTP protocol. This is a very very valid case in many hosting environments.

I fail to see how this would work any other way, you can't authenticate remote connections that are sending to local domains, but you can authenticate remote connections that are sending to non-local domains (considered relaying) and Qmail does that.

The other problem with Qmail is that it is a poorly managed & distributed package and you have to resort to patching it to make it reasonably robust.

Naturally things change and they progress, but it doesn't necessarily mean the MTA you are using supports the features you want. See the paragraph above, it is one huge reason why Qmail falls flat on it's backside. I personally would prefer another MTA integrated with Plesk, I could care less if Qmail is the most secure -- I find it hard to believe that Qmail is the most secure MTA when you have to apply 30 patches from 30 different totally untrusted sources because the maintainer fails to maintain it.
 
I did not say that sending should not be authenticated. Maybe I formed my sentence poorly.

I was trying to say that incoming email from outside is the primary purpose of an email server.

Sending by the hosted users, of course, would be by authentication only.
 
Wagner, I understand this is the way SMTP is. Matter of fact that's exactly the problem. SMTP is so old that it wasn't build to be secure. But that's a long history I'm sure you know.

I've misused the term "flaw" (sorry I'm not a native english speaker/writer). My point is that Plesk does not implement a very common (and welcome) security measure to avoid the described problem (sending e-mail to local domains without providing authentication).

Of course the server must be able to *receive* messages from other servers whitout asking for credentials or authentication. But, what I'm saying is that the server must aways ask for authentication to *send* (originate, create, etc) messages through it. It's slightly different. Try for yourself, using the examples I've posted here .

Yes, it's possible to also ask for authentication (SMTP_AUTH or "POP before SMTP) for messages destinated to the local domain, when those messages are sent using the local SMTP address. This behaviour will prevent malicious users (1) claiming to be from one of your local domains to (2) use your SMTP server to (3) send messages to users within your local domains, whitout being prompt for credentials. I just don't know how to do it using Plesk.

I've used the word "flaw" because I believe this is the kind of protection that Plesk must include, since it's not difficult to implement and increases SMTP security a lot more. Matter of fact, I belive Plesk is a flawed product if you want to use it as a mail server, but of course that's my opinion.

I'm still looking for a solution since this "flaw", "feature" (whatever :D) is beeing used against my Plesk servers.
 
Yes, it's possible to also ask for authentication (SMTP_AUTH or "POP before SMTP) for messages destinated to the local domain, when those messages are sent using the local SMTP address. This behaviour will prevent malicious users (1) claiming to be from one of your local domains to (2) use your SMTP server to (3) send messages to users within your local domains, whitout being prompt for credentials. I just don't know how to do it using Plesk.
Does this mean that from the control panel, in "SERVER" - "MAIL", on the Preferences tab, you do not have "Authorization is required" selected? And a checkmark next to SMTP (but no checkmark next to POP3) ?

This requires all email coming from clients to do SMTP_Auth, even if they are going to send to their own local domain (like another employee at their same company).

Or am I still not understanding what your problem is?
 
Of course the server must be able to *receive* messages from other servers whitout asking for credentials or authentication. But, what I'm saying is that the server must aways ask for authentication to *send* (originate, create, etc) messages through it. It's slightly different.

Actually it is not different. Qmail has no idea whether someone using TCP/IP is another server or a client. Qmail only implicitly trusts clients that use qmail-inject, otherwise the TCP/IP clients must go through a certain set of scenarios that determine whether it is acceptable.

Yes, it's possible to also ask for authentication (SMTP_AUTH or "POP before SMTP) for messages destinated to the local domain, when those messages are sent using the local SMTP address. This behaviour will prevent malicious users (1) claiming to be from one of your local domains to (2) use your SMTP server to (3) send messages to users within your local domains, whitout being prompt for credentials. I just don't know how to do it using Plesk.

And I gave a very very valid case (that is common practice!) why you wouldn't use such a feature. And why it would break the protocol.

Additionally, the implementation "SMTP authentication" you are talking about is to allow relaying, and relaying is defined as the TO is not within my valid list of rcpthosts. Your case doesn't meet this criteria.


In any event, you can continue to believe whatever you want -- but I have noticed that you haven't really gotten anywhere, which makes me believe it is not a flaw or a standard feature. I would suggest if you really really really want to pursue it then you should chase it on the Qmail mailing lists, as that is where the true experts would be hanging out. If you do find something there then please post back, I would be interested in hearing the pros & cons of this feature.


Personally, I think people are too fanatical about stopping spam. At some point they will block legitimate messages and clients will notice when they lose important messages, they would prefer to be in control with what mail is good and bad.
 
Does this mean that from the control panel, in "SERVER" - "MAIL", on the Preferences tab, you do not have "Authorization is required" selected? And a checkmark next to SMTP (but no checkmark next to POP3) ?

This requires all email coming from clients to do SMTP_Auth, even if they are going to send to their own local domain (like another employee at their same company).

Actually the POP3 checkbox only applies to relaying, if you are sending it TO a local domain no authorization is required at all. Alex is talking about something different than relaying, he is talking about the case where the FROM & TO are the same domain but since the FROM is in his rcpthosts he believe Qmail should require authentication. Which I agree sounds legitimate at first, but there a consequences of such a feature.

BTW, this is what Plesk says about those switches (which are applicable to relaying, and again relaying is defined as the TO is not within my rcpthosts):

The Relaying fields are used to set the mail system relay mode. Mail relaying can work in one of three modes: closed relay, relay with authorization and open relay.

Selecting closed will only allow mail to be sent and received locally (to and from domains residing on the server). The only exception would be hosts specified as allowed relay hosts in the White List.

Selecting authorization is required will allow any host computer to utilize the mail services of a domain on the server provided that a valid username and password are used to authenticate the mail user.

In the authorization required mode you can use the following authorization types:

POP3 - requires a POP3 login before sending mail. The lock time field sets the allowed time given for sending mail after login.

SMTP - SMTP authorization (Plesk mail system supports LOGIN, CRAM-MD5 and PLAIN methods of SMTP authorization)
 
Wagner, not only when FROM and TO are the same, but also when FROM and TO are different, as long as TO belongs to a local domain. Plesk will aways send messages to local domains whitout asking for credentials... Ok, I know... that's the expected behaviour, otherwise will not be able receive messages from outside. But wait. Many Qmail servers I've know do require for authentication even if you're sending messages to a local domain. And they do that for a good reason I think. What are the difference? Patches?

I'll try to elaborate with an example:

Take one of your Plesk box and do the following (with command prompt):

01: telnet YOURPLESKBOX.COM 25
02: 220 YOURPLESKBOX.COM ESMTP
03: helo
04: 250 YOURPLESKBOX.COM
05: mail from:[email protected]
06: 250 ok
07: rcpt to:[email protected]
08: 250 ok
09: data
10: 354 go ahead
11: subject=test
12: content
13:.
14: 250 ok 1149023436 qp 11545
15: quit
16: 221 YOURPLESKBOX.COM
17: Connection closed by foreign host.

Message is delivered without authentication. For a more realist test, you can use an e-mail client (ie. Outlook) to send messages claiming to be "[email protected]" (or worst: claiming to be a local user - TO=FROM - bypassing SPF and other checks), and, of course, using *no* authentication at all.

You only need to specify your Plesk IP or host address as SMTP server and you're ready to inject anything into local domains, whitout being prompt for credentials. Again: this is a expected behaviour - if you want to receive external messages - but yet, it's definitively not a common thing among many SMTP servers I've know.

Try for for yourself with other SMTP servers you know (ie: know ISP, companies and others). You *wont* be able to send messages to local domains without providing credentials. I have one Qmail server that shows that. It's IP is 200.234.205.147, and "hubner.org.br" is a local domain. Feel free to test. You'll se that even if the message is destinated to a local domain (hubner.org.br), Qmail will aways ask for authentication, returning an error message: "553 THIS SERVER IS TO BE USED WITH AUTHENTICATION (#5.7.1)" if you didn't provide one. And yes, I do receive messages from anybody in this server, it's not a close relay.

That's what I want to do with Plesk.

James: yes, I'm using authentication under Plesk "Mail" settings

UPDATE: I believe Plesk 8.0 behaviours the same.
 
Alex,
Plesk 8.0 does include SPF. It may be worthwhile for you to upgrade to get that bleeding edge feature. If not then take a look at qmail-spp.

SPF is a bit bleeding edge, and has several negative impacts that cannot be ignored here.

Good luck anyways.
 
woah guys,

your discussion is surely an eye opener.

I think what alexhubner mentioned covered my initial concerns/questions:

any users is able to send mails to the local domains within a PLESK box, without any authentication.

Shouldn't it require a login/password to send mails even to local domain, just like when we need to auth ourselves when we send out of the box?

Really interesting discussion :)
 
I have one Qmail server that shows that. It's IP is 200.234.205.147, and "hubner.org.br" is a local domain. Feel free to test.
Since you call this a Qmail server (not a Plesk server), the question is - what version of Qmail and what additional qmail patches have been placed onto that server?

This appears to be a 3rd party server (not your plesk server), possibly your hosting company/data center (LocaWeb) uses it for hosted clients to use for Sending outbound. And you appear to be using Gmail servers for incoming emails. If this is true, then it would be a 'closed' mail server as posted earlier.

A Plesk server uses the basic Qmail package without many of the patches which are available on the internet. Not all Qmail servers are equal, unfortunately Plesk did not design things to make it easy to apply patches to qmail.
 
Originally posted by Swakoo
Shouldn't it require a login/password to send mails even to local domain, just like when we need to auth ourselves when we send out of the box?
Since the SMTP server does not know or care if the outside connection is a client or another server, and it is told that there is an incoming email for a locally hosted domain, there would be no need for any authentication. It is an incoming email for a locally hosted domain, again, this is a normal function of any SMTP server, to receive incoming emails from the outside world for users of the locally hosted domains.

If every incoming email to your email server had to be done by authentication, then every possible email server in the world would have to be configured with valid credentials for your server, my server, everyone else's server. Otherwise no email would flow around the world at all.

I think the problem here may be that some may 'think' that since the connection is at the Plesk server, (see alexhubner's telnet commands) that the email is 'originating' from the Plesk server. This is not the case. The telnet commands are the basic commands which happen when a connection is established from one server to another. The email message is not being originated or 'sent' from the Plesk server. All incoming email messages from the outside world, obviously, must pass the message to the Plesk server to be delivered to the local email box.
 
The telnet commands are the basic commands which happen when a connection is established from one server to another. The email message is not being originated or 'sent' from the Plesk server.
Yes it is. Telnet was just an example (to make possible to paste the responses from the SMTP server). You can send messages using the Plesk IP address with any e-mail client. And the message wil be sent through Plesk.

If this is a normal behaviour, why you can't do the same with (for example) AOL SMTP servers?

Try for your self:

1) Use your prefered e-mail client;
2) Create an ordinary account for the e-mail "[email protected]";
3) Use "smtp.aol.com" as SMTP server for this account and do not enter any authentication method;
4) Send a message to [email protected] (it can be a valid user if you want).

You wont be able to send the message. In Thunderbird email client (that I've used), you will receive an error message that states:An error occured while sending mail. The mail server responded: CLIENT AUTHENTICATION REQUIRED. USE ESMTP EHLO AND AUTH. . You'll find variations of the error message if you try different SMTP servers, from large ISP or companies. Aol is just an example. I gave one above: 200.234.205.147 (which is smtp.hubner.org.br). You are aways prompt to credentials, even if the destination domain is local.

But if your SMTP server is hosted by Plesk, you aways be allowed to send messages. That's the problem.
 
Back
Top