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

[Stefan Winter <address@concealed>]

Hello,

> It first connects from the IPv4, then from the IPv6 and then again from
> the IPv6. During the first two connections it only does an "EHLO
> eduroam.org" and after the response ends the connection with a TCP FIN.
> 
> During the third connection it actually does an "EHLO
> cat-ams.eduroam.org" and then continues with STARTTLS and delivering the
> e-mail.
> 
> The first two attempts seem to happen for all servers listed in the MX
> records.
> 
> I suppose an painstaking firewall could take the first, disconnected
> connection as a reason to block the sender IP address.
> 
> Do you know why it does this?

Well, yes, I wrote the code :-)

We want to find out whether the mail will be sent with transport
encryption (and inform the admin about that fact).

Since we don't necessarily have access to the actual SMTP server and its
logs, we need to do the legwork to figure this out ourselves.

Only if all MX servers on all IP versions indicate support for STARTTLS,
our STARTTLS-using SMTP server will deterministically be able to deliver
the mail with (opportunistic) transport security enabled. If one doesn't
respond, or does not have STARTTLS, there is a chance that the mail will
be sent unencrypted.

So we connect to each and every one, see if they have STARTTLS
capability, and produce the UI feedback after sending the mail accordingly.

Greetings,

Stefan

> 
> Regards,
> 
> Gerald
> 
> On 09.11.18 12:28, Stefan Winter wrote:
>> 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
>>> <address@concealed <mailto:address@concealed>> 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
>>>      > <address@concealed <mailto:address@concealed>
>>>      <mailto:address@concealed
>>> <mailto:address@concealed>>>
>>>      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=<address@concealed
>>>      <mailto:address@concealed>
>>>      >     <mailto:address@concealed
>>>      <mailto:address@concealed>>>,
>>>      >     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
>>>      address@concealed <mailto:address@concealed>
>>>      >     <mailto:address@concealed
>>>      <mailto:address@concealed>>
>>>      >              (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