Iam tyring to figure out why we have Posits from overseas stations repeatedly coming out on RF here from our Igates onto RF when they are not setup to do this.
It is however normal behaviour for a posit to pop out from the IS via the IGates if messaging traffic is happening between a station on the IS and a local station.
This is where it gets interesting. Ive found one station consistantly sending REJ to Bulletins generated here on the local frequency.
The station is WA1PLE-4 which I would have thought would be a HF Igate.
Every time a Bulletin goes out locally at about a 20-30 min rate we get a string of REJ frames back off the IS via our local Igates from this station

It appears to be a Kenwood D710 . Checking on aprs.fi he is in fact sending REJ frames out all over the world to various stations from his D710 with great frequency.  Check his RAW frames.
What this is doing is just generating excess traffic not just on the IS but on RF likely in many places where IS to RF messaging is working like it likely should.

It begs the question as to Why a D710 in Boston can hear all these messages from around the world presumably on RF ? Also I was not aware it was possible to send REJ packets in response to Bulletins.
Does a D710 send REJ frames in response to new messages once the message buffer is full ? This could explain a few things too.
His local Igates appear to be N3LLO-1 running a WX3in1 and N3LEE-1 also running a Wx3in1 but there are plenty of others involved in the return paths via the IS

I also have seen some APRSIS32 stations APWW11 tocalls popping out with responses to our local bulletins .

Another culprit is AB1OC-10  which is also a D710 is seems in range of N3LLO-3 which is another WX3in1 or a derivative from microsat.com.pl

So another question is this.
Are these Igates in Boston setup to Gate indiscriminately all Messaging from the IS ? Its starting to look that way !!! Without being in Boston on the RF channel I can't tell from here but there appears to be a lot of message traffic centered around Boston from all over the world to and fro .

I can setup a exclusion on my Igate for this station but that does not really fix much. Does someone know who this is and how to contact him ?

Tony VK5AH

First question: Does this happen mostly on Thursdays in UTC time zone?  If so, it's due to the HOTG ANSRVR APRS net.   To read about it, check https://aprsph.net/aprsthursday/

I haven't taken the time to investigate the details you provided because if it is on Thursday, it is likely all WAD - Working As Designed, except for those stations that check into the net and don't bother to clear their message lists which generates the rej messages that you reported.

If you want to hear the excrutiating details about why most things you are observing are justified, just let me now and I'll try to find the time to do a complete analysis.   If you want the really good dirt on the topic, you'll send me an RF capture of the packets that you are seeing on your local RF that you don't think you should be seeing.

You may see some evidence of this outside of Thursdays, but it is noise level compared to the volume of APRS message traffic during the official Thursday net window.  Yesterday they had >500 unique callsigns check into the net from literally all over the planet!

Lynn ,  Thanks for the reply . Ive been capturing packets here. I cant see its directly related to the HOTG ANSRVR net . Basically I can use any client locally here to generate a Bulletin and I get replies and REJ messages from D710 mobiles around Boston every time. Its been happening for days now. I believe after reading the D710 manual it may be related to Menu option 622 , Auto Message Reply.
These periodic bulletins have been going out on local RF for years here now and this unwanted traffic has just started happening in the last week.
It comes down to the questions I posed in the original post.
Specifically Why am I getting replies from stations on RF on the other side of the world that the Messages was not directed to in the first place. This would appear to be due to the fact that the D710s are hearing bulk message traffic gated from the IS to the local RF net in Boston from all over the world. Have a look at the RAW frames from these stations and messaging traffic. Just where and who its going.

Have a look at the messaging and raw traffic on aprs.fi from these stations all around Boston .
WA1PLE-4   Raw frames https://aprs.fi/?c=raw&call=WA1PLE-4+&limit=50&view=normal
AB1OC-10 messages   https://aprs.fi/?c=message&limit=&call=AB1OC-1 
AB10C-10 Raw frames  https://aprs.fi/?c=raw&call=AB1OC-10 
K2VUD-1   https://aprs.fi/?c=raw&call=K2VUD-1

