1. Forum
  2. FidoNet
  3. Z2REGION25

  • For information

    From Vincent Coen@2:250/1 to All on Tue Nov 22 15:22:54 2022
    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)
  • From Alan Ianson@1:153/757 to Vincent Coen on Tue Nov 22 23:53:38 2022
    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)
  • From Vincent Coen@2:250/1 to Alan Ianson on Wed Nov 23 16:27:39 2022
    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)