Hello all,
Would any of you know if the following scenario is "doable"?
We run an old Exchange 2010 infrastructure at my work, and there is no way
they are going to spring for newer: getting them to go from 2003 to 2010
was an ordeal...
Could I set up an Ubuntu Postfix "relay" server between Exchange and the
Internet, that also permits one particular mailbox to be accessible from a
Dovecot install on the same server (as well as relaying the mail for that
mailbox to Exchange)?
Yes/no and pointers most welcomed.
Kind regards
Murray Crane
I'm trying to set up SPF for my carfax.org.uk domain (whence this
email comes). I'm getting a bounce from trying to send to gmail:
Diagnostic-Code: smtp; 550-5.7.26 This mail is unauthenticated, which poses a
security risk to the
550-5.7.26 sender and Gmail users, and has been blocked. The sender must
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
550-5.7.26 DKIM checks did not pass and SPF check for [savella.carfax.org.uk]
550-5.7.26 did not pass with ip: [2001:ba8:1f1:f0e6::2].
However, I think I have the right TXT record in the DNS for carfax.org.uk:
@ TXT "v=spf1 mx a ip4:85.119.84.138/21 ip6:2001:ba8:1f1:f0e6::/64 a:mail.carfax.org.uk a:savella.carfax.org.uk -all"
and the diagnostic message from gmail isn't all that helpful about why
it's not matching.
Does anyone have any idea what I've missed here?
Thanks,
Hugo.
--
Hugo Mills | One of these days, I'll catch that man without a
hugo@... carfax.org.uk | quotation, and he'll look undressed.
http://carfax.org.uk/ |
PGP: E2AB1DE4 | Leto Atreides, Dune
Hi,
Back at the start of June the version of OpenSSH that we run on the
Xen Shell hosts was updated in order to provide support for
ecdsa-sk and ed25519-sk keys. These are used with "security key"
devices which support FIDO/U2F and was done after customer request.
At the same time this version of SSH disables the ssh-rsa signature
scheme. Older ssh clients may fail to negotiate an SSH connection to
the Xen Shell hosts (i.e. when you do "ssh
username(a)username.console.bitfolk.com") due to this.
If you see an error that reads something like this:
Couldn't agree a key exchange algorithm (available
curve25519-sha256,curve25519-sha256(a)libssh.org,ecdh-sha2-nistp256,
ecdh-sha2-nistp384,ecdh-sha2-nistp512,diffie-hellman-group16-sha512,
diffiehellman-group18-sha512,diffie-hellman-group14-sha256)
then this is the problem. You do not need to change your
authentication keys (if any) because that is not the problem. You
need to upgrade your SSH client.
The above message was from PuTTY 0.64; version 0.78 and above are
known to work.
ssh-rsa was deprecated since version 8.2 of the server in February
2020:
https://www.openssh.com/txt/release-8.2
Future deprecation notice
=========================
It is now possible[1] to perform chosen-prefix attacks against
the SHA-1 hash algorithm for less than USD$50K. For this reason,
we will be disabling the "ssh-rsa" public key signature
algorithm that depends on SHA-1 by default in a near-future
release.
[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1
and Application to the PGP Web of Trust" Leurent, G and
Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdf
It was then disabled from version 8.8 in September 2021:
https://www.openssh.com/txt/release-8.8
Potentially-incompatible changes
================================
This release disables RSA signatures using the SHA-1 hash
algorithm by default. This change has been made as the SHA-1
hash algorithm is cryptographically broken, and it is possible
to create chosen-prefix hash collisions for <USD$50K.
For most users, this change should be invisible and there is no
need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing
ssh-rsa keys will automatically use the stronger algorithm where
possible.
If you are unsure whether this affects you, just verify that you can
connect to your Xen Shell host. If you can't, and you can't find a
way to upgrade your client (or doing so is ineffective), please let
us know at support(a)bitfolk.com.
Again, this not about rsa authentication keys. You do not need to
abandon ssh-rsa public keys:
https://ikarus.sg/rsa-is-not-dead/
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
I did this yesterday and thought that others might be interested in the issues that I came across. It wasn’t quite as smooth as the upgrade to Bullseye this time last year but there were no show-stoppers.
The main issues were:
1. Interface renaming from eth0 to enX0 (as previously mentioned by Andy). Just remember to update /etc/network/interfaces before you reboot for the first time after the upgrade. If you forget, do it via the console and reboot (or ifup enX0). Don’t forget to update anything else that references eth0 - I forgot to update my ip6tables config and wondered for a minute why there was no IPv6 firewalling…
You can, of course, choose to keep using eth0 but I like to move with the times :)
2. mrtg now runs in daemon mode rather than being called regularly via cron. It will ask if you want the cron entry removing as part of the upgrade. In my case, I had set up mrtg a few years ago to use /var/www/mrtg for output and for the config file to be /etc/mrtg.cfg. After yesterday’s upgrade, the new version expects the config file to be at /etc/mrtg/mrtg.cfg and uses /var/www/html/mrtg, so I needed to do some minor Apache httpd reconfiguration.
I also had to add "Interval: 5” to mrtg.cfg for it to poll every 5 minutes.
3. Exim - this one was a bit strange. The upgrade to Exim 4.96 failed with "option "message_linelength_limit” unknown” while running the post install script.
I use a split config so worked round this by commenting out this setting from both
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp
and
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost
then re-running the upgrade. I don’t know if this is the right way to solve this but it worked for my setup.
I think those were the only issues I came across (I have a short memory) but will mention anything else that I remember (or come across).
Cheers,
Mike
