Paul, at 23:30 on Jun 21 1996, you wrote to David Drummond ...

>> Where does one stand in the situation where one's mail 
. . .[chomp]. . .

DN>> Then the system where it "barfs" has a problem with the 
DN>> person who originated or otherwise mangled the mail in the 
DN>> first place (which may not actually be the originating 
DN>> system, but for the sake of argument here we will assume 
DN>> that it is).

PE> In this case it is, 3:640/305 is the system generating the 
PE> out of spec message.

Was it?  Didn't it originate from Russell's?

DN>> It is not "non-conforming" to be tolerant of errors or 
. . .[chomp]. . .

PE> Oh, how surprising.

>> Policy says my software "must not cause problems to the
>> network".  The only apparent problems are caused to the
>> home-made processor at ONE node.

DN>> If the messages causing the problem are outside of FidoNet 
DN>> technical specifications, then that one node has a 
DN>> perfectly valid complaint. Whether 

PE> That's me!

DN>> or not they will get anywhere with it depends on how they 
DN>> go about approaching the people involved. Contacting the 
DN>> originating system first would be a good idea - some people 
DN>> are not aware that an incorrectly configured software 
DN>> package can cause problems on the network.

PE> Exactly what I did, inform you that you were putting out 
PE> out-of-spec messages, to which you replied "Well Squish 
PE> didn't care about it, and it's far more popular than your 
PE> heap of shit" rather than a more helpful "Oh, sorry about 
PE> that - thanks for pointing it out, I'll go and fix it".  
PE> Actually, fortunately your points are far more responsible 
PE> than you anyway, and basically did that after being
PE> prompted.

Considering the point generated the message in the first place, it was the
least he could do.

DN>> However, as I indicated above, the responsibility for the 
DN>> data is still firmly with the the originating system. If 
DN>> there is any complaint to be 

PE> That's you.

Only if there is a valid complaint

DN>> made over this, then it should be initially to that node, 
DN>> and if you get 

PE> That was done.

NOT  - I received a rude robot message.

DN>> nowhere, then to the node's NC. 

PE> Like I said, a PC-able offence.

Try it . . .

DN>> Whether a formal policy complaint is 
DN>> appropriate depends entirely on the situation - most 
DN>> reasonable people are perfectly happy to fix any problems 
DN>> if you point it out politely and don't 

PE> Yeah, but what happens when you get an unreasonable person?  
PE> You point it out to them politely and they tell you your 
PE> software is a heap of shit.

You point it out by sending a robot message which states 'your message is
out of spec" - no explanation of how or what spec?

DN>> give them cause to become defensive; e.g. threats right at 
DN>> the start get nowhere very fast and usually escalate for no 
DN>> good cause. Nevertheless, 

PE> No threats at the start.  Just a simple pointing out that 
PE> messages from your system were out of spec. 

DN>> that does not alter the fact that the originating system is 
DN>> causing problems on the network, and fixing it is still 
DN>> that system's responsibility.

PE> :-)  I was *real* interested in the answer to that question 
PE> of yours David.  The answer made my day, just as it probably 
PE> ruined yours.  :-)  Shit, I'm almost glad I voted for him!  
PE> It's amazing where you can find friends these days.  Just 
PE> when I was told by a highly reliable, extremely knowledgable 
PE> source, that there was no way a PC against a node for 
PE> generating out-of-spec messages could ever possibly succeed 
PE> under any circumstances.  :-)

PE> BFN.  Paul.

PE> P.S. You will see that all the hair-splitting over "serious" 
PE> in "serious network problems" has now been said as "network 
PE> problems" even when it was emphasised that there was only ONE 
PE> node affected.

The network was not involved in the alleged non-compliant message Paul. 
The conference is a closed conference that just happens to be moved by
fidinet technology.  

David
@EOT:

--- Msgedsq/2 3.10