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,
Recommendations are not laws.
The management that we adopt works and meets the requirements and current security policies.
Verify that what you need is in compliance and proceed with our request.
Att

___________________________________

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 sex, 9 de nov de 2018 às 05:04, Stefan Winter <stefan.winter AT restena.lu> escreveu:

Hello,

> Good Morning, Connections on TCP / 25 port are allowed, but the
> recommendations are the use of TCP / 587 TLS.

I don't know who gave you that recommendation, but it is wrong. There is
a difference between mail submission and mail transfer. Transfer has
always been and is exclusively and legitimately on TCP/25. And transfer
is what MX servers do.

Read the introduction of RFC 2476 for a rationale and discussion. Or ask
any savvy email domain administrator in your vicinity.

> 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

Our servers are not located in any of those countries. It is also a
terrible idea to block whole countries. You are saying there will never
be any legitimate email coming from those countries and the people there
are all spammers.

Frankly, this is a filtering strategy from the last century.

And then it doesn't even work. If the CAT invitation mails are blocked
by your GeoIP, then that filter is apparently blocking mails from The
Netherlands in Europe. We might decide to switch our sending server to
the UK or Croatia in the future, also in Europe. If blocking countries
from Europe is not what you configured, complain to the filter vendor.

I will not entertain things like subnet whitelisting for you. You really
need to learn how to operate a MX server in a contemporary way.

Greetings,

Stefan Winter

>
> ___________________________________
> 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 <mailto: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
>     <http://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
>     <http://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
>     <mailto:humberto.parreira AT uftm.edu.br>>,
>     relay=mail.uftm.edu.br <http://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
>     <mailto:stefan.winter AT restena.lu>
>              (connect to mail.uftm.edu.br
>     <http://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
>


--
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