Hello All!

I get all of the Fido echo areas from Mark Lewis at 1:3436/12.

Over the last month or so a number of bad packets arrive with the content from one poster Dan Richter at 1:317/3, who consistently sends file announcements that just get larger and larger using his own software RCS.

I have sent a netmail to him regarding this, but have not received any response.
I also contacted Mark, who has advised me that his system send out everything received regardless without verifying content.

The most likely cause of this is that Dan is not clearing down the input source
(copy of received tic files) for it (RCS) and this in turn (may be) is producing bad content in the date fields of the messages when packing.

I have the same s/w here but it is not in operation and it clearing removes these tic files used as input to it once processed, so to work you have to have
a script that copies over received .tic files to another folder for input to RCS before the main system processes them so I do not know what is wrong with Dans system that is causing repeats of files to be re-announced - like months worth.

My system always checks for valid mail packet content, and rejects any that fail, needless to say the entire packet is rejected.

This helps to prevent rubbish data getting into the system that would get sent to you all.

As near as I can tell using pktview to examine these bad packets, you are not missing anything and no I do not look at them all :)


Vincent

--- Mageia Linux v8 X64/Mbse v1.0.8/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Over the last month or so a number of bad packets arrive with the content from one poster Dan Richter at 1:317/3, who consistently sends file announcements that just get larger and larger using his own software RCS.

The packets that originate at 1:317/3 are valid, although they are large. A little over 400k the last time I looked.

When those message pass through some systems they get borked.

I recieve those messages from 1:317/3 and they toss just fine. For every one of those good messages I get two bad ones that passed through a node that can't handle that message size. It sends out two messages without header info or MSGID.

I have sent a netmail to him regarding this, but have not received any response. I also contacted Mark, who has advised me that his system send out everything received regardless without verifying content.

Technically there is nothing wrong with the messages that originate at 1:317/3, they are getting borked somewhere enroute.

The most likely cause of this is that Dan is not clearing down the input source (copy of received tic files) for it (RCS) and this in turn (may be)
is producing bad content in the date fields of the messages when packing.

I think you are right about this. His new file announce message states over 500 new files! If Dan could fix that then the message size would drop significantly, although the message size isn't really the issue here.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hello Alan!

Tuesday November 22 2022 23:53, you wrote to me:

Funny enough he is sending these also through ALLFIX_FILE and I notice the last
was 241k in size and that is fine although I do wonder why my mailer is not slicing them in 60k chunks but there again it might be a bug in the mailer
code i.e., just not doing so :)

Personally, I don't have a problem with larger messages but larger sizes do indicate a possible problem some where such as in this case where the announcements are repeated continuously.

Vince

Over the last month or so a number of bad packets arrive with the
content from one poster Dan Richter at 1:317/3, who consistently
sends file announcements that just get larger and larger using his
own software RCS.

The packets that originate at 1:317/3 are valid, although they are
large. A little over 400k the last time I looked.

When those message pass through some systems they get borked.

I recieve those messages from 1:317/3 and they toss just fine. For
every one of those good messages I get two bad ones that passed
through a node that can't handle that message size. It sends out two messages without header info or MSGID.

I have sent a netmail to him regarding this, but have not received
any response. I also contacted Mark, who has advised me that his
system send out everything received regardless without verifying
content.

Technically there is nothing wrong with the messages that originate at 1:317/3, they are getting borked somewhere enroute.

The most likely cause of this is that Dan is not clearing down the
input source (copy of received tic files) for it (RCS) and this in
turn (may be) is producing bad content in the date fields of the
messages when packing.

I think you are right about this. His new file announce message states
over 500 new files! If Dan could fix that then the message size would
drop significantly, although the message size isn't really the issue
here.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.8/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)