Re: [leafnode-list] Posting Problem

[Ralf Wildenhues <wildenhu@xxxxxxxxxxxxxxx>]

[ sorry for quoting so much ]

Joerg Dietrich wrote:
>
[ nntpd:dopost() control flow ]
> 		|
> 		v
> 	article goes to 
> 	moderated group	--yes-------------->-----
> 		|				|	
> 		n				|
> 		o			try to get moderator address	
> 		|			and approved header	
> 		|				|
> 		|				|
> 		v				|
> 	We have no mod address <----------------
> 	AND article goes to
> 	external group	  -----yes--------->----
> 		|				|
> 		n			store in out.going (**)
> 		o				|
> 		|			article goes to mod--yes--
> 		|			     group		 |
> 		|				|		 v
> 		|				n	    unlink from	
> 		|				o	 in.coming, return
> 		|				|
> 		|<------------------------------
> 		|
> 		v
> 	we have mod address
> 	AND post is not approved----yes--->mail, unlink in.coming, return (*)
> 		|
> 		|
> 		v
> 	 store article
*snip*
> 
> > The "retry" behaviour comes from #2, and #1 should make sure that in
> > your case, the article is mailed to exactly one moderator, not stored or
> > posted anywhere, that's the deal about moderated crossposts: the
> > crosspost is up to the moderator.
> 
> The problem seems to be at (*) (at a quick look), it should also
> unlink the article in out.going, if present.

I think the problem I am trying to see is somewhere else.  At least in
the scenario I sketched: The slave leafnode does not have the
moderator's address, thus stores the article in out.going (marked (**)).
The upstream mails it to the moderator.  Next time the slave runs
fetchnews, the upstream still does not report the article as "already
seen", so the slave posts it again.  The upstream mails it again.  Bad.

Now what I'm not sure of: if you post to moderated groups on a "real
world" news server, will they detect your duplicate or just happily mail
away again (given the fact that the article hasn't been approved)?

This scenario was not intended to test the upstream server or the local
groups feature, but to prevent multiple mails to moderators.  Obviously
I didn't want to test this on outside groups :->

I'm not sure if there is another similar problem at (*) in the case of
leafnode being the upstream.

HTH&HAND
Ralf

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list