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

[Stefan Winter <stefan.winter AT restena.lu>]

Hello Anderson,

CAT's inability to send mail to your institution is not due to a bug in
the system but to the lack of standards compliance on the receiving side.

I'm afraid there is nothing we can do to fix that situation.

Greetings,

Stefan Winter

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


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

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature