The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Divisão de Rede/DTI/UFTM <rede.dti AT uftm.edu.br>]

Good Morning, Connections on TCP / 25 port are allowed, but the recommendations are the use of TCP / 587 TLS. Our perimeter firewall is implemented GeoIP control of connections from China, Russia, India and United Arab Emirates, as recommended by the manufacturer of the SonicWall firewall. Please report domains or LANs to add firewall rules to ignore GeoIP. graciously

___________________________________

Jihann Resende Marques Fernandes

Diretor da Divisão de Rede, Portaria: 337

DOU: 108, quarta-feira, 8 de junho de 2016

Universidade Federal do Triangulo Mineiro

Departamento: Tecnologia da Informação
Rua do Carmo, 143 - Bairro Abadia
CEP: 38025-000 - Uberaba-MG

34 3700 6432

Em ter, 30 de out de 2018 às 11:18, Stefan Winter <stefan.winter AT restena.lu> escreveu:

Hello,

> we are using the security connection in the number  port 587 with the
> TLS protocol in our server (mail.uftm.edu.br) because it's one the best
> practics of security in computer networking.

As stated, that is incorrect.

Submission (TCP/587) is the best practice for connections from a MUA to
an MTA (in other words, for mails sent from a end user computer/device
to a server which is willing to send my mail onwards across the planet).

MTA to MTA connections continue to run on SMTP (TCP/25). This is a
worldwide standard and hasn't changed since the early days of the internet.

An MX record in DNS indicates that you run a MTA which is willing to
receive mails as sent from other MTAs on behalf of their users. This has
to happen on port 25.

As of recent, these connections have a best practice of doing STARTTLS
on port 25 (opportunistic hop-by-hop encrpytion). That's something we
test for in CAT and warn the end user that the mail is not encrypted if
STARTTLS is not supported.

If you care about receiving mail for your users from arbitrary third
parties, please do set up an MTA that is capable of receiving mails on
TCP/25.

This is becoming an off-topic discussion for this list. Please do not
continue this thread here.

> Too, we aren't using protocol IPV6 ( AAAA) in our enviroment.

That's what I saw and it's not the root cause of the "mail could not be
sent" error.

> Please, use the informations mencioned for new tests.

There is nothing to test. Your mail server is not or only sporadically
listening on port TCP/25. You need to change that.

For reference, I dug out our mail server logs from the original off-list
mail I sent to you, and the one from this morning when I wrote the mail
to the list with you in cc:

Oct 26 13:42:44 smtprelay postfix/smtp[11026]: Untrusted TLS connection
established to mail.uftm.edu.br[200.131.62.18]:25: TLSv1.2 with cipher
DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 26 13:42:47 smtprelay postfix/smtp[11026]: BAED640BFF:
to=<humberto.parreira AT uftm.edu.br>,
relay=mail.uftm.edu.br[200.131.62.18]:25, delay=5.8,
delays=0.03/0/3.4/2.4, dsn=2.0.0, status=sent (250 Ok.
000000005BD2FDB6.00001BF7)

As you can see, your server *was* listening on port 25 as it should, and
the mail got through.

888FC40D76    14692 Tue Oct 30 09:42:01  stefan.winter AT restena.lu
         (connect to mail.uftm.edu.br[200.131.62.18]:25: Connection
timed out)

And this time it was not.

Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66