Heres a grab of some typical packets from a Terminal over the last 2 days. The common denominator here is the D710 radios generating the REJ and replys as can be seen from the ToCall field APK102 and they are All nearby Boston trashing the plently of the RF APRS networks all over the world . This is just irresponsible and clearly the operators of this part of the network have put little thought or effort to monitor what they are inflicting on the rest of the world .
I see someone over there is advertising a APRS2-Twitter Gateway also WA1GOV  https://aprs.fi/?c=message&call=WA1PLE-4

 
0:fm VK5RAD-1 to APNU19,WIDE2-1 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5RAD-1 to APNU19,VK5RSC-1*,WIDE2* ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5AH-5 to APJI23,WIDE2-2,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RAD-1 :rejB
 0:fm VK5RAD-1 to APNU19,VK5RHO-1*,WIDE2* ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5RWR-5 to APMI06,VK5RBV-1*,VK5RAD-1*,WIDE2* ctl UI pid F0 len=048
}WA1PLE-4>APK102,TCPIP,VK5RWR-5*::VK5RAD-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RHO-1*,WIDE2-1,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RAD-1 :rejB

 0:fm VK5RHO-1 to APNU19,ADEL2-1 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5AH-5 to APJI23,WIDE2-2,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RAD-1*,WIDE2-1,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RHO-1*,WIDE2-1,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB

0:fm VK5RHO-1 to APNU19,ADEL2-2 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5RHO-1 to APNU19,ADEL2-1 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5RHO-1 to APNU19,ADEL2-1 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5AH-5 to APJI23,WIDE2-2,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RHO-1*,WIDE2-1,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RSC-1*,WIDE2-1,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB

 0:fm VK5AH-5 to APJI23,ADEL2-2 ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ll #/]"5%}=
 0:fm VK5AH-5 to APJI23,ADEL2-1 ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ll #/]"5%}=
 0:fm VK5AH-5 to APJI23,ADEL2* ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ll #/]"5%}=
 0:fm VK5AH-5 to APJI23,ADEL2* ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ll #/]"5%}=

0:fm VK5RHO-1 to APNU19,ADEL2-2 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5RHO-1 to APNU19,ADEL2-1 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5RHO-1 to APNU19,ADEL2-1 ctl UI pid F0 len=070
:BLNB     :Mobiles use WIDE1-1,WIDE2-1 & Home stns ADEL2-2 in Adelaide
 0:fm VK5AH-5 to APJI23,WIDE2-2,NOGATE ctl UI pid F0 len=046
}K2VUD-1>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,WIDE2-2,NOGATE ctl UI pid F0 len=048
}WA1PLE-13>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RHO-1*,WIDE2-1,NOGATE ctl UI pid F0 len=046
}K2VUD-1>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RHO-1*,WIDE2-1,NOGATE ctl UI pid F0 len=048
}WA1PLE-13>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RAD-1*,WIDE2-1,NOGATE ctl UI pid F0 len=046
}K2VUD-1>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,WIDE2-2,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RAD-1*,WIDE2-1,NOGATE ctl UI pid F0 len=048
}WA1PLE-13>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5EX-1 to APRS,WIDE2-2 ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5EX-1*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RHO-1*,WIDE2-1,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5EX-1 to APRS,VK5RHO-1*,WIDE2-1 ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5EX-1*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,VK5RAD-1*,VK5RSC-1*,WIDE2*,NOGATE ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5AH-5*::VK5RHO-1 :rejB
 0:fm VK5EX-1 to APRS,VK5RAD-1*,VK5RSC-1*,WIDE2* ctl UI pid F0 len=047
}WA1PLE-4>APK102,TCPIP,VK5EX-1*::VK5RHO-1 :rejB
 0:fm VK5AH-5 to APJI23,ADEL2-2 ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ml #/]"55}=
 0:fm VK5AH-5 to APJI23,ADEL2-1 ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ml #/]"55}=
 0:fm VK5AH-5 to APJI23,ADEL2-1 ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ml #/]"55}=
 0:fm VK5AH-5 to APJI23,ADEL2-1 ctl UI pid F0 len=046
}WA1PLE-4>4R0X3V,TCPIP,VK5AH-5*:`c)Ml #/]"55}=

Tony VK5AH

Here is yet another one thats popped up on RF here since the last report AB1II-1    https://aprs.fi/?c=raw&call=AB1II-1
Looks like yet another Kenwood D710 in Boston sending REJs and replies all over the world .

Tony VK5AH