> 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
DN> who originated or otherwise mangled the mail in the first place
DN> (which may not actually be the originating system, but for the
DN> sake of argument here we will assume that it is).

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

You can claim that if you like, its nothing like as absolute as you claim tho.

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
DN> and inject malformed data in the first place.

PE> Oh, how surprising.

Happens to be the truth, PARTICULARLY when the SEEN-BYs
aint actually rigidly specified. You cant actually proclaim
that those SEEN-BYs were actually 'out of spec'.

> 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.

Which is choosing to barf on a SEEN-BY which Squish has had the sense
to handle gracefully, just like YOU choose to handle the dates which
actually ARE out of spec gracefully yourself. You cant actually claim
that those messages actually were 'causing problems to the network' when
you arent actually using the SEEN-BYs that you claim were out of spec.

DN> If the messages causing the problem are
DN> outside of FidoNet technical specifications,

You havent actually established that they were.

DN> then that one node has a perfectly valid complaint.

PE> That's me!

Nope, coz you havent actually established that they
were 'outside of FidoNet technical specifications'

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

PE> Exactly what I did, inform you that you
PE> were putting out out-of-spec messages,

You havent actually established that they actually
were. Just claimed that. And clearly Squish doesnt
think that they were out of spec enough to reject them.

PE> to which you replied "Well Squish didn't care about
PE> it, and it's far more popular than your heap of shit"

He does have a point when the SEEN-BY aint actually being used.

PE> rather than a more helpful "Oh, sorry about that - thanks for pointing it
PE> out, I'll go and fix it". Actually, fortunately your points are far more
PE> responsible than you anyway, and basically did that after being prompted.

Thats an entirely separate issue to whether they were
actually out of spec and whether that was essential tho.

DN> However, as I indicated above, the responsibility for
DN> the data is still firmly with the the originating system.

PE> That's you.

ONLY if they are actually 'causing a problem for the network'.
You havent actually established that they are.

DN> If there is any complaint to be made over
DN> this, then it should be initially to that node,

PE> That was done.

DN> and if you get nowhere, then to the node's NC.

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

Soorree, he AINT talking about a PC there, just a complaint
to the NC instead of the previous one to the node.

DN> Whether a formal policy complaint is
DN> appropriate depends entirely on the situation -

And THIS is where he is actually talking about a PC.

DN> most reasonable people are perfectly happy to
DN> fix any problems if you point it out politely

PE> Yeah, but what happens when you get an unreasonable person?

You havent actually established that they were out of spec.

PE> You point it out to them politely and they
PE> tell you your software is a heap of shit.

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

PE> No threats at the start.

Pigs arse there werent, you said right from the start
that it was a PCable offense. You were in fact doing
PRECISELY what Nugent was an undesirable approach.

PE> Just a simple pointing out that messages from your system were out of spec.

You havent actually established that they WERE and you DID wave
around the your claim that it was a PCable offense. Which leaves
the clear implication that if it isnt fixed, you may choose to PC.

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

PE> :-)

No point in grinning yet, you aint established
that it was 'causing problems for the network'

PE> I was *real* interested in the answer to that question of yours David.
PE> The answer made my day, just as it probably ruined yours. :-)

Shouldnt have, he aint actually agreeing with you.

PE> Shit, I'm almost glad I voted for him!  It's
PE> amazing where you can find friends these days.

Dont get too excited, not only hasnt he agreed with you, he has
hasnt even bothered to mention that you can get shafted yourself
if you choose to PC when you dont have sufficient grounds to do that.

PARTICULARLY when you have a reputation for mindlessly PCing on trivial
breaches of what you claim are 'the specs' or threatening to do that.

The date problem is much more clearly breaching 'the specs'
and even you have likely noticed that systems generating
those have NOT been PCed and forced to fix that problem.
So it aint even as simple as Nugent stated there either.

PE> Just when I was told by a highly reliable, extremely knowledgable

(Continued to next message)
@EOT:

---