From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30860 invoked from network); 10 Apr 2021 17:08:37 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 10 Apr 2021 17:08:37 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lVH62-00GTgN-GZ for ml@inbox.vuxu.org; Sat, 10 Apr 2021 12:08:34 -0500 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1lVH62-006pvg-17 for ml@inbox.vuxu.org; Sat, 10 Apr 2021 12:08:34 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lVH5z-006pvY-NH for ding@lists.math.uh.edu; Sat, 10 Apr 2021 12:08:31 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lVH5x-00GTg6-7c for ding@lists.math.uh.edu; Sat, 10 Apr 2021 12:08:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:References:Message-ID:Date:Subject: From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HUE17JU5fa59ajXB6OcB2kM1WHG7otTG1aiLG0H0T8I=; b=NSnFXNzflpwaABYtdvOHIsdQRK +BnX3VlmcJf1yWUK78Vd06i/ujYQNewnPlXeroyJ7Ev+u9DIZ5aLzECD+lT/1u52pTfpUE6BRIYEG sieYt9DNqLjkJPlNnaY/MJL+KSzEmVWT/ctpMRG//sklj6GIoQYdAHTxrBhm1VSGrU/k=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lVH5o-0006cm-V3 for ding@gnus.org; Sat, 10 Apr 2021 19:08:24 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lVH5o-0006RM-4M for ding@gnus.org; Sat, 10 Apr 2021 19:08:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org To: ding@gnus.org From: Emanuel Berg Subject: Re: empty Followup-to: header Date: Sat, 10 Apr 2021 19:08:15 +0200 Message-ID: <87zgy6dq4g.fsf@zoho.eu> References: <87k0pafdbs.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:zYazh/3bRsGSKNe4TQpnRLiH2vM= Mail-Copies-To: never List-ID: Precedence: bulk > o/ can I have an empty Followup-to: header? sometimes when > I crosspost I use it. crossposts e.g. to the dead but existing > gmane.emacs.erc.general AND to gmane.emacs.help where there > are some ERC users, for sure? can I have it (empty) for mails, > gmane, and Usenet (i.e., nntp.aioe.org) ? TIA > > (I have it empty now!) Whole discussion on #gnus: o/ can I have an empty Followup-to: header? sometimes when I crosspost I use it. crossposts e.g. to the dead but existing gmane.emacs.erc.general AND to gmane.emacs.help where there are some ERC users, for sure? can I have it (empty) for mails, gmane, and Usenet (i.e., nntp.aioe.org) ? TIA what would you be trying to convey, semantically, by including that header but having it be blank? it is always included so does it do any harm if it is empty? not conveying anything, it is just practical to have when needed, when not needed, does leaving it blank do any harm? it is only meaningful for mailing lists. it's a bug to include it anywhere else fortunately most clients ignore it anyway OK, you have a source it is a bug? not that I don't believe you, would just be interesting to see wgreenhouse ^ incal: https://cr.yp.to/proto/replyto.html has some info; it is not specified in any of the email RFCs, however. it is only semantically useful for mailing lists and gnus shouldn't (and as fae as I know does not) ever set it automatically in other contexts supporting clients are limited to gnus, thunderbird, mutt, and other muas used in software development-type mailing lists. it did not catch on beyond that, and most "muggle" MUAs will simply ignore it even if set as the above indicates, it exists only because mailing lists may set Reply-To:, meaning that MUAs are unable to use that to control whether or not direct replies to mailing list postings are desired in other contexts, nothing would disturb Reply-To: so it's pointless ^ actually, correction: the above concerns *Mail*-Followup-To. Plain Followup-To is only used in NNTP and has *no specified meaning* for email. see https://tools.ietf.org/html/rfc2076#section-3.5 it is used when crossposting to gmane or Usenet groups and then directing traffic for replies right NNTP as you say and real Usenet (USENET), works the same way but - does it say what happens when used in NNTP _and empty_ ? incal: see 2.2.3 of https://tools.ietf.org/html/rfc1036 present but empty seems at best meaningless and at worst likely to cause unspecified behaviors in clients again, meaningless maybe on the other side, but for me it is useful so it is there when needed. so it is an interface thing. maybe Gnus should remove it automagically if empty when sent BTW? wgreenhouse ^ I do the same with Newsgroups: and To: - bring them both there, if it is a mail, I use To:, if it is gmane, etc, if it is both, ..., you follow? :) incal: maybe gnus should remove it if empty, idk. but it makes no sense to send it empty, for the reason that the header is specified to *override* Newsgroups: if present. But what are we asking the client to do when we override Newsgroups: with a blank header? followups go to /dev/null? :) incal: btw, are you saying gnus is in fact sending this header blank with a default configuration, or that this happens in your configuration, or what? it is not included in `message-required-news-headers` so gnus is not forcing it hehehe everything is my configuration, https://dataswamp.org/~incal/emacs-init/gnus <-- 13 Gnus .el files wgreenhouse ^ ok. well it is unnecessary to force Followup-To into being. message-mode has a command to make it for you and some other client *could* misbehave on encountering a blank Followup-To:. from the RFC I can't tell you what should happen in that situation so beware of nasal demons OK point taken can I send this whole discussion to gmane.emacs.gnus.general ? I can obfuscate your name if you'd like. or include it. or not do it at all I don't mind. Do you have any indication if gnus (or perhaps news.gmane.org) does anything to alter such messages, btw? it works when used as intended for NNTP & USENET, i.e. with a non-blank header for a blank header don't know, maybe I should ask at #gnus... I think gmane has a testing newsgroup, you could try it there indeed gmane.test but how would that test be? just send it with a blank? it appears! and the blank Followup-To: is retained? now try following up that message :) OK, thanks, will do, must go. BTW as you seem to like RFC, please see RFC 2812, 1.2.1 Users - https://tools.ietf.org/html/rfc2812 - "Each user is distinguished from other users by a unique nickname having a maximum length of nine (9) characters." :) IRC RFCs are deader than dinos, though. :D https://modern.ircdocs.horse/ serves as a pseudo RFC of actual practice see: https://dataswamp.org/~incal/pimgs/comp/nine-chars-irc-nick.png well sorry-not-sorry for messing up your indentation. :P https://modern.ircdocs.horse/#nicklen-parameter is the thing freenode actually enforces (at 31, IIRC) you think one should have 31 char nicks? *** WARNING: Nick length (30) exceeds max NICKLEN(16) defined by server no, in practice it's obnoxious to have a nick that long. nick incalincalincalincalincalincal # nope, DNC, max NICKLEN = 16 yeah? OK, if you say hm. 16 is sensible but anyway it is these days a server decision, and few if any irc networks strictly follow 2812 9 is sensible, as said in the RFC that's right, sorry. 1s now 9 https://dataswamp.org/~incal/blog the best in blog entertainment brought to you by: B-LOG The tree house, winter 2020/21 now, -> out -- underground experts united https://dataswamp.org/~incal