> Where does one stand in the situation where one's mail processing
> program (in this case Squish) is quite happy to pass on certain
> messages but when they reach a certain other node (via intermediate
> nodes), the target's home-grown mail processor barfs over them as
> non-conforming to spec?

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

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

DN> It is not "non-conforming" to be tolerant of errors or
specifications 
DN> outside of the accepted standards. It *is* non-conforming to generate and 
DN> inject malformed data in the first place.

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 technical 
DN> specifications, then that one node has a perfectly valid complaint. Whether 

That's me!

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

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

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

That's you.

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

That was done.

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

Like I said, a PC-able offence.

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

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

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

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

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

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

BFN.  Paul.

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

---