0

I want to block smtp 25, pop 110 & imap 143 and only use secured smtps 465, pop3s 995 & imaps 993. Are there good reasons to let port 25,110,143 open?

  • 2
    More detail. Block what from what and from whom? – ewwhite Aug 29 '15 at 19:34
5

Actually the ports you mentionned, 465, 995 and 993 are deprecated and should no more be used.

See RFC2995 section 7

  1. imaps and pop3s ports

    Separate "imaps" and "pop3s" ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLS commands.

    A number of problems have been observed with separate ports for "secure" variants of protocols. This is an attempt to enumerate some of those problems.

    • Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. For example, many web pages use language like "click here if your browser supports SSL." This is a decision the browser is often more capable of making than the user.

    • Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Thus the separate port distinction makes the complex topic of security policy even more confusing. One common result of this confusion is that firewall administrators are often misled into permitting the "secure" port and blocking the standard port. This could be a poor choice given the common use of SSL with a 40-bit key encryption layer and plain-text password authentication is less secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.

    • Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. The desirable security policy "use TLS when available" would be cumbersome with the separate port model, but is simple with STARTTLS.

    • Port numbers are a limited resource. While they are not yet in short supply, it is unwise to set a precedent that could double (or worse) the speed of their consumption.

Regarding port 465 for SMTPS it was even re-assigned by IANA to a different usage:

urd 465 tcp URL Rendesvous Directory for SSM

Source : http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=9

Specifically for SMTP , a mail server should (in most case) accept uncrypted communication, since it will likely received email from server that will not propose TLS.

However it is also advise to use port 25 for server to server mail transfer and use port 587 for mail submissions from clients.

See RFC2476

Extract:

  1. Message Submission

3.1. Submission Identification

Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with additional restrictions as specified here.

While most email clients and servers can be configured to use port 587 instead of 25, there are cases where this is not possible or convenient. A site MAY choose to use port 25 for message submission, by designating some hosts to be MSAs and others to be MTAs.

Regarding POP3, IMAP, and mail submission on port 587, you can enforce encryption on the standard ports 110, 143, 587 by configuring you server to refuse connection not encrypted with TLS. (and it is strongly advised to do so).

  • 1
    While quite true, the attitude shown in this RFC has set back email security by decades. This was written when many people still had no idea the NSA even existed, let alone does what it does today. It's the insecure ports which should be deprecated, analogous to the "HTTPS Everywhere" movement for web sites. – Michael Hampton Aug 29 '15 at 21:19
  • 2
    It's not the port that is secure or insecure, it's what you run behind. As stated in my answer you CAN and should refuse non-TLS-encrypted connection. – JFL Aug 29 '15 at 21:34
1

Since STARTTLS can be issued within plain session there is no reason to use ports other than standard 25/110/143.

If the other side can use TLS - let there be TLS. If no, then a plain unencrypted session will occur.

0

Ports 110 & 143: If i let open 110 (pop3s) & 143 imaps, it means that users can download mails in plain text to their clients.

Port 25: If i block the port 25, users will be unable to send mails in plain text. But there is something i have just tested now. The mail server will be unable to receive mails because mails will not be able to be received. In fact, mail servers communicate through port 25.

  • 1
    It's not a conspiracy; it's just legacy. Many relays and MTAs support opportunistic TLS, but not all, so (as you've found) you can't really require it. – Falcon Momot Aug 29 '15 at 21:25
  • 2
    @FalconMomot And it is worth noting that SMTP with opportunistic TLS uses port 25 juts like unencrypted SMTP. – kasperd Aug 29 '15 at 22:49
  • @FalconMomot for sure, on port 25, TLS is not mandatory. You are right, i have seen in raw headers of some mails that there were no TLS. On the other hand, i have checked with gmail & hotmail and there is always something like (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128) in raw headers. – Nicolas Guérinet Aug 30 '15 at 8:19
  • Yes, major providers usually support it, but all kinds of people don't. – Falcon Momot Aug 30 '15 at 8:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.