[db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois

Colleagues

I know none of you want to talk about any redevelopment of the RIPE
Database. Not even doing it bit by bit. I keep reminding you that it
is a 30 year old design and barely fit for purpose in the modern
world. But still you all want to keep this dinosaur even though it is
now on life support. However, the environment in which the RIPE
Database lives and operates IS constantly changing. It is only the
database that stands still. This latest move by Google and Yahoo to
combat spam is another nail in the coffin of the RIPE Database. It
simply cannot continue to operate in the way it has for the last 30
years. The environment in which the database operates is outside of
our control. Technology and regulations evolve. They are not going to
be adapted to accommodate the RIPE Database just because we don't want
to change anything. At any moment a big tech company or regulatory
authority can just announce that a change is coming that may cripple
the RIPE Database. Then we are thrown into panic mode, trying to adapt
and modify an ancient product to keep it alive in a modern
environment. Could you imagine Apple trying to keep a 30 year old
version of OSX working in today's environment?

This new anti-spam measure is a convenient point to reflect on how one
part of the RIPE Database is used. Notifications are just one part of
an audit system. Many other parts are missing. To be sending out 30k
emails a day to hundreds of thousands of email addresses stored in a
public database as part of an incomplete audit system has to stop.
Notification emails on this scale are a relic of the past. Just
thinking out aloud, perhaps what we need is to extend the LIR portal
to an account system for anyone who maintains data in the RIPE
Database. Through that account a complete audit trail will be
accessible to designated people with an SSO credential. That audit
trail should contain fully indexed details of what data has been
created, updated and deleted, when, who did it, from where, by what
means, using what authorisation, what the outcome was, for example.
The audit trail will contain details of all updates no matter which
interface was used. Currently if you update using the web interface
the details of the update are lost to the user when you close your
browser. You may be notified, but the who, when, how is lost. All of
those details will be saved in a full audit trail. When you log into
your account there will be messages to tell you data has changed so
authorised people can check the changes. ALL attributes related to any
form of notification can then be removed from the RIPE Database. NO
emails will be sent out relating to notifications or acknowledgements.
That will avoid all this spam sent out by the RIPE NCC and other spam
received on the emails harvested by abusers from the database and take
a lot of pressure off the RIPE NCC who have to maintain this archaic
email service to such a high service level. The RIPE NCC currently
archives all data related to updates. That is updates received, ack
and notif messages sent out. As long as these audit trails are
non-editable by users that can replace the current archive system
maintained by the RIPE NCC. Extending the LIR portal to accounts for
any data holder can be used later for a number of other improvements.

What we need now from the community is agreement to ask the RIPE NCC
database engineers to have an ideas storming session to come up with
an outline design for such an audit trail system to replace all the
notifications. The time really has come to start replacing some bits
of the old RIPE Database system. I hope, finally, some of you will
agree with me...

cheers
denis
co-chair DB-WG

========================================================
DISCLAIMER
Everything I said above is my personal, professional opinion. It is
what I believe to be honest and true to the best of my knowledge. No
one in this industry pays me anything. I have nothing to gain or lose
by any decision. I push for what I believe is for the good of the
Internet, in some small way. Nothing I say is ever intended to be
offensive or a personal attack. Even if I strongly disagree with you
or question your motives. Politicians question each other's motives
all the time. RIPE discussion is often as much about politics and self
interest as it is technical. I have a style of writing that some may
not be familiar with, others sometimes use it against me. I also have
OCD. It makes me see the world slightly differently to others. It
drives my mind's obsessive need for detail. I can not change the way I
express my detailed opinions. People may choose how to interpret them.
========================================================

On Thu, 14 Mar 2024 at 17:04, Edward Shryane via db-wg <db-wg at ripe.net> wrote:
>
> Dear colleagues,
>
> As part of the Whois 1.111 release planned for 28th March, we will make changes to comply with new requirements for bulk email senders from two of the large email providers, namely Google [1][2] and Yahoo [3][4]. The RIPE NCC are reviewing these requirements across all our services. Please refer to the RIPE Labs article published today [5].
>
> We send a lot of mail from Whois, on average 30,000 messages a day (comprised mostly of update acknowledgements and notifications) which qualifies us as a bulk sender. We want to comply with these requirements as we depend on email for notifications but also to listen to our users wishes. There are nearly 900,000 email addresses in the RIPE Database. 65,000 are hosted by Google and 5,000 by Yahoo, so these addresses are directly affected by these requirements.
>
> In this release, we will implement mail bounce detection (i.e. an outgoing message has permanently failed delivery) and also unsubscription (i.e. one-click unsubscribe from a mail client). Once an address is undeliverable or unsubscribed, we will not send further Whois update acknowledgements or notifications to that address. However we will continue to send targeted notifications where required by RIPE policy (e.g. abuse-c validation, RIPE-NONAUTH route object cleanup etc.).
>
> Notification attributes in the RIPE Database (i.e. irt-nfy, mnt-nfy, notify, ref-nfy, upd-to) will be affected, as we will no longer send update notifications to an unsubscribed or undeliverable address. In update acknowledgements we will warn if any address is undeliverable or unsubscribed. Once unsubscribed, if you want to re-subscribe, for now you will need to contact RIPE NCC support [6].
>
> The changes can already be tested in our Release Candidate environment [7].
>
> We welcome feedback from the community.
>
> Regards
> Ed Shryane
> RIPE NCC
>
> ---
>
> References
>
> 1. Google announcement: https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
> 2. Google email sender guidelines: https://support.google.com/a/answer/81126?hl=en
> 3. Yahoo announcement: https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam
> 4. Yahoo sender best practices: https://senders.yahooinc.com/best-practices/
> 5. Enhancing Email Delivery at the RIPE NCC: https://labs.ripe.net/author/fergalc/enhancing-email-delivery-at-the-ripe-ncc/
> 6. Contacting the RIPE NCC https://www.ripe.net/support/contact/
> 7. Release candidate environment https://apps.db.ripe.net/docs/Release-Notes/#release-candidate-environment
>
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/