Hetzner website at debug mode?

I don't know if there's anyone who is working for Hetzner. Just want to let you know that hetzner.com and hetzner.com/cloud popped up with a bunch of debug messages and SQL. Regards, Jason

Weekly Global IPv4 Routing Table Report

This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...

Re: 202212160543.AYC Re: eMail Conventions

On 12/16/22 10:04 AM, ic wrote: In my experience, threading is done by clients looking for the In-Reply-To: header, not subject. Subject is a heuristic fallback, in case In-Reply-To is absent. I believe the References: header is what most clients use as well? -- Brielle Bruns The Summit Open

Re: 202212160543.AYC Re: eMail Conventions

> On Dec 16, 2022, at 12:04 PM, ic wrote: > > Hi there, > >> On 16 Dec 2022, at 17:13, William Herrin > > wrote: >> >> Most email clients assume that a change to the subject line (other >> than adding "Re:" to the front) indicates that the sender wants to >> discuss a n

Re: 202212160543.AYC Re: eMail Conventions

On Fri, Dec 16, 2022 at 9:05 AM ic wrote: > In my experience, threading is done by clients looking for the In-Reply-To: > header, not subject. Subject is a heuristic fallback, in case In-Reply-To is > absent. Correct, they use the In-Reply-To and References headers to thread the emails. Subject

Re: 202212160543.AYC Re: eMail Conventions

Hi there, > On 16 Dec 2022, at 17:13, William Herrin wrote: > > Most email clients assume that a change to the subject line (other > than adding "Re:" to the front) indicates that the sender wants to > discuss a new topic related to but meaningly different from the last. Although I generally ag

Re: 202212160543.AYC Re: eMail Conventions

> > Now, I would appreciate very much to see an example of how > your eMail system handles the message threads. So that we can compare > notes. Thanks, > Email *systems* don't do anything with threads. It's a construct of mail clients. Even different mail clients do things differently, so as a ru

RE: 202212160543.AYC Re: eMail Conventions

> Most email clients assume that a change to the subject line (other than > adding "Re:" to the front) indicates that the sender wants to discuss a new > topic related to but meaningly different from the last. When I managed a help desk, my users would constantly complain that they weren't rece

Re: 202212160543.AYC Re: eMail Conventions

On Fri, Dec 16, 2022 at 7:05 AM Abraham Y. Chen wrote: > As you > can see, my practice of continuously prefixing timestamps to the > "Subject" line of messages in a thread seems to conform to ThunderBird's > mechanism! Ave, Most email clients assume that a change to the subject line (other than

Re: 202212160543.AYC Re: eMail Conventions

Hello Abe, Actually there is a RFC describing Netiquette Guidelines from 1995 (rfc 1855), with guidelines still valid today. See https://www.rfc-editor.org/info/rfc1855 Best regards, Pim van Stam > On 16 Dec 2022, at 16:05, Abraham Y. Chen wrote: > > Dear Bill, Et al.: > > 0) Ever since I

Re: 202212160543.AYC Re: eMail Conventions

If you are running thunderbird, all you need to do is hit Reply and respond accordingly, maybe trimming off some extra fluff at the end of the quoted message. The defaults in Thunderbird are pretty ‘normal’ in terms of what the bulk of the world expects a message reply to be. It handles quotin

Re: 202212160543.AYC Re: eMail Conventions

Abe, Since you ask, and it's coffee time on a Friday, I'll chip in. This is not an invitation for an extended conversation; take or leave what I say below as you wish, but note my remark at the end. The only other general remark I'd make is observe what others do; these are the usual norms fo

202212160543.AYC Re: eMail Conventions

Dear Bill, Et al.: 0)  Ever since I signed up to the NANOG List, I have been getting complaints about my eMail style, format, etc. Since I could not find any document that clearly stated the guidelines and no one cared about providing an explicit lead, it has been a very frustrating experience

McAfee Net Guard lookup? (was Re: Spectrum (California) and Xlorenet (Ontario) blocking web access to single /32 here)

Thanks to those who responded offline. The problem appears to be McAfee Net Guard which when disabled, allows access to the sites https://sitelookup.mcafee.com/ When I check McAfee's lookup tool, the websites either show as "Minimal Risk" or "Unverified". Does anybody know if Net Guard act