* Re: empty Followup-to: header
2021-04-10 14:01 empty Followup-to: header Emanuel Berg
@ 2021-04-10 17:08 ` Emanuel Berg
2021-04-10 17:41 ` Andreas Schwab
1 sibling, 0 replies; 7+ messages in thread
From: Emanuel Berg @ 2021-04-10 17:08 UTC (permalink / raw)
To: ding
> 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:
<incal> o/
<incal> 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
<wgreenhouse> what would you be trying to convey, semantically, by including
that header but having it be blank?
<incal> it is always included
<incal> so does it do any harm if it is empty?
<incal> not conveying anything, it is just practical to have when needed,
when not needed, does leaving it blank do any harm?
<wgreenhouse> it is only meaningful for mailing lists. it's a bug to include
it anywhere else
<wgreenhouse> fortunately most clients ignore it anyway
<incal> OK, you have a source it is a bug? not that I don't believe you,
would just be interesting to see
<incal> wgreenhouse ^
<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
<wgreenhouse> 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
<wgreenhouse> 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
<wgreenhouse> in other contexts, nothing would disturb Reply-To: so it's
pointless
<wgreenhouse> ^ 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
<incal> it is used when crossposting to gmane or Usenet groups and then
directing traffic for replies
<incal> right NNTP as you say
<incal> and real Usenet (USENET), works the same way
<incal> but - does it say what happens when used in NNTP _and empty_ ?
<wgreenhouse> incal: see 2.2.3 of https://tools.ietf.org/html/rfc1036
<wgreenhouse> present but empty seems at best meaningless and at worst likely
to cause unspecified behaviors in clients
<incal> 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?
<incal> wgreenhouse ^
<incal> 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? :)
<wgreenhouse> 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?
<wgreenhouse> followups go to /dev/null? :)
<wgreenhouse> 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?
<wgreenhouse> it is not included in `message-required-news-headers` so gnus is
not forcing it
<incal> hehehe everything is my configuration,
https://dataswamp.org/~incal/emacs-init/gnus <-- 13 Gnus .el files
<incal> wgreenhouse ^
<wgreenhouse> ok. well it is unnecessary to force Followup-To into being.
message-mode has a command to make it for you
<wgreenhouse> 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
<wgreenhouse> so beware of nasal demons
<incal> OK point taken
<incal> 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
<wgreenhouse> I don't mind. Do you have any indication if gnus (or perhaps
news.gmane.org) does anything to alter such messages, btw?
<incal> it works when used as intended for NNTP & USENET, i.e.
with a non-blank header
<incal> for a blank header don't know, maybe I should ask at #gnus...
<wgreenhouse> I think gmane has a testing newsgroup, you could try it there
<incal> indeed gmane.test but how would that test be? just send it with
a blank? it appears!
<wgreenhouse> and the blank Followup-To: is retained? now try following up
that message :)
<incal> 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." :)
<wgreenhouse> IRC RFCs are deader than dinos, though. :D
<wgreenhouse> https://modern.ircdocs.horse/ serves as a pseudo RFC of actual
practice
<incal> see:
https://dataswamp.org/~incal/pimgs/comp/nine-chars-irc-nick.png
<wgreenhouse> 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)
<incal> you think one should have 31 char nicks?
*** WARNING: Nick length (30) exceeds max NICKLEN(16) defined by
server
<wgreenhouse> no, in practice it's obnoxious to have a nick that long.
<incalincalincali> nick incalincalincalincalincalincal # nope, DNC, max
NICKLEN = 16
<incalincalincal> yeah? OK, if you say
<wgreenhouse> hm. 16 is sensible
<wgreenhouse> but anyway it is these days a server decision, and few if any
irc networks strictly follow 2812
<incalincalincal> 9 is sensible, as said in the RFC
<incalincalincal> that's right, sorry. 1s
<incalinca> now
<treehouse> 9
<treehouse> https://dataswamp.org/~incal/blog
<treehouse> the best in blog entertainment
<treehouse> brought to you by: B-LOG
<treehouse> The tree house, winter 2020/21
<incal> now, -> out
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 7+ messages in thread