Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
Hello, currently notifications are configurable for the event when a probe is disconnected; however when a probes remains connected but stops working (loosing or no having either system-ipv4-works and system-ipv6-works tags), we are blind. I have written a monitor script to query the API for this, to get this notification but I'm wondering if it would be possible to implement this at RIPE. The system-<AF>-works tags are already there. Software bugs and I guess HW issues can trigger hung probes that remain connected. It's hard to find out, unless one is specifically looking for it or specifically expecting the result of a single probe in a measurement. Lukas
Hi Lukas, Internally we refer to these probes as not-reporting and I agree that a notification would be useful. These would then be sent if the probe: - does not have system-ipv4-works AND system-ipv6-works tags - does have a system-ipv4-doesnt-work OR system-ipv6-doesnt-work tag Question is if these emails should be send again after for instance 24 hours or a week or? As I am working on emails lately, I will add this notification to my list. Cheers, Johan On Mon, 25 Aug 2025 at 11:47, Lukas Tribus <lukas@ltri.eu> wrote:
Hello,
currently notifications are configurable for the event when a probe is disconnected; however when a probes remains connected but stops working (loosing or no having either system-ipv4-works and system-ipv6-works tags), we are blind.
I have written a monitor script to query the API for this, to get this notification but I'm wondering if it would be possible to implement this at RIPE. The system-<AF>-works tags are already there.
Software bugs and I guess HW issues can trigger hung probes that remain connected. It's hard to find out, unless one is specifically looking for it or specifically expecting the result of a single probe in a measurement.
Lukas ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi, On Tuesday, 26 August 2025, Johan ter Beest <jterbeest@ripe.net> wrote:
Hi Lukas,
Internally we refer to these probes as not-reporting and I agree that a notification would be useful.
These would then be sent if the probe: - does not have system-ipv4-works AND system-ipv6-works tags - does have a system-ipv4-doesnt-work OR system-ipv6-doesnt-work tag
Question is if these emails should be send again after for instance 24 hours or a week or?
24 hours I don't think so, but a week is fine imho. Whats the behaviour for disconnected probes? Lukas
Hi, On Tue, Aug 26, 2025 at 04:33:48PM +0200, Johan ter Beest wrote:
As I am working on emails lately, I will add this notification to my list.
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert & all - On 01.09.2025 09:20, Gert Doering wrote:
On Tue, Aug 26, 2025 at 04:33:48PM +0200, Johan ter Beest wrote:
As I am working on emails lately, I will add this notification to my list.
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency).
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch? Cheers, -C.
Hi, On Mon, Sep 01, 2025 at 11:13:19AM +0200, Carsten Schiefner wrote:
On 01.09.2025 09:20, Gert Doering wrote:
On Tue, Aug 26, 2025 at 04:33:48PM +0200, Johan ter Beest wrote:
As I am working on emails lately, I will add this notification to my list.
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency).
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch?
No. This is, in practice, one of the worst things that happen - multipart mails that have differing content in both bodies (and it happens quite more often that one would assume). If there is *benefit* in HTML, like "nice advertising with pictures and tracking pixels and all that", go for it. If you want to send information, go for plain text (only). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert & all - On 01.09.2025 11:20, Gert Doering wrote:
On Mon, Sep 01, 2025 at 11:13:19AM +0200, Carsten Schiefner wrote:
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch?
No. This is, in practice, one of the worst things that happen - multipart mails that have differing content in both bodies (and it happens quite more often that one would assume).
my underlying, but not explicitly voiced assumption would, of course, be that there is no content diff - the diff is merely (formatted where necessary) ASCII and (intrinsically formatted) HTML.
If there is *benefit* in HTML, like "nice advertising with pictures and tracking pixels and all that", go for it. If you want to send information, go for plain text (only).
There even here might be corner cases where an embedded pic in such 'system-ipv[46]-works' notifications would come in handy, I guess. Cheers, -C.
Comments in line
On Sep 1, 2025, at 5:20 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Sep 01, 2025 at 11:13:19AM +0200, Carsten Schiefner wrote:
On 01.09.2025 09:20, Gert Doering wrote:
On Tue, Aug 26, 2025 at 04:33:48PM +0200, Johan ter Beest wrote:
As I am working on emails lately, I will add this notification to my list.
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency).
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch?
No. This is, in practice, one of the worst things that happen - multipart mails that have differing content in both bodies (and it happens quite more often that one would assume).
If there is *benefit* in HTML, like "nice advertising with pictures and tracking pixels and all that", go for it. If you want to send information, go for plain text (only).
Emphasis on information: Data intended as information, as in an email, should be Human readable Easily parsed by eye Easily parsed by code In the Monthly probe report, the tables of keys and values do not meet criterion 2 as the variable width font messes with the vertical alignment. Plain text and fixed field sizes could remedy that for both GUI and TextUI users. James R Cutler - 🦉 No AI content james.cutler@consultant.com
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
I tend to keep a low profile, but I must say that requiring that emails be in text format in case someone wants to build some fragile text parsing thing around them - that will break with the slightest change to wording or organization - seems suboptimal. If there is a need for machine parsing RIPE emails, that should be handled with an attachment in a structured format such as yaml or json. Though I would also argue that that sort of info should just be grabbed with an API call of some sort and left out of the email entirely. Maybe things are different in Europe, but speaking of decades, I ran my own mail servers at home in the US for decades. The antispammers have made that effectively impossible, or at least so difficult that the effort far outweighs the benefits. If you send mail directly, you’re typically coming from an address range that isn’t among the blessed, so your mail is treated as spam, and there you are, trying to convince obscure antispam provider #36 that you aren’t a spammer. Personally, I hate that it’s come to this, but it is what it is. I gave in and now I have a Google Workspace account for my household. I can’t do anything but applaud anyone’s decision to get out of the email-delivery rat-race and just outsource it. -Steve ------ Original Message ------ From "James R Cutler via ripe-atlas" <ripe-atlas@ripe.net> To "Gert Doering" <gert@space.net> Cc "Carsten Schiefner" <carsten@schiefner.de>; ripe-atlas@ripe.net Date 9/1/2025 11:31:23 AM Subject [atlas] Re: Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
Comments in line
On Sep 1, 2025, at 5:20 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Sep 01, 2025 at 11:13:19AM +0200, Carsten Schiefner wrote:
On 01.09.2025 09:20, Gert Doering wrote:
On Tue, Aug 26, 2025 at 04:33:48PM +0200, Johan ter Beest wrote:
As I am working on emails lately, I will add this notification to my list.
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency).
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch?
No. This is, in practice, one of the worst things that happen - multipart mails that have differing content in both bodies (and it happens quite more often that one would assume).
If there is *benefit* in HTML, like "nice advertising with pictures and tracking pixels and all that", go for it. If you want to send information, go for plain text (only).
Emphasis on information: Data intended as information, as in an email, should be Human readable Easily parsed by eye Easily parsed by code
In the Monthly probe report, the tables of keys and values do not meet criterion 2 as the variable width font messes with the vertical alignment. Plain text and fixed field sizes could remedy that for both GUI and TextUI users.
James R Cutler - 🦉 No AI content james.cutler@consultant.com
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
incoming works tho. i've ran mail behind dynamic ip for decades. in is ok. out is a hassle to plug the input, i chose no filter but multi alias setup, so far it holds. or, i can know exactly where the spammers get sources. apparently don't really scour the internet like mailing lists, despite many of them don't mangle the from's. one would question if it even helps. maybe i'm calling devil out here since i'm pretty sure some spammers read my mail here too funnily many big players ban v4 dyn permanently but somehow allow v6 after my mta retries on v6 after v4 fail. i guess spammers haven't yet found that absolute gold mine to spam via v6. can't block that either. have to ban /64, /48 or more! where mails go through, i feel like some end up in wrong place, rarely that said, i while ip is dynamic, it still has all the spf, dkim, dmarc configured so maybe that's why most of systems still accept it maybe i blame ripe too much for that but i still wonder what's best, know source like ripe sending it from own servers and ip ranges or random company sending it via servers they use for all and it's only e-mail marketing with performance metrics if you are sender and work in company marketing department no receiver whatsoever perceives this, especially in 2025, as nothing more than a spam that tracks too. especially if same provider also distributes strange optout newsletters and other deceptions that nobody really wants i don't know, maybe ripe is right to outsource mail but then i wonder how do those mass mail companies could even guarantee absolute best deliverability if they go against users and sysadmins and rbl providers and other companies that do the best to not allow mass mailings so that's why i was surprised that ripe decided to dilute their legitimate important mails into strange pool of all others, with html and pixels i don't actively hate html myself but i know html mail is often used for malicious purposes and text is much harder to abuse, unless you try to coerce people into buying your grand piano (probably most wtf spam i've ever got in my 26 years of internet usage time) html is useful too, and that's the problem here, on what to choose i think most of notices ripe send out don't need to be design masterpieces of megabytes of inline svg but quick important reminders. maybe i'm not aware of all ripe work but i assume this. assume = make ass out of u and me? after all i don't send mails a lot personally or professionally, so no idea? so maybe i was unfair for ripe here... On September 1, 2025 9:19:04 PM GMT+03:00, Steven Miller <ripe@idrathernotsay.com> wrote:
I tend to keep a low profile, but I must say that requiring that emails be in text format in case someone wants to build some fragile text parsing thing around them - that will break with the slightest change to wording or organization - seems suboptimal. If there is a need for machine parsing RIPE emails, that should be handled with an attachment in a structured format such as yaml or json.
Though I would also argue that that sort of info should just be grabbed with an API call of some sort and left out of the email entirely.
Maybe things are different in Europe, but speaking of decades, I ran my own mail servers at home in the US for decades. The antispammers have made that effectively impossible, or at least so difficult that the effort far outweighs the benefits. If you send mail directly, you’re typically coming from an address range that isn’t among the blessed, so your mail is treated as spam, and there you are, trying to convince obscure antispam provider #36 that you aren’t a spammer. Personally, I hate that it’s come to this, but it is what it is. I gave in and now I have a Google Workspace account for my household.
I can’t do anything but applaud anyone’s decision to get out of the email-delivery rat-race and just outsource it.
-Steve
------ Original Message ------
From "James R Cutler via ripe-atlas" <ripe-atlas@ripe.net> To "Gert Doering" <gert@space.net> Cc "Carsten Schiefner" <carsten@schiefner.de>; ripe-atlas@ripe.net Date 9/1/2025 11:31:23 AM Subject [atlas] Re: Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
Comments in line
On Sep 1, 2025, at 5:20 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Sep 01, 2025 at 11:13:19AM +0200, Carsten Schiefner wrote:
On 01.09.2025 09:20, Gert Doering wrote:
On Tue, Aug 26, 2025 at 04:33:48PM +0200, Johan ter Beest wrote:
As I am working on emails lately, I will add this notification to my list.
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency).
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch?
No. This is, in practice, one of the worst things that happen - multipart mails that have differing content in both bodies (and it happens quite more often that one would assume).
If there is *benefit* in HTML, like "nice advertising with pictures and tracking pixels and all that", go for it. If you want to send information, go for plain text (only).
Emphasis on information: Data intended as information, as in an email, should be Human readable Easily parsed by eye Easily parsed by code
In the Monthly probe report, the tables of keys and values do not meet criterion 2 as the variable width font messes with the vertical alignment. Plain text and fixed field sizes could remedy that for both GUI and TextUI users.
James R Cutler - 🦉 No AI content james.cutler@consultant.com
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Am 01.09.25 um 11:13 schrieb Carsten Schiefner:
Gert & all -
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency).
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch?
The html mail has no advantage for the user, as it looks like before. It seems the only purpose is the tracking pixel. Management/Advertisement people like it, I don't like it. Thomas
Thomas & all - On 01.09.2025 11:21, Thomas Schäfer wrote:
Am 01.09.25 um 11:13 schrieb Carsten Schiefner:
how about: /-> "Content-Type: text/plain" "Content-Type: multipart/alternative"-| \-> "Content-Type: text/html" - would this scratch your itch?
The html mail has no advantage for the user, as it looks like before. It seems the only purpose is the tracking pixel. Management/Advertisement people like it, I don't like it.
I would expect the RIPE NCC to not use any tracking pixels or such unless technically unavoidable for the service in question and therefore announced as such in any such email. But then again, I don't have any strong feeling in either direction - just attempting to offer ideas. :-) Cheers, -C.
On 01.09.2025 11:36, Carsten Schiefner wrote:
[...]
I would expect the RIPE NCC to not use any tracking pixels or such unless technically unavoidable for the service in question and therefore announced as such in any such email.
I stand corrected:
-------- Forwarded Message -------- Subject: [atlas] Re: Notification on removal of system-ipv4-works && system-ipv6-works tags while connected Date: Mon, 1 Sep 2025 15:13:16 +0200 From: Johan ter Beest <jterbeest@ripe.net> To: Randy Bush <randy@psg.com> CC: Thomas Schäfer <tschaefer@t-online.de>, ripe-atlas@ripe.net
[...]
We're using Brevo to send emails now and they add the tracking pixel. This happens also when you use their SMTP server and not their special templates.
[...]
The html mail has no advantage for the user, as it looks like before. It seems the only purpose is the tracking pixel. Management/Advertisement people like it, I don't like it.
+1 randy
Hi all, We're using Brevo to send emails now and they add the tracking pixel. This happens also when you use their SMTP server and not their special templates. Side effect is that they also send the email as HTML. I will see if I can force SMTP emails to be sent as plain text without a tracking pixel. For the record: we are not using the tracking pixel for advertising purposes. It's purely so we know if the email was delivered and if it was opened so we get some idea how often people actually read these emails. Cheers, Johan On Mon, 1 Sept 2025 at 14:48, Randy Bush <randy@psg.com> wrote:
The html mail has no advantage for the user, as it looks like before. It seems the only purpose is the tracking pixel. Management/Advertisement people like it, I don't like it.
+1
randy ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
I block external content by default. So that tracking pixel isn't getting loaded even when I do read the message. Can't wait to get kicked off the list. David -- https://dprall.net On 9/1/2025 9:13 AM, Johan ter Beest wrote:
Hi all,
We're using Brevo to send emails now and they add the tracking pixel. This happens also when you use their SMTP server and not their special templates.
Side effect is that they also send the email as HTML. I will see if I can force SMTP emails to be sent as plain text without a tracking pixel.
For the record: we are not using the tracking pixel for advertising purposes. It's purely so we know if the email was delivered and if it was opened so we get some idea how often people actually read these emails.
Cheers, Johan
On Mon, 1 Sept 2025 at 14:48, Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote:
> The html mail has no advantage for the user, as it looks like before. > It seems the only purpose is the tracking pixel. > Management/Advertisement people like it, I don't like it.
+1
randy ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe- atlas.ripe.net/ <https://mailman.ripe.net/mailman3/lists/ripe- atlas.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3- migration/ <https://www.ripe.net/membership/mail/mailman-3-migration/>
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
it boggles my mind that ripe ncc doesn't run it's own infra and relies on spam company to forward them. i expect more mails end up in actual spam folder due them coming via so called email marketing provider it also boggles my mind that it should be expected that anyone's mua even loads remote resources. many don't anymore for a long time. spam, viruses and other attacks have removed that nice feature. many allow whitelisted and trusted sources only. that skews this metric a ton those reports also go to technical people who might use them without pixel being loaded anyway. i don't know, i receive them to their own aliases, they go into their own folders and system makes them read automatically. for stats / future use and who came to this decision anyway. it feels like whoever it was, he never uses atlas him / herself. at least it very much feels so. what's fun is those things likely are decided by like team on 10 people or so it's often problem everywhere, eg, bus schedules are often as if made by people who always drive a car. kind of user/decisionmaker disconnect. similar thing seems to happen here i would expect better things from that 33 year old mature world famous highly knowledged important internet management organization that a réseaux IP européens network coordination centre established in year 1992 is On September 1, 2025 4:13:16 PM GMT+03:00, Johan ter Beest <jterbeest@ripe.net> wrote:
Hi all,
We're using Brevo to send emails now and they add the tracking pixel. This happens also when you use their SMTP server and not their special templates.
Side effect is that they also send the email as HTML. I will see if I can force SMTP emails to be sent as plain text without a tracking pixel.
For the record: we are not using the tracking pixel for advertising purposes. It's purely so we know if the email was delivered and if it was opened so we get some idea how often people actually read these emails.
Cheers, Johan
On Mon, 1 Sept 2025 at 14:48, Randy Bush <randy@psg.com> wrote:
The html mail has no advantage for the user, as it looks like before. It seems the only purpose is the tracking pixel. Management/Advertisement people like it, I don't like it.
+1
randy ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On 01.09.2025 16:02, Sulev-Madis Silber via ripe-atlas wrote:
it boggles my mind that ripe ncc doesn't run it's own infra and relies on spam company to forward them. i expect more mails end up in actual spam folder due them coming via so called email marketing provider
it also boggles my mind that it should be expected that anyone's mua even loads remote resources. many don't anymore for a long time. spam, viruses and other attacks have removed that nice feature. many allow whitelisted and trusted sources only. that skews this metric a ton
those reports also go to technical people who might use them without pixel being loaded anyway. i don't know, i receive them to their own aliases, they go into their own folders and system makes them read automatically. for stats / future use
and who came to this decision anyway. it feels like whoever it was, he never uses atlas him / herself. at least it very much feels so. what's fun is those things likely are decided by like team on 10 people or so
it's often problem everywhere, eg, bus schedules are often as if made by people who always drive a car. kind of user/decisionmaker disconnect. similar thing seems to happen here
i would expect better things from that 33 year old mature world famous highly knowledged important internet management organization that a réseaux IP européens network coordination centre established in year 1992 is
Sulev-Madis's point of view gets my full sympathy, if it's not even already a "+1". Cheers, -C.
Carsten Schiefner wrote on 01/09/2025 15:34:
On 01.09.2025 16:02, Sulev-Madis Silber via ripe-atlas wrote:
it boggles my mind that ripe ncc doesn't run it's own infra and relies on spam company to forward them. i expect more mails end up in actual spam folder due them coming via so called email marketing provider [...]
Sulev-Madis's point of view gets my full sympathy, if it's not even already a "+1".
I do understand the exasperation that happens when they see the RIPE NCC outsourcing its email to some third party or another, but they have good reasons for doing this:
https://labs.ripe.net/author/fergalc/enhancing-email-delivery-at-the-ripe-nc...
I.e. the NCC has a choice about whether to spend a good deal of money running an in-house mail transport service, or else outsource mail transport for very little cost, and spend money doing the job that they were asked to do by the community. SMTP delivery is hard above a certain threshold of emails, so I'd argue that we need to cut them some slack on this one. Incidentally, the IETF also outsources its smtp email delivery. Nick
Hi, On Mon, Sep 01, 2025 at 03:59:31PM +0100, Nick Hilliard wrote:
Incidentally, the IETF also outsources its smtp email delivery.
The IETF uses service providers that have no IPv6, and call that "progress". So that's not really setting a good example... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote on 01/09/2025 16:11:
The IETF uses service providers that have no IPv6, and call that "progress". So that's not really setting a good example...
They're aware of this, but their prime concern is to make sure the email arrives. https://mailarchive.ietf.org/arch/msg/ietf/GLDqO_ck6zjlg-P3HUP0O8ikGMQ/ Nick
Hi, On Mon, Sep 01, 2025 at 04:20:49PM +0100, Nick Hilliard wrote:
Gert Doering wrote on 01/09/2025 16:11:
The IETF uses service providers that have no IPv6, and call that "progress". So that's not really setting a good example...
They're aware of this, but their prime concern is to make sure the email arrives.
https://mailarchive.ietf.org/arch/msg/ietf/GLDqO_ck6zjlg-P3HUP0O8ikGMQ/
Yeah, "we have heard you, we don't care, go away". I have seen that mail, and it's not like there are no mail service provider available that *do* work and *do* have IPv6. Heck, even Microsoft and Google can get that part right (they are not very good at accepting mail, but sending, this they can). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 2025/09/01 16:27, Gert Doering wrote:
Heck, even Microsoft and Google can get that part right (they are not very good at accepting mail, but sending, this they can).
Yes, Google in particular sends me *loads* of email that they would rightfully decline if it was going in the opposite direction... Ray
Hi Nick & all - On 01.09.2025 16:59, Nick Hilliard wrote:
Carsten Schiefner wrote on 01/09/2025 15:34:
[...]
Sulev-Madis's point of view gets my full sympathy, if it's not even already a "+1".
I do understand the exasperation that happens when they see the RIPE NCC outsourcing its email to some third party or another, but they have good reasons for doing this:
https://labs.ripe.net/author/fergalc/enhancing-email-delivery-at-the-ripe-nc...
I at least am well aware of this piece and do follow the overarching reasoning in it. However:
I.e. the NCC has a choice about whether to spend a good deal of money running an in-house mail transport service, or else outsource mail transport for very little cost, and spend money doing the job that they were asked to do by the community. SMTP delivery is hard above a certain threshold of emails, so I'd argue that we need to cut them some slack on this one.
I wonder why the NCC then appears to have picked an ESP that seems to offer a certain set of services - tracking pixel mandatorily included -, but needs to be "forced" for "SMTP emails to be sent as plain text without a tracking pixel", if possible at all.
Incidentally, the IETF also outsources its smtp email delivery.
Fine by me. But "HTML only" emails with mandatory tracking pixels? I doubt that. Cheers, -C.
Carsten Schiefner wrote on 01/09/2025 16:19:
Fine by me. But "HTML only" emails with mandatory tracking pixels? I doubt that.
Looks like I'm going to exceed the recommended 1 email in 24 hours. Tracking pixels: email transport companies gain insight into the activity of the recipient. There is a privacy issue here and it would be super if the Atlas team could remove this. HTML emails: didn't we flog this horse to death in the 1990s? Well, it's a long time ago and maybe we didn't, or didn't flog hard enough, or for long enough. Also as ripe-atlas@ripe.net is the ideal forum for re-litigating this important issue: Personally I like HTML emails. Some people like text-only emails and that's fine too - we all have our likes and dislikes. However text depends on fully unstructured information which is most likely to be rendered in a proportional-spaced font on most MUAs, i.e. terribly broken by default for most people but works fine if you're in a terminal. If tabular data is being presented, then html tables provide a sensible presentation layer. I'm not so sure that the preferences of a vociferous minority who use text-only MUAs should override the UX experience of the vast majority of people who use MUAs which render plaintext using proportional spaced fonts by default. But as Carsten points out, this problem is already solved with Content-Type: multipart/alternative. If multipart/alternative presents inconsistent information, then that's a bug and it needs to be fixed. Presumably the Atlas team won't do this (but if they did, it would be an excellent troll). Also, welcome back everyone from northern hemisphere summer holidays and I'm glad to see such universal good cheer on the Atlas mailing list today, and about such important things too. 🎉🎉🎉 Nick
i'm aware why, but... reputable mail source chose to buy email delivery from non-ipv6 provider so they can send them at puny rate of one message every 3 seconds...? and they can't split the load over pool of ip's? this organization *MANAGES* ip space for entire european continent? they can't have agreements with large providers for whitelisting? if they chose a service instead of own employee and hw, why do they "battle" against service as if that's like single person freelance web design company everyone could just flip off since (s)he only pays 30€ / month and thereforce is unimportant small customer? also they admit they don't know how to configure spf and find that as a big hassle? and they can have like expensive beautiful office? and they somehow made ripe atlas? i have many questions!
And again, +1. Just for the record. Relying on an email provider that alters mail after sending is IMHO not acceptable.
On 1. Sep 2025, at 16:02, Sulev-Madis Silber via ripe-atlas <ripe-atlas@ripe.net> wrote:
it boggles my mind that ripe ncc doesn't run it's own infra and relies on spam company to forward them. i expect more mails end up in actual spam folder due them coming via so called email marketing provider
it also boggles my mind that it should be expected that anyone's mua even loads remote resources. many don't anymore for a long time. spam, viruses and other attacks have removed that nice feature. many allow whitelisted and trusted sources only. that skews this metric a ton
those reports also go to technical people who might use them without pixel being loaded anyway. i don't know, i receive them to their own aliases, they go into their own folders and system makes them read automatically. for stats / future use
and who came to this decision anyway. it feels like whoever it was, he never uses atlas him / herself. at least it very much feels so. what's fun is those things likely are decided by like team on 10 people or so
it's often problem everywhere, eg, bus schedules are often as if made by people who always drive a car. kind of user/decisionmaker disconnect. similar thing seems to happen here
i would expect better things from that 33 year old mature world famous highly knowledged important internet management organization that a réseaux IP européens network coordination centre established in year 1992 is
On September 1, 2025 4:13:16 PM GMT+03:00, Johan ter Beest <jterbeest@ripe.net> wrote:
Hi all,
We're using Brevo to send emails now and they add the tracking pixel. This happens also when you use their SMTP server and not their special templates.
Side effect is that they also send the email as HTML. I will see if I can force SMTP emails to be sent as plain text without a tracking pixel.
For the record: we are not using the tracking pixel for advertising purposes. It's purely so we know if the email was delivered and if it was opened so we get some idea how often people actually read these emails.
Cheers, Johan
On Mon, 1 Sept 2025 at 14:48, Randy Bush <randy@psg.com> wrote:
The html mail has no advantage for the user, as it looks like before. It seems the only purpose is the tracking pixel. Management/Advertisement people like it, I don't like it.
+1
randy ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On Mon, 1 Sep 2025, Johan ter Beest wrote:
We're using Brevo to send emails now and they add the tracking pixel. This happens also when you use their SMTP server and not their special templates.
Then I would suggest switching away from Brevo ASAP. Why would you ever want to use an SMTP server that changes the content of your emails? Adding "Received:"-headers and stuff like that, sure, that's who emails work, but changing the actual body of the email? NO!
Side effect is that they also send the email as HTML. I will see if I can force SMTP emails to be sent as plain text without a tracking pixel.
Maybe I'm misunderstanding you, but just to be clear, the monthly reports I received wasn't "also" HTML. They were HTML-only, which made them unreadable for me.
For the record: we are not using the tracking pixel for advertising purposes. It's purely so we know if the email was delivered and if it was opened so we get some idea how often people actually read these emails.
I'm 100% sure that tracking pixel wasn't loaded by my alpine, so your stats are already wrong. -- Povl Ole
Hi, I might have missed this part of the discussion, but ... Am Mon, 01 Sep 2025 schrieb Johan ter Beest:
For the record: we are not using the tracking pixel for advertising purposes. It's purely so we know if the email was delivered and if it was opened so we get some idea how often people actually read these emails.
... There has been a user- and privacy-friendly smtp extension for this purpose (rfc1891 and following). Maybe It's just me ... It's concerning, that ripe ncc even considered allowing a privacy nightmare like tracking pixels in it's emails. I would have expected more thorough checks during outsourcing of essential services like smtp. Bjørn P.S: Sorry for this late reply. You know, vacation ... ;o) -- Pengutronix e.K. | Bjørn Bürger | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-102 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
+1 for this request. HTML mail is a nuisance. Peter Eckel.
On 1. Sep 2025, at 09:20, Gert Doering <gert@space.net> wrote:
Signed PGP part Hi,
On Tue, Aug 26, 2025 at 04:33:48PM +0200, Johan ter Beest wrote:
As I am working on emails lately, I will add this notification to my list.
Please undo the change that makes the "monthly status mails" now arrive in HTML format. This is not adding useful information but makes it more annoying for people that do not use a GUI mail client (because, you know, efficiency).
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (15)
-
Bjoern Buerger -
Carsten Schiefner -
David Prall -
Gert Doering -
James R Cutler -
Johan ter Beest -
Lukas Tribus -
Nick Hilliard -
Peter Eckel -
Povl Ole Haarlev Olsen -
Randy Bush -
Ray Bellis -
Steven Miller -
Sulev-Madis Silber -
Thomas Schäfer