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

[Gerald Vogt <vogt AT dkrz.de>]

Hi Stefan,

for what it's worth, the eduroam mail server seems to do something weird 
before sending. Here is an extract from our postfix log from one attempt:

postfix/smtpd[4983]: connect from cat-ams.eduroam.org[145.100.191.84]
postfix/smtpd[4983]: lost connection after EHLO from 
cat-ams.eduroam.org[145.100.191.84]
postfix/smtpd[4983]: disconnect from cat-ams.eduroam.org[145.100.191.84]
postfix/smtpd[4983]: connect from 
cat-ams.eduroam.org[2001:610:188:450:145:100:191:84]
postfix/smtpd[4983]: lost connection after EHLO from 
cat-ams.eduroam.org[2001:610:188:450:145:100:191:84]
postfix/smtpd[4983]: disconnect from 
cat-ams.eduroam.org[2001:610:188:450:145:100:191:84]
postfix/smtpd[4983]: connect from 
cat-ams.eduroam.org[2001:610:188:450:145:100:191:84]
postfix/smtpd[4983]: setting up TLS connection from 
cat-ams.eduroam.org[2001:610:188:450:145:100:191:84]
postfix/smtpd[4983]: Anonymous TLS connection established from 
cat-ams.eduroam.org[2001:610:188:450:145:100:191:84]: TLSv1.2 with 
cipher ADH-AES256-GCM-SHA384 (256/256 bits)

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?

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


--
Gerald Vogt
Energiemanagement
Abteilung Systeme

Deutsches Klimarechenzentrum GmbH (DKRZ)
Bundesstrasse 45a • D-20146 Hamburg • Germany

Phone:  +49 40 460094-127
Fax:    +49 40 460094-270
Email:  vogt AT dkrz.de
URL:    https://www.dkrz.de/

Geschäftsführer: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature