Bug#472006: slrn now nags user about too long reference header in reply to groups.google messages
Hi Tim,
Tim Connors schrieb am Mon 04. Aug, 21:33 (+1000):
Since this is a rather useless feature,
I don't think so.
I have just wholesale disabled it in the following patch.
I don't like this idea, because it might hide bug. I've created a
different patch and asked upstream for inclusion. Can you try the patch
and see if you have any problem?
diff --git a/src/mime.c b/src/mime.c
index d36568c..9d11e8f 100644
--- a/src/mime.c
+++ b/src/mime.c
@@ -1238,7 +1238,12 @@ static Slrn_Mime_Error_Obj *fold_line (char
**s_ptr)/*{{{*/
s = skip_non_ascii_whitespace (s, smax);
line_len = s - s0;
- if (line_len = MAX_CONTINUED_HEADER_SIZE)
+ /* Google Groups uses big message IDs they lead to overlong lines. But we
+* can't fold these lines, because we must keep the message ID as is.
+*/
+ if (line_len = MAX_CONTINUED_HEADER_SIZE
+(0 != slrn_case_strncmp(s0, references:, 11)
+ || 0 != slrn_case_strncmp(s - 17, googlegroups.com, 17)))
long_words++;
if (NULL == (folded_text = slrn_strnmalloc (s0, line_len, 1)))
Bye, Jörg.
--
chinesiches Sprichwort:
Wer fragt, ist ein Narr für fünf Minuten.
Wer nicht fragt, ist ein Narr fürs ganze Leben.
signature.asc
Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Bug#472006: slrn now nags user about too long reference header in reply to groups.google messages
On Sat, 22 Mar 2008, Tim Connors wrote: Package: slrn Version: 0.9.9~pre97-1 Severity: normal I don't know whether this is a new feature, or one that has been exposed by a recent change at google, but slrn now nags with: Your message is not acceptable for the following reason(s): One word of the header is too long to get folded. This message was generated while looking at the following line References: [EMAIL PROTECTED] Sure it's long, and a weak violation of the RFC's, but the alternative is to break the reference header altogether. Since any half decent software out there will be programmed competantly enough not to get a buffer overflow when presented with a long header of this sorts, does it really matter if we send out a header that is slightly too long? This has been discussed in news.software.readers, but I don't know what the long term plan is - I was under the impression that this had been recently fixed, but then it seems that there were actually several header-breaking bugs and this one might have slipped under the radar. Since this is a rather useless feature, I have just wholesale disabled it in the following patch. Presumably every user who follows up to google groups postings would find such a patch useful (or fear getting used to having to press f to force posting otherwise, which will one day come back to bite them when they accidentally end up forcing something that was a real warning) See also the posts in this thread: http://newsgroups.derkeiler.com/Archive/Misc/news.software.readers/2008-02/msg00482.html --- src/mime.c.bak 2008-08-04 21:27:44.0 +1000 +++ src/mime.c 2008-08-04 21:24:52.0 +1000 @@ -1288,9 +1288,9 @@ slrn_free (*s_ptr); *s_ptr = folded_text; - if (long_words) - return slrn_add_mime_error(NULL, _(One word of the header is too long to get folded.), *s_ptr, 0, MIME_ERROR_WARN); - else +// if (long_words) +// return slrn_add_mime_error(NULL, _(One word of the header is too long to get folded.), *s_ptr, 0, MIME_ERROR_WARN); +// else return NULL; } (other warnings about non-rfc compliant messages can stay - this is the only one that has proven to be a useless check, so far). -- TimC New!: Sysadmin Barbie! Complete with tiny pager, Leatherman, selection of LARTs, and makeup kit for that haven't-slept-in-3-days look. --unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472006: slrn now nags user about too long reference header in reply to groups.google messages
Package: slrn Version: 0.9.9~pre97-1 Severity: normal I don't know whether this is a new feature, or one that has been exposed by a recent change at google, but slrn now nags with: Your message is not acceptable for the following reason(s): One word of the header is too long to get folded. This message was generated while looking at the following line References: [EMAIL PROTECTED] Sure it's long, and a weak violation of the RFC's, but the alternative is to break the reference header altogether. Since any half decent software out there will be programmed competantly enough not to get a buffer overflow when presented with a long header of this sorts, does it really matter if we send out a header that is slightly too long? This has been discussed in news.software.readers, but I don't know what the long term plan is - I was under the impression that this had been recently fixed, but then it seems that there were actually several header-breaking bugs and this one might have slipped under the radar. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24 (SMP w/2 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages slrn depends on: ii debconf [debconf-2.0] 1.5.20 Debian configuration management sy ii libc6 2.7-9 GNU C Library: Shared libraries ii libcanlock2 2b-4 library for creating and verifying ii libslang2 2.1.3-2The S-Lang programming library - r slrn recommends no packages. -- debconf information: * shared/mailname: dirac.rather.puzzling.org slrn/manual_getdescs: slrn/getdescs: cron job slrn/getdescs_now: false * shared/news/server: news.rather.puzzling.org slrn/lost_slrnpull: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
