[ mailman-Bugs-1256272 ] NNTP gatewaying trashes Message-IDs

[SourceForge.net]

Bugs item #1256272, was opened at 2005-08-11 01:47
Message generated for change (Comment added) made by poelzi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1256272&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: nntp/news
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kate Turner (kateturner)
Assigned to: Nobody/Anonymous (nobody)
Summary: NNTP gatewaying trashes Message-IDs

Initial Comment:
when a message is relayed to NNTP, the NewsRunner
unconditionally replaces the existing Message-ID with
its own.  this breaking threading when reading a list
via news, and when an NNTP user replies to a list message.

a better solution would be either:
1) do not rewrite the message-id unless the NNTP server
reports an error when posting it (duplicate ID); or
2) optionally, always rewrite posters' message-ids into
a mailman-generated ID, and use this ID for both mail
and news.

i have implemented the former at our site and it
appears to work, but it's so ugly i'd not feel
comfortable submitting a patch for it.

----------------------------------------------------------------------

Comment By: Daniel Poelzleithner (poelzi)
Date: 2006-12-12 21:12

Message:
Logged In: YES 
user_id=70861
Originator: NO

nobrowser: the problem is, that newsserver drop messages in crossposts
when one is a mailinglist and the other is a newsgroup.

i just had an idea. we you use a small sqlite table:

| Original-ID | Translated-ID | Last-Used |

When a message is pulled von news, we replace in the reference header alle
ocurrences of translated-id's with their original id's.
When a message is posted to news, we replace all original-id's with
translated-id's.
A new message still generates a new message id, the original is inserted
into the table along with it's original id.
On all actions, we update last-used.

The daily cron job, deletes all last-used older than x days (60 for
example) to keep the table small. This way, no thread trashing would occure
on both sides, while keeping crossposting possible and overhead isn't too
much i think.


----------------------------------------------------------------------

Comment By: Kate Turner (kateturner)
Date: 2006-04-29 16:44

Message:
Logged In: YES 
user_id=1116721

the conflicts occur when a user cross-posts a message to 
two lists.  the newsrunner won't turn it into a cross-post, 
instead it tries to post it separately to both groups, and 
the news server rejects the second one for a duplicate 
message-id (tested with innd).

of course, you could say this behaviour is a bug too :) i'm 
not sure what the best way to group cross-posted messages 
is, since they won't be received by the same mailman 
instance.  (cancelling the first and re-posting to both 
groups might work, but i don't know if inn will still 
record the message-id and not allow it to be reused.)


----------------------------------------------------------------------

Comment By: Ian Z. (nobrowser)
Date: 2006-04-20 07:13

Message:
Logged In: YES 
user_id=1192798

Finally!  I thought I was the only one who noticed this.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346413

Why would the mail message-id ever cause a conflict with
the NNTP server?  message-ids are supposed to be globally
unique and there is a convention (in RFC 2822?) that ensures
it (put in the FQDN and something unique to the generating
software).  So I think 1) is not ugly but correct :)

2) wouldn't completely solve the problem.  
I can post one copy of a message to a mailman list and
another directly to another recipient, including myself.
(I actually Cc myself on all mail I send).  If mailman
does 2), the extra recipient will still be confused.

Ian


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1256272&group_id=103