HS>> But why is FRODO spitting out invalid FTS-1 mail? Frodo checks for
HS>> nulls in the EMSI storage of the key, where it is less important,
HS>> why not do it also in the PID?

ML> see above... it's not joho's fault... it is the fault of the key
ML> generator putting a null in when it shouldn't ;-)

Right, what I am saying is that Joho watches for NULLS in the EMSI string.
He changes it there correctly. He should watch for it in the PID as well.

HS>> You're asking me to add special logic to honor Frodo's registration
HS>> logic? I don't understand your request.  The message was KILLED as a
HS>> empty message because of the null. I am not going to go into my

ML> i bounce them when i catch them... it's easy enough to do... since 
ML> there is generally no tear line or origin line... but see? that's in 
ML> echomail where it is easier to catch them... netmail is much harder 
ML> and you didn't state if this problem was netmail or echomail based... 
ML> i assumed echomail...

No it was netmail.  As an echo it would of kicked out because of lack of
seen-bys and path.

ML> when are you going to comply with or drop support for FSC-0046?

Your software already corrects it for me by email tampering with the
tear lines.

When is your software going to stop spitting out BAD Addresses for people
to use which has a MUCH MORE drastic communications effect in Fidonet?
--- Platinum Xpress/386/Wildcat! v1.2j