DirectAdmin 1.676

Bumped into an issue where a customer reported that one of their subdomains now returned a 404 error instead of the expected application.

The issue turned out to be a wrong pointer under the subdomains setup of their account.

For domain test.example.com it looked like this:
/domains/example.com/public_html/test
whereas it should have been:
/domains/example.com/private_html/test

The public_html folder exists, but only has a single index.html instead of the full application.

Fixing the mapping resolved the issue.
So not a big issue, but figured to report it.
--
Wil
 
fln said:
@wila The default Exim configuration does not log the incoming TCP port. Logging of incoming connection details can be enabled by customizing the /etc/exim.conf file and appending +incoming_interface to the log_selector field:

Code: 
...
log_selector = \
  +incoming_interface \
...

In main Exim log file /var/log/exim/mainlog the log lines will have I={ip}:{port} section, authenticated connections will have P=esmtpa or P=esmtpsa (if encryption is used). Quick grep over the logs that used 25 port (with or without encryption) would be:
Click to expand...
Since we should not modify the config file directly, how is this solved via the custom include file (/etc/exim.variables.conf.custom - there are several lines)?

Does an entry work in this form?:

log_selector = \
+incoming_interface \
+delivery_size \
+sender_on_delivery \
+received_recipients \
+received_sender \
+smtp_confirmation \
+subject \
+smtp_incomplete_transaction \
-dnslist_defer \
-host_lookup_failed \
-queue_run \
-rejected_header \
-retry_defer \
-skip_delivery \
+arguments
Click to expand...
what happens if the DA default configuration (for log_selector) is adjusted?

With cpanel the port is written to the logfile by default, I think that would also make sense here.
 
Last edited:
@Rolf B
All software logs scanner for Brute force Protection could go wrong, like csf firewall, BFM from Directadmin.
 
I'm seeing this when restarting Exim.
Code: 
exim 4.98.2 daemon started: pid=2847512, -q1h, listening for SMTP on port 25 (IPv6 and IPv4) port 587 (IPv6 and IPv4) and for SMTPS on port 465 (IPv6 and IPv4)
So SMTP on port 25? I thought this was disabled, or only for dovecot? Or is this correct as it is?
 
zEitEr said:
Mail servers still use TCP 25 for exchanging emails,
Click to expand...
Yep I'm aware of that. But I didn't know that was also called SMTP. In that case all is fine, thank you!
Because it says "listening on port 25 for SMTP" I got confused. I thought Exim would just send via port 25, not stating to itself to listen for smtp on port 25 for itself.
 
Historically, Simple Mail Transfer Protocol or SMTP only used port 25. Today, port 25 is still in use for SMTP, but it can also use ports 465, 587, others.
  • Port 25 is most used for connections between SMTP servers.
  • Port 465 was once designated for use by SMTP with Secure Sockets Layer (SSL) encryption.
  • Port 587 is now the default port for email submission. SMTP communications via this port use TLS encryption.
More reading: https://www.cloudflare.com/learning/email-security/what-is-smtp/
 
What will really confuse you in regards to SMTP and TLS. is whether or not if an email client (MSA) is being configured for implicit or explicit TLS.

As far as I know, Thunderbird makes a distinction (not necessarily a well described one). When you configure an outgoing mail server and choosing security it will allow you to select "SSL/TLS" or "STARTTLS".

STARTTLS is implied as being explicit TLS. This is where you connect to the SMTP server in plain text, but before the MSA actually sends anything, it issues a STARTTLS to request that the connection be upgraded to TLS.

SSL/TLS is implied (by reason of deduction from the above paragraph... this is why it's not a well described distinction) to mean an implicit TLS. Implicit TLS means that the connection is already secure when the daemon picks it up. HTTPS is an implicit TLS, the connection is already secured before the web server handles it (if you exclude the SNI part - which is effectively the same thing that the HOST header added in HTTP v1.1 allowing shared IPs among VirtualHosts).

The issue comes about when you have an MSA (some of the Windows ones come to mind) that simply configures the connection to "use a secure connection." Well... what type of secure connection is the client expecting with this? An implicit or explicit TLS connection?

If the MSA is expecting to issue a STARTTLS with the connection, then port 587 needs to be used so that a STARTTLS command can be issued.

If the MSA is expecting the entire connection to be sure - and no STARTTLS is being issued - then port 465 needs to be used. This assumes that 465 is listed as a tls_on_connect_ports in your exim.conf - /etc/exim.variables.conf on Directadmin.

What does "use a secure connection" mean in this context? Nobody knows.

If you choose wrong, then the connection's not going to do anything. If you think "use a secure connection" means that the MSA is going to issue a STARTTLS command - so you tell it to connect on port 587, but the MSA is expecting the connection to the implicit TLS - then the connection won't do anything because the TLS handshake will never complete.

If you think "use a secure connection" means that the the entire connection will be secured - implicit TLS - and tell it to connect on port 465, but the MSA is expecting to make an explicit TLS upgrade with STARTTLS then the connection won't do anything because the daemon listening on port 465 will be expecting a TLS handshake that it never gets.

This also applies with POP3 and IMAP. In whether to use an explicit STLS to upgrade a POP3 connection on port 110 or use an implicit TLS on connect on port 995. Or whether to upgrade an IMAP connection on port 143 with STARTTLS or use an implicit TLS on connect on port 993.

There really should be one de-facto standard for each of these protocols. I really thought explicit TLS was more of the standard, but I'm no longer sure.
 
You must log in or register to reply here.
Back
Top