1 Mar
2017
1 Mar
'17
2:43 a.m.
On 02/28/2017 05:21 PM, Jon Auringer wrote:
Chuck,
I had the same display issue. Uncheck "Show only display name for
people in my address book" under Tools-Options-Display-Advanced.
Jon,
Thanks for the hint! I'm using the Linux version of Thunderbird, so the
setting isn't under "Tools"; it took me a bit of searching to find it.
In the *nix version, it appears to be under Edit->Preferences->Display.
That seems to have fixed things.
Thanks again,
Chuck
3 Mar
3 Mar
9:41 p.m.
On 02/28/2017 07:43 PM, Chuck Guzis via cctalk wrote:
On 02/28/2017 05:21 PM, Jon Auringer wrote:
Thanks to both of you. I came back to cctalk after not checking it for a
few days, and wondered what the %$#^ was going on, with every message
showing with cctalk as the "from" field.
It is indeed under edit/preferences/display on my version, too. I'm not
sure why it's not consistent with the non-Linux versions, I would have
thought a consistent UI across all platforms was a Good Thing.
cheers
Jules
Chuck,
I had the same display issue. Uncheck "Show only display name for
people in my address book" under Tools-Options-Display-Advanced.
Jon,
Thanks for the hint! I'm using the Linux version of Thunderbird, so the
setting isn't under "Tools"; it took me a bit of searching to find it.
In the *nix version, it appears to be under Edit->Preferences->Display. 
4 Mar
4 Mar
8:38 a.m.
On Fri, 3 Mar 2017, Jules Richardson wrote:
Thanks to both of you. I came back to cctalk after not
checking it for a few
days, and wondered what the %$#^ was going on, with every message showing
with cctalk as the "from" field.
I'm another one who dislikes the new system. It would be much better if
the Reply-To field did *not* contain the sender's email address because
when I reply to a message, I use the Reply-To field (of course) and have
to delete the extra line because I want to reply to the list and *not*
privately to the sender. So either the sender's address should be in the
From field or in a new header field, e.g.
List-Original-Sender or
something like that.
For now I have set up a procmail rule to strip the "via cctalk" from the
From field because this is ugly and redundant.
Christian
9:15 a.m.
The whole "foo via cctalk" is *really* annoying... What is wrong with
a half default mailman setup? There is no Reply-To header there, From
is set to the person actually sending the message (as it should be).
And all the bounce addresses are set to
cctalk-bounces+foo=bar at classiccmp.org where foo=bar is the user
sending the message.
6 Mar
6 Mar
7:53 a.m.
And for what it is worth, continued bounces.
From: cctalk-request at classiccmp.org
To: ams at gnu.org
Subject: confirm xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Date: Sun, 05 Mar 2017 14:28:13 -0600
Your membership in the mailing list cctalk has been disabled due to
excessive bounces The last bounce received from you was dated
05-Mar-2017. You will not get any more messages from this list until
you re-enable your membership. You will receive 3 more reminders like
this before your membership in the list is deleted.
11:01 a.m.
That seems to be peculiar to GNU. I haven't had any on GMAIL
Dave
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Alfred M.
Szmidt via cctalk
Sent: 06 March 2017 06:53
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Cc: cctalk at classiccmp.org
Subject: Re: I hate the new mail system
And for what it is worth, continued bounces.
From: cctalk-request at classiccmp.org
To: ams at gnu.org
Subject: confirm xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Date: Sun, 05 Mar 2017 14:28:13 -0600
Your membership in the mailing list cctalk has been disabled due to
excessive bounces The last bounce received from you was dated
05-Mar-2017. You will not get any more messages from this list
until
you re-enable your membership. You will
receive 3 more reminders
like
this before your membership in the list is deleted.
11:16 a.m.
"Alfred M. Szmidt" <ams at gnu.org> wrote:
And for what it is worth, continued bounces.
Alfred,
Two of the four ipv4 nameservers for gnu.org are broken. By those
odds, I would expect anything up to 50% of any mail you receive via ipv4
to bounce.
I gave you some hints in this direction the last time you mentioned you
were getting bounces but maybe you didn't see my posting due to your
problem with your nameservers?
Regards,
Peter Coghlan.
1:10 p.m.
Two of the four ipv4 nameservers for gnu.org are broken. By those
odds, I would expect anything up to 50% of any mail you receive via
ipv4 to bounce.
Which has nothing to do with anything.
I gave you some hints in this direction the last time you mentioned you
were getting bounces but maybe you didn't see my posting due to your
problem with your nameservers?
Uhm, it has nothing to do with "nameservers". Just the fact that this
is the _only_ list in the whole world that sends bounces like this
should tell you something. Just the fact that multiple people have
complained about bounces should tell you something.
10:04 a.m.
On Sat, 4 Mar 2017, Alfred M. Szmidt wrote:
The whole "foo via cctalk" is *really*
annoying... What is wrong with
a half default mailman setup? There is no Reply-To header there, From
is set to the person actually sending the message (as it should be).
Yes, that is most annoying. My complaint (and I guess many more from other
users will follow) is, that if you reply to a message on the list, the
author of that message gets a private mail, too, as he is listed in the
Reply-To:-field. This is *wrong* and must be corrected (i.e. removed)!
(BTW this reply to Alfed's mail is to one sent to me privately because of
that error).
And all the bounce addresses are set to
cctalk-bounces+foo=bar at classiccmp.org where foo=bar is the user
sending the message.
No, the Envelope-From: only has "cctalk-bounces at classiccmp.org", there's
no "+foo=bar" in it.
And yes, the change in the address fields don't cure the bounce problem
because the envelope from field is unchanged (and *that* field is used for
bounces, not the header fields *within* the mail).
Christian
10:42 a.m.
The whole "foo via cctalk" is *really*
annoying... What is wrong with
a half default mailman setup? There is no Reply-To header there, From
is set to the person actually sending the message (as it should be).
Yes, that is most annoying. My complaint (and I guess many more
from other users will follow) is, that if you reply to a message on
the list, the author of that message gets a private mail, too, as
he is listed in the Reply-To:-field. This is *wrong* and must be
corrected (i.e. removed)! (BTW this reply to Alfed's mail is to
one sent to me privately because of that error).
Indeed, the Reply-To header should be nuked.
And all the bounce addresses are set to
cctalk-bounces+foo=bar at classiccmp.org where foo=bar is the user
sending the message.
No, the Envelope-From: only has "cctalk-bounces at classiccmp.org",
there's
no "+foo=bar" in it.
And yes, the change in the address fields don't cure the bounce problem
because the envelope from field is unchanged (and *that* field is used for
bounces, not the header fields *within* the mail).
I meant that it should have the +foo=bar thing in it, the example I
was showing was how it _should_ look like, not what it currently looks
like. Was a bit unclear there I suppose.
2:30 p.m.
My complaint (and I guess many more from other users
will follow) is,
that if you reply to a message on the list, the author of that
message gets a private mail, too, as he is listed in the
Reply-To:-field.
Only if you don't bother editing it down to whichever address you want
to reply to (as I did for this message). If your user agent doesn't
let you do that, well, your choice of a crippled user agent (and an
inability to edit the list of recipients is a pretty serious failing
for a user agent) is not reason to mangle the list even further for
everyone else.
This is *wrong* and must be corrected (i.e. removed)!
I disagree.
For one thing, that is one of only two places the actual sender's
address appears anywhere in the headers, based on the mail I'm replying
to (and the other one is in a Received: comment, even less available to
user agents and not present unless the sending mailsystem happens to
add it).
Mind you, I'd prefer the former state. But I'm not about to criticize
Jay's handling of the lists when I'm in only peripheral touch with the
relevant issues; even the issue of the bounces I have only the smallest
experience with. I haven't personally seen a subscription suspension
since I made my mailer accept-and-drop list mail it would normally
reject, which makes me think that the suspensions people are seeing are
probably due to the receiving mailserver rejecting the mail and should
be dealt with by the subscriber in question talking with the mailserver
admin in question and getting that sorted out.
No, the Envelope-From: [...]
The envelope-from is not a header and in general does not have a name
with a colon after it. (Your user agent, or possibly your mail store,
may be (mis)presenting it that way, but that's not how it's carried on
the wire and it is not handled that way in general.)
And yes, the change in the address fields don't
cure the bounce
problem because the envelope from field is unchanged (and *that*
field is used for bounces, not the header fields *within* the mail).
As I understand it, the attempt to "fix" the suspended-subscription
"problem" has nothing to do with where the bounces are going, but
rather with their being produced in the first place. As far as I have
seen described on the list, nobody knows why the bounces are being
generated; there have been plausible guesses involving misguided
anti-spam measures, but even those I haven't seen any confirmation of
as the cause of any of the suspensions. It's certainly possible I've
missed something, but the continuation of the discussion as before
seems to imply that's not it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:01 p.m.
On Mon, 6 Mar 2017, Mouse wrote:
I disagree with your disagreement.
Ehm, right ;-)
Only if you don't bother editing it down to
whichever address you want
to reply to (as I did for this message). If your user agent doesn't
let you do that, well, your choice of a crippled user agent (and an
inability to edit the list of recipients is a pretty serious failing
for a user agent) is not reason to mangle the list even further for
everyone else.
You know how to see what user agent I use (hint: alpine). And it is fully
capable of editing or changing anything I want.
This is
*wrong* and must be corrected (i.e. removed)!
I disagree. For one thing, that is one of only two places the
actual sender's
address appears anywhere in the headers, based on the mail I'm replying
to (and the other one is in a Received: comment, even less available to
user agents and not present unless the sending mailsystem happens to
add it).
Yes, and it must not be in the Reply-To: field because in normal cases,
this field is the one used for replying, and I want to reply to the
list, and only to the list. If I want to reply personally, I override the
default and take the From: address instead. That's how it should work.
For example, alpine ask me "Use "Reply-To:" address instead of
"From:"
address?" and defaults to "yes" because the former field has a higher
priority.
A compromise would be to have just the sender's address in the header
field, not with a second recipient cctalk at ...
No, the
Envelope-From: [...]
The envelope-from is not a header and in general does not have a name with a colon after it. (Your user agent, or possibly
your mail store,
Don't blame my user agent, I'm fond of it ;-) It was just my fault.
As I understand it, the attempt to "fix" the
suspended-subscription
"problem" has nothing to do with where the bounces are going, but
rather with their being produced in the first place. As far as I have
[...]
Yes, it is, well, funny... I haven't been able to figure out what the
problem could be. I know that in my case, I've never had any bounce
problem with this list, although the mail gateway and server on my side
are quite picky. BTW over here, legally it is not allowed to reject spam
mails.
Christian
PS: Replying to "Mouse <cctalk at classiccmp.org>" is somehow weird...
6:33 p.m.
You know how to see what user agent I use (hint:
alpine). And it is
fully capable of editing or changing anything I want.
Good. Then what's the problem?
Do you just want the list to be tuned so that you won't have to take a
few seconds to edit out any addresses you don't want to send to?
Basically, on the assumption that everyone shares your particular
preferences? Because...
Yes, and it must not be in the Reply-To: field because
in normal
cases, this field is the one used for replying, and I want to reply
to the list, and only to the list.
...that's sure what this sounds like. If so, I have little sympathy
for your position.
As I
understand it, the attempt to "fix" the suspended-subscription
"problem" has nothing to do with where the bounces are going, but
rather with their being produced in the first place.
Yes, it is, well, funny... I
haven't been able to figure out what the
problem could be.
7 Mar
7 Mar
10:48 a.m.
On Mon, 6 Mar 2017, Mouse wrote:
So you say the Reply-To: field is to be ignored although in all other
contexts it is preferred over the From: field. Say what you want, I don't
understand that.
Quotes from RFC 5322:
"
The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message.
[...]
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the address(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.
In all cases, the "From:" field *SHOULD NOT* contain any mailbox that
does not belong to the author(s) of the message. See also section
3.6.3 for more information on forming the destination addresses for a
reply.
"
And cctalk at ... is neither responsible for the writing of the message nor
does it belong to the author of the message. But replies should be
directed there, so there should be a Reply-To: field containing cctalk at ...
and the From: field should contain the author's address.
EOD from my part ;-)
Christian
Yes, and it
must not be in the Reply-To: field because in normal
cases, this field is the one used for replying, and I want to reply
to the list, and only to the list.
...that's sure what this sounds like. If so, I have little sympathy
for your position. 
11:21 a.m.
On Tue, Mar 7, 2017 at 2:48 AM, Christian Corti via cctalk <
cctalk at classiccmp.org> wrote:
And cctalk at ... is neither responsible for the
writing of the message nor
does it belong to the author of the message. But replies should be directed
there, so there should be a Reply-To: field containing cctalk at ... and the
From: field should contain the author's address.
And thus we come full circle. The "From:" header containing the original
author's address is the cause of the unsubscribes due to bounces, and (I
assume) the motivation for the recent change to the list behavior.
The problem is that major production MTAs will reject (bounce) email with a
"From:" whose domain uses DKIM or SPF, when the sending MTA isn't in the
DKIM or SPF authorized sender list. This will almost always be true when
messages are forwarded by a mailing list. Since the bounces go back to the
mailing list, the mailing list software then drops the entirely legitimate
list subscriber's subscription. :-(
The behavior you describe is certainly correct according to the RFCs, but
unfortunately now falls apart in practice. :-(
8 Mar
8 Mar
3:23 a.m.
On Tue, Mar 07, 2017, Eric Smith via cctalk wrote:
On Tue, Mar 7, 2017 at 2:48 AM, Christian Corti via
cctalk <
cctalk at classiccmp.org> wrote:
What makes it so that other mailing lists don't unsubscribe people when
bounces occur?
--
Eric Christopherson
And cctalk at ... is neither responsible for the
writing of the message nor
does it belong to the author of the message. But replies should be directed
there, so there should be a Reply-To: field containing cctalk at ... and the
From: field should contain the author's address.
And thus we come full circle. The "From:" header containing the original
author's address is the cause of the unsubscribes due to bounces, and (I
assume) the motivation for the recent change to the list behavior.
The problem is that major production MTAs will reject (bounce) email with a
"From:" whose domain uses DKIM or SPF, when the sending MTA isn't in the
DKIM or SPF authorized sender list. This will almost always be true when
messages are forwarded by a mailing list. Since the bounces go back to the
mailing list, the mailing list software then drops the entirely legitimate
list subscriber's subscription. :-(
The behavior you describe is certainly correct according to the RFCs, but
unfortunately now falls apart in practice. :-( 
3:38 a.m.
On Tue, 7 Mar 2017, Eric Christopherson via cctalk wrote:
What makes it so that other mailing lists don't
unsubscribe people when
bounces occur?
This list displays (not "full headers"):
Date: Tue, 7 Mar 2017 20:23:42 -0600
From: Eric Christopherson via cctalk <cctalk at classiccmp.org>
Reply-To: Eric Christopherson <echristopherson at gmail.com>,
"General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: I hate the new mail system
Some yahoos would do it as:
Date: Tue, 7 Mar 2017 20:23:42 -0600
From: "Eric Christopherson echristopherson at gmail.com [cctalk]"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: I hate the new mail system
Notice, that they also munge the From:, but they include the author's
email address buried within the munged From:.
It is not the "correct" From: and Reply-to:,
but, apparently some "modern" systems will not tolerate it done
"correctly".
Given that it is NOT going to be done "correctly", which among us are
capable of successfully working around it?
This discussion is a little like a pedantic grammar argument.
--
Grumpy Ol' Fred cisin at xenosoft.com
3:58 a.m.
It was thus said that the Great Fred Cisin via cctalk once stated:
On Tue, 7 Mar 2017, Eric Christopherson via cctalk
wrote:
Well, RFC-5322 allows a mailbox-list in the From: header, and an
address-list for the Reply-To:, I don't think this is illegal. And I just
noticed this RFC:
6854 Update to Internet Message Format to Allow Group Syntax in the
"From:" and "Sender:" Header Fields. B. Leiba. March 2013.
(Format:
TXT=20190 bytes) (Updates RFC5322) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC6854)
Given that, I think adding to the Reply-To: header is kosher now.
-spc (Hmm ... looks like I have to update my email parser ... )
What makes it so that other mailing lists
don't unsubscribe people when
bounces occur?
This list displays (not "full headers"):
Date: Tue, 7 Mar 2017 20:23:42 -0600
From: Eric Christopherson via cctalk <cctalk at classiccmp.org>
Reply-To: Eric Christopherson <echristopherson at gmail.com>,
"General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: I hate the new mail system
Some yahoos would do it as:
Date: Tue, 7 Mar 2017 20:23:42 -0600
From: "Eric Christopherson echristopherson at gmail.com [cctalk]"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: I hate the new mail system
Notice, that they also munge the From:, but they include the author's
email address buried within the munged From:.
It is not the "correct" From: and Reply-to:,
but, apparently some "modern" systems will not tolerate it done
"correctly".
Given that it is NOT going to be done "correctly", which among us are
capable of successfully working around it?
This discussion is a little like a pedantic grammar argument.
7 Mar
7 Mar
10:57 a.m.
On Mon, 6 Mar 2017, Mouse wrote:
[...]
And BTW, what you are doing is not clever at all:
mouse at Rodents-Montreal.ORG
SMTP error from remote mail server after initial connection:
host MX-4.rodents-montreal.org [98.124.61.89]:
550-.de's whois server, whois.denic.de, is completely broken, handing
550-out no contact information at all when queried for .de domains in
550 the usual way. Such a domain has no place on a civilized network.
This is just wrong. Of course they hand out contact information!
Sorry, I had to post it here since I cannot contact you directly.
Christian
11:58 a.m.
On 07/03/2017 09:57, Christian Corti via cctalk wrote:
And BTW, what you are doing is not clever at all:
mouse at Rodents-Montreal.ORG
SMTP error from remote mail server after initial connection:
host MX-4.rodents-montreal.org [98.124.61.89]:
550-.de's whois server, whois.denic.de, is completely broken, handing
550-out no contact information at all when queried for .de domains in
550 the usual way. Such a domain has no place on a civilized network.
This is just wrong. Of course they hand out contact information!
Sorry, I had to post it here since I cannot contact you directly.
No, Mouse is right, it's broken:
$ whois uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
$ whois -h whois.denic.de uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
$
So then I try this:
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
help
% SYNTAX: whois [-r] [-T types] [-C charset] key
%
% where our server understands the following options:
%
% -r turn off recursive lookups (default: on)
% -T ace ACE input for domain lookup
% -T domain (dn) only look for objects of type domain
% -T status (st) only look for domain status
% -C charset specify character set for the input/output
% Available charsets: US-ASCII, ISO-8859-1,
UTF-8 (default)
%
% NOTE: Read the detailed documentation for valid argument combinations.
There are two special queries
%
% [?, HELP, help] displays this text
% alive at whois returns 'alive' if whois server runs properly
%
% Detailed documentation under https://www.denic.de/webwhois/?lang=en
%
Connection closed by foreign host.
$
So far, so good. The server's alive (yes, I also tried the
"alive at whois" command). But:
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
whois -r uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
Connection closed by foreign host.
$
That's broken.
And there is little helpful documentation about how to query the whois
service at the URL given in the HELP text. I eventually found a document at
https://www.denic.de/fileadmin/public/documentation/DENIC-12p_EN.pdf
which describes how to make a whois query of this rather idiosyncratic
server. It states that it should work as I tested it - but even
adopting the example given in that document fails:
$ whois -h whois.denic.de -T status uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
$
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
whois -T status uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
Connection closed by foreign host.
$
Epic fail.
--
Pete
Pete Turnbull
2:47 p.m.
On Tue, 7 Mar 2017, Pete Turnbull wrote:
No, Mouse is right, it's broken:
Works for me (also from different networks outside the university
network):
# whois uni-stuttgart.de
% Copyright (c) 2010 by DENIC
% Version: 2.0
%
% Restricted rights.
%
% Terms and Conditions of Use
%
% The data in this record is provided by DENIC for informational purposes only.
% DENIC does not guarantee its accuracy and cannot, under any circumstances,
[...]
Domain: uni-stuttgart.de
Nserver: dns0.uni-stuttgart.de 129.69.0.1 2001:7c0:7c0:0:0:0:babe:face
Nserver: dns1.belwue.de
Nserver: dns1.uni-stuttgart.edu
Nserver: dns3.belwue.de
Nserver: minnehaha.rhrk.uni-kl.de
[...]
Christian
3:57 p.m.
On 07/03/2017 13:47, Christian Corti via cctalk wrote:
On Tue, 7 Mar 2017, Pete Turnbull wrote:
Interesting... I still get the same errors. Could it be
location-dependant in some way? Are you using the standard whois port
43/TCP?
--
Pete
Pete Turnbull
No, Mouse is right, it's broken:
Works for me (also from different networks outside the university network):
4:43 p.m.
No, Mouse is
right, it's broken:
Works for me (also from different networks outside the university network): 
8 Mar
8 Mar
8:11 a.m.
On 7 March 2017 at 15:57, Pete Turnbull via cctalk
<cctalk at classiccmp.org> wrote:
On 07/03/2017 13:47, Christian Corti via cctalk wrote:
I tested 'whois -h whois.denic.de uni-stuttgart.de'
On Tue, 7 Mar 2017, Pete Turnbull wrote:
Interesting... I still get the same errors. Could it be location-dependant
in some way? Are you using the standard whois port 43/TCP?
No, Mouse is right, it's broken:
Works for me (also from different networks outside the university
network): from Oslo, London, Tokyo, and it seems to work fine - I
got all
expected whois output. Tested yesterday too.
Sounds like it may be the whois client instead - what OS are you guys
using, and which 'whois' version?
I'm using various Linux distros.
7:46 p.m.
On 08/03/2017 07:11, Tor Arntsen via cctalk wrote:
I tested 'whois -h whois.denic.de
uni-stuttgart.de'
from Oslo, London, Tokyo, and it seems to work fine - I got all
expected whois output. Tested yesterday too.
Sounds like it may be the whois client instead - what OS are you guys
using, and which 'whois' version?
This is rather intriguing.
No, not the fault of the whois client. I repeated yesterday's tests and
a few more because I'd closed the terminal windows I used yesterday, and
also to try to eliminate any temporary aberrations. I did wonder if
whois.denic.de is actually a load-balanced server farm and I just
happened to be hitting a broken member of the farm and some of you guys
weren't. But that does not seem to be the case.
FWIW I was using linux whois-4.5.17 originally from www.linux.it, based
on the RIPE whois client, compiled locally from source under IRIX. It's
part of various Linux distributions and it works on hundreds of other
whois servers; I use it frequently (part of my job) and never had a
problem before. That's important because when I eventually found the
"DENIC Public-Whois Documentation" I noted that it recommends the RIPE
whois client. So just to be thorough I downloaded and compiled the
latest RIPE whois on an Ubuntu Linux system and get a similar result
with a standard query. I also downloaded and tested Microsoft's whois
for Windows and got the same broken result, same "Error: 55000000007
Request not clearly specified" message.
More importantly, I tested connecting directly using telnet to port 43,
exactly as specified in RFCs 3912 and 954. Here it is again, showing
the output of the (required) HELP command:
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
?
% SYNTAX: whois [-r] [-T types] [-C charset] key
%
% where our server understands the following options:
%
% -r turn off recursive lookups (default: on)
% -T ace ACE input for domain lookup
% -T domain (dn) only look for objects of type domain
% -T status (st) only look for domain status
% -C charset specify character set for the input/output
% Available charsets: US-ASCII, ISO-8859-1,
UTF-8 (default)
%
% NOTE: Read the detailed documentation for valid argument combinations.
There are two special queries
%
% [?, HELP, help] displays this text
% alive at whois returns 'alive' if whois server runs properly
%
% Detailed documentation under https://www.denic.de/webwhois/?lang=en
%
Connection closed by foreign host.
$
Notice that - unlike normal whois servers - this one apparently requires
some other stuff, possibly including the text "whois", as part of the
query. That may explain why a normal whois client gets an error, because
the standard way to make a query is simply to send the string to query
(eg, "uni-stuttgart.de" or "dunnington.cx"):
$ whois -h whois.denic.de uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
OK, so back to telnet, and try it with the syntax DENIC claims to want:
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
-T dn uni-stuttgart.de
[lots of output]
$
Aha! That works. But I can't replicate it with most whois clients.
However, it /does/ work with the jwhois client, which some linux systems
have, and which seems to have some special method to deal with DENIC. It
doesn't work with the RIPE client - despite DENIC recommending that -
unless you construct a rather odd-looking query by adding at least "--T dn":
gleek:whois3-3.2.2 $ ./whois -h whois.denic.de uni-stuttgart.de Domain:
uni-stuttgart.de
Status: connect
gleek:whois3-3.2.2 $
gleek:whois3-3.2.2 $ ./whois -h whois.denic.de --T dn uni-stuttgart.de
[lots of output]
gleek:whois3-3.2.2 $
So IMHO it's broken; it doesn't respond to a standard query format as
defined in the RFCs, but only to a modified query string, one which some
perfectly good clients can't correctly format.
Just for comparison, I also tested the RIPE client, Microsoft client,
and telnet with some .co.uk, .ac.uk, .com, .cn and .cx domains using
several whois servers, and found a standard query worked every time.
Obviously that's not exhaustive but so far whois.denic.de is the only
one I've found with this odd behaviour.
--
Pete
Pete Turnbull
9 Mar
9 Mar
8:25 a.m.
On 8 March 2017 at 19:46, Pete Turnbull <pete at dunnington.plus.com> wrote:
Notice that - unlike normal whois servers - this one
apparently requires
some other stuff, possibly including the text "whois", as part of the query.
That may explain why a normal whois client gets an error, because the
standard way to make a query is simply to send the string to query (eg,
"uni-stuttgart.de" or "dunnington.cx"):
$ whois -h whois.denic.de uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
OK, so back to telnet, and try it with the syntax DENIC claims to want:
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
-T dn uni-stuttgart.de
[lots of output]
$
Aha! That works. But I can't replicate it with most whois clients.
However, it /does/ work with the jwhois client, which some linux systems
have, and which seems to have some special method to deal with DENIC. It
doesn't work with the RIPE client - despite DENIC recommending that - unless
you construct a rather odd-looking query by adding at least "--T dn":
[..]
Pete Turnbull
I did an strace and I can confirm that the Linux 'whois' client that I
used from those various sites sends '-T dn' (or actually -T dn,ace)
write(3, "-T dn,ace uni-stuttgart.de\r\n", 28) = 28
I can't see where this whois originates from, it has version number
'5.2.<something>'. Its man page refers to RFC 3912, but RFC 3912 says
nothing about -T. RFC 3912's single example wouldn't have worked in
this case. So I wonder what replaced RFC 3912, and why there's a
mismatch between documentation and functionality.
10:50 a.m.
On Thu, 9 Mar 2017, Tor Arntsen wrote:
I did an strace and I can confirm that the Linux
'whois' client that I
used from those various sites sends '-T dn' (or actually -T dn,ace)
write(3, "-T dn,ace uni-stuttgart.de\r\n", 28) = 28
I can't see where this whois originates from, it has version number
'5.2.<something>'. Its man page refers to RFC 3912, but RFC 3912 says
nothing about -T. RFC 3912's single example wouldn't have worked in
this case. So I wonder what replaced RFC 3912, and why there's a
mismatch between documentation and functionality.
I did a little research on that:
The '-T' option is passed to the whois server, it's not a client option.
Intelligent or modern clients know what options to pass to the appropriate
server, in this case '-T dn' to the DENIC whois server.
This option is completely legal and was introduced at DENIC in an attempt
to better protect the domain holder's privacy (you know, different
country, different rules). This was many years ago, but it's still there.
RFC 3912 doesn't specify what output the whois server is supposed to send.
Everybody "assumes" that it should be the complete domain information, but
that's simply not the case.
Imposing this assumption is what Mouse does, and that is wrong. Heck, I
could even have a whois server that tells me the current weather forecast
for a specific request ;-) It is a minimalistic directory service, nothing
more.
Christian
10 Mar
10 Mar
9:42 p.m.
On 09/03/2017 09:50, Christian Corti via cctalk wrote:
On Thu, 9 Mar 2017, Tor Arntsen wrote:
> I did an strace and I can confirm that the Linux 'whois' client that I
> used from those various sites sends '-T dn' (or actually -T dn,ace)
I did a little research on that:
The '-T' option is passed to the whois server, it's not a client option.
I don't think Tor has suggested it's a client option, and I certainly
did not. It's simply part of the string that one particular client
knows to send to DENIC, and which at least one other client can be
forced (manually) to send.
Intelligent or modern clients know what options to
pass to the
appropriate server, in this case '-T dn' to the DENIC whois server.
Well, for one value of modern :-) The RIPE client which DENIC
themselves recommend people to use, does not do that. It has to be
cajoled into sending the "-T dn" along with the query string.
This option is completely legal and was introduced at
DENIC in an
attempt to better protect the domain holder's privacy (you know,
different country, different rules). This was many years ago, but it's
still there.
Legal in what sense? It's not part of any RFC, and appears to be unique
to DENIC. I regularly use dozens of whois servers and not one other
honours, let alone requires, that option. Also not that RFC3912 gives a
single protocol example which does not require any such option, and
refers to RFC954 for normative references - ie, they way it should be
done. No -T there either.
RFC 3912 doesn't specify what output the whois
server is supposed to
send. Everybody "assumes" that it should be the complete domain
information, but that's simply not the case.
That's certainly true. Very few whois servers return all the
information; many won't disclose phone numbers, for example. In fact I
was surprised how much text /is/ returned by DENIC.
Imposing this assumption is what Mouse does, and that
is wrong.
I disagree; Mouse (and I) were simply using standard common whois
clients and getting either nothing or an error in return to queries.
--
Pete
Pete Turnbull
11 Mar
11 Mar
3:17 a.m.
> RFC 3912 doesn't specify what output the whois
server is supposed to
> send. Everybody "assumes" that it should be the complete domain
> information, but that's simply not the case.
> Imposing this assumption is what Mouse does, and
that is wrong.
No, that is not what I'm doing, though I can certainly see how you
could come to that conclusion.
I'm not expecting/requiring/whatever that the relevant WHOIS server
return all available information. But there is a lot of room between
that and returning no contact information whatever, which latter is
what DENIC does when queried in the usual way, ie, just the domain name
without any DENIC-specific text. And that's well on the "unreasonable"
side of the line.
In my opinion, of course. It's my mailserver, so that's what matters.
This option is
completely legal [...]
Legal in what sense? 
12 Mar
12 Mar
12:10 p.m.
Mouse via cctalk wrote:
[..]
law). I simply consider it antisocial and
uncivilized, and am not
interested in accepting mail from any domain within its bailiwick.
...what you call social and civilized it seems...
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
info at tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741
15 Mar
15 Mar
10:44 a.m.
I was wondering why 99% of my cctalk shows up as "read mail".. =/
What a PITA, I can't tell what I have read from what I have not read - is
this part of the 'new' system?
On Mon, Mar 13, 2017 at 2:46 PM, ben via cctalk <cctalk at classiccmp.org>
wrote:
What did you do? 99% of all my cctalk is now in my
spam filter.
5:07 p.m.
On Wed, Mar 15, 2017 at 4:44 AM, drlegendre . via cctalk <
cctalk at classiccmp.org> wrote:
I was wondering why 99% of my cctalk shows up as
"read mail".. =/
What a PITA, I can't tell what I have read from what I have not read - is
this part of the 'new' system?
You mean in Gmail? I don't have that problem with mine. Do you perhaps have
a filter that automatically marks them read, which wasn't being run before?
--
Eric Christopherson
16 Mar
16 Mar
3:26 a.m.
I didn't make any intentional changes to my filters (do I even have any?)
so I can't say that's the cause. But about 75% of my cctalk mails now show
up as "read".. and it's super-annoying. Anyone know how to correct it?
On Wed, Mar 15, 2017 at 11:07 AM, Eric Christopherson via cctalk <
cctalk at classiccmp.org> wrote:
On Wed, Mar 15, 2017 at 4:44 AM, drlegendre . via
cctalk <
cctalk at classiccmp.org> wrote:
I was wondering why 99% of my cctalk shows up as
"read mail".. =/
What a PITA, I can't tell what I have read from what I have not read - is
this part of the 'new' system?
You mean in Gmail? I don't have that problem with mine. Do you perhaps have
a filter that automatically marks them read, which wasn't being run before?
--
Eric Christopherson
5:57 a.m.
I don't hate it, but it sure is inconvenient:
Looks like I get messages with three different "TO" addresses:
cctalk at classiccmp.org
and
General Discussion: On-Topic and Off-Topic Posts; <Sender>
No problem with those two; easy to pick out cctalk messages.
But
<Sender>;General Discussion: On-Topic and Off-Topic Posts
is a PITA since of course it sorts etc. by the Sender instead of a CCTALK ID.
Why the difference?
m
13 Mar
13 Mar
9:30 a.m.
On 9 March 2017 at 10:50, Christian Corti via cctalk
<cctalk at classiccmp.org> wrote:
On Thu, 9 Mar 2017, Tor Arntsen wrote:
>
> I did an strace and I can confirm that the Linux 'whois' client that I
> used from those various sites sends '-T dn' (or actually -T dn,ace)
>
> write(3, "-T dn,ace uni-stuttgart.de\r\n", 28) = 28
[..]
I did a little research on that:
The '-T' option is passed to the whois server, it's not a client option.
[..]
I didn't say it was - the above output is the *strace* output (I could
as well have used tcpdump I suppose) to see what was passed to the
whois server, from the whois client, when used with those options
shown before (-h <whois server> domain)
9 Mar
9 Mar
11:24 a.m.
On 09/03/2017 07:25, Tor Arntsen wrote:
I did an strace and I can confirm that the Linux
'whois' client that I
used from those various sites sends '-T dn' (or actually -T dn,ace)
write(3, "-T dn,ace uni-stuttgart.de\r\n", 28) = 28
I can't see where this whois originates from, it has version number
'5.2.<something>'. Its man page refers to RFC 3912, but RFC 3912 says
nothing about -T. RFC 3912's single example wouldn't have worked in
this case. So I wonder what replaced RFC 3912, and why there's a
mismatch between documentation and functionality.
RFC 3912 is still the current RFC for whois; it's not been replaced.
But there are two other related information systems, Rwhois (Referral
whois, RFC1714, RFC2167) and whois++ (structured whois, RFC1835,
RFC1913, RFC1914). They're more sophisticated, of course, but I don't
know of any real-life examples and references I've found suggest they
were never deployed.
Rwhois runs on port 4321 by default and its syntax is nothing like that
used by DENIC, while whois++ runs on port 63. Being an extension to
provide structured responses to a range of template-based queries (it
too can perform recursive queries on behalf of a client, like rwhois),
its syntax also looks nothing like normal whois or that used by DENIC.
However, one of the above-mentioned RFCs does comment, wrt whois, that
"Unfortunately, these additions and extensions have been done in an ad
hoc and uncoordinated manner." Uh-huh :-)
--
Pete
Pete Turnbull
7 Mar
7 Mar
4:07 p.m.
> And BTW, what you are doing is not clever at all:
> mouse at Rodents-Montreal.ORG
> SMTP error from remote mail server after initial connection:
> host MX-4.rodents-montreal.org [98.124.61.89]:
> 550-.de's whois server, whois.denic.de, is completely broken, handing
> 550-out no contact information at all when queried for .de domains in
> 550 the usual way. Such a domain has no place on a civilized network.
It's not supposed to be clever. I'm just willing to call brokenness
brokenness. That it's an entire country that's broken does not make it
any less broken. Nor does it get them a pass on brokenness; if
anything, being big makes the offence greater - they have less excuse.
> This is just wrong. Of course they hand out
contact information!
They didn't when I put that block in place, not without some
DENIC-specific option - and still don't; see below. That's why I wrote
"when queried...in the usual way".
Since the whole point of WHOIS is to find data on domains you don't
know things about, requiring some idiosyncratic option is, IMO, broken.
Here's what I see, run while composing this mail:
[Sparkle] 1> whois -h whois.denic.de uni-stuttgart.de
Domain: uni-stuttgart.de
Status: connect
[Sparkle] 2>
or
[Sparkle] 3> telnet whois.denic.de whois
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
uni-stuttgart.de
Domain: uni-stuttgart.de
Status: connect
Connection closed by foreign host.
[Sparkle] 4>
Maybe you consider that to be contact information. I don't.
$ whois -h whois.denic.de uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
I don't know what's going on here. The only way I've got that is to
query for "-r uni-stuttgart.de". I know some whois clients
automatically try to add the DENIC-specific option I mentioned above;
perhaps yours is, but DENIC has changed and no longer accepts it? (IMO
that would be, if anything, even more broken.)
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
whois -r uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
Connection closed by foreign host.
$
That's broken.
In that case, it's the query that's broken. The normal way to use
whois for domains is to send just the domain name upon connecting; the
"whois -r " prefix you used is probably responsible.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
4:43 p.m.
On 07/03/2017 15:07, Mouse via cctalk wrote:
Nope, that's taken from their own documentation - and it makes no
difference which options I give it, or none. I didn't show all the
permutations I tried, both using a standard UNIX whois client, and using
telnet to port 43. It's just broken.
--
Pete
Pete Turnbull
$ telnet
whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
whois -r uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
Connection closed by foreign host.
$
That's broken.
In that case, it's the query that's broken. The normal way to use
whois for domains is to send just the domain name upon connecting; the
"whois -r " prefix you used is probably responsible.
8:01 p.m.
Mouse via cctalk wrote:
Yes..you are the good guy.
It's better now?
It may be not supposed to be clever, it's just supposed to be idiotic..you
behave like a moron in this case, I'm toldd my opinion about that years
before to you.
I think no one from the german guys here can change anything on the
DeNics behavior regarding their whois service, and you punishing all the
germans for ther NIC service...OMG...
You are an intelligent guy and a very good programmer..but in this case,
sorry...
Regards,
Holm
$ whois uni-stuttgart.de
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.denic.de
domain: DE
organisation: DENIC eG
address: Kaiserstrasse 75-77
address: Frankfurt am Main 60329
address: Germany
contact: administrative
name: Vorstand DENIC eG
organisation: DENIC eG
address: Kaiserstrasse 75-77
address: Frankfurt am Main 60329
address: Germany
phone: +49 69 27235 0
fax-no: +49 69 27235 235
e-mail: vorstand at denic.de
contact: technical
name: Business Services
organisation: DENIC eG
address: Kaiserstrasse 75-77
address: Frankfurt am Main 60329
address: Germany
....
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
info at tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741
> And BTW,
what you are doing is not clever at all:
> mouse at Rodents-Montreal.ORG
> SMTP error from remote mail server after initial connection:
> host MX-4.rodents-montreal.org [98.124.61.89]:
> 550-.de's whois server, whois.denic.de, is completely broken, handing
> 550-out no contact information at all when queried for .de domains in
> 550 the usual way. Such a domain has no place on a civilized network.
It's not supposed to be clever. I'm just willing to call brokenness
brokenness. That it's an entire country that's broken does not make it
any less broken. Nor does it get them a pass on brokenness; if
anything, being big makes the offence greater - they have less excuse. 
16 Mar
16 Mar
6:01 p.m.
On 03/07/2017 10:57 AM, Christian Corti via cctalk wrote:
On Mon, 6 Mar 2017, Mouse wrote:
[...]
And BTW, what you are doing is not clever at all:
mouse at Rodents-Montreal.ORG
SMTP error from remote mail server after initial connection:
host MX-4.rodents-montreal.org [98.124.61.89]:
550-.de's whois server, whois.denic.de, is completely broken, handing
550-out no contact information at all when queried for .de domains in
550 the usual way. Such a domain has no place on a civilized network.
This is just wrong. Of course they hand out contact information!
Sorry, I had to post it here since I cannot contact you directly.
Uh, that's funny! I visited the rodent-server as well... Interesting....
The opposite of a mouse trap!
hachti at donald:~$ telnet MX-4.rodents-montreal.org
25
Trying 192.139.46.68...
Trying 98.124.61.89...
Connected to MX-4.rodents-montreal.org.
Escape character is '^]'.
helo donald.hachti.de
550-.de's whois server, whois.denic.de, is completely broken, handing
550-out no contact information at all when queried for .de domains in
550 the usual way. Such a domain has no place on a civilized network.
Connection closed by foreign host.
RUDE!
4 Mar
4 Mar
9:40 a.m.
New subject: I <am pretty okay with> the new mail system
On 3/3/2017 11:38 PM, Christian Corti via cctalk wrote:
On Fri, 3 Mar 2017, Jules Richardson wrote:
Thunderbird is putting in the list with the person in the Reply-To being
an additional recipient in the To:
I have not bothered stripping that extra.
The via ctalk is useful as a target for filtering the traffic. For some
reason there is leakage of detected emails on google. It is perhaps due
to prior mentioned non conforming emails of some sort, don't know, their
filtering sucks.
But it may be that that will allow me to catch more if not all of the
cctalk traffic in gmail.
I'm subscribed three times for archival purposes. I read via an email
subscription that ends up in a Thunderbird file via pop3 from that
server. Never misses with the email rule.
I wanted an outside the building forget it archive I could peruse, so
created a subscription into my gmail account. That one is leaking about
1 to 5 messages a week using the same rule as Thunderbird, which is
based on email to / from etc.
And a third subscription goes to an account on a server which pulls
everything via fetchmail. That subscription has nothing but Cctalk on
it. i have it as my main archive if all else fails. (and Thunderbird is
getting flaky, and has failed).
If the via cctalk stays, I'll try looking for that. I had asked jay
eons ago about a [cctalk] prepend on the subject and his and others
opinions was that that was not desirable. However it always works on
all lists I have for filtering. Maybe putting it in the from will be
unobtrusive enough people will put up with it, and maybe Google's
filtering won't suck with a rule hitting that field.
thanks
jim
Thanks to both of you. I came back to cctalk
after not checking it
for a few days, and wondered what the %$#^ was going on, with every
message showing with cctalk as the "from" field.
I'm another one who dislikes the new system. It would be much better
if the Reply-To field did *not* contain the sender's email address
because when I reply to a message, I use the Reply-To field (of
course) and have to delete the extra line because I want to reply to
the list and *not* privately to the sender. So either the sender's
address should be in the
From field or in a new header field, e.g.
List-Original-Sender or
something like that.
For now I have set up a procmail rule to strip the "via cctalk" from the
From field because this is ugly and redundant.
Christian 
5:40 p.m.
New subject: I <am pretty okay with> the new mail system
For what it's worth, I'm OK with it too. It correctly shows that this is a message
relayed by a list sent from a person. I can easily choose whether I want to respond to the
list or to the person or both, I had to make that choice before anyhow. If bounces are
fixed that's great.
Marc
On Mar 4, 2017, at 12:40 AM, jim stephens via cctalk
<cctalk at classiccmp.org> wrote:
On 3/3/2017 11:38 PM, Christian Corti via cctalk
wrote:
Thunderbird is putting in the list with the person in the Reply-To being
an additional recipient in the To:
I have not bothered stripping that extra.
The via ctalk is useful as a target for filtering the traffic. For some reason there is
leakage of detected emails on google. It is perhaps due to prior mentioned non conforming
emails of some sort, don't know, their filtering sucks.
But it may be that that will allow me to catch more if not all of the cctalk traffic in
gmail.
I'm subscribed three times for archival purposes. I read via an email subscription
that ends up in a Thunderbird file via pop3 from that server. Never misses with the email
rule.
I wanted an outside the building forget it archive I could peruse, so created a
subscription into my gmail account. That one is leaking about 1 to 5 messages a week
using the same rule as Thunderbird, which is based on email to / from etc.
And a third subscription goes to an account on a server which pulls everything via
fetchmail. That subscription has nothing but Cctalk on it. i have it as my main archive
if all else fails. (and Thunderbird is getting flaky, and has failed).
If the via cctalk stays, I'll try looking for that. I had asked jay eons ago about a
[cctalk] prepend on the subject and his and others opinions was that that was not
desirable. However it always works on all lists I have for filtering. Maybe putting it
in the from will be unobtrusive enough people will put up with it, and maybe Google's
filtering won't suck with a rule hitting that field.
thanks
jim On Fri, 3 Mar 2017, Jules Richardson wrote:
Thanks to both of you. I came back to cctalk after not checking it for a few days, and
wondered what the %$#^ was going on, with every message showing with cctalk as the
"from" field.
I'm another one who dislikes the new system. It would be much better if the Reply-To
field did *not* contain the sender's email address because when I reply to a message,
I use the Reply-To field (of course) and have to delete the extra line because I want to
reply to the list and *not* privately to the sender. So either the sender's address
should be in the
From field or in a new header field, e.g.
List-Original-Sender or
something like that.
For now I have set up a procmail rule to strip the "via cctalk" from the
From field because this is ugly and redundant.
Christian
6 Mar
6 Mar
8:01 a.m.
New subject: I <am pretty okay with> the new mail system
On 4 March 2017 at 17:40, CuriousMarc via cctalk <cctalk at classiccmp.org> wrote:
For what it's worth, I'm OK with it too. It
correctly shows that this is a message relayed by a list sent from a person. I can easily
choose whether I want to respond to the list or to the person or both, I had to make that
choice before anyhow. If bounces are fixed that's great.
It's a good fix, in my opinion. Nothing has changed for the worse with
respect to replying, and it solved the bounce problem. All's good.
16 Mar
16 Mar
5:51 p.m.
This header change thing is A BIG MESS!!!!! Make it like before, PLEASE!
It's just annoying, unusable (On my iOS devices, I can't find the
original sender at all!) and completely unneeded.
I'm losing fun using the list.
On 03/04/2017 08:38 AM, Christian Corti via cctalk wrote:
For now I have set up a procmail rule to strip the
"via cctalk" from the
> From field because this is ugly and redundant.
I want the rule, too!
Does it restore the old headers as well?!?
And WHY do I now have you personally AND the list in my TO: field after
simply hitting "reply" in thunderbird?
9:30 p.m.
It was written....
==============
This header change thing is A BIG MESS!!!!! Make it like before, PLEASE!
It's just annoying, unusable (On my iOS devices, I can't find the original
sender at all!) and completely unneeded.
I'm losing fun using the list.
----------------------
We've been in the process of moving our datacenter. As a result, changing
headers on this list has been the last thing on my mind priority-wise.
Add to that, we still have a few machines to move that will require
hand-reimplementation instead of just migration, and those have to be
finished first (paying customers).
Add to that... when THIS server gets reimplemented, the lists will be
recombined and the above patch should not be necessary.
So - given available time and priorities, I'd appreciate it if you could
suffer the lack of fun for a few weeks or a couple months, whatever it takes
me to (a) find the time and (b) to get it done. After that, I'm sure the fun
will return. Thanks for patience and understanding!
Best,
J
10:07 p.m.
Jay,
I think that despite the occasional venting of frustration we're mostly just trying to
add some data points that may help in the migration.
I'm pretty confident that every member of the list appreciates the time, effort and
whatever else you and certain others have contributed to keep this list humming as well as
it almost always does; I certainly do.
Thank you!
m
----- Original Message -----
From: "Jay West via cctalk" <cctalk at classiccmp.org>
To: "'Philipp Hachtmann'" <hachti at hachti.de>;
"'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at
classiccmp.org>
Sent: Thursday, March 16, 2017 4:30 PM
Subject: RE: I hate the new mail system
It was written....
==============
This header change thing is A BIG MESS!!!!! Make it like before, PLEASE!
It's just annoying, unusable (On my iOS devices, I can't find the original
sender at all!) and completely unneeded.
I'm losing fun using the list.
----------------------
We've been in the process of moving our datacenter. As a result, changing
headers on this list has been the last thing on my mind priority-wise.
Add to that, we still have a few machines to move that will require
hand-reimplementation instead of just migration, and those have to be
finished first (paying customers).
Add to that... when THIS server gets reimplemented, the lists will be
recombined and the above patch should not be necessary.
So - given available time and priorities, I'd appreciate it if you could
suffer the lack of fun for a few weeks or a couple months, whatever it takes
me to (a) find the time and (b) to get it done. After that, I'm sure the fun
will return. Thanks for patience and understanding!
Best,
J
17 Mar
17 Mar
2:43 p.m.
On 03/16/2017 10:07 PM, Mike Stein via cctalk wrote:
I'm pretty confident that every member of the list
appreciates the
time, effort and whatever else you and certain others have
contributed to keep this list humming as well as it almost always
does;
Full ack, of course!
But the new addressing scheme still sucks, sorry.
Kind regards
Philipp
7:50 p.m.
From: Jay West
Sent: Thursday, March 16, 2017 1:31 PM
We've been in the process of moving our
datacenter. As a result, changing
headers on this list has been the last thing on my mind priority-wise.
Add to that, we still have a few machines to move that
will require
hand-reimplementation instead of just migration, and those have to be
finished first (paying customers).
Add to that... when THIS server gets reimplemented,
the lists will be
recombined and the above patch should not be necessary.
So - given available time and priorities, I'd
appreciate it if you could
suffer the lack of fun for a few weeks or a couple months, whatever it takes
me to (a) find the time and (b) to get it done. After that, I'm sure the fun
will return. Thanks for patience and understanding!
Jay,
Thanks for putting up with the long, long discussion my original intemperate
complaint sparked. (A good friend who's also on the list privately said to
me "See what you started?", weeks ago.)
Thank you as well for hosting all of this at no charge to the group's members,
something for which we are all grateful (even if it does not appear so from
time to time).
Having managed multiple mailing lists over the decades, I applaud your efforts
to keep this a vibrant, civil place to discuss broadly our mutual interests.
Best regards,
Rich
Rich Alderson
Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Ave S
Seattle, WA 98134
http://www.LivingComputers.org/
3198
days inactive
3214
days old
50 comments
22 participants
participants (22)
-
amsï¼ gnu.org -
bfranchukï¼ jetnet.ab.ca -
ccï¼ informatik.uni-stuttgart.de -
cclistï¼ sydex.com -
cctalkï¼ beyondthepale.ie -
cisinï¼ xenosoft.com -
curiousmarc3ï¼ gmail.com -
dave.g4ugmï¼ gmail.com -
drlegendreï¼ gmail.com -
echristophersonï¼ gmail.com -
hachtiï¼ hachti.de -
holmï¼ freibergnet.de -
jules.richardson99ï¼ gmail.com -
jwestï¼ classiccmp.org -
jwsmailï¼ jwsss.com -
kspt.torï¼ gmail.com -
mhs.steinï¼ gmail.com -
mouseï¼ Rodents-Montreal.ORG -
peteï¼ dunnington.plus.com -
RichAï¼ livingcomputers.org -
spacewarï¼ gmail.com -
spcï¼ conman.